On Tue, 19 Nov 2024 12:53:02 -0800
Thea Corinne Rossman <thea.rossman@cs.stanford.edu> wrote:

> I'm following up on this to ask a more specific question, since my first
> question was a bit all over the place. This is regarding the interplay
> between the host and the containers when setting up containers that can run
> DPDK applications.
>
> Based on what I've found so far, it looks like I will have to fully
> configure DPDK on the host and then mount devices onto each container, even
> if there's no need to connect the containers to the outside world. (Is this
> correct?) If so, I don't fully understand this, since a container/container
> network should be self-contained.
>
>    - Why do we need to set up DPDK on the host? (Why isn't the container
>    enough?)
>    - Why do we need to set up a DPDK-compatible driver on the host NICs? If
>    the containers are on the same machine, exchanging packets, why would the
>    host NIC be involved at all? Nothing is going in or out.
>    - Why do we need to configure hugepages on the host and then mount them
>    on the container? Why can't you just configure this on the containers? Is
>    this something that can't be emulated?
>

Containers are a made up construct. They are made by setting permissions for
namespaces and groups for resources.

In most cases, DPDK works by passing through the raw hardware (PCI device)
to the userspace application. To make it work with a container system you
need to either acquire the resource in an restricted environment and then
allow access to that resource in the restricted container; or you need
to give the restricted container environment lots of privileges to configure
and setup the raw hardware directly. In the latter case, there really is
no point in having containers.

Same applies to hugepages.  I don't think hugepages are namespaced either.