2016-06-27 13:06, Wiles, Keith: > > 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.
Yes it's me, sorry I've been quick when I've seen the first 2 comments.
