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 96860A0509 for ; Thu, 14 Apr 2022 21:51:42 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 29CAE4067E; Thu, 14 Apr 2022 21:51:42 +0200 (CEST) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by mails.dpdk.org (Postfix) with ESMTP id ACF524067C for ; Thu, 14 Apr 2022 21:51:40 +0200 (CEST) Received: by mail-lj1-f169.google.com with SMTP id b21so7354792ljf.4 for ; Thu, 14 Apr 2022 12:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IHtdwYayB7g3XKSDmQ9lyd/olr6QFG92en/6ucJtqDA=; b=ZpzY+e14gXkC4CrtGAgvKX6tdpmp8SEnGKN4j49KVqZ7YyusqYD6fw/tCJ9OOgMO9V r8gE2+81roBo3WGOZWLL/T09uYQylRCGt1z8CWU5/ExdebDonRfD+lomZrLQQholBCbY 7a1QGfgKKIjXL+hjiIAZjffOMFryj7mEyRMBKXMOBb3dqqifbaUxo47VJHRhAs5JbbWk Jl+/Zt3NmP+y1GQZSgZUUhhAyA98OQA787HJjKQGF4XwS0QjfihNsvpwJ0hrnzpiZD9I 96eG9qVWGwbDb0m2Jj9c6zqBJqeSHmfWx5FBTVlHWcTw8jGzj6tKLdELkIOdde2u+vuU rBIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IHtdwYayB7g3XKSDmQ9lyd/olr6QFG92en/6ucJtqDA=; b=BllPA1Wapxf6qiVVp+v1DWRUL+vuFPSFE+Iw1kQ4piQhc9CTZkYDTRlAB09chW8Prq vgQqnLrSPbQn+IZnoggeT8AXn/uhiAFqCCEkLHZEMXfJTBMavTlb3/XAzJMJ83IeAtue xE8s5iLzXNV6pyxifuvOK1P6OMtDrGmjm5MBmOX9bMuoQ3hpHTT2bJI/NAhBHJDq1nEv JgveowQhrNKWD65frA71VzADU3hGR31lRUQ0S6tjEz/yJUA/SYa9oOW201wQt2fPemfW nJKQ20G/MCBsEPQhfaF3GpciNNiT86McO+ZoE5sG+/n9MsQNnYTD9KK97QrpF6/w+eSc qK0A== X-Gm-Message-State: AOAM53187S6qZYkQ0bzSnryOXrBZTzatLFgfyV+sMpt14B+sQ3VHQXGh MEzecZ+sZtWNpCej7xWiWg6xa/wFQmyb6lxX/Hk= X-Google-Smtp-Source: ABdhPJwVVqQcI6znMFTOu9QuGJm42m15bxmZL/mTBX9J2WYYxNYzDJm6sGkJ2rKuUWSb4KAIpDyq1+CcvJL38myhywc= X-Received: by 2002:a05:651c:cf:b0:24d:9c91:123 with SMTP id 15-20020a05651c00cf00b0024d9c910123mr2341728ljr.384.1649965900007; Thu, 14 Apr 2022 12:51:40 -0700 (PDT) MIME-Version: 1.0 References: <20220408162629.372dfd0d@sovereign> <20220411203011.4df9f6f4@sovereign> <20220414220148.0d638532@sovereign> In-Reply-To: <20220414220148.0d638532@sovereign> From: Antonio Di Bacco Date: Thu, 14 Apr 2022 21:51:28 +0200 Message-ID: Subject: Re: Shared memory between two primary DPDK processes To: Dmitry Kozlyuk Cc: users@dpdk.org Content-Type: multipart/alternative; boundary="0000000000005c8ca305dca29f0c" 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 --0000000000005c8ca305dca29f0c Content-Type: text/plain; charset="UTF-8" Il giorno gio 14 apr 2022 alle ore 21:01 Dmitry Kozlyuk < dmitry.kozliuk@gmail.com> ha scritto: > 2022-04-14 10:20 (UTC+0200), Antonio Di Bacco: > [...] > > Ok, after having a look to memif I managed to exchange the fd between > the > > two processes and it works. > > Anyway the procedure seems a little bit clunky and I think I'm going to > use > > the new SYSCALL pidfd_getfd > > to achieve the same result. In your opinion this method (getfd_pidfd) > > could also work if the two DPDK processes > > are inside different docker containers? > > Honestly, I've just learned about pidfd_getfd() from you. > But I know that containers use PID namespaces, so there's a question > how you will obtain the pidfd of a process in another container. > > In general, any method of sharing FD will work. > Remember that you also need offset and size. > Given that some channel is required to share those, > I think Unix domain socket is still the preferred way. > > > Or is there another mechanims like using handles to hugepages present in > > the filesystem to share between two > > different containers? > > FD is needed for mmap(). > You need to either pass the FD or open() the same hugepage file by path. > I advise against using paths because they are not a part of DPDK API > contract. > Thank you very much Dmitry, your answers are always enlightening. I'm going to ask a different question on the dpdk.org about the best practice to share memory between two dpdk processes running in different containers. --0000000000005c8ca305dca29f0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
Il giorno gio 14 apr 2022 alle ore 21= :01 Dmitry Kozlyuk <dmitry.k= ozliuk@gmail.com> ha scritto:
2022-04-14 10:20 (UTC+0200), Antonio Di Bacco:
[...]
> Ok, after having a look to memif I managed to exchange the fd=C2=A0 be= tween the
> two processes and it works.
> Anyway the procedure seems a little bit clunky and I think I'm goi= ng to use
> the new SYSCALL pidfd_getfd
> to achieve the same result.=C2=A0 In your opinion this method (getfd_p= idfd)
> could also work if the two DPDK processes
> are inside different docker containers?

Honestly, I've just learned about pidfd_getfd() from you.
But I know that containers use PID namespaces, so there's a question how you will obtain the pidfd of a process in another container.

In general, any method of sharing FD will work.
Remember that you also need offset and size.
Given that some channel is required to share those,
I think Unix domain socket is still the preferred way.

> Or is there another mechanims like using handles to hugepages present = in
> the filesystem to share between two
> different containers?

FD is needed for mmap().
You need to either pass the FD or open() the same hugepage file by path. I advise against using paths because they are not a part of DPDK API contra= ct.

Thank you very much Dmitry, your an= swers are always enlightening.
I'm going to ask a different q= uestion on the dpdk.org about the best prac= tice to share memory between two dpdk processes running in different contai= ners.=C2=A0
--0000000000005c8ca305dca29f0c--