Re: Issue with non-scattered rx in ixgbe and i40e when mbuf private area size is odd

2015-07-30 13:22, Olivier MATZ:

On 07/30/2015 11:43 AM, Ananyev, Konstantin wrote:

quoted

From: Olivier MATZ [mailto:olivier.matz@6wind.com]

quoted

On 07/30/2015 11:00 AM, Ananyev, Konstantin wrote:

quoted

From: Olivier MATZ [mailto:olivier.matz@6wind.com]

quoted

On 07/29/2015 10:24 PM, Zhang, Helin wrote:

quoted

The similar situation in i40e, as explained by Konstantin.
As header split hasn't been supported by DPDK till now. It would be better to put the header address in RX descriptor to 0.
But in the future, during header split enabling. We may need to pay extra attention to that. As at least x710 datasheet said

specifically as below.

quoted

"The header address should be set by the software to an even number (word aligned address)". We may need to find a way to

ensure that during mempool/mbuf allocation.

Indeed it would be good to force the priv_size to be aligned.

The priv_size could be aligned automatically in
rte_pktmbuf_pool_create(). The only possible problem I could see
is that it would break applications that access to the data buffer
by doing (sizeof(mbuf) + sizeof(priv)), which is probably not the
best thing to do (I didn't find any applications like this in dpdk).

Might be just make rte_pktmbuf_pool_create() fail if input priv_size % MIN_ALIGN != 0?

Hmm maybe it would break more applications: an odd priv_size is
probably rare, but a priv_size that is not aligned to 8 bytes is
maybe more common.

My thought was that rte_mempool_create() was just introduced in 2.1,
so if we add extra requirement for the input parameter now -
there would be no ABI breakage, and not many people started to use it already.
For me just seems a bit easier and more straightforward then silent alignment -
user would not have wrong assumptions here.
Though if you think that a silent alignment would be more convenient
for most users - I wouldn't insist.

Yes, I agree on the principle, but it depends whether this fix
is integrated for 2.1 or not.
I think it may already be a bit late for that, especially as it
is not a very critical bug.

Thomas, what do you think?

It is a fix.
Adding a doc comment, an assert and an alignment constraint or a new automatic
alignment in the not yet released function shouldn't hurt.
A patch would be welcome for 2.1. Thanks