From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 00D7D422A2 for ; Fri, 1 Sep 2023 23:30:34 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 767F040285; Fri, 1 Sep 2023 23:30:34 +0200 (CEST) Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) by mails.dpdk.org (Postfix) with ESMTP id 3B3AA4014F for ; Fri, 1 Sep 2023 23:30:32 +0200 (CEST) Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-5734f54dc44so1438166eaf.2 for ; Fri, 01 Sep 2023 14:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693603831; x=1694208631; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dR4f16Fy+RwkdzZfOo3vDKHMfyg3ZyrIHFpmYSpDn3s=; b=PJMOUpbj0qzBtIfpmu/qXJul8im4AVYkkrF4gFq20bOXOVHR1Lo6uA80NAxsWtiVXz zoB3W7J+yFUynuvJW0SPwPiOn9Dq4b2fjSzENHEBOjaIQtZ56HDf8JFhAWA6shSgJt5z KeBtcH3zdftuO2+VKXK9ZyZoO+a1qXXeiS2mn+nRwy7sXv0z9gnicP33Gfj0y2KLF/Z6 KI0lokJO9GnRl9/2c8pWcuEnt/d9L8pjtiG5q3ShgIAD3/FMoIpLX1iwxDIeMgDTL4F8 RRw87NtDbIJyXqtwYNxRdaK1p1xsNOUBPSI8Mo6LJgXbbvZiq/jqByEzIjzYSNfjD2lC BlfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693603831; x=1694208631; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dR4f16Fy+RwkdzZfOo3vDKHMfyg3ZyrIHFpmYSpDn3s=; b=hkz9+wwHsLzxXX2DS4PD+7ZK35zeVerwOn+8JCV0dgXm+/NuilSVU51Tc1PaD0cIr8 iZXMKekvU96BcNjn1qnxigTwTWeR+TM4A2XlqyGm3PKfOUknJrq9xVLxIjHojwlZPMOQ 17VpYyZY8c6MmNR05kcv/AO7mLKCHHuSnGJa4WR3JVcxyddh+lMaIY6vMmjsbG5CuFuB UwLx892Ff8cGKSFSFL9dSPVj0yedBfudiNZITc0v0qCqmTbirotudeGvPDZeqNzR1K33 gtIAOgIIG5R48VwAZz3YNlqiYCwtFmqJ6ETocKZSijr12KTwQtCfWjaSeEbiGWrWebPl 2TFQ== X-Gm-Message-State: AOJu0Yx4JNDrkEdYDzIxlk3uRk3wqn7hbMCqNGBdj8vvqyPo4zYCmEMR dPakfWKxqoCC6nCopQLPYIj7EOsVKYV36+f2udsgkSgyyOA= X-Google-Smtp-Source: AGHT+IE/PbmsvCy/lJZpcS4jWjZOLWjH96wzrbbyeXsgIbrmS3DQ1qakX5IvSbRA2b9nBEWvu8pzhjhv6MPUa4v1xSk= X-Received: by 2002:a4a:dfb4:0:b0:573:5539:43d9 with SMTP id k20-20020a4adfb4000000b00573553943d9mr3532289ook.9.1693603831120; Fri, 01 Sep 2023 14:30:31 -0700 (PDT) MIME-Version: 1.0 References: <14989106.JCcGWNJJiE@thomas> In-Reply-To: From: =?UTF-8?B?QWJkdWxsYWggw5ZtZXIgWWFtYcOn?= Date: Sat, 2 Sep 2023 00:30:20 +0300 Message-ID: Subject: Re: Direct Mem Pool vs Indirect mem pool creation To: Thomas Monjalon Cc: users@dpdk.org Content-Type: multipart/alternative; boundary="000000000000be866c060452de75" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000be866c060452de75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I found the answer in the comments: "/* Creates a shallow copy of mbuf */" for the rte_pktmbuf_clone. Thanks On Fri, Sep 1, 2023 at 4:31=E2=80=AFPM omer yamac wr= ote: > Thank you for the clarification. Now, I understand more clearly. May I as= k > one more question? I used the rte_pktmbuf_clone function to duplicate the > packet. Then, the new packet is cloned to the indirect memory. After the > clone, I used the RTE_MBUF_DIRECT macro to check this, which returns fals= e. > So, to get a direct buffer, I need to use the alloc function and copy the > data. Am I right? > > I just want to use the "static inline int rte_vlan_insert(struct rte_mbuf > **m)" function; a direct buffer is necessary for this function. > > On Fri, Sep 1, 2023 at 4:08=E2=80=AFPM Thomas Monjalon > wrote: > >> 01/09/2023 14:47, omer yamac: >> > Hello, >> > >> > I need clarification while creating direct/indirect buffers for mbuf. = I >> > couldn't find exact documentation, and I just looked over the >> fragmentation >> > test case and saw that two pools were created. One is a >> > direct pool, and the other is an indirect pool. Here are the methods t= o >> > create pools: >> > direct_pool =3D rte_pktmbuf_pool_create("FRAG_D_MBUF_POOL", >> > NUM_MBUFS, BURST, 0, >> > RTE_MBUF_DEFAULT_BUF_SIZE, >> > SOCKET_ID_ANY); >> > indirect_pool =3D rte_pktmbuf_pool_create("FRAG_I_MBUF_POOL", >> > NUM_MBUFS, BURST, 0, >> > 0, SOCKET_ID_ANY) >> > >> > I couldn't see the exact difference. Just the "data_room_size" >> parameter is >> > different. If this parameter is 0, then is the pool indirect? >> >> A pool is neither direct or indirect, it is just a pool of buffers >> with a defined size for all buffers of a pool. >> You are free to create any pool for your needs. >> >> Now if you create a pool of buffers with size 0, >> we can expect you will save some data elsewhere, >> using rte_pktmbuf_attach_extbuf() for instance. >> >> More explanations can be found in the doc: >> >> https://doc.dpdk.org/guides/prog_guide/mbuf_lib.html#direct-and-indirect= -buffers >> >> >> --000000000000be866c060452de75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I found the answer in the comments: "= ;/* Creates a shallow copy of mbuf */" for the rte_pktmbuf_clone. Than= ks

