From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id EB14E2A5B for ; Tue, 24 Jan 2017 17:19:25 +0100 (CET) Received: by mail-wm0-f41.google.com with SMTP id c85so189494686wmi.1 for ; Tue, 24 Jan 2017 08:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=VPLevaGpdfIsnzQMTK+zYJpr6XuKnLEuUk7w1nMH9Ek=; b=s4tTBLPrsTLI4nEVnRhuwQNT7bEnfpqzEnfcIYNhT76y7p3ZMKOLSb2m4l9tmRtKDR 8LOVTZ606FfI18kLnkywyBoM2mHE4sza0/rvwzHNXANHWYoiCkOF5SuWcxa8+5YoWes6 IrOrTGJW0NPxDK1YtNO/Rr0Lbn0LIuhq8AHKaGXhWXPxftyVoxYB6COOIIXzI+gdPm5V IeehiadgtjLzKaz6bux36oRM1juzZxPGZMOnk4qpukuiOyrNf1kbTd7C/IX8Zg7X/7rs f95QrD4tyOSDUWeubc6v6q4VdGXEC4LmvV/S3BQHfWWT8nLYt7D6uHVwFhA9yBZBtDwe EsNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=VPLevaGpdfIsnzQMTK+zYJpr6XuKnLEuUk7w1nMH9Ek=; b=CjphUc6qhIvTpayPofoo0lD2AbTKvf6v2vOCdHaXvuHqKdJaLYb+6JiwDFlUAnobqe EPQQC5g2G5Upejhg4dmgEuVHpPIElxpfoKjDFqBofPpBsSND9M0xSeu/1QNJMthrxOpW OHQFABMoDqN5JuXQDf52q8y3jiT3sn+yezqfB4tQMF1suNYQOs+3O3T6dkFpmQLDduaI zFVd7lCRSfOiE3+6J9opGSEH9vz7iKw+SQ0jMbrciM6rTkALamn7cTjzf+SNhNw6tY4d vMRmC/qh2R+wPo2mrqPEcG6kjOBOTjh1i2wmqHmIMNsQW1Ow/fRuzsDRb8gSfbjjrp0j xTVQ== X-Gm-Message-State: AIkVDXIpKUNaLtMmY9rh4uq1fuT5ICTnLRec/398xHKJDGDR4u3IkJI7a/XyUX1QyM79yPN1 X-Received: by 10.28.7.7 with SMTP id 7mr20586719wmh.55.1485274765674; Tue, 24 Jan 2017 08:19:25 -0800 (PST) Received: from glumotte.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id v102sm20641888wrb.11.2017.01.24.08.19.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 24 Jan 2017 08:19:25 -0800 (PST) From: Olivier MATZ X-Google-Original-From: Olivier MATZ Date: Tue, 24 Jan 2017 17:19:18 +0100 To: Ilya Matveychikov Cc: Olivier MATZ , "Ananyev, Konstantin" , "Yigit, Ferruh" , "dev@dpdk.org" Message-ID: <20170124171918.5102c3b9@glumotte.dev.6wind.com> In-Reply-To: <7040BD38-C057-41F1-888A-32922934C148@gmail.com> References: <7181C1FE-0FB9-4FB8-9A12-08AB4506880E@gmail.com> <37EFD294-2DEE-4140-9A74-423429B82B02@gmail.com> <2601191342CEEE43887BDE71AB9772583F10925D@irsmsx105.ger.corp.intel.com> <20170124135627.7ab3d703@glumotte.dev.6wind.com> <7040BD38-C057-41F1-888A-32922934C148@gmail.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH] mbuf: remove redundant line in rte_pktmbuf_attach X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:19:26 -0000 On Tue, 24 Jan 2017 19:57:13 +0400, Ilya Matveychikov wrote: > > On Jan 24, 2017, at 4:56 PM, Olivier MATZ > > wrote: > >=20 > > Hi, > >=20 > > On Sat, 21 Jan 2017 16:28:29 +0000, "Ananyev, Konstantin" > > wrote: =20 > >>> -----Original Message----- > >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ilya > >>> Matveychikov Sent: Saturday, January 21, 2017 3:08 PM > >>> To: Yigit, Ferruh > >>> Cc: dev@dpdk.org > >>> Subject: Re: [dpdk-dev] [PATCH] mbuf: remove redundant line in > >>> rte_pktmbuf_attach > >>>=20 > >>> =20 > >>>> On Jan 20, 2017, at 4:08 PM, Ferruh Yigit > >>>> wrote: > >>>>=20 > >>>> On 1/20/2017 12:19 AM, Ilya Matveychikov wrote: =20 > >>>>> mi->next will be assigned to NULL few lines later, trivial patch > >>>>>=20 > >>>>> Signed-off-by: Ilya V. Matveychikov > >>>>> --- > >>>>> lib/librte_mbuf/rte_mbuf.h | 1 - > >>>>> 1 file changed, 1 deletion(-) > >>>>>=20 > >>>>> diff --git a/lib/librte_mbuf/rte_mbuf.h > >>>>> b/lib/librte_mbuf/rte_mbuf.h index ead7c6e..5589d54 100644 > >>>>> --- a/lib/librte_mbuf/rte_mbuf.h > >>>>> +++ b/lib/librte_mbuf/rte_mbuf.h > >>>>> @@ -1139,7 +1139,6 @@ static inline void > >>>>> rte_pktmbuf_attach(struct rte_mbuf *mi, struct rte_mbuf *m) > >>>>> mi->buf_addr =3D m->buf_addr; mi->buf_len =3D m->buf_len; > >>>>>=20 > >>>>> - mi->next =3D m->next; =20 > >>>> =20 > >=20 > > Fixes: ea672a8b1655 ("mbuf: remove the rte_pktmbuf structure") > >=20 > > Acked-by: Olivier Matz > >=20 > > =20 > >>>> Do you know why attaching mbuf is not supporting > >>>> multi-segment? =20 > >>=20 > >> This is supported, but you have to do it segment by segment. > >> Actually rte_pktmbuf_clone() does that. > >> Konstantin > >>=20 > >> =20 > >>>> Perhaps this can be documented in function comment, as one of the > >>>> "not supported" items. =20 > >>>=20 > >>> No, I don=E2=80=99t know. For my application I=E2=80=99ve found that = nb_segs with > >>> it=E2=80=99s limit in 256 segments is very annoying and I=E2=80=99ve = decided not > >>> to use DPDK functions that dealt with nb_segs=E2=80=A6 But it is not > >>> about the rte_pktmbuf_attach() function and the patch. =20 > >=20 > >=20 > > Out of curiosity, can you explain why your application needs more > > than 256 segments? When we were discussing the possibility of > > extending this field to 16 bits, Konstantin convinced me that it > > was not so useful. =20 >=20 > In my application I need to do IPv4 fragments reassembly. There is no > explicit limit of number of fragments in datagram, so I=E2=80=99m trying = to > avoid any limitations and `nb_segs` here is a constraint for me. > Expanding it from 8-bit to 16-bit can solve that issue for me. But I > don=E2=80=99t remember are there any other places in DPDK where we need = to > know how many segments are in the packet? I mean that is `nb_segs` > required at all? >=20 Yes, it is used for instance in some PMDs to know how many tx ring descriptors are needed to send a packet. Thank you for the explanation. As you probably seen, I'm proposing to extend the nb_segs to 16 bits in my latest RFC patchset. Regards, Olivier