Re: [dpdk-dev] [PATCH 1/1] mbuf: move pool pointer in first half

[Thomas Monjalon <thomas@monjalon.net>]

09/11/2020 14:35, Jerin Jacob:
> On Mon, Nov 9, 2020 at 6:29 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 09/11/2020 13:01, Jerin Jacob:
> > > Hi @Thomas Monjalon
> > >
> > > Any specific reason why you removed the static assert from octeontx2.
> >
> > I have a build failure when cross-compiling for octeontx2.

I was wrong here.

> I am trying the below command, I am not able to see any issue
> meson build --cross-file config/arm/arm64_octeontx2_linux_gcc
> 
> Are you facing the issue with 32bit? Could you share the steps to
> reproduce and gcc version?

Oh you're right, the issue was with 32-bit build,
sorry for the confusion.

> --- a/drivers/net/octeontx2/otx2_ethdev.c
> +++ b/drivers/net/octeontx2/otx2_ethdev.c
> @@ -749,7 +749,7 @@ nix_tx_offload_flags(struct rte_eth_dev *eth_dev)
>         RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, pkt_len) !=
>                          offsetof(struct rte_mbuf, ol_flags) + 12);
>         RTE_BUILD_BUG_ON(offsetof(struct rte_mbuf, tx_offload) !=
> -                        offsetof(struct rte_mbuf, pool) + 2 * sizeof(void *));
> +                        offsetof(struct rte_mbuf, pool) + 2 * sizeof(uint64_t));

The actual "fix" is
offsetof(struct rte_mbuf, pool) + sizeof(uint64_t) + sizeof(void *)

I don't understand the octeontx2 vector code.
Please check what is the impact of this offset change.
BTW, is 32-bit build really supported with octeontx2?