| Message ID | 20201109133005.67035-1-ferruh.yigit@intel.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | Ferruh Yigit |
| Headers | show |
| Series |
|
| Related | show |
| Context | Check | Description |
|---|---|---|
| ci/Intel-compilation | success | Compilation OK |
| ci/iol-mellanox-Performance | success | Performance Testing PASS |
| ci/travis-robot | success | Travis build: passed |
| ci/iol-intel-Performance | success | Performance Testing PASS |
| ci/iol-intel-Functional | success | Functional Testing PASS |
| ci/iol-testing | success | Testing PASS |
| ci/iol-broadcom-Performance | success | Performance Testing PASS |
| ci/iol-broadcom-Functional | success | Functional Testing PASS |
| ci/checkpatch | success | coding style OK |
> > 'uint64_t' is used to hold the pointer, for 32-bits build this > assumption is wrong and giving following build error: > > rte_eth_af_xdp.c: In function ‘xdp_umem_configure’: > rte_eth_af_xdp.c:970:15: > error: cast to pointer from integer of different size > [-Werror=int-to-pointer-cast] > 970 | base_addr = (void *)get_base_addr(mb_pool, &align); > | ^ > > Replacing the 'uint64_t' return type of the 'get_base_addr()' to the > 'uintptr_t'. > Although not sure if the overall logic supports the 32-bits, using > 'uintptr_t' should be safe both for 64/32 bits. > > Fixes: d8a210774e1d ("net/af_xdp: support unaligned umem chunks") > Cc: stable@dpdk.org > > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com> > > --- > > Hi Ciara, > > I am not sure if 32-bit is supported for the af_xdp, but even not does > this change make sense for the 64-bits? Hi Ferruh, LGTM. I've tested it for 64bit and all looks good to me. Tested-by: Ciara Loftus <ciara.loftus@intel.com> I've been looking into 32-bit compatibility and will submit a patch for at least the docs when I've verified what works. Thanks, Ciara > --- > drivers/net/af_xdp/rte_eth_af_xdp.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c > b/drivers/net/af_xdp/rte_eth_af_xdp.c > index 4076ff797c..2c7892bd7e 100644 > --- a/drivers/net/af_xdp/rte_eth_af_xdp.c > +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c > @@ -910,13 +910,13 @@ eth_link_update(struct rte_eth_dev *dev > __rte_unused, > } > > #if defined(XDP_UMEM_UNALIGNED_CHUNK_FLAG) > -static inline uint64_t get_base_addr(struct rte_mempool *mp, uint64_t > *align) > +static inline uintptr_t get_base_addr(struct rte_mempool *mp, uint64_t > *align) > { > struct rte_mempool_memhdr *memhdr; > - uint64_t memhdr_addr, aligned_addr; > + uintptr_t memhdr_addr, aligned_addr; > > memhdr = STAILQ_FIRST(&mp->mem_list); > - memhdr_addr = (uint64_t)memhdr->addr; > + memhdr_addr = (uintptr_t)memhdr->addr; > aligned_addr = memhdr_addr & ~(getpagesize() - 1); > *align = memhdr_addr - aligned_addr; > > -- > 2.26.2
On 11/9/2020 6:00 PM, Loftus, Ciara wrote: >> >> 'uint64_t' is used to hold the pointer, for 32-bits build this >> assumption is wrong and giving following build error: >> >> rte_eth_af_xdp.c: In function ‘xdp_umem_configure’: >> rte_eth_af_xdp.c:970:15: >> error: cast to pointer from integer of different size >> [-Werror=int-to-pointer-cast] >> 970 | base_addr = (void *)get_base_addr(mb_pool, &align); >> | ^ >> >> Replacing the 'uint64_t' return type of the 'get_base_addr()' to the >> 'uintptr_t'. >> Although not sure if the overall logic supports the 32-bits, using >> 'uintptr_t' should be safe both for 64/32 bits. >> >> Fixes: d8a210774e1d ("net/af_xdp: support unaligned umem chunks") >> Cc: stable@dpdk.org >> >> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com> >> >> --- >> >> Hi Ciara, >> >> I am not sure if 32-bit is supported for the af_xdp, but even not does >> this change make sense for the 64-bits? > > Hi Ferruh, > > LGTM. I've tested it for 64bit and all looks good to me. > > Tested-by: Ciara Loftus <ciara.loftus@intel.com> > > I've been looking into 32-bit compatibility and will submit a patch for at least the docs when I've verified what works. > Applied to dpdk-next-net/main, thanks.
diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c b/drivers/net/af_xdp/rte_eth_af_xdp.c index 4076ff797c..2c7892bd7e 100644 --- a/drivers/net/af_xdp/rte_eth_af_xdp.c +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c @@ -910,13 +910,13 @@ eth_link_update(struct rte_eth_dev *dev __rte_unused, } #if defined(XDP_UMEM_UNALIGNED_CHUNK_FLAG) -static inline uint64_t get_base_addr(struct rte_mempool *mp, uint64_t *align) +static inline uintptr_t get_base_addr(struct rte_mempool *mp, uint64_t *align) { struct rte_mempool_memhdr *memhdr; - uint64_t memhdr_addr, aligned_addr; + uintptr_t memhdr_addr, aligned_addr; memhdr = STAILQ_FIRST(&mp->mem_list); - memhdr_addr = (uint64_t)memhdr->addr; + memhdr_addr = (uintptr_t)memhdr->addr; aligned_addr = memhdr_addr & ~(getpagesize() - 1); *align = memhdr_addr - aligned_addr;
'uint64_t' is used to hold the pointer, for 32-bits build this assumption is wrong and giving following build error: rte_eth_af_xdp.c: In function ‘xdp_umem_configure’: rte_eth_af_xdp.c:970:15: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast] 970 | base_addr = (void *)get_base_addr(mb_pool, &align); | ^ Replacing the 'uint64_t' return type of the 'get_base_addr()' to the 'uintptr_t'. Although not sure if the overall logic supports the 32-bits, using 'uintptr_t' should be safe both for 64/32 bits. Fixes: d8a210774e1d ("net/af_xdp: support unaligned umem chunks") Cc: stable@dpdk.org Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com> --- Hi Ciara, I am not sure if 32-bit is supported for the af_xdp, but even not does this change make sense for the 64-bits? --- drivers/net/af_xdp/rte_eth_af_xdp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)