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

> > From: Stephen Hemminger [mailto:step...@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 <step...@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.

Reply via email to