RFC - Tap io_uring PMD
The current tap device is slow both due to architectural choices and the overhead of Linux system calls. I am exploring a how to fix that but some of the choices require some tradeoffs. Which leads to some open questions:
1. DPDK tap also support tunnel (TUN) mode where there is no Ethernet header only L3. Does anyone actually use this? It is different than what every other PMD expects.
2. The fastest way to use kernel TAP device would be to use io_uring. But this was added in 5.1 kernel (2019). Rather than having conditional or dual mode in DPDK tap device, perhaps there should just be a new PMD tap_uring?
3. Current TAP device provides hooks for several rte_flow types by playing games with kernel qdisc. Does anyone really use this? Propose just not doing this in new tap_uring.
4. What other features of TAP device beyond basic send/receive make sense? It looks like new device could support better statistics.
5. What about Rx interrupt support?
Probably the hardest part of using io_uring is figuring out how to collect completions. The simplest way would be to handle all completions rx and tx in the rx_burst function.
Quoted 6 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Wednesday, 30 October 2024 22.57The current tap device is slow both due to architectural choices and the
overhead of Linux system calls.
Yes; but isn't it only being used for (low volume) management traffic? Is the TAP PMD performance an issue for anyone? What is their use case?
Or is the key issue that the TAP PMD makes system calls in the fast path, so you are looking to implement a new TAP PMD that doesn't make any system calls in the fast path?
Quoted 10 lines
I am exploring a how to fix that but
some
of the choices require some tradeoffs. Which leads to some open questions:1. DPDK tap also support tunnel (TUN) mode where there is no Ethernet header
only L3. Does anyone actually use this? It is different than what
every other
PMD expects.
If used for high volume (data plane) traffic, I would assume standard PMD behavior (i.e. incl. Ethernet headers) would suffice.
Quoted 6 lines
2. The fastest way to use kernel TAP device would be to use
io_uring. But this was added in 5.1 kernel (2019). Rather than having
conditional or
dual mode in DPDK tap device, perhaps there should just be a new PMDtap_uring?
If the features differ significantly, I'm in favor of a new PMD.
And it would be an opportunity to get rid of useless cruft, which I think you are already asking about here. :-)
Furthermore, a "clean sheet" implementation - adding all the experience accumulated since the old TAP PMD - could serve as showcase for "best practices" for software PMDs.
Quoted 10 lines
3. Current TAP device provides hooks for several
rte_flowtypes by playing
games with kernel qdisc. Does anyone really use this? Propose just
not doing
this in newtap_uring.4. What other features of TAP device beyond basic send/receive make sense?
It looks like new device could support better statistics.
IMHO, statistics about missed packets are relevant. If the ingress (kernel->DPDK) queue is full, and the kernel has to drop packets, this drop counter should be exposed to the application through the PMD.
I don't know if the existing TAP PMD supports it, but associating a port/queue with a "network namespace" or VRF in the kernel could also be relevant.
Quoted 2 lines
5. What about Rx interrupt support?
RX interrupt support seems closely related to power management.
It could be used to reduce jitter/latency (and burstiness) when someone on the network communicates with an in-band management interface.
Quoted 6 lines
Probably the hardest part of using
io_uringis figuring out how to collect
completions. The simplest way would be to handle all completions rx and tx
in therx_burstfunction.
Please don't mix RX and TX, unless explicitly requested by the application through the recently introduced "mbuf recycle" feature.
<side tracking>
Currently, rte_rx() does two jobs:
* Deliver packets received from the HW to the application.
* Replenish RX descriptors.
Similarly, rte_tx() does two jobs:
* Deliver packets to be transmitted from the application to the HW.
* Release completed TX descriptors.
It would complicate things, but these two associated jobs could be separated into separate functions, rx_pre_rx() for RX replenishment and tx_post_tx() for TX completion. This would also give latency sensitive applications more control over when to do what.
And it could introduce a TX completion interrupt.
</side tracking>
Why does this PMD need to handle TX completions differently than other PMDs?
Quoted 9 lines · On Thu, 31 Oct 2024 11:27:25 +0100 Morten Brørup <[email protected]>…
Quoted 6 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Wednesday, 30 October 2024 22.57The current tap device is slow both due to architectural choices and the
overhead of Linux system calls.Yes; but isn't it only being used for (low volume) management traffic? Is the TAP PMD performance an issue for anyone? What is their use case?
In embedded systems, if you want to use DPDK for dataplane, you still need to have a control plane path to the kernel. And most of the hardware used does not support a bifurcated driver. Either that or have two NIC's.
Quoted 2 lines
Or is the key issue that the TAP PMD makes system calls in the fast path, so you are looking to implement a new TAP PMD that doesn't make any system calls in the fast path?
Even the control path performance matters. Think of a router with lots BGP connections, or doing updates.
Quoted 15 lines
Quoted 11 lines
I am exploring a how to fix that but
some
of the choices require some tradeoffs. Which leads to some open questions:1. DPDK tap also support tunnel (TUN) mode where there is no Ethernet header
only L3. Does anyone actually use this? It is different than what
every other
PMD expects.If used for high volume (data plane) traffic, I would assume standard PMD behavior (i.e. incl. Ethernet headers) would suffice.
Quoted 1 line
Quoted 8 lines
Quoted 5 lines
2. The fastest way to use kernel TAP device would be to use
io_uring. But this was added in 5.1 kernel (2019). Rather than having
conditional or
dual mode in DPDK tap device, perhaps there should just be a new PMDtap_uring?If the features differ significantly, I'm in favor of a new PMD.
And it would be an opportunity to get rid of useless cruft, which I think you are already asking about here. :-)
Yes, and the TAP device was written to support a niche use case (all the flow stuff). Also TAP device has lots of extra code, at some point doing bit-by-bit cleanup gets annoying.
Quoted 10 lines
Furthermore, a "clean sheet" implementation - adding all the experience accumulated since the old TAP PMD - could serve as showcase for "best practices" for software PMDs.
Quoted 7 lines
3. Current TAP device provides hooks for several
rte_flowtypes by playing
games with kernel qdisc. Does anyone really use this? Propose just
not doing
this in newtap_uring.
Quoted 5 lines
Quoted 3 lines
4. What other features of TAP device beyond basic send/receive make sense?
It looks like new device could support better statistics.IMHO, statistics about missed packets are relevant. If the ingress (
kernel->DPDK) queue is full, and the kernel has to drop packets, this drop counter should be exposed to the application through the PMD.
It may require some kernel side additions to extract that, but not out of scope.
Quoted 2 lines
I don't know if the existing TAP PMD supports it, but associating a port/queue with a "network namespace" or VRF in the kernel could also be relevant.
All network devices can be put in network namespace; VRF in Linux is separate from netns it has to do with which routing table is associated with the net device.
Quoted 6 lines
Quoted 3 lines
5. What about Rx interrupt support?
RX interrupt support seems closely related to power management.
It could be used to reduce jitter/latency (and burstiness) when someone on the network communicates with an in-band management interface.
Not sure if ioring has wakeup mechanism, but probably epoll() is possible.
Quoted 9 lines
Quoted 7 lines
Probably the hardest part of using
io_uringis figuring out how to collect
completions. The simplest way would be to handle all completions rx and tx
in therx_burstfunction.Please don't mix RX and TX, unless explicitly requested by the application through the recently introduced "mbuf recycle" feature.
The issue is Rx and Tx share a single fd and ioring for completion is per fd. The implementation for ioring came from the storage side so initially it was for fixing the broken Linux AIO support.
Some other devices only have single interrupt or ring shared with rx/tx so not unique. Virtio, netvsc, and some NIC's.
The problem is that if Tx completes descriptors then there needs to be locking to prevent Rx thread and Tx thread overlapping. And a spin lock is a performance buzz kill.
Quoted 17 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Friday, 1 November 2024 01.35Quoted 4 lines · On Thu, 31 Oct 2024 11:27:25 +0100 Morten Brørup <[email protected]>…
Quoted 4 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Wednesday, 30 October 2024 22.57The current tap device is slow both due to architectural choices
and
Quoted 4 lines
Quoted 2 lines
the
overhead of Linux system calls.Yes; but isn't it only being used for (low volume) management
traffic?
Quoted 1 line
Is the TAP PMD performance an issue for anyone? What is their use
Quoted 8 lines
case?
In embedded systems, if you want to use DPDK for dataplane, you still need
to have a control plane path to the kernel. And most of the hardware used
does not support a bifurcated driver. Either that or have two NIC's.
Yes, our application does that (not using a bifurcated driver); it can be configured for in-band management or a dedicated management port.
Quoted 9 lines
Quoted 3 lines
Or is the key issue that the TAP PMD makes system calls in the fast
path, so you are looking to implement a new TAP PMD that doesn't make any system calls in the fast path?
Even the control path performance matters. Think of a router with lots BGP
connections, or doing updates.
BGP is an excellent example where performance matters.
(Our applications currently don't support BGP, so I'm used to a relatively low volume of management traffic, and didn't think about BGP.)
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
I am exploring a how to fix that but
some
of the choices require some tradeoffs. Which leads to some open questions:1. DPDK tap also support tunnel (TUN) mode where there is no
Ethernet
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
header
only L3. Does anyone actually use this? It is different thanwhat
Quoted 4 lines
Quoted 2 lines
every other
PMD expects.If used for high volume (data plane) traffic, I would assume standard
PMD behavior (i.e. incl. Ethernet headers) would suffice.
The traffic to/from the TAP port is likely to be exchanged with a physical port, so the packets will have an Ethernet header at this point.
Quoted 56 lines
Quoted 3 lines
Quoted 3 lines
2. The fastest way to use kernel TAP device would be to use
io_uring.Quoted 3 lines
Quoted 3 lines
But this was added in 5.1 kernel (2019). Rather than having
conditional or
dual mode in DPDK tap device, perhaps there should just be a newPMD
Quoted 4 lines
Quoted 1 line
tap_uring?If the features differ significantly, I'm in favor of a new PMD. And it would be an opportunity to get rid of useless cruft, which I
think you are already asking about here. :-)
Yes, and the TAP device was written to support a niche use case (all the flow stuff).
Also TAP device has lots of extra code, at some point doing bit-by-bit cleanup gets annoying.Quoted 2 lines
Furthermore, a "clean sheet" implementation - adding all the
experience accumulated since the old TAP PMD - could serve as showcase for "best practices" for software PMDs.
Quoted 5 lines
Quoted 5 lines
3. Current TAP device provides hooks for several
rte_flowtypes by playing
games with kernel qdisc. Does anyone really use this? Proposejust
Quoted 8 lines
Quoted 6 lines
not doing
this in newtap_uring.4. What other features of TAP device beyond basic send/receive make sense?
It looks like new device could support better statistics.IMHO, statistics about missed packets are relevant. If the ingress
(
kernel->DPDK) queue is full, and the kernel has to drop packets, this drop counter should be exposed to the application through the PMD.It may require some kernel side additions to extract that, but not out of scope.
Quoted 2 lines
I don't know if the existing TAP PMD supports it, but associating a
port/queue with a "network namespace" or VRF in the kernel could also be relevant.
All network devices can be put in network namespace; VRF in Linux is separate from netns it has to do with
which routing table is associated with the net device.Quoted 4 lines
Quoted 3 lines
5. What about Rx interrupt support?
Quoted 7 lines
Quoted 2 lines
RX interrupt support seems closely related to power management. It could be used to reduce jitter/latency (and burstiness) when
someone on the network communicates with an in-band management interface.
Not sure if ioring has wakeup mechanism, but probably
epoll()is possible.
Yes, it seems to be:
https://unixism.net/loti/tutorial/register_eventfd.html
Quoted 19 lines
Quoted 6 lines
Quoted 6 lines
Probably the hardest part of using
io_uringis figuring out how to collect
completions. The simplest way would be to handle all completions rxand
Quoted 4 lines
Quoted 2 lines
tx
in therx_burstfunction.Please don't mix RX and TX, unless explicitly requested by the
application through the recently introduced "mbuf recycle" feature.
The issue is Rx and Tx share a single fd and ioring for completion is per fd.
The implementation for ioring came from the storage side so initially it was for fixing
the broken Linux AIO support.
Quoted 8 lines
Some other devices only have single interrupt or ring shared with rx/tx so not unique.
Virtio, netvsc, and some NIC's.The problem is that if Tx completes descriptors then there needs to be locking
to prevent Rx thread and Tx thread overlapping. And a spin lock is a performance buzz kill.
Brainstorming a bit here...
What if the new TAP io_uring PMD is designed to use two io_urings per port, one for RX and another one for TX on the same TAP interface?
This requires that a TAP interface can be referenced via two file descriptors (one fd for the RX io_uring and another fd for the TX io_uring), e.g. by using dup() to create the additional file descriptor. I don't know if this is possible, and if it works with io_uring.
Quoted 21 lines · On Sat, 2 Nov 2024 23:28:49 +0100 Morten Brørup <[email protected]>…
Quoted 21 lines
Quoted 4 lines
Quoted 4 lines
Probably the hardest part of using
io_uringis figuring out how to collect
completions. The simplest way would be to handle all completions rxand
Quoted 4 lines
Quoted 2 lines
tx
in therx_burstfunction.Please don't mix RX and TX, unless explicitly requested by the
application through the recently introduced "mbuf recycle" feature.
The issue is Rx and Tx share a single fd and ioring for completion is per fd.
The implementation for ioring came from the storage side so initially it was for fixing
the broken Linux AIO support.Some other devices only have single interrupt or ring shared with rx/tx so not unique.
Virtio, netvsc, and some NIC's.
Quoted 8 lines
Quoted 4 lines
The problem is that if Tx completes descriptors then there needs to be locking
to prevent Rx thread and Tx thread overlapping. And a spin lock is a performance buzz kill.Brainstorming a bit here...
What if the new TAPio_uringPMD is designed to use twoio_uringsper port, one for RX and another one for TX on the same TAP interface?
This requires that a TAP interface can be referenced via two file descriptors (one fd for the RXio_uringand another fd for the TXio_uring), e.g. by usingdup()to create the additional file descriptor. I don't know if this is possible, and if it works withio_uring.
There a couple of problems with multiple fd's.
- multiple fds pointing to same internal tap queue are not going to get completed separately.
- when multi-proc is supported, limit of 253 fd's in Unix domain IPC comes into play
- tap does not support tx only fd for queues. If fd is queue of tap, receive fan out will go to it.
If DPDK was more flexible, harvesting of completion could be done via another thread but that is not general enough to work transparently with all applications. Existing TAP device plays with SIGIO, but signals are slower.
Quoted 56 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Tuesday, 5 November 2024 19.59Quoted 2 lines · On Sat, 2 Nov 2024 23:28:49 +0100 Morten Brørup <[email protected]>…
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Probably the hardest part of using
io_uringis figuring out howto
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
collect
completions. The simplest way would be to handle allcompletions rx
Quoted 8 lines
Quoted 8 lines
and
Quoted 4 lines
Quoted 2 lines
tx
in therx_burstfunction.Please don't mix RX and TX, unless explicitly requested by the
application through the recently introduced "mbuf recycle" feature.
The issue is Rx and Tx share a single fd and ioring for completion
is
Quoted 2 lines
Quoted 2 lines
per fd.
The implementation for ioring came from the storage side soinitially
Quoted 4 lines
Quoted 4 lines
it was for fixing
the broken Linux AIO support.Some other devices only have single interrupt or ring shared with
rx/tx
Quoted 4 lines
Quoted 4 lines
so not unique.
Virtio, netvsc, and some NIC's.The problem is that if Tx completes descriptors then there needs to
be
Quoted 2 lines
Quoted 2 lines
locking
to prevent Rx thread and Tx thread overlapping. And a spin lock isa
Quoted 4 lines
Quoted 1 line
performance buzz kill.
Brainstorming a bit here...
What if the new TAPio_uringPMD is designed to use twoio_uringsperport, one for RX and another one for TX on the same TAP interface?
Quoted 1 line
This requires that a TAP interface can be referenced via two file
descriptors (one fd for the RX
io_uringand another fd for the TXio_uring), e.g. by usingdup()to create the additional file descriptor. I don't know if this is possible, and if it works withio_uring.There a couple of problems with multiple fd's.
- multiple fds pointing to same internal tap queue are not going to
get completed separately.
- when multi-proc is supported, limit of 253 fd's in Unix domain IPC
comes into play
- tap does not support tx only fd for queues. If fd is queue of tap,
receive fan out will go to it.
Quoted 4 lines
If DPDK was more flexible, harvesting of completion could be done via another thread but that is not general enough
to work transparently with all applications. Existing TAP device plays with SIGIO, but signals are slower.
I have now read up a bit about io_uring, so here are some thoughts and ideas...
To avoid locking, there should only be one writer of io_uring Submission Queue Events (SQE), and only one reader of io_uring Completion Queue Events (CQE) per TAP interface.
From what I understand, the TAP io_uring PMD only supports one RX queue per port and one TX queue per port (i.e. per TAP interface). We can take advantage of this:
We can use rte_tx() as the Submission Queue writer and rte_rx() as the Completion Queue reader.
The PMD must have two internal rte_rings for respectively RX refill and TX completion events.
rte_rx() does the following:
Read the Completion Queue;
If RX CQE, pass the data to the next RX MBUF, convert the RX CQE to an RX Refill SQE and enqueue it in the RX Refill rte_ring;
If TX CQE, enqueue it in the TX Completion rte_ring;
Repeat until nb_pkts RX CQEs have been received, or no more CQE's are available. (This complies with the rte_rx() API, which says that less than nb_pkts is only returned if no more packets are available for receiving.)
rte_tx() does the following:
Pass the data from the TX MBUFs to io_uring TX SQEs, using the TX CQEs in the TX Completion rte_ring, and write them to the io_uring Submission Queue. Dequeue any RX Refill SQEs from the RX Refill rte_ring and write them to the io_uring Submission Queue.
This means that the application must call both rte_rx() and rte_tx(); but it would be allowed to call rte_tx() with zero MBUFs.
The internal rte_rings are Single-Producer, Single-Consumer, and large enough to hold all TX+RX descriptors.
Alternatively, we can let rte_rx() do all the work and use an rte_ring in the opposite direction...
The PMD must have two internal rte_rings, one for TX MBUFs and one for TX CQEs. (The latter can be a stack, or any other type of container.)
rte_tx() only does the following:
Enqueue the TX MBUFs to the TX MBUF rte_ring.
rte_rx() does the following:
Dequeue any TX MBUFs from the TX MBUF rte_ring, convert them to TX SQEs, using the TX CQEs in the TX Completion rte_ring, and write them to the io_uring Submission Queue.
Read the Completion Queue;
If TX CQE, enqueue it in the TX Completion rte_ring;
If RX CQE, pass the data to the next RX MBUF, convert the RX CQE to an RX Refill SQE and write it to the io_uring Submission Queue;
Repeat until nb_pkts RX CQEs have been received, or no more CQE's are available. (This complies with the rte_rx() API, which says that less than nb_pkts is only returned if no more packets are available for receiving.)
With the second design, the PMD can support multiple TX queues by using a Multi-Producer rte_ring for the TX MBUFs. But it postpones all transmits until rte_rx() is called, so I don't really like it.
Of the two designs, the first feels more natural to me.
And if some application absolutely needs multiple TX queues, it can implement a Multi-Producer, Single-Consumer rte_ring as an intermediate step in front of the PMD's single TX queue.
Quoted 1 line · On Wed, 6 Nov 2024 00:22:19 +0100 Morten Brørup <[email protected]>…
From what I understand, the TAP
io_uringPMD only supports one RX queue per port and one TX queue per port (i.e. per TAP interface). We can take advantage of this:
No kernel tap support multi queue and we need to use that.
Quoted 6 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Wednesday, 6 November 2024 00.26On Wed, 6 Nov 2024 00:22:19 +0100
Morten Brørup <[email protected]> wrote:
Quoted 6 lines
Quoted 1 line
From what I understand, the TAP
io_uringPMD only supports one RXqueue per port and one TX queue per port (i.e. per TAP interface). We can take advantage of this:
No kernel tap support multi queue and we need to use that.
Maybe I got it wrong then... I thought you said fanout (of kernel->TAP packets) would affect all fds associated with the TAP interface. How can the application then use multiple queues?
Another thing is:
For which purposes do applications need multi queue support for TAP, considering the interface is for management traffic only? If single queue suffices, it might make the PMD simpler.
On the other hand, it is more important making it simple for the application than making a simple PMD! :-)
Quoted 12 lines · Morten Brørup
Quoted 12 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Wednesday, 6 November 2024 00.26Quoted 1 line · On Wed, 6 Nov 2024 00:22:19 +0100 Morten Brørup <[email protected]>…
From what I understand, the TAP
io_uringPMD only supports one RXqueue per port and one TX queue per port (i.e. per TAP interface). We can take advantage of this:
Quoted 7 lines
Quoted 1 line
No kernel tap support multi queue and we need to use that.
Maybe I got it wrong then... I thought you said fanout (of
kernel->TAPpackets) would affect all fds associated with the TAP interface. How can the application then use multiple queues?Another thing is:
For which purposes do applications need multi queue support for TAP, considering the interface is for management traffic only?
I've previously used net_pcap as well as net_af_packet PMDs for debugging/testing and even benchmarking purposes. I'd set up a software interface, then feed test traffic via tcpreplay. Some of the limitations I've encountered are:
- net_af_packet does not report received/missed packet counters
- net_pcap does not have multi queue support (AFAIK)
As an example, non symmetric RSS configurations may cause 2-way TCP packets to be steered to different queues. If your application is a worker-per-queue application with no shared state, you might want to have these packets to be steered to the same queue instead. Without multi queue, you can't easily test against scenarios like that.
Though, as you've said, if TAP is for management only, perhaps I was trying to use the wrong tool for the wrong job.
In the end, I ended up getting a real two port NIC (feeding traffic from one port to the other) because software PMDs are not similar enough to the actual hardware.
--
Igor
Quoted 35 lines · On Wed, 6 Nov 2024 03:52:51 +0300 Igor Gutorov <[email protected]> wrote:
Quoted 12 lines · Morten Brørup
Quoted 12 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Wednesday, 6 November 2024 00.26Quoted 1 line · On Wed, 6 Nov 2024 00:22:19 +0100 Morten Brørup <[email protected]>…
From what I understand, the TAP
io_uringPMD only supports one RXqueue per port and one TX queue per port (i.e. per TAP interface). We can take advantage of this:
Quoted 7 lines
Quoted 1 line
No kernel tap support multi queue and we need to use that.
Maybe I got it wrong then... I thought you said fanout (of
kernel->TAPpackets) would affect all fds associated with the TAP interface. How can the application then use multiple queues?Another thing is:
For which purposes do applications need multi queue support for TAP, considering the interface is for management traffic only?I've previously used
net_pcapas well asnet_af_packetPMDs for debugging/testing and even benchmarking purposes. I'd set up a software interface, then feed test traffic viatcpreplay. Some of the limitations I've encountered are:-
net_af_packetdoes not report received/missed packet counters
-net_pcapdoes not have multi queue support (AFAIK)As an example, non symmetric RSS configurations may cause 2-way TCP packets to be steered to different queues. If your application is a worker-per-queue application with no shared state, you might want to have these packets to be steered to the same queue instead. Without multi queue, you can't easily test against scenarios like that.
Quoted 5 lines
Though, as you've said, if TAP is for management only, perhaps I was trying to use the wrong tool for the wrong job.
In the end, I ended up getting a real two port NIC (feeding traffic from one port to the other) because software PMDs are not similar enough to the actual hardware.
DPDK interactions with kernel devices is complicated, there are overlapping drivers:
- TAP - uses Linux tap device
- PCAP - uses libpcap which ends up using af_packet
- AF_PACKET - uses af_packet
- AF_XDP - uses XDP
- Virtio user - relies on vhost in kernel
There are lots of differences in performance, control usage, and other details between these.
The proposal is to do simpler faster version of the TAP.
Will also do some comparisons and detail (maybe presentation or document) on all the others later.
So far, have a basic driver that does setup and basic management operations; still working on details of the ring stuff.
Quoted 102 lines
Quoted 51 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Probably the hardest part of using
io_uringis figuring out howto
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
collect
completions. The simplest way would be to handle allcompletions rx
Quoted 8 lines
Quoted 8 lines
and
Quoted 4 lines
Quoted 2 lines
tx
in therx_burstfunction.Please don't mix RX and TX, unless explicitly requested by the
application through the recently introduced "mbuf recycle" feature.
The issue is Rx and Tx share a single fd and ioring for completion
is
Quoted 2 lines
Quoted 2 lines
per fd.
The implementation for ioring came from the storage side soinitially
Quoted 4 lines
Quoted 4 lines
it was for fixing
the broken Linux AIO support.Some other devices only have single interrupt or ring shared with
rx/tx
Quoted 4 lines
Quoted 4 lines
so not unique.
Virtio, netvsc, and some NIC's.The problem is that if Tx completes descriptors then there needs to
be
Quoted 2 lines
Quoted 2 lines
locking
to prevent Rx thread and Tx thread overlapping. And a spin lock isa
Quoted 4 lines
Quoted 1 line
performance buzz kill.
Brainstorming a bit here...
What if the new TAPio_uringPMD is designed to use twoio_uringsperport, one for RX and another one for TX on the same TAP interface?
Quoted 1 line
This requires that a TAP interface can be referenced via two file
descriptors (one fd for the RX
io_uringand another fd for the TXio_uring), e.g. by usingdup()to create the additional file descriptor. I don't know if this is possible, and if it works withio_uring.There a couple of problems with multiple fd's.
- multiple fds pointing to same internal tap queue are not going to
get completed separately.
- when multi-proc is supported, limit of 253 fd's in Unix domain IPC
comes into play
- tap does not support tx only fd for queues. If fd is queue of tap,
receive fan out will go to it.Quoted 4 lines
If DPDK was more flexible, harvesting of completion could be done via another thread but that is not general enough
to work transparently with all applications. Existing TAP device plays with SIGIO, but signals are slower.I have now read up a bit about
io_uring, so here are some thoughts and ideas...To avoid locking, there should only be one writer of
io_uringSubmission Queue Events (SQE), and only one reader ofio_uringCompletion Queue Events (CQE) per TAP interface.From what I understand, the TAP
io_uringPMD only supports one RX queue per port and one TX queue per port (i.e. per TAP interface). We can take advantage of this:We can use
rte_tx()as the Submission Queue writer andrte_rx()as the Completion Queue reader.The PMD must have two internal
rte_ringsfor respectively RX refill and TX completion events.
rte_rx()does the following:
Read the Completion Queue;
If RX CQE, pass the data to the next RX MBUF, convert the RX CQE to an RX Refill SQE and enqueue it in the RX Refillrte_ring; If TX CQE, enqueue it in the TX Completionrte_ring;
Repeat untilnb_pktsRX CQEs have been received, or no more CQE's are available. (This complies with therte_rx()API, which says that less thannb_pktsis only returned if no more packets are available for receiving.)
rte_tx()does the following:
Pass the data from the TX MBUFs toio_uringTX SQEs, using the TX CQEs in the TX Completionrte_ring, and write them to theio_uringSubmission Queue.
Dequeue any RX Refill SQEs from the RX Refillrte_ringand write them to theio_uringSubmission Queue.This means that the application must call both
rte_rx()andrte_tx(); but it would be allowed to callrte_tx()with zero MBUFs.The internal
rte_ringsare Single-Producer, Single-Consumer, and large enough to hold all TX+RX descriptors.Alternatively, we can let
rte_rx()do all the work and use anrte_ringin the opposite direction...The PMD must have two internal
rte_rings, one for TX MBUFs and one for TX CQEs. (The latter can be a stack, or any other type of container.)
rte_tx()only does the following:
Enqueue the TX MBUFs to the TX MBUFrte_ring.
rte_rx()does the following:
Dequeue any TX MBUFs from the TX MBUFrte_ring, convert them to TX SQEs, using the TX CQEs in the TX Completionrte_ring, and write them to theio_uringSubmission Queue.
Read the Completion Queue;
If TX CQE, enqueue it in the TX Completionrte_ring;
If RX CQE, pass the data to the next RX MBUF, convert the RX CQE to an RX Refill SQE and write it to theio_uringSubmission Queue; Repeat untilnb_pktsRX CQEs have been received, or no more CQE's are available. (This complies with therte_rx()API, which says that less thannb_pktsis only returned if no more packets are available for receiving.)
Quoted 6 lines
With the second design, the PMD can support multiple TX queues by using a Multi-Producer
rte_ringfor the TX MBUFs. But it postpones all transmits untilrte_rx()is called, so I don't really like it.Of the two designs, the first feels more natural to me.
And if some application absolutely needs multiple TX queues, it can implement a Multi-Producer, Single-Consumerrte_ringas an intermediate step in front of the PMD's single TX queue.
And why we can't simply have 2 io_uring(s): one for RX ops, second for TX ops?
[Public]
Snipped
Quoted 9 lines
The current tap device is slow both due to architectural choices and the overhead of Linux system calls. I am exploring a how to fix that but some of the choices require some tradeoffs. Which leads to some open questions:
1. DPDK tap also support tunnel (TUN) mode where there is no Ethernet header only L3. Does anyone actually use this? It is different than what every other PMD expects.
Hi Stephen, TUN interface were added in 2017 to support couple of use cases in teleco (ipsec tunneling) based on actual uses cases from user space stack. But I am not sure if anyone is using the same now.
Follow up question, is not TUN rx-tx sperate function from TAP?
Note: I am open to get this removed or separated if it is not used much.
Quoted 10 lines
2. The fastest way to use kernel TAP device would be to use
io_uring. But this was added in 5.1 kernel (2019). Rather than having conditional or dual mode in DPDK tap device, perhaps there should just be a new PMDtap_uring?3. Current TAP device provides hooks for several
rte_flowtypes by playing games with kernel qdisc. Does anyone really use this? Propose just not doing this in newtap_uring.
Quoted 8 lines
4. What other features of TAP device beyond basic send/receive make sense? It looks like new device could support better statistics.
5. What about Rx interrupt support?
Probably the hardest part of using
io_uringis figuring out how to collect completions. The simplest way would be to handle all completions rx and tx in therx_burstfunction.
For the above questions from 2 to 5, I do like the idea of exploring better alternatives.
Hi Stephen,
Quoted 16 lines · Stephen Hemminger
The current tap device is slow both due to architectural choices and the overhead of Linux system calls. I am exploring a how to fix that but some of the choices require some tradeoffs. Which leads to some open questions:
1. DPDK tap also support tunnel (TUN) mode where there is no Ethernet header only L3. Does anyone actually use this? It is different than what every other PMD expects.
2. The fastest way to use kernel TAP device would be to use
io_uring. But this was added in 5.1 kernel (2019). Rather than having conditional or dual mode in DPDK tap device, perhaps there should just be a new PMDtap_uring?3. Current TAP device provides hooks for several
rte_flowtypes by playing games with kernel qdisc. Does anyone really use this? Propose just not doing this in newtap_uring.
Quoted 9 lines
4. What other features of TAP device beyond basic send/receive make sense? It looks like new device could support better statistics.
5. What about Rx interrupt support?
Probably the hardest part of using
io_uringis figuring out how to collect completions. The simplest way would be to handle all completions rx and tx in therx_burstfunction.
Why not just use Virtio-user PMD with Vhost-kernel backend [0]? Are there any missing features that io_uring can address?
Regards,
Maxime
[0]: http://doc.dpdk.org/guides/howto/virtio_user_as_exception_path.html
Quoted 12 lines
From: Maxime Coquelin [mailto:[email protected]]
Sent: Wednesday, 6 November 2024 08.47Hi Stephen,
Quoted 1 line · Stephen Hemminger
The current tap device is slow both due to architectural choices and
the
Quoted 1 line
overhead of Linux system calls. I am exploring a how to fix that but
some
Quoted 1 line
of the choices require some tradeoffs. Which leads to some open
questions:
[...]
Quoted 9 lines
Why not just use Virtio-user PMD with Vhost-kernel backend [0]? Are there any missing features that
io_uringcan address?Regards,
Maxime[0]:
http://doc.dpdk.org/guides/howto/virtio_user_as_exception_path.html
Thanks for the pointer, Maxime.
After taking a look at it, I think this is exactly what we were looking for!
Quoted 29 lines · On Wed, 6 Nov 2024 08:46:55 +0100 Maxime Coquelin <[email protected]>…
Hi Stephen,
Quoted 16 lines · Stephen Hemminger
The current tap device is slow both due to architectural choices and the overhead of Linux system calls. I am exploring a how to fix that but some of the choices require some tradeoffs. Which leads to some open questions:
1. DPDK tap also support tunnel (TUN) mode where there is no Ethernet header only L3. Does anyone actually use this? It is different than what every other PMD expects.
2. The fastest way to use kernel TAP device would be to use
io_uring. But this was added in 5.1 kernel (2019). Rather than having conditional or dual mode in DPDK tap device, perhaps there should just be a new PMDtap_uring?3. Current TAP device provides hooks for several
rte_flowtypes by playing games with kernel qdisc. Does anyone really use this? Propose just not doing this in newtap_uring.Quoted 9 lines
4. What other features of TAP device beyond basic send/receive make sense? It looks like new device could support better statistics.
5. What about Rx interrupt support?
Probably the hardest part of using
io_uringis figuring out how to collect completions. The simplest way would be to handle all completions rx and tx in therx_burstfunction.
Quoted 8 lines
Why not just use Virtio-user PMD with Vhost-kernel backend [0]? Are there any missing features that
io_uringcan address?Regards,
Maxime[0]: http://doc.dpdk.org/guides/howto/virtio_user_as_exception_path.html
Yes, I looked at that but:
- virtio user ends up with a busy kernel thread which is not acceptable in SOC environment where all resources are locked down. In the SOC I was working on DPDK was limited to 4 polling isolated CPU's and 1 sleeping main thread. The rest of the CPU resources were hard constrained by cgroups. The virtio user thread was a problem.
- virtio user device is not persistent. If DPDK is being used a dataplane, need to be able to quickly restart and not disturb applications and routing in the kernel while the tap device is unavailable. I.e having device present but in no carrier state is better than having to teach applications about hot plug or play around with multiple addresses on loopback device (which is what Cisco routers do).
Quoted 16 lines
From: Stephen Hemminger [mailto:[email protected]]
Sent: Tuesday, 12 November 2024 06.21Quoted 8 lines · On Wed, 6 Nov 2024 08:46:55 +0100 Maxime Coquelin <[email protected]>…
Why not just use Virtio-user PMD with Vhost-kernel backend [0]? Are there any missing features that
io_uringcan address?Regards,
Maxime[0]:
http://doc.dpdk.org/guides/howto/virtio_user_as_exception_path.html
Quoted 1 line
Quoted 10 lines
Yes, I looked at that but:
- virtio user ends up with a busy kernel thread which is not
acceptable
in SOC environment where all resources are locked down. In the SOC
I was working
on DPDK was limited to 4 polling isolated CPU's and 1 sleeping main
thread.
The rest of the CPU resources were hard constrained by cgroups. The
virtio user
thread was a problem.
I suppose the Kernel needs to schedule CPU resources to process the packets at some point anyway.
So how does the ioring driver improve the situation with the virtio-user thread? I.e. what's the difference in the way the Kernel handles these two types of drivers?
And a slightly related question: Are there any differences in throughput, latency or other performance metrics? (At very high bandwidth, scheduling latency matters; the "latency" parameter of the BDP becomes dominant.)
Overall, I'm trying to figure out when to use the virtio-user PMD, and when to use the ioring PMD. Eventually, this should be described in the driver documentation or a user guide.
Quoted 11 lines
- virtio user device is not persistent. If DPDK is being used a
dataplane, need to
be able to quickly restart and not disturb applications and routing
in the kernel
while the tap device is unavailable. I.e having device present but
in no carrier
state is better than having to teach applications about hot plug or
play around
with multiple addresses on loopback device (which is what Cisco
routers do).
virtio-user device persistence can probably be achieved in some other way.
(E.g. a persistent user space daemon could be used as a middle man for allocation. Just an idea; probably better solutions are available, if given more brain cycles.)