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.