DPDK usage discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Thea Corinne Rossman <thea.rossman@cs.stanford.edu>
Cc: users@dpdk.org
Subject: Re: Containernet (Docker/Container Networking) with DPDK?
Date: Tue, 19 Nov 2024 13:29:03 -0800	[thread overview]
Message-ID: <20241119132903.12fefa8c@hermes.local> (raw)
In-Reply-To: <CAHXF6-quagc=+VypJn070Ycv3qLV5JY74BaiNvP7giyF81Grrw@mail.gmail.com>

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.

  reply	other threads:[~2024-11-19 21:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-18  5:42 Thea Corinne Rossman
2024-11-19 20:53 ` Thea Corinne Rossman
2024-11-19 21:29   ` Stephen Hemminger [this message]
2024-11-19 21:39     ` Thea Corinne Rossman
2024-11-19 22:03       ` Stephen Hemminger
2024-11-20  7:10         ` Kompella V, Purnima
2024-11-20  9:27           ` Tom Barbette
2024-11-20  9:28             ` Tom Barbette
2024-11-20  9:28               ` Tom Barbette
2024-11-20 19:49               ` Thea Corinne Rossman
2024-11-19 22:14       ` Thomas Monjalon
2024-11-19 23:23         ` Thea Corinne Rossman
2024-11-19 23:30           ` Thomas Monjalon

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=20241119132903.12fefa8c@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=thea.rossman@cs.stanford.edu \
    --cc=users@dpdk.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).