DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: dev@dpdk.org
Subject: [dpdk-dev] [PATCH] ixgbe: fix clang compile - remove truncation errors
Date: Fri, 28 Nov 2014 15:31:00 +0000	[thread overview]
Message-ID: <1417188660-14587-1-git-send-email-bruce.richardson@intel.com> (raw)

When compiling with clang, errors were being emitted due to truncation
of values when assigning to the tx_offload_mask bit fields.

dpdk.org/lib/librte_pmd_ixgbe/ixgbe_rxtx.c:404:27: fatal error: implicit truncation from 'int' to bitfield changes value from -1 to 127 [-Wbitfield-constant-conversion]
		    tx_offload_mask.l2_len = ~0;

The fix proposed here is to define a static const value of the same type
with all fields set to 1s, and use that instead of constants for assigning to.

Other options would be to explicitily define the suitable constants that
would not truncate for each individual field e.g. 0x7f for l2_len, 0x1FF
for l3_len, etc., but this solution here has the advantage that it works
without any changes to values if the field sizes are ever modified.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 8559ef6..4f71194 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
@@ -367,6 +367,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
 		volatile struct ixgbe_adv_tx_context_desc *ctx_txd,
 		uint64_t ol_flags, union ixgbe_tx_offload tx_offload)
 {
+	static const union ixgbe_tx_offload offload_allones = { .data = ~0 };
 	uint32_t type_tucmd_mlhl;
 	uint32_t mss_l4len_idx = 0;
 	uint32_t ctx_idx;
@@ -381,7 +382,7 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
 	mss_l4len_idx |= (ctx_idx << IXGBE_ADVTXD_IDX_SHIFT);
 
 	if (ol_flags & PKT_TX_VLAN_PKT) {
-		tx_offload_mask.vlan_tci = ~0;
+		tx_offload_mask.vlan_tci = offload_allones.vlan_tci;
 	}
 
 	/* check if TCP segmentation required for this packet */
@@ -391,17 +392,17 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
 			IXGBE_ADVTXD_TUCMD_L4T_TCP |
 			IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
 
-		tx_offload_mask.l2_len = ~0;
-		tx_offload_mask.l3_len = ~0;
-		tx_offload_mask.l4_len = ~0;
-		tx_offload_mask.tso_segsz = ~0;
+		tx_offload_mask.l2_len = offload_allones.l2_len;
+		tx_offload_mask.l3_len = offload_allones.l3_len;
+		tx_offload_mask.l4_len = offload_allones.l4_len;
+		tx_offload_mask.tso_segsz = offload_allones.tso_segsz;
 		mss_l4len_idx |= tx_offload.tso_segsz << IXGBE_ADVTXD_MSS_SHIFT;
 		mss_l4len_idx |= tx_offload.l4_len << IXGBE_ADVTXD_L4LEN_SHIFT;
 	} else { /* no TSO, check if hardware checksum is needed */
 		if (ol_flags & PKT_TX_IP_CKSUM) {
 			type_tucmd_mlhl = IXGBE_ADVTXD_TUCMD_IPV4;
-			tx_offload_mask.l2_len = ~0;
-			tx_offload_mask.l3_len = ~0;
+			tx_offload_mask.l2_len = offload_allones.l2_len;
+			tx_offload_mask.l3_len = offload_allones.l3_len;
 		}
 
 		switch (ol_flags & PKT_TX_L4_MASK) {
@@ -409,23 +410,23 @@ ixgbe_set_xmit_ctx(struct igb_tx_queue* txq,
 			type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_UDP |
 				IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
 			mss_l4len_idx |= sizeof(struct udp_hdr) << IXGBE_ADVTXD_L4LEN_SHIFT;
-			tx_offload_mask.l2_len = ~0;
-			tx_offload_mask.l3_len = ~0;
+			tx_offload_mask.l2_len = offload_allones.l2_len;
+			tx_offload_mask.l3_len = offload_allones.l3_len;
 			break;
 		case PKT_TX_TCP_CKSUM:
 			type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_TCP |
 				IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
 			mss_l4len_idx |= sizeof(struct tcp_hdr) << IXGBE_ADVTXD_L4LEN_SHIFT;
-			tx_offload_mask.l2_len = ~0;
-			tx_offload_mask.l3_len = ~0;
-			tx_offload_mask.l4_len = ~0;
+			tx_offload_mask.l2_len = offload_allones.l2_len;
+			tx_offload_mask.l3_len = offload_allones.l3_len;
+			tx_offload_mask.l4_len = offload_allones.l4_len;
 			break;
 		case PKT_TX_SCTP_CKSUM:
 			type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_SCTP |
 				IXGBE_ADVTXD_DTYP_CTXT | IXGBE_ADVTXD_DCMD_DEXT;
 			mss_l4len_idx |= sizeof(struct sctp_hdr) << IXGBE_ADVTXD_L4LEN_SHIFT;
-			tx_offload_mask.l2_len = ~0;
-			tx_offload_mask.l3_len = ~0;
+			tx_offload_mask.l2_len = offload_allones.l2_len;
+			tx_offload_mask.l3_len = offload_allones.l3_len;
 			break;
 		default:
 			type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_RSV |
-- 
2.1.0

             reply	other threads:[~2014-11-28 15:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-28 15:31 Bruce Richardson [this message]
2014-11-30  1:05 ` Neil Horman
2014-12-01  9:09   ` Olivier MATZ
2014-12-01  9:48     ` Bruce Richardson
2014-12-01  9:59       ` Olivier MATZ
2014-12-01 11:18     ` Neil Horman
2014-12-01 11:24       ` Bruce Richardson
2014-12-01 14:25         ` Neil Horman
2014-12-01 14:36           ` Bruce Richardson
2014-12-01 15:18             ` Neil Horman
2014-12-01 15:24               ` Bruce Richardson
2014-12-01 16:35                 ` Neil Horman
2014-12-01 16:44                   ` Bruce Richardson
2014-12-01 17:16                     ` Neil Horman
2014-12-01 21:55                       ` Olivier MATZ
2014-12-02 11:32                         ` Neil Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1417188660-14587-1-git-send-email-bruce.richardson@intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).