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 BA67C42220 for ; Fri, 1 Sep 2023 15:31:28 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8AE2840285; Fri, 1 Sep 2023 15:31:28 +0200 (CEST) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) by mails.dpdk.org (Postfix) with ESMTP id 20EA04014F for ; Fri, 1 Sep 2023 15:31:27 +0200 (CEST) Received: by mail-oi1-f182.google.com with SMTP id 5614622812f47-3a9b41ffe12so1284061b6e.3 for ; Fri, 01 Sep 2023 06:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693575086; x=1694179886; 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=vAil+7zLBobrmowFy3AzgwRgmjyPl08BMPyLVVpeLP4=; b=hSDXFzLnVRnvelew/1b4im2+T+KsHocgT0jQcZCiptluqmws8WDDr35bg0yjFgPbPj 9WtKTsDq512J3cFqEqW4kbhVbPSDv4QsJKpl+H5BHRzpPrS+hUB55X+cMEOw8C3gKQsh Y8Kv8uEFA9YwPREREjL/kIsFBUSRSQc0Rx84PCoDijDiWTBkwjE9c9wnchOKjujbgzvj UvsDAFvUl+KivNsYbdMJdPqjxs5U0HM0hIsWqR0GurexOZA6KCfYqSxvcJGBRlZ/Pc9y xAneegf72IhBdD4E83tpIz55MG0O/55BtW6XM0XILm9fo9qddWDefF/Aish238xhyIcV kL0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693575086; x=1694179886; 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=vAil+7zLBobrmowFy3AzgwRgmjyPl08BMPyLVVpeLP4=; b=heTaJWdKdGp7I4eoCnG1zEztzaW1GTJ2d4TTkLnZ9KrCmjIMN9G/A5prjy4m1oylSI A+BzpkjMI6XmtPJF7oMVPKjFxy5CVQLN7bXJeZ1bokXN+o2Ku/7qzGij/1eudUIGjeyZ dwz71FsPHdhgl7pGtIWjwoJFsaOvti+Y3gMifjuABT/q0AOGDFtZiZBatlVvavFktTbX Y0wZLscScZN53lGvPW39AZk7Sx+NLxEAPqtv2WAvzg7cKqd09JVprisSkl43u2uCzzXf IK0P4j5GCrDklLzNtGCgZRQ/5FRvpP6YCurQkPyB4PMnIjwZt+3Z6oh9vuOCHc3UsFLT p+mw== X-Gm-Message-State: AOJu0YwB98nnriFO6pkYgjqLSZo0j+DEbHlQrvBUqPvPP2anPlxra4nF /LEAp7muPiC9rvV0kdoz837bnRvB6IDJKNgQX0oEwz58NxY= X-Google-Smtp-Source: AGHT+IEi7uLx+efan7YPhQBUTctAgp6HbH9lIYXK1t2g9TAgrTWMk0qLav/1mdiJyMUuznsKqN2FLQMlb8NsUihkFsQ= X-Received: by 2002:a05:6808:f94:b0:3a7:8e6:c935 with SMTP id o20-20020a0568080f9400b003a708e6c935mr2661843oiw.43.1693575086199; Fri, 01 Sep 2023 06:31:26 -0700 (PDT) MIME-Version: 1.0 References: <14989106.JCcGWNJJiE@thomas> In-Reply-To: <14989106.JCcGWNJJiE@thomas> From: omer yamac Date: Fri, 1 Sep 2023 16:31:15 +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="00000000000069d75606044c2d2b" 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 --00000000000069d75606044c2d2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 false. 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 to > > 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" paramete= r > 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 > > > --00000000000069d75606044c2d2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for the clarification. Now, I u= nderstand more clearly. May I ask 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 c= heck this, which returns false. So, to get a direct buffer, I need to use t= he 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)" fun= ction; a direct buffer is necessary for this function.

On Fri, Sep 1, 20= 23 at 4:08=E2=80=AFPM Thomas Monjalon <thomas@monjalon.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


--00000000000069d75606044c2d2b--