Re: [PATCH v3 net-next 11/15] selftests: xsk: add a hardware mode to xskxceiver

["Björn Töpel" <bjorn@kernel.org>]

Maciej Fijalkowski <maciej.fijalkowski@intel.com> writes:

> drivers/net/hw/xsk.py, added later in this series, runs each hardware
> AF_XDP case as a zero-copy DUT endpoint and an SKB-mode remote endpoint
> over a physical link, without negotiating capabilities between them.
> Add what such a run needs to xskxceiver:
>
> - --hw sends UDP/IPv4 test packets (--udp-src, --udp-dst, --udp-port)
>   between the real interface MACs (--peer-mac); XDP_SHARED_UMEM, whose
>   program picks the socket by a synthetic destination MAC, skips

This reads weird to me.

I wonder if we can avoid introducing a separate "hardware" mode here? It
seems to bundle packet format, link handling, and assumptions about the
endpoint modes. Those are separate concerns, and much of this should
work with veth too, no?

Could we first make the real MAC addresses and IPv4/UDP format common to
both veth and physical-device runs?

Then --listen could work independently, timeouts could be configurable,
and test selection could reflect the actual endpoint modes and
capabilities. For example, skipping TX_QUEUE_CONSUMER because hw_test
implies mixed ZC/SKB endpoints seems to encode the launcher's current
configuration into the test itself. "Real" endpoints could also run the
same mode.

If we need to keep both packet formats, something like
--packet-format=udp would maybe describe it better. I'd prefer keeping
these behaviors independent rather than giving the combined mode another
name.

Also, we need IPv6 support here in addition to IPv4. You can't assume
that the DUT is onlink or IPv4.


Björn