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 --]
next prev 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).