efc6f9104c
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=2 - m1: next=NULL, nb_seg=2 - 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: stable@dpdk.org Signed-off-by: Olivier Matz <olivier.matz@6wind.com> Acked-by: Morten Brørup <mb@smartsharesystems.com> Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com> Tested-by: Ali Alnubani <alialnu@nvidia.com>