On 6/27/16, 4:05 AM, "Thomas Monjalon" <thomas.monjalon at 6wind.com> wrote:
>2016-06-27 10:27, Olivier Matz: >> On 06/27/2016 10:21 AM, Ananyev, Konstantin wrote: >> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Keith Wiles >> >> Move the next pointer to the first cacheline of the rte_mbuf structure >> >> and move the offload values to the second cacheline to give better >> >> performance to applications using chained mbufs. >> >> >> >> Enabled by a configuration option CONFIG_RTE_MBUF_CHAIN_FRIENDLY default >> >> is set to No. >> > >> > First, it would make ixgbe and i40e vector RX functions to work >> > incorrectly. >> > Second, I don't think we can afford to allow people swap mbuf fields in >> > the way they like. >> > Otherwise we'll end-up with totally unmaintainable code pretty soon. >> > So NACK. >> >> +1 > >To be more precise, the arrangement of fields in rte_mbuf is open >to debate and changes. >There is a recent discussion here: > http://dpdk.org/ml/archives/dev/2016-May/039483.html > >I think we must try to improve few things in mbuf during the 16.11 cycle. >But it must not be allowed to have a build option to adapt this structure >or any other API. There is only one DPDK API for a given version. I just received a private email thread on this one and it appears it is not a big of a problem as was stated before. ? So yes we can reject this one. Someone rejected these in patchwork already, which I expected I would be the one to reject the patches. Is this not the case? I understand if the patch just hangs round, but I would have expected after the list rejected the patch I would be the one to reject the patches. I try to keep up with my patches and rejecting a patch before I have a chance to do so seems a bit harsh to me. >