From: Maryam Tahhan <mtahhan@redhat.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: ferruh.yigit@amd.com, lihuisong@huawei.com,
fengchengwen@huawei.com, liuyonglong@huawei.com,
shibin.koikkara.reeny@intel.com, dev@dpdk.org
Subject: Re: [v2] net/af_xdp: enable a sock path alongside use_cni
Date: Wed, 6 Dec 2023 15:00:12 +0000 [thread overview]
Message-ID: <fcd4c39f-d302-43c1-a2ad-9a9e17b6696b@redhat.com> (raw)
In-Reply-To: <20231205103029.1a5ce926@hermes.local>
On 05/12/2023 18:30, Stephen Hemminger wrote:
> On Mon, 4 Dec 2023 05:31:01 -0500
> Maryam Tahhan <mtahhan@redhat.com> wrote:
>
>> With the original 'use_cni' implementation, (using a
>> hardcoded socket rather than a configurable one),
>> if a single pod is requesting multiple net devices
>> and these devices are from different pools, then
>> the container attempts to mount all the netdev UDSes
>> in the pod as /tmp/afxdp.sock. Which means that at best
>> only 1 netdev will handshake correctly with the AF_XDP
>> DP. This patch addresses this by making the socket
>> parameter configurable alongside the 'use_cni' param.
>> Tested with the AF_XDP DP CNI PR 81.
>>
>> v2:
>> * Rename sock_path to uds_path.
>> * Update documentation to reflect when CAP_BPF is needed.
>> * Fix testpmd arguments in the provided example for Pods.
>> * Use AF_XDP API to update the xskmap entry.
>>
>> Signed-off-by: Maryam Tahhan <mtahhan@redhat.com>
> Why does XDP PMD not use abstract socket path?
> Having actual file visible in file system can cause permission
> and leftover file issues that are not present with abstract path.
>
> If you use abstract path then when last reference is gone (ie server exits)
> the path is removed. With regular paths, the file gets stuck in the
> file system and has to be cleaned up.
>
Hi Stephen
I've not seen abstract sockets being used in pod to pod communications
in Kubernetes before. I would love to learn more if you have any
references.
In the scenario mentioned above, the AF_XDP Device Plugin (A pod that is
the K8s entity on host provisioning and managing interfaces that want to
use AF_XDP) manages access and cleanup for this uds path so there's no
overhead on the XDP PMD side inside the DPDK pod. The AF_XDP DP uses
file permissions on the host side to ensure that other processes/pods
(that shouldn't) can't access the uds path for a specific pod. Both the
AF_XDP DP and the DPDK Pod will have different network namespaces.
Additionally, the actual path (on the host) and the mounted volume path
in the container are not the same, on the Container side we set it up so
that the path appears in a predictable location (which is the path
mentioned above). I'm not sure I can do this with an abstract socket
without picking a name/path that's entirely predictable on both ends?
Just for clarity on what this UDS is used for - this is the uds that's
mounted into a the DPDK Pod/container as a volume, so that the XDP_PMD
can "handshake" with the AF_XDP device plugin to get a FD for the xskmap
that the PMD can use when it creates the AF_XDP socket (all this to
remove elevated privileges being granted to the container).
Thanks
Maryam
prev parent reply other threads:[~2023-12-06 15:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 10:31 Maryam Tahhan
2023-12-04 17:18 ` Koikkara Reeny, Shibin
2023-12-04 18:41 ` Maryam Tahhan
2023-12-05 10:29 ` Koikkara Reeny, Shibin
2023-12-05 11:28 ` Maryam Tahhan
2023-12-05 11:54 ` Koikkara Reeny, Shibin
2023-12-08 17:23 ` Stephen Hemminger
[not found] ` <CAFdtZit1v+F1UNve4wDtVJYMSPNMdFayPKHOpTyJsn_cVgMjRQ@mail.gmail.com>
2023-12-11 13:22 ` Maryam Tahhan
2023-12-05 11:31 ` Maryam Tahhan
2023-12-05 11:49 ` Koikkara Reeny, Shibin
2023-12-05 13:43 ` Loftus, Ciara
2023-12-05 14:38 ` Maryam Tahhan
2023-12-05 14:42 ` Koikkara Reeny, Shibin
2023-12-05 18:30 ` Stephen Hemminger
2023-12-06 15:00 ` Maryam Tahhan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fcd4c39f-d302-43c1-a2ad-9a9e17b6696b@redhat.com \
--to=mtahhan@redhat.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=lihuisong@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=shibin.koikkara.reeny@intel.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).