Re: [RFC] net: add experimental UDP encapsulation PMD

[Stephen Hemminger <stephen@networkplumber.org>]

On Tue, 11 Oct 2022 08:47:30 +0200
Morten Brørup <mb@smartsharesystems.com> wrote:

> > From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> > Sent: Tuesday, 11 October 2022 02.10
> > 
> > This is a new PMD which can be useful to test a DPDK application
> > from another test program. The PMD binds to a connected UDP socket
> > and expects to receive and send raw Ethernet packets over that
> > socket.
> > 
> > This is especially useful for testing envirionments where you
> > can't/don't want to give the test driver program route permission.
> > 
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---  
> 
> Good idea.
> 
> Multiple queues are supported, but how does the remote application steer traffic into specific queues (for PMD RX), or identify which queue the packet was supposed to egress on (for PMD TX)?

For Tx it relies on the fact that a UDP socket is idempotent so multiple Tx queues
just share a single file descriptor.

On Rx, there is no steering, it just has multiple threads reading on the same socket.
For testing this simulates multiple receivers being active.

> 
> You could use a range of UDP port numbers for that, so the second queue uses the UDP port number following the configured port number, etc..
> 
> Or you could open for feature creep. Here are some thoughts.
> 
> Add a metadata header in front of each packet - this might also allow more advanced use in the future, e.g. the remote application could set mbuf hash fields.
> 
> Consider if this PMD somehow can be integrated with the TUN/TAP PMD or something similar, and through that existing PMD support more advanced NIC features towards the DPDK application, such as VLAN stripping, GRO, etc..

The other alternative is making a VXLAN driver, which is on my TODO list.