On Fri, Sep 1, 2023 at 4:31=E2=80=AFPM omer yamac <aomeryamac@gmail.com> wrote:
= Thank you for the clarification. Now, I understand more clearly. May I ask = one more question? I used the rte_pktmbuf_clone function to duplicate the p= acket. Then, the new packet is cloned to the indirect memory. After the clo= ne, I used the RTE_MBUF_DIRECT macro to check this, which returns false. So= , to get a direct buffer, I need to use the alloc function and copy the dat= a. Am I right?

I just want to use the "static inline int rte_v= lan_insert(struct rte_mbuf **m)" function; a direct buffer is necessar= y for this function.

On Fri, Sep 1, 2023 at 4:08=E2=80=AFPM Thomas Monja= lon <thomas@mon= jalon.net> wrote:
01/09/2023 14:47, omer yamac:
> Hello,
>
> I need clarification while creating direct/indirect buffers for mbuf. = I
> couldn't find exact documentation, and I just looked over the frag= mentation
> test case and saw that two pools were created. One is a
> direct pool, and the other is an indirect pool. Here are the methods t= o
> create pools:
> direct_pool =3D rte_pktmbuf_pool_create("FRAG_D_MBUF_POOL",<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0NUM_MBUFS, BURST, 0,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0RTE_MBUF_DEFAULT_BUF_SIZE,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0SOCKET_ID_ANY);
> indirect_pool =3D rte_pktmbuf_pool_create("FRAG_I_MBUF_POOL"= ,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0NUM_MBUFS, BURST, 0,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A00, SOCKET_ID_ANY)
>
> I couldn't see the exact difference. Just the "data_room_size= " parameter is
> different. If this parameter is 0, then is the pool indirect?

A pool is neither direct or indirect, it is just a pool of buffers
with a defined size for all buffers of a pool.
You are free to create any pool for your needs.

Now if you create a pool of buffers with size 0,
we can expect you will save some data elsewhere,
using rte_pktmbuf_attach_extbuf() for instance.

More explanations can be found in the doc:
https://doc.dpdk.org= /guides/prog_guide/mbuf_lib.html#direct-and-indirect-buffers


--000000000000be866c060452de75--