From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 0802CA09FD;
	Sat, 19 Dec 2020 00:33:57 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id CCE22CAF1;
	Sat, 19 Dec 2020 00:33:55 +0100 (CET)
Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com
 [209.85.208.54]) by dpdk.org (Postfix) with ESMTP id F1BEBCA9B;
 Sat, 19 Dec 2020 00:33:53 +0100 (CET)
Received: by mail-ed1-f54.google.com with SMTP id cw27so4063149edb.5;
 Fri, 18 Dec 2020 15:33:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=/oezIy8J1e+ZFnOs05SL0FaltOtJ0SvJUhQU1VCXzoA=;
 b=rVzfMtfaNjctwBJGRj5dVPPV5e7EDE40jjXS+zDnFaZIV0hb0LcZsqvc+Om+Gu112N
 mOwlW8NSQ0epD20ZAGDFwyxyE3AzAa67uG72TY7xSQIPPAc/elauCSeC9fEtb60qGHzY
 4xFEFvSbS13U3oEopFFIj9nihVAJU//eNEScYQUVz0Fm0dJnn/zDGnMnNk1EH14traFz
 aTf17erN4f3hZE/Pl/3P9C3nEl2seq3J5Z0VELLRciE0TZw/KA3sEprvAJTqHDEHRd86
 t9jQyTy4Bg65GmZgSx+3VQ+s8W+3Rv+J/N+OkubqvRsOCmUDO3KED6QFirH+oWg1WYos
 lilw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=/oezIy8J1e+ZFnOs05SL0FaltOtJ0SvJUhQU1VCXzoA=;
 b=TX/4NNnFcjeT96m/kB/ORa6vCFQBvGdJcVsLXYOUHr21cQDGzY/exeO3bDAO3BlMOq
 7yNoPbnLDul/Z+lBOqz23VYMboOaEYbiV5se2tfN5xgUilN4eJwKP1B/MFGB5OA7o8fA
 RptbUYEHVrkfRGCaiIuq0SU/GXoQEoVZq4Ne4OGMa95ZVHPC93T2UN6bxje3WZacr0nR
 0s8LbTFBcxjbXGI7VQBhvnbs77xY6dIL0LQZCkRmkx1oO16HaJ1DHbRh4mhUWTx7ON6O
 cRsC8EbuOGJk4eg9qqT1uyaweQbPZiAsobeh4WVebDTM99+L78Rz/B8DyNPbEjkV5yEZ
 oXeg==
X-Gm-Message-State: AOAM531dRBTMlmZWqh1uIpkNBwCfB87aVWWDv+nG/KXQsDTPcwx8I1DL
 HAuDFpyH+yQXezR+Wk/CtbFpXcqcTYyXSIfmf+8=
X-Google-Smtp-Source: ABdhPJxmY9sDP8LVCYOI2v9op/MFKzetcNbAjkK4i47k+CDMV/BGKoitjiU1qsSb05j88cIVlmIqGvCc2KE8F7TVQyE=
X-Received: by 2002:a05:6402:1a30:: with SMTP id
 be16mr6917509edb.124.1608334432568; 
 Fri, 18 Dec 2020 15:33:52 -0800 (PST)
MIME-Version: 1.0
References: <20201104170007.8026-1-olivier.matz@6wind.com>
 <20201218125238.13074-1-olivier.matz@6wind.com>
 <98CBD80474FA8B44BF855DF32C47DC35C614E2@smartserver.smartshare.dk>
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C614E2@smartserver.smartshare.dk>
From: Ajit Khaparde <ajitkhaparde@gmail.com>
Date: Fri, 18 Dec 2020 15:33:41 -0800
Message-ID: <CAD6mc5YTFp64f5+05J4PcZg2KpMjg6LWLzVd+8vpShJssgOrcg@mail.gmail.com>
To: =?UTF-8?Q?Morten_Br=C3=B8rup?= <mb@smartsharesystems.com>
Cc: Olivier Matz <olivier.matz@6wind.com>, dev@dpdk.org,
 andrew.rybchenko@oktetlabs.ru, 
 konstantin.ananyev@intel.com, stable@dpdk.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dpdk-dev] [PATCH v2] mbuf: fix reset on mbuf free
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Fri, Dec 18, 2020 at 5:18 AM Morten Br=C3=B8rup <mb@smartsharesystems.co=
m> wrote:
>
> > From: dev [mailto:dev-bounces@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 !=3D 1. For instance in this
> > case:
> >
> >   m1 =3D rte_pktmbuf_alloc(mp);
> >   rte_pktmbuf_append(m1, 500);
> >   m2 =3D rte_pktmbuf_alloc(mp);
> >   rte_pktmbuf_append(m2, 500);
> >   rte_pktmbuf_chain(m1, m2);
> >   m0 =3D 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=3Dm1, nb_seg=3D3
> >   - m1: next=3Dm2, nb_seg=3D2
> >   - m2: next=3DNULL, nb_seg=3D1
> >
> > Then split this chain between m1 and m2, it would result in 2 packets:
> >   - first packet
> >     - m0: next=3Dm1, nb_seg=3D3
> >     - m1: next=3Dm2, nb_seg=3D2
>
> I think you mean:
>
> - m0: next=3Dm1, nb_seg=3D2  //< nb_seg corrected
> - m1: next=3DNULL, nb_seg=3D2   //< next corrected
>
> >   - second packet
> >     - m2: next=3DNULL, nb_seg=3D1
> >
> > Freeing the first packet will not restore nb_seg=3D1 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>
>
> The code looks good, so:
> Acked-by: Morten Br=C3=B8rup <mb@smartsharesystems.com>

Acked-by: Ajit Khaparde <ajit.khaparde@broadcom.com>