DPDK usage discussions
 help / color / mirror / Atom feed
From: Thea Corinne Rossman <thea.rossman@cs.stanford.edu>
To: Tom Barbette <tom.barbette@uclouvain.be>
Cc: "Kompella V, Purnima" <Kompella.Purnima@commscope.com>,
	 Stephen Hemminger <stephen@networkplumber.org>,
	"users@dpdk.org" <users@dpdk.org>
Subject: Re: Containernet (Docker/Container Networking) with DPDK?
Date: Wed, 20 Nov 2024 11:49:30 -0800	[thread overview]
Message-ID: <CAHXF6-oSgtjofccj1K_a8pCWveM=b5mvgBqVdO42Jc_TqKDvww@mail.gmail.com> (raw)
In-Reply-To: <00808E3C-24A4-4D0C-A7EC-D07EA1F790B4@uclouvain.be>

[-- Attachment #1: Type: text/plain, Size: 3442 bytes --]

Hi Tom :)

This is great, and the SR-IOV option feels quite clear now. I'm trying to
better understand the virtio-user option as well for communication within
the same host. I've looked at the DPDK resources, the links you've shared
(Tom), and the original virtio-user paper.

1) From your email:

> Internal host networking without going through PCIe can be handled like
VMs too: with virtio and the DPDK vhost driver. Memory copies are involved
in that case.

Where is the memory copy here? I thought that the point of virtio-user
(containers) + vhost-user backend (since on host) is that it is zero-copy.
Where does the copy happen?

2) This may be a basic container networking question. I want to connect
multiple (say, three) containers on the same host. From the diagram in the
DPDK-provided instructions
<https://doc.dpdk.org/guides/howto/virtio_user_for_container_networking.html>
and virtio-user paper, it appears that a virtual switching infrastructure
will be required. (Noting that I believe that Containernet
<https://containernet.github.io> sets up a namespace a la Mininet, but it
doesn't set up a "virtual switch".)

Am I understanding this correctly? Is there additional container networking
infrastructure required for connecting containers? Or is the vhost
backend + testpmd sufficient? If so, how does the vhost backend "know"
where to switch packets?

Thank you all so much!!
Thea

On Wed, Nov 20, 2024 at 1:28 AM Tom Barbette <tom.barbette@uclouvain.be>
wrote:

>
>
> Le 20 nov. 2024 à 10:27, Tom Barbette <tom.barbette@uclouvain.be> a écrit
> :
>
> Hi Stephen, Thea,
>
> If you uses SRIOV, then containers behave essentially like VMs, packets
> will be exchanged through the PCIe bus and switched on the NIC ASIC, which
> as Stephen mentions, will identify MAC addresses as « itself » and packets
> do not physically get out of the NIC . I’d argue these days it’s not as
> much of a problem. You can typically have a PCIe5 x16 ConnectX7 that has a
> bus BW of 500Gbps but has actually only one or two 100G ports, so you’ve
> got plenty of spare bandwidth for internal host exchange. We know NICs are
> getting smart and take a broader role than pure « external »  I/O.
>
> Internal host networking without going through PCIe can be handled like
> VMs too : with virtio and the DPDK vhost driver. Memory copies are involved
> in that case.
>
> I suspect for your matter at hand Thea, the easiest is to use SRIOV.
> Research-wise, a simple solution is to use —networking=host …
>
> Eg this is working well but uses privileged container and lets the docker
> access all host network for fastclick :
> sudo docker run -v /mnt/huge:/dev/hugepages -it --privileged --network
> host tbarbette/fastclick-dpdk:generic --dpdk -a $VF_PCIE_ADDR -- -e
> "FromDPDKDevice(0) -> Discard;"
>
> The related sample Dockerfile can be found at :
> https://github.com/tbarbette/fastclick/blob/main/etc/Dockerfile.dpdk
>
> A problem also with DPDK-based dockers is that you generally don’t want to
> keep the -march=native, so personally I got that script to build a version
> of my docker image with many architectures :
> https://github.com/tbarbette/fastclick/blob/main/etc/docker-build.sh so
> the user can use the image that targets their own arch.
>
>
> May that be helpful,
>
> Tom
>
>
> *sorry I meant Purnima, not Stephen
>
>
>

[-- Attachment #2: Type: text/html, Size: 4829 bytes --]

  parent reply	other threads:[~2024-11-20 19:50 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
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 [this message]
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='CAHXF6-oSgtjofccj1K_a8pCWveM=b5mvgBqVdO42Jc_TqKDvww@mail.gmail.com' \
    --to=thea.rossman@cs.stanford.edu \
    --cc=Kompella.Purnima@commscope.com \
    --cc=stephen@networkplumber.org \
    --cc=tom.barbette@uclouvain.be \
    --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).