From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f67.google.com (mail-wm0-f67.google.com [74.125.82.67]) by dpdk.org (Postfix) with ESMTP id 143DD293C for ; Tue, 24 Jan 2017 16:57:47 +0100 (CET) Received: by mail-wm0-f67.google.com with SMTP id d140so35724831wmd.2 for ; Tue, 24 Jan 2017 07:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iAsmjiponIs7Sfu8HV6clj0dzQoCFwFdH+BZuK+AL84=; b=ozM/3AwUS2jmmaPU1gEPbp/YIazuX46OqmnlkXfbo1oooYrRuNjUrX8IS1IVttRrvw AGRQK6mNz+GGh7/rxjZDlcowj0YtrGNjSQlBhyOaSJN6IObM0rEAPaKuwmjWGuXZO5l3 syzlD1wmxY5sE414piI1AcPGjR8To4fMbBmBLPxqzZhOzSrK2H3yFCXrPG4cezPjPfxz Y7ZE1JUGEJnZnOgcwmR3SurkqC0UyilFB9qBdyD0EW7pkEbFjv2qDt4TPhGQVitqcG7Z zfDA+/GX4NdwEf3oc3b69PI+NAl/nb7uEZwVLZPq2++J7bG6VplgRL/O+CWX1QO7mgeB Nlag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iAsmjiponIs7Sfu8HV6clj0dzQoCFwFdH+BZuK+AL84=; b=FVUO0pO3xVszYrNxaxBsMSvBklETRcV0/End4rFvwscR4IzTute8hxw4jOQVGa26kD t3x0ZnwBC0PavohcX1UILoikdkdjKxijiRFwVcXWaLBdC2gs/bf8ZJBpvyYfJm8ft+sy NqA6XAKXxGUQizlsEcZzU1hqCbtPcipLNpuSxrXEUjxqHGAo8AMuSoNV+svDQZE8D6YF Tz0bZZVt0m2E/Utl1xXiLp3rFZ0Q74XnO7TzVOVZUw5mblyZsum6brJzcdFhsCeojtav P3NT48Meg+oXZvxRitwz9egV5zFzyt5iO0A7ITvhPwaH6x/mVtKKY4ot0e9e0XSW6OGE +61g== X-Gm-Message-State: AIkVDXKqAnNWRRI5cdxHrVVzWbPjTtdfr3mQC5Nglfu5fc0T+jW0lHGv3CCKkjgdMoQi/g== X-Received: by 10.28.87.19 with SMTP id l19mr19267371wmb.95.1485273466803; Tue, 24 Jan 2017 07:57:46 -0800 (PST) Received: from [192.168.0.101] ([94.204.18.159]) by smtp.gmail.com with ESMTPSA id u41sm20511515wrc.1.2017.01.24.07.57.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jan 2017 07:57:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ilya Matveychikov In-Reply-To: <20170124135627.7ab3d703@glumotte.dev.6wind.com> Date: Tue, 24 Jan 2017 19:57:13 +0400 Cc: "Ananyev, Konstantin" , "Yigit, Ferruh" , "dev@dpdk.org" Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Olivier MATZ X-Mailer: Apple Mail (2.3259) 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 15:57:47 -0000 > 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: >>> -----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. 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?