[dpdk-dev,v6,5/8] rte_mbuf.h: avoid implicit demotion in 64-bit arith

Message ID 152686807841.58694.11466927240402649305.stgit@localhost.localdomain (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/Intel-compilation success Compilation OK

Commit Message

Andy Green May 21, 2018, 2:01 a.m. UTC
  /projects/lagopus/src/dpdk/build/include/rte_mbuf.h:
In function 'rte_validate_tx_offload':
/projects/lagopus/src/dpdk/build/include/rte_mbuf.h:
2112:19: warning: conversion to 'uint64_t'
{aka 'long unsigned int'} from 'int' may change the
sign of the result [-Wsign-conversion]
  inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
                   ^~

  uint64_t inner_l3_offset...

  /* fields for TX offloading of tunnels */
  uint64_t outer_l3_len:9; /**< Outer L3 (IP) Hdr Length. */
  uint64_t outer_l2_len:7; /**< Outer L2 (MAC) Hdr Length. */

We want to do the arithmetic entirely in uint64_t
space, but there is an implicit demotion to int created by
the +=.  Remove the +=.

Fixes: 4fb7e803eb ("ethdev: add Tx preparation")
Signed-off-by: Andy Green <andy@warmcat.com>
---
 lib/librte_mbuf/rte_mbuf.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
  

Comments

Bruce Richardson May 21, 2018, 12:27 p.m. UTC | #1
On Mon, May 21, 2018 at 10:01:18AM +0800, Andy Green wrote:
> /projects/lagopus/src/dpdk/build/include/rte_mbuf.h:
> In function 'rte_validate_tx_offload':
> /projects/lagopus/src/dpdk/build/include/rte_mbuf.h:
> 2112:19: warning: conversion to 'uint64_t'
> {aka 'long unsigned int'} from 'int' may change the
> sign of the result [-Wsign-conversion]
>   inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
>                    ^~
> 
>   uint64_t inner_l3_offset...
> 
>   /* fields for TX offloading of tunnels */
>   uint64_t outer_l3_len:9; /**< Outer L3 (IP) Hdr Length. */
>   uint64_t outer_l2_len:7; /**< Outer L2 (MAC) Hdr Length. */
> 
> We want to do the arithmetic entirely in uint64_t
> space, but there is an implicit demotion to int created by
> the +=.  Remove the +=.
> 
> Fixes: 4fb7e803eb ("ethdev: add Tx preparation")
> Signed-off-by: Andy Green <andy@warmcat.com>
> ---
>  lib/librte_mbuf/rte_mbuf.h |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

Fix looks ok, but given that it's non-obvious why += doesn't work, I think
it would be good to put a comment in explaining it. Otherwise I could see
someone changing this back in a later patch, because the problem doesn't
arise with regular DPDK compiles 

Acked-by: Bruce Richardson <bruce.richardson@intel.com>
  
Andy Green May 22, 2018, 1:29 a.m. UTC | #2
On 05/21/2018 08:27 PM, Bruce Richardson wrote:
> On Mon, May 21, 2018 at 10:01:18AM +0800, Andy Green wrote:
>> /projects/lagopus/src/dpdk/build/include/rte_mbuf.h:
>> In function 'rte_validate_tx_offload':
>> /projects/lagopus/src/dpdk/build/include/rte_mbuf.h:
>> 2112:19: warning: conversion to 'uint64_t'
>> {aka 'long unsigned int'} from 'int' may change the
>> sign of the result [-Wsign-conversion]
>>    inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
>>                     ^~
>>
>>    uint64_t inner_l3_offset...
>>
>>    /* fields for TX offloading of tunnels */
>>    uint64_t outer_l3_len:9; /**< Outer L3 (IP) Hdr Length. */
>>    uint64_t outer_l2_len:7; /**< Outer L2 (MAC) Hdr Length. */
>>
>> We want to do the arithmetic entirely in uint64_t
>> space, but there is an implicit demotion to int created by
>> the +=.  Remove the +=.
>>
>> Fixes: 4fb7e803eb ("ethdev: add Tx preparation")
>> Signed-off-by: Andy Green <andy@warmcat.com>
>> ---
>>   lib/librte_mbuf/rte_mbuf.h |    3 ++-
>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>
> 
> Fix looks ok, but given that it's non-obvious why += doesn't work, I think
> it would be good to put a comment in explaining it. Otherwise I could see

I commnented these and the related stanzas in the second patch you 
suggested the comment in v7.

> someone changing this back in a later patch, because the problem doesn't
> arise with regular DPDK compiles

Yes the header apis are not actually used just building dpdk, so you 
don't see any problem.  But the problem will come as soon as you try to 
actually build something else against dpdk + gcc8.1.

-Andy

> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
>
  

Patch

diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 76e37a2f8..55fba3b14 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -2112,7 +2112,8 @@  rte_validate_tx_offload(const struct rte_mbuf *m)
 		return 0;
 
 	if (ol_flags & PKT_TX_OUTER_IP_CKSUM)
-		inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
+		inner_l3_offset = inner_l3_offset + m->outer_l2_len +
+						  m->outer_l3_len;
 
 	/* Headers are fragmented */
 	if (rte_pktmbuf_data_len(m) < inner_l3_offset + m->l3_len + m->l4_len)