On 05/12/2023 18:30, Stephen Hemminger wrote:
On Mon, 4 Dec 2023 05:31:01 -0500
Maryam Tahhan <mtah...@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 <mtah...@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
