From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ilya Matveychikov Subject: Re: [PATCH] mbuf: remove redundant line in rte_pktmbuf_attach Date: Sat, 21 Jan 2017 19:08:28 +0400 Message-ID: <37EFD294-2DEE-4140-9A74-423429B82B02@gmail.com> References: <7181C1FE-0FB9-4FB8-9A12-08AB4506880E@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org To: Ferruh Yigit Return-path: Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) by dpdk.org (Postfix) with ESMTP id 841983B5 for ; Sat, 21 Jan 2017 16:09:01 +0100 (CET) Received: by mail-wm0-f65.google.com with SMTP id d140so14134769wmd.2 for ; Sat, 21 Jan 2017 07:09:01 -0800 (PST) In-Reply-To: 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 Jan 20, 2017, at 4:08 PM, Ferruh Yigit = wrote: >=20 > On 1/20/2017 12:19 AM, Ilya Matveychikov wrote: >> 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 > Do you know why attaching mbuf is not supporting multi-segment? > Perhaps this can be documented in function comment, as one of the "not > supported" items. 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. > Also, should we check mi->next before overwriting, in case it is not = NULL? >=20 >> mi->data_off =3D m->data_off; >> mi->data_len =3D m->data_len; >> mi->port =3D m->port; >>=20 >=20 I don=E2=80=99t know. It depends of the usage. Will someone needs to = chain two chains of mbuf?=