Hi, I've re-read the entire thread. If I understand correctly, the root problem was (in initial patch):
> m1 = rte_pktmbuf_alloc(mp); > rte_pktmbuf_append(m1, 500); > m2 = rte_pktmbuf_alloc(mp); > rte_pktmbuf_append(m2, 500); > rte_pktmbuf_chain(m1, m2); > m0 = rte_pktmbuf_alloc(mp); > rte_pktmbuf_append(m0, 500); > rte_pktmbuf_chain(m0, m1); > > As rte_pktmbuf_chain() does not reset nb_seg in the initial m1 segment > (this is not required), after this code the mbuf chain have 3 > segments: > - m0: next=m1, nb_seg=3 > - m1: next=m2, nb_seg=2 > - m2: next=NULL, nb_seg=1 > The proposed fix was to ALWAYS set next and nb_seg fields on mbuf_free(), regardless next field content. That would perform unconditional write to mbuf, and might affect the configurations, where are no multi-segment packets at al. mbuf_free() is "backbone" API, it is used by all cases, all scenaries are affected. As far as I know, the current approach for nb_seg field - it contains other value than 1 only in the first mbuf , for the following segments, it should not be considered at all (only the first segment fields are valid), and it is supposed to contain 1, as it was initially allocated from the pool. In the example above the problem was introduced by rte_pktmbuf_chain(). Could we consider fixing the rte_pktmbuf_chain() (used in potentially fewer common sceneries) instead of touching the extremely common rte_mbuf_free() ? With best regards, Slava > -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Tuesday, September 28, 2021 11:29 > To: Olivier Matz <olivier.m...@6wind.com>; Ali Alnubani > <alia...@nvidia.com>; Slava Ovsiienko <viachesl...@nvidia.com> > Cc: Morten Brørup <m...@smartsharesystems.com>; dev@dpdk.org; David > Marchand <david.march...@redhat.com>; Alexander Kozyrev > <akozy...@nvidia.com>; Ferruh Yigit <ferruh.yi...@intel.com>; > zhaoyan.c...@intel.com; Andrew Rybchenko > <andrew.rybche...@oktetlabs.ru>; Ananyev, Konstantin > <konstantin.anan...@intel.com>; Ajit Khaparde > <ajit.khapa...@broadcom.com>; jer...@marvell.com > Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH v4] mbuf: fix reset on mbuf > free > > Follow-up again: > We have added a note in 21.08, we should fix it in 21.11. > If there are no counter proposal, I suggest applying this patch, no matter the > performance regression. > > > 30/07/2021 16:54, Thomas Monjalon: > > 30/07/2021 16:35, Morten Brørup: > > > > From: Olivier Matz [mailto:olivier.m...@6wind.com] > > > > Sent: Friday, 30 July 2021 14.37 > > > > > > > > Hi Thomas, > > > > > > > > On Sat, Jul 24, 2021 at 10:47:34AM +0200, Thomas Monjalon wrote: > > > > > What's the follow-up for this patch? > > > > > > > > Unfortunatly, I still don't have the time to work on this topic yet. > > > > > > > > In my initial tests, in our lab, I didn't notice any performance > > > > regression, but Ali has seen an impact (0.5M PPS, but I don't know > > > > how much in percent). > > > > > > > > > > > > > 19/01/2021 15:04, Slava Ovsiienko: > > > > > > Hi, All > > > > > > > > > > > > Could we postpose this patch at least to rc2? We would like to > > > > conduct more investigations? > > > > > > > > > > > > With best regards, Slava > > > > > > > > > > > > From: Olivier Matz <olivier.m...@6wind.com> > > > > > > > On Mon, Jan 18, 2021 at 05:52:32PM +0000, Ali Alnubani wrote: > > > > > > > > Hi, > > > > > > > > (Sorry had to resend this to some recipients due to mail > > > > > > > > server > > > > problems). > > > > > > > > > > > > > > > > Just confirming that I can still reproduce the regression > > > > > > > > with > > > > single core and > > > > > > > 64B frames on other servers. > > > > > > > > > > > > > > Many thanks for the feedback. Can you please detail what is > > > > > > > the > > > > amount of > > > > > > > performance loss in percent, and confirm the test case? (I > > > > suppose it is > > > > > > > testpmd io forward). > > > > > > > > > > > > > > Unfortunatly, I won't be able to spend a lot of time on this > > > > > > > soon > > > > (sorry for > > > > > > > that). So I see at least these 2 options: > > > > > > > > > > > > > > - postpone the patch again, until I can find more time to analyze > > > > > > > and optimize > > > > > > > - apply the patch if the performance loss is acceptable > > > > > > > compared > > > > to > > > > > > > the added value of fixing a bug > > > > > > > > > > > > [...] > > > > > > > > Statu quo... > > > > > > > > Olivier > > > > > > > > > > The decision should be simple: > > > > > > Does the DPDK project support segmented packets? > > > If yes, then apply the patch to fix the bug! > > > > > > If anyone seriously cares about the regression it introduces, optimization > patches are welcome later. We shouldn't wait for it. > > > > You're right, but the regression is flagged to a 4-years old patch, > > that's why I don't consider it as urgent. > > > > > If the patch is not applied, the documentation must be updated to > mention that we are releasing DPDK with a known bug: that segmented > packets are handled incorrectly in the scenario described in this patch. > > > > Yes, would be good to document the known issue, no matter how old it > > is. > > > > > Generally, there could be some performance to gain by not supporting > segmented packets at all, as a compile time option. But that is a different > discussion. > > >
