From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Matveychikov Subject: Re: [PATCH 2/2] mbuf: reset nb_segs of chained packet Date: Thu, 16 Nov 2017 23:15:18 +0400 Message-ID: References: <20171116090155.31419fe3@xeon-e3> Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org To: Stephen Hemminger Return-path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id EB0B51B2E7 for ; Thu, 16 Nov 2017 20:15:18 +0100 (CET) Received: by mail-wm0-f66.google.com with SMTP id z3so2267336wme.3 for ; Thu, 16 Nov 2017 11:15:18 -0800 (PST) In-Reply-To: <20171116090155.31419fe3@xeon-e3> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Nov 16, 2017, at 9:01 PM, Stephen Hemminger = wrote: >=20 > On Thu, 16 Nov 2017 18:05:35 +0400 > Ilya Matveychikov wrote: >=20 >> Fixes: 139debc42dc0 ("mbuf: move chaining from ip_frag library") >> Cc: simon.kagstrom@netinsight.net >>=20 >> Signed-off-by: Ilya V. Matveychikov >> --- >> lib/librte_mbuf/rte_mbuf.h | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >>=20 >> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h >> index ce8a05ddf..2126dc94b 100644 >> --- a/lib/librte_mbuf/rte_mbuf.h >> +++ b/lib/librte_mbuf/rte_mbuf.h >> @@ -1828,9 +1828,12 @@ static inline int rte_pktmbuf_chain(struct = rte_mbuf *head, struct rte_mbuf *tail >> head->nb_segs +=3D tail->nb_segs; >> head->pkt_len +=3D tail->pkt_len; >>=20 >> - /* pkt_len is only set in the head */ >> + /* nb_segs and pkt_len are only set in the head */ >> + tail->nb_segs =3D 1; >> tail->pkt_len =3D tail->data_len; >>=20 >> + __rte_mbuf_sanity_check(head, 1); >> + >> return 0; >> } >=20 > My understanding is that nb_segs and pkt_len are only valid > in head. For other packets in the chain nb_segs and pkt_len > can be anything. So why not to keep them in consistency with multi-seg logic? I mean that pkt_len/nb_segs for the head always have meaning but for the rest of chain pkt_len is the same as data_len and nb_segs :=3D 1