From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH] mbuf: remove redundant line in rte_pktmbuf_attach Date: Tue, 24 Jan 2017 17:19:18 +0100 Message-ID: <20170124171918.5102c3b9@glumotte.dev.6wind.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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Olivier MATZ , "Ananyev, Konstantin" , "Yigit, Ferruh" , "dev@dpdk.org" To: Ilya Matveychikov 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) In-Reply-To: <7040BD38-C057-41F1-888A-32922934C148@gmail.com> 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 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