On Fri, Dec 18, 2020 at 5:18 AM Morten Brørup <m...@smartsharesystems.com> wrote: > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz > > > > m->nb_seg must be reset on mbuf free whatever the value of m->next, > > because it can happen that m->nb_seg is != 1. For instance in this > > case: > > > > 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 > > > > Then split this chain between m1 and m2, it would result in 2 packets: > > - first packet > > - m0: next=m1, nb_seg=3 > > - m1: next=m2, nb_seg=2 > > I think you mean: > > - m0: next=m1, nb_seg=2 //< nb_seg corrected > - m1: next=NULL, nb_seg=2 //< next corrected > > > - second packet > > - m2: next=NULL, nb_seg=1 > > > > Freeing the first packet will not restore nb_seg=1 in the second > > segment. This is an issue because it is expected that mbufs stored > > in pool have their nb_seg field set to 1. > > > > Fixes: 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool") > > Cc: sta...@dpdk.org > > > > Signed-off-by: Olivier Matz <olivier.m...@6wind.com> > > The code looks good, so: > Acked-by: Morten Brørup <m...@smartsharesystems.com>
Acked-by: Ajit Khaparde <ajit.khapa...@broadcom.com>
