Re: [PATCH net-next v2 3/3] tun: AF_XDP Tx zero-copy support
On Wed, Feb 28, 2024 at 07:05:56PM +0800, Yunjian Wang wrote:
> This patch set allows TUN to support the AF_XDP Tx zero-copy feature,
> which can significantly reduce CPU utilization for XDP programs.
Why no Rx ZC support though? What will happen if I try rxdrop xdpsock
against tun with this patch? You clearly allow for that.
>
> Since commit fc72d1d54dd9 ("tuntap: XDP transmission"), the pointer
> ring has been utilized to queue different types of pointers by encoding
> the type into the lower bits. Therefore, we introduce a new flag,
> TUN_XDP_DESC_FLAG(0x2UL), which allows us to enqueue XDP descriptors
> and differentiate them from XDP buffers and sk_buffs. Additionally, a
> spin lock is added for enabling and disabling operations on the xsk pool.
>
> The performance testing was performed on a Intel E5-2620 2.40GHz machine.
> Traffic were generated/send through TUN(testpmd txonly with AF_XDP)
> to VM (testpmd rxonly in guest).
>
> +--+-+-+-+
> | | copy |zero-copy| speedup |
> +--+-+-+-+
> | UDP | Mpps | Mpps |%|
> | 64 | 2.5 | 4.0 | 60% |
> | 512 | 2.1 | 3.6 | 71% |
> | 1024 | 1.9 | 3.3 | 73% |
> +--+-+-+-+
>
> Signed-off-by: Yunjian Wang
> ---
> drivers/net/tun.c | 177 +++--
> drivers/vhost/net.c| 4 +
> include/linux/if_tun.h | 32
> 3 files changed, 208 insertions(+), 5 deletions(-)
>
Re: [PATCH net-next] sfc: reduce the number of requested xdp ev queues
On Thu, Jan 21, 2021 at 06:11:30PM +0100, Jesper Dangaard Brouer wrote:
> On Wed, 20 Jan 2021 13:27:59 -0800
> Ivan Babrou wrote:
>
> > Without this change the driver tries to allocate too many queues,
> > breaching the number of available msi-x interrupts on machines
> > with many logical cpus and default adapter settings:
> >
> > Insufficient resources for 12 XDP event queues (24 other channels, max 32)
> >
> > Which in turn triggers EINVAL on XDP processing:
> >
> > sfc :86:00.0 ext0: XDP TX failed (-22)
Please mention in commit message *how* you are addressing/fixing this
issue.
> >
> > Signed-off-by: Ivan Babrou
> > ---
>
> I guess the patch is good in itself due to available msi-x interrupts.
>
> Per earlier discussion: What will happen if a CPU with an ID higher
> than available XDP TX-queues redirect a packet out this driver?
+1 on that question
>
>
> > drivers/net/ethernet/sfc/efx_channels.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/sfc/efx_channels.c
> > b/drivers/net/ethernet/sfc/efx_channels.c
> > index a4a626e9cd9a..1bfeee283ea9 100644
> > --- a/drivers/net/ethernet/sfc/efx_channels.c
> > +++ b/drivers/net/ethernet/sfc/efx_channels.c
> > @@ -17,6 +17,7 @@
> > #include "rx_common.h"
> > #include "nic.h"
> > #include "sriov.h"
> > +#include "workarounds.h"
> >
> > /* This is the first interrupt mode to try out of:
> > * 0 => MSI-X
> > @@ -137,6 +138,7 @@ static int efx_allocate_msix_channels(struct efx_nic
> > *efx,
> > {
> > unsigned int n_channels = parallelism;
> > int vec_count;
> > + int tx_per_ev;
> > int n_xdp_tx;
> > int n_xdp_ev;
> >
> > @@ -149,9 +151,9 @@ static int efx_allocate_msix_channels(struct efx_nic
> > *efx,
> > * multiple tx queues, assuming tx and ev queues are both
> > * maximum size.
> > */
> > -
> > + tx_per_ev = EFX_MAX_EVQ_SIZE / EFX_TXQ_MAX_ENT(efx);
> > n_xdp_tx = num_possible_cpus();
> > - n_xdp_ev = DIV_ROUND_UP(n_xdp_tx, EFX_MAX_TXQ_PER_CHANNEL);
> > + n_xdp_ev = DIV_ROUND_UP(n_xdp_tx, tx_per_ev);
> >
> > vec_count = pci_msix_vec_count(efx->pci_dev);
> > if (vec_count < 0)
>
>
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
>
Re: [PATCH net v3] ixgbe: fix double clean of tx descriptors with xdp
On Thu, 22 Aug 2019 20:12:37 +0300
Ilya Maximets wrote:
> Tx code doesn't clear the descriptors' status after cleaning.
> So, if the budget is larger than number of used elems in a ring, some
> descriptors will be accounted twice and xsk_umem_complete_tx will move
> prod_tail far beyond the prod_head breaking the completion queue ring.
>
> Fix that by limiting the number of descriptors to clean by the number
> of used descriptors in the tx ring.
>
> 'ixgbe_clean_xdp_tx_irq()' function refactored to look more like
> 'ixgbe_xsk_clean_tx_ring()' since we're allowed to directly use
> 'next_to_clean' and 'next_to_use' indexes.
>
> Fixes: 8221c5eba8c1 ("ixgbe: add AF_XDP zero-copy Tx support")
> Signed-off-by: Ilya Maximets
> ---
>
> Version 3:
> * Reverted some refactoring made for v2.
> * Eliminated 'budget' for tx clean.
> * prefetch returned.
>
> Version 2:
> * 'ixgbe_clean_xdp_tx_irq()' refactored to look more like
> 'ixgbe_xsk_clean_tx_ring()'.
>
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 29
> 1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> index 6b609553329f..a3b6d8c89127 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> @@ -633,19 +633,17 @@ static void ixgbe_clean_xdp_tx_buffer(struct ixgbe_ring
> *tx_ring,
> bool ixgbe_clean_xdp_tx_irq(struct ixgbe_q_vector *q_vector,
> struct ixgbe_ring *tx_ring, int napi_budget)
While you're at it, can you please as well remove the 'napi_budget' argument?
It wasn't used at all even before your patch.
I'm jumping late in, but I was really wondering and hesitated with taking
part in discussion since the v1 of this patch - can you elaborate why simply
clearing the DD bit wasn't sufficient?
Maciej
> {
> + u16 ntc = tx_ring->next_to_clean, ntu = tx_ring->next_to_use;
> unsigned int total_packets = 0, total_bytes = 0;
> - u32 i = tx_ring->next_to_clean, xsk_frames = 0;
> - unsigned int budget = q_vector->tx.work_limit;
> struct xdp_umem *umem = tx_ring->xsk_umem;
> union ixgbe_adv_tx_desc *tx_desc;
> struct ixgbe_tx_buffer *tx_bi;
> - bool xmit_done;
> + u32 xsk_frames = 0;
>
> - tx_bi = &tx_ring->tx_buffer_info[i];
> - tx_desc = IXGBE_TX_DESC(tx_ring, i);
> - i -= tx_ring->count;
> + tx_bi = &tx_ring->tx_buffer_info[ntc];
> + tx_desc = IXGBE_TX_DESC(tx_ring, ntc);
>
> - do {
> + while (ntc != ntu) {
> if (!(tx_desc->wb.status & cpu_to_le32(IXGBE_TXD_STAT_DD)))
> break;
>
> @@ -661,22 +659,18 @@ bool ixgbe_clean_xdp_tx_irq(struct ixgbe_q_vector
> *q_vector,
>
> tx_bi++;
> tx_desc++;
> - i++;
> - if (unlikely(!i)) {
> - i -= tx_ring->count;
> + ntc++;
> + if (unlikely(ntc == tx_ring->count)) {
> + ntc = 0;
> tx_bi = tx_ring->tx_buffer_info;
> tx_desc = IXGBE_TX_DESC(tx_ring, 0);
> }
>
> /* issue prefetch for next Tx descriptor */
> prefetch(tx_desc);
> + }
>
> - /* update budget accounting */
> - budget--;
> - } while (likely(budget));
> -
> - i += tx_ring->count;
> - tx_ring->next_to_clean = i;
> + tx_ring->next_to_clean = ntc;
>
> u64_stats_update_begin(&tx_ring->syncp);
> tx_ring->stats.bytes += total_bytes;
> @@ -688,8 +682,7 @@ bool ixgbe_clean_xdp_tx_irq(struct ixgbe_q_vector
> *q_vector,
> if (xsk_frames)
> xsk_umem_complete_tx(umem, xsk_frames);
>
> - xmit_done = ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
> - return budget > 0 && xmit_done;
> + return ixgbe_xmit_zc(tx_ring, q_vector->tx.work_limit);
> }
>
> int ixgbe_xsk_async_xmit(struct net_device *dev, u32 qid)
Re: [PATCH net-next 3/4] mvpp2: add basic XDP support
On Thu, Jul 02, 2020 at 11:08:19AM +0300, ilias.apalodi...@linaro.org wrote:
> On Tue, Jun 30, 2020 at 08:09:29PM +0200, Matteo Croce wrote:
> > From: Matteo Croce
> >
> > Add XDP native support.
> > By now only XDP_DROP, XDP_PASS and XDP_REDIRECT
> > verdicts are supported.
> >
> > Co-developed-by: Sven Auhagen
> > Signed-off-by: Sven Auhagen
> > Signed-off-by: Matteo Croce
> > ---
>
> [...]
>
> > }
> >
> > +static int
> > +mvpp2_run_xdp(struct mvpp2_port *port, struct mvpp2_rx_queue *rxq,
> > + struct bpf_prog *prog, struct xdp_buff *xdp,
> > + struct page_pool *pp)
> > +{
> > + unsigned int len, sync, err;
> > + struct page *page;
> > + u32 ret, act;
> > +
> > + len = xdp->data_end - xdp->data_hard_start - MVPP2_SKB_HEADROOM;
> > + act = bpf_prog_run_xdp(prog, xdp);
> > +
> > + /* Due xdp_adjust_tail: DMA sync for_device cover max len CPU touch */
> > + sync = xdp->data_end - xdp->data_hard_start - MVPP2_SKB_HEADROOM;
> > + sync = max(sync, len);
> > +
> > + switch (act) {
> > + case XDP_PASS:
> > + ret = MVPP2_XDP_PASS;
> > + break;
> > + case XDP_REDIRECT:
> > + err = xdp_do_redirect(port->dev, xdp, prog);
> > + if (unlikely(err)) {
> > + ret = MVPP2_XDP_DROPPED;
> > + page = virt_to_head_page(xdp->data);
> > + page_pool_put_page(pp, page, sync, true);
> > + } else {
> > + ret = MVPP2_XDP_REDIR;
> > + }
> > + break;
> > + default:
> > + bpf_warn_invalid_xdp_action(act);
> > + fallthrough;
> > + case XDP_ABORTED:
> > + trace_xdp_exception(port->dev, prog, act);
> > + fallthrough;
> > + case XDP_DROP:
> > + page = virt_to_head_page(xdp->data);
> > + page_pool_put_page(pp, page, sync, true);
> > + ret = MVPP2_XDP_DROPPED;
> > + break;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > /* Main rx processing */
> > static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
> > int rx_todo, struct mvpp2_rx_queue *rxq)
> > {
> > struct net_device *dev = port->dev;
> > + struct bpf_prog *xdp_prog;
> > + struct xdp_buff xdp;
> > int rx_received;
> > int rx_done = 0;
> > + u32 xdp_ret = 0;
> > u32 rcvd_pkts = 0;
> > u32 rcvd_bytes = 0;
> >
> > + rcu_read_lock();
> > +
> > + xdp_prog = READ_ONCE(port->xdp_prog);
> > +
> > /* Get number of received packets and clamp the to-do */
> > rx_received = mvpp2_rxq_received(port, rxq->id);
> > if (rx_todo > rx_received)
> > @@ -3060,7 +3115,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct
> > napi_struct *napi,
> > dma_addr_t dma_addr;
> > phys_addr_t phys_addr;
> > u32 rx_status;
> > - int pool, rx_bytes, err;
> > + int pool, rx_bytes, err, ret;
> > void *data;
> >
> > rx_done++;
> > @@ -3096,6 +3151,33 @@ static int mvpp2_rx(struct mvpp2_port *port, struct
> > napi_struct *napi,
> > else
> > frag_size = bm_pool->frag_size;
> >
> > + if (xdp_prog) {
> > + xdp.data_hard_start = data;
> > + xdp.data = data + MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM;
> > + xdp.data_end = xdp.data + rx_bytes;
> > + xdp.frame_sz = PAGE_SIZE;
> > +
> > + if (bm_pool->pkt_size == MVPP2_BM_SHORT_PKT_SIZE)
> > + xdp.rxq = &rxq->xdp_rxq_short;
> > + else
> > + xdp.rxq = &rxq->xdp_rxq_long;
> > +
> > + xdp_set_data_meta_invalid(&xdp);
> > +
> > + ret = mvpp2_run_xdp(port, rxq, xdp_prog, &xdp, pp);
> > +
> > + if (ret) {
> > + xdp_ret |= ret;
> > + err = mvpp2_rx_refill(port, bm_pool, pp, pool);
> > + if (err) {
> > + netdev_err(port->dev, "failed to refill
> > BM pools\n");
> > + goto err_drop_frame;
> > + }
> > +
> > + continue;
> > + }
> > + }
> > +
> > skb = build_skb(data, frag_size);
> > if (!skb) {
> > netdev_warn(port->dev, "skb build failed\n");
> > @@ -3118,7 +3200,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct
> > napi_struct *napi,
> > rcvd_pkts++;
> > rcvd_bytes += rx_bytes;
> >
> > - skb_reserve(skb, MVPP2_MH_SIZE + NET_SKB_PAD);
> > + skb_reserve(skb, MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM);
> > skb_put(skb, rx_bytes);
> > skb->protocol = eth_type_trans(skb, dev);
> > mvpp2_rx_csum(port, rx_status, skb);
> > @@ -3133,6 +3215,8 @@ static int mvpp2_
Re: [PATCH 10/13] selftests/bpf: test_xsk: Split xskxceiver
On Thu, Mar 13, 2025 at 11:48:08AM +0100, Bastien Curutchet (eBPF Foundation)
wrote:
> AF_XDP features are tested by the test_xsk.sh script but not by the
> test_progs framework. The tests used by the script are defined in
> xksxceiver.c which can't be integrated in the test_progs framework as is.
>
> Extract these test definitions from xskxceiver{.c/.h} to put them in new
> test_xsk{.c/.h} files.
> Keep the main() function and its unshared dependencies in xksxceiver to
> avoid impacting the test_xsk.sh script which is often used to test real
> hardware.
>
> Signed-off-by: Bastien Curutchet (eBPF Foundation)
>
> ---
> tools/testing/selftests/bpf/Makefile |2 +-
> tools/testing/selftests/bpf/test_xsk.c | 2416
> tools/testing/selftests/bpf/test_xsk.h | 279
> tools/testing/selftests/bpf/xskxceiver.c | 2503
> +-
> tools/testing/selftests/bpf/xskxceiver.h | 156 --
> 5 files changed, 2727 insertions(+), 2629 deletions(-)
> +
(...)
> +int testapp_hw_sw_max_ring_size(struct test_spec *test)
> +{
> + u32 max_descs = XSK_RING_PROD__DEFAULT_NUM_DESCS * 4;
> + int ret;
> +
> + test->set_ring = true;
> + test->total_steps = 2;
> + test->ifobj_tx->ring.tx_pending = test->ifobj_tx->ring.tx_max_pending;
> + test->ifobj_tx->ring.rx_pending = test->ifobj_tx->ring.rx_max_pending;
> + test->ifobj_rx->umem->num_frames = max_descs;
> + test->ifobj_rx->umem->fill_size = max_descs;
> + test->ifobj_rx->umem->comp_size = max_descs;
> + test->ifobj_tx->xsk->batch_size = XSK_RING_PROD__DEFAULT_NUM_DESCS;
> + test->ifobj_rx->xsk->batch_size = XSK_RING_PROD__DEFAULT_NUM_DESCS;
> +
> + ret = testapp_validate_traffic(test);
> + if (ret)
> + return ret;
> +
> + /* Set batch_size to 8152 for testing, as the ice HW ignores the 3
> lowest bits when
> + * updating the Rx HW tail register.
> + */
> + test->ifobj_tx->xsk->batch_size = test->ifobj_tx->ring.tx_max_pending -
> 8;
> + test->ifobj_rx->xsk->batch_size = test->ifobj_tx->ring.tx_max_pending -
> 8;
> + if (!pkt_stream_replace(test, max_descs, MIN_PKT_SIZE))
Here's the victim of test failures that i reported last week. This
function succeds with 0 and you interpret it as failure:) One sign wrong
caused two days of debugging, but it was kinda fun.
What was happening was due to the failure here one of the sockets was not
deleted and later on whole test suite could not attach the socket for
every other test case which caused the ever going failures. Which makes me
think that since you changed the logic from exits to returning failures
probably we need to take care of state cleanup in a better way so case
like this one described here wouldn't take place.
This test is only executed for hw tests that's why you haven't seen this
problem as you were focused on veth case.
If you want to proceed with that then i would like to ask you to grab the
hw and check you're not introducing regressions. FWIW i have been working
with i40e and ice drivers.
One last note is that verbose mode seemed to be broken for me.
> + return TEST_FAILURE;
> + return testapp_validate_traffic(test);
> +}
> +
(...)
Re: [PATCH 00/13] selftests/bpf: Integrate test_xsk.c to test_progs framework
On Thu, Mar 13, 2025 at 11:47:58AM +0100, Bastien Curutchet (eBPF Foundation) wrote: > Hi all, > > This patch series continues the work to migrate the script tests into > prog_tests. Hi Bastien, the sole purpose of this is a cleanup of some sort? > > The test_xsk.sh script tests lots of AF_XDP use cases. The tests it uses > are defined in xksxceiver.c. As this script is used to test real > hardware, the goal here is to keep it as is and only integrate the > tests on veth peers into the test_progs framework. We're doubling the functionality for no additional benefits? Or the benefit of this set would be the veth xsk tests execution within BPF CI? > Three tests are flaky on s390 so they won't be integrated to test_progs > yet (I'm currently trying to make them more robust). > > PATCH 1 & 2 fix some small issues xskxceiver.c > PATCH 3 to 9 rework the xskxceiver to ease the integration in the > test_progs framework. Two main points are addressed in them : > - wrap kselftest calls behind macros to ease their replacement later > - handle all errors to release resources instead of calling exit() when >any error occurs. > PATCH 10 extracts test_xsk[.c/.h] from xskxceiver[.c/.h] to make the > tests available to test_progs > PATCH 11 enables kselftest de-activation > PATCH 12 isolates the flaky tests > PATCH 13 integrate the non-flaky tests to the test_progs framework I didn't bisect but this set breaks the HW tests for me which *is* what we care about. I'll dig onto that on monday and will get back to you. sudo ./test_xsk.sh -i enp24s0f1np1 PREREQUISITES: [ PASS ] 1..93 ok 1 PASS: SKB SEND_RECEIVE ok 2 PASS: SKB SEND_RECEIVE_2K_FRAME ok 3 PASS: SKB SEND_RECEIVE_SINGLE_PKT ok 4 PASS: SKB POLL_RX ok 5 PASS: SKB POLL_TX ok 6 PASS: SKB POLL_RXQ_FULL ok 7 PASS: SKB POLL_TXQ_FULL ok 1 # SKIP No huge pages present. ok 8 PASS: SKB ALIGNED_INV_DESC ok 9 PASS: SKB ALIGNED_INV_DESC_2K_FRAME_SIZE ok 2 # SKIP No huge pages present. ok 3 # SKIP No huge pages present. ok 10 PASS: SKB UMEM_HEADROOM ok 11 PASS: SKB BIDIRECTIONAL ok 12 PASS: SKB STAT_RX_DROPPED ok 13 PASS: SKB STAT_TX_INVALID ok 14 PASS: SKB STAT_RX_FULL ok 15 PASS: SKB STAT_FILL_EMPTY ok 16 PASS: SKB XDP_PROG_CLEANUP ok 17 PASS: SKB XDP_DROP_HALF ok 18 PASS: SKB XDP_SHARED_UMEM ok 19 PASS: SKB XDP_METADATA_COPY ok 20 PASS: SKB XDP_METADATA_COPY_MULTI_BUFF ok 21 PASS: SKB ALIGNED_INV_DESC_MULTI_BUFF ok 4 # SKIP No huge pages present. ok 22 PASS: SKB TOO_MANY_FRAGS ok 23 PASS: SKB HW_SW_MIN_RING_SIZE not ok 5 FAIL: SKB TEARDOWN not ok 6 FAIL: SKB SEND_RECEIVE_9K_PACKETS ok 7 # SKIP No huge pages present. not ok 8 FAIL: DRV SEND_RECEIVE not ok 9 FAIL: DRV SEND_RECEIVE_2K_FRAME not ok 10 FAIL: DRV SEND_RECEIVE_SINGLE_PKT not ok 11 FAIL: DRV POLL_RX not ok 12 FAIL: DRV POLL_TX ok 24 PASS: DRV POLL_RXQ_FULL ok 25 PASS: DRV POLL_TXQ_FULL ok 13 # SKIP No huge pages present. not ok 14 FAIL: DRV ALIGNED_INV_DESC not ok 15 FAIL: DRV ALIGNED_INV_DESC_2K_FRAME_SIZE ok 16 # SKIP No huge pages present. ok 17 # SKIP No huge pages present. not ok 18 FAIL: DRV UMEM_HEADROOM not ok 19 FAIL: DRV BIDIRECTIONAL not ok 20 FAIL: DRV STAT_RX_DROPPED not ok 21 FAIL: DRV STAT_TX_INVALID not ok 22 FAIL: DRV STAT_RX_FULL not ok 23 FAIL: DRV STAT_FILL_EMPTY not ok 24 FAIL: DRV XDP_PROG_CLEANUP not ok 25 FAIL: DRV XDP_DROP_HALF not ok 26 FAIL: DRV XDP_SHARED_UMEM not ok 27 FAIL: DRV XDP_METADATA_COPY not ok 28 FAIL: DRV XDP_METADATA_COPY_MULTI_BUFF not ok 29 FAIL: DRV ALIGNED_INV_DESC_MULTI_BUFF ok 30 # SKIP No huge pages present. not ok 31 FAIL: DRV TOO_MANY_FRAGS ok 32 # SKIP Failed to change HW ring size. not ok 33 FAIL: DRV HW_SW_MAX_RING_SIZE not ok 34 FAIL: DRV TEARDOWN not ok 35 FAIL: DRV SEND_RECEIVE_9K_PACKETS ok 36 # SKIP No huge pages present. not ok 37 FAIL: ZC SEND_RECEIVE not ok 38 FAIL: ZC SEND_RECEIVE_2K_FRAME not ok 39 FAIL: ZC SEND_RECEIVE_SINGLE_PKT not ok 40 FAIL: ZC POLL_RX not ok 41 FAIL: ZC POLL_TX ok 26 PASS: ZC POLL_RXQ_FULL ok 27 PASS: ZC POLL_TXQ_FULL ok 42 # SKIP No huge pages present. not ok 43 FAIL: ZC ALIGNED_INV_DESC not ok 44 FAIL: ZC ALIGNED_INV_DESC_2K_FRAME_SIZE ok 45 # SKIP No huge pages present. ok 46 # SKIP No huge pages present. not ok 47 FAIL: ZC UMEM_HEADROOM not ok 48 FAIL: ZC BIDIRECTIONAL ok 49 # SKIP Can not run RX_DROPPED test for ZC mode not ok 50 FAIL: ZC STAT_TX_INVALID not ok 51 FAIL: ZC STAT_RX_FULL not ok 52 FAIL: ZC STAT_FILL_EMPTY not ok 53 FAIL: ZC XDP_PROG_CLEANUP not ok 54 FAIL: ZC XDP_DROP_HALF not ok 55 FAIL: ZC XDP_SHARED_UMEM not ok 56 FAIL: ZC XDP_METADATA_COPY not ok 57 FAIL: ZC XDP_METADATA_COPY_MULTI_BUFF not ok 58 FAIL: ZC ALIGNED_INV_DESC_MULTI_BUFF ok 59 # SKIP No huge pages present. not ok 60 FAIL: ZC TOO_MANY_FRAGS ok 61 # SKIP Failed to change HW ring size. not ok 62 FAIL: ZC HW_SW_MAX_RING_SIZE not ok 63 FAIL: ZC TEARDOWN not ok 64 FAIL: ZC SEND_RECEIVE_9K_PACKETS ok 65 # SKIP No huge pages present. # Planned tests != run tests (93 != 27) # Totals: pass:27 fail:0 xfail:0 xpass:0 skip:0 error:0 (same for BU
Re: [RFC PATCH net-next v2 2/2] selftests: net: add XDP socket tests for virtio-net
On Sat, May 31, 2025 at 03:51:57PM +0700, Bui Quang Minh wrote: > On 5/30/25 18:45, Maciej Fijalkowski wrote: > > On Thu, May 29, 2025 at 09:29:14PM +0700, Bui Quang Minh wrote: > > > On 5/29/25 18:18, Maciej Fijalkowski wrote: > > > > On Tue, May 27, 2025 at 11:19:04PM +0700, Bui Quang Minh wrote: > > > > > This adds a test to test the virtio-net rx when there is a XDP socket > > > > > bound to it. There are tests for both copy mode and zerocopy mode, > > > > > both > > > > > cases when XDP program returns XDP_PASS and XDP_REDIRECT to a XDP > > > > > socket. > > > > > > > > > > Signed-off-by: Bui Quang Minh > > > > Hi Bui, > > > > > > > > have you considered adjusting xskxceiver for your needs? If yes and you > > > > decided to go with another test app then what were the issues around it? > > > > > > > > This is yet another approach for xsk testing where we already have a > > > > test framework. > > > Hi, > > > > > > I haven't tried much hard to adapt xskxceiver. I did have a look at > > > xskxceiver but I felt the supported topology is not suitable for my need. > > > To > > > test the receiving side in virtio-net, I use Qemu to set up virtio-net in > > > the guest and vhost-net in the host side. The sending side is in the host > > > and the receiving is in the guest so I can't figure out how to do that > > > with > > > xskxceiver. > > I see - couldn't the python side be executing xdpsock then instead of your > > own app? > > I'm not aware of xdpsock. Could you give the path to that file? https://github.com/xdp-project/bpf-examples/tree/main/AF_XDP-example this is our go-to app side of AF_XDP. > > > I wouldn't like to end up with several xsk tools for testing data path on > > different environments.
Re: [RFC PATCH net-next v2 2/2] selftests: net: add XDP socket tests for virtio-net
On Tue, May 27, 2025 at 11:19:04PM +0700, Bui Quang Minh wrote:
> This adds a test to test the virtio-net rx when there is a XDP socket
> bound to it. There are tests for both copy mode and zerocopy mode, both
> cases when XDP program returns XDP_PASS and XDP_REDIRECT to a XDP socket.
>
> Signed-off-by: Bui Quang Minh
Hi Bui,
have you considered adjusting xskxceiver for your needs? If yes and you
decided to go with another test app then what were the issues around it?
This is yet another approach for xsk testing where we already have a
test framework.
> ---
> .../selftests/drivers/net/hw/.gitignore | 3 +
> .../testing/selftests/drivers/net/hw/Makefile | 12 +-
> .../drivers/net/hw/xsk_receive.bpf.c | 43 ++
> .../selftests/drivers/net/hw/xsk_receive.c| 398 ++
> .../selftests/drivers/net/hw/xsk_receive.py | 75
> 5 files changed, 530 insertions(+), 1 deletion(-)
> create mode 100644 tools/testing/selftests/drivers/net/hw/xsk_receive.bpf.c
> create mode 100644 tools/testing/selftests/drivers/net/hw/xsk_receive.c
> create mode 100755 tools/testing/selftests/drivers/net/hw/xsk_receive.py
>
> diff --git a/tools/testing/selftests/drivers/net/hw/.gitignore
> b/tools/testing/selftests/drivers/net/hw/.gitignore
> index 6942bf575497..c32271faecff 100644
> --- a/tools/testing/selftests/drivers/net/hw/.gitignore
> +++ b/tools/testing/selftests/drivers/net/hw/.gitignore
> @@ -1,3 +1,6 @@
> # SPDX-License-Identifier: GPL-2.0-only
> iou-zcrx
> ncdevmem
> +xsk_receive.skel.h
> +xsk_receive
> +tools
> diff --git a/tools/testing/selftests/drivers/net/hw/Makefile
> b/tools/testing/selftests/drivers/net/hw/Makefile
> index df2c047ffa90..964edbb3b79f 100644
> --- a/tools/testing/selftests/drivers/net/hw/Makefile
> +++ b/tools/testing/selftests/drivers/net/hw/Makefile
> @@ -1,6 +1,9 @@
> # SPDX-License-Identifier: GPL-2.0+ OR MIT
>
> -TEST_GEN_FILES = iou-zcrx
> +TEST_GEN_FILES = \
> + iou-zcrx \
> + xsk_receive \
> + #
>
> TEST_PROGS = \
> csum.py \
> @@ -20,6 +23,7 @@ TEST_PROGS = \
> rss_input_xfrm.py \
> tso.py \
> xsk_reconfig.py \
> + xsk_receive.py \
> #
>
> TEST_FILES := \
> @@ -48,3 +52,9 @@ include ../../../net/ynl.mk
> include ../../../net/bpf.mk
>
> $(OUTPUT)/iou-zcrx: LDLIBS += -luring
> +
> +$(OUTPUT)/xsk_receive.skel.h: xsk_receive.bpf.o
> + bpftool gen skeleton xsk_receive.bpf.o > xsk_receive.skel.h
> +
> +$(OUTPUT)/xsk_receive: xsk_receive.skel.h
> +$(OUTPUT)/xsk_receive: LDLIBS += -lbpf
> diff --git a/tools/testing/selftests/drivers/net/hw/xsk_receive.bpf.c
> b/tools/testing/selftests/drivers/net/hw/xsk_receive.bpf.c
> new file mode 100644
> index ..462046d95bfe
> --- /dev/null
> +++ b/tools/testing/selftests/drivers/net/hw/xsk_receive.bpf.c
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct {
> + __uint(type, BPF_MAP_TYPE_XSKMAP);
> + __uint(max_entries, 1);
> + __uint(key_size, sizeof(__u32));
> + __uint(value_size, sizeof(__u32));
> +} xsk_map SEC(".maps");
> +
> +SEC("xdp.frags")
> +int dummy_prog(struct xdp_md *ctx)
> +{
> + return XDP_PASS;
> +}
> +
> +SEC("xdp.frags")
> +int redirect_xsk_prog(struct xdp_md *ctx)
> +{
> + void *data_end = (void *)(long)ctx->data_end;
> + void *data = (void *)(long)ctx->data;
> + struct ethhdr *eth = data;
> + struct iphdr *iph;
> +
> + if (data + sizeof(*eth) + sizeof(*iph) > data_end)
> + return XDP_PASS;
> +
> + if (bpf_htons(eth->h_proto) != ETH_P_IP)
> + return XDP_PASS;
> +
> + iph = data + sizeof(*eth);
> + if (iph->protocol != IPPROTO_UDP)
> + return XDP_PASS;
> +
> + return bpf_redirect_map(&xsk_map, 0, XDP_DROP);
> +}
> +
> +char _license[] SEC("license") = "GPL";
> diff --git a/tools/testing/selftests/drivers/net/hw/xsk_receive.c
> b/tools/testing/selftests/drivers/net/hw/xsk_receive.c
> new file mode 100644
> index ..96213ceeda5c
> --- /dev/null
> +++ b/tools/testing/selftests/drivers/net/hw/xsk_receive.c
> @@ -0,0 +1,398 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "xsk_receive.skel.h"
> +
> +#define load_acquire(p) \
> + atomic_load_explicit((_Atomic typeof(*(p)) *)(p), memory_order_acquire)
> +
> +#define store_release(p, v) \
> + atomic_store_explicit((_Atomic typeof(*(p)) *)(p), v, \
> + memory_order_release)
> +
> +#define UMEM_CHUNK_SIZE 0x1000
> +#define BUFFER_SIZE 0x2000
> +
> +#define SERVER_PORT
> +#define CLIENT_PORT
> +
> +const int num_entries = 256;
> +const char *pass_msg = "PASS";
> +
> +int cfg_client;
> +int cfg_server;
> +char *cfg_server_ip;
> +char *cfg_client_ip;
Re: [RFC PATCH net-next v2 2/2] selftests: net: add XDP socket tests for virtio-net
On Thu, May 29, 2025 at 09:29:14PM +0700, Bui Quang Minh wrote: > On 5/29/25 18:18, Maciej Fijalkowski wrote: > > On Tue, May 27, 2025 at 11:19:04PM +0700, Bui Quang Minh wrote: > > > This adds a test to test the virtio-net rx when there is a XDP socket > > > bound to it. There are tests for both copy mode and zerocopy mode, both > > > cases when XDP program returns XDP_PASS and XDP_REDIRECT to a XDP socket. > > > > > > Signed-off-by: Bui Quang Minh > > Hi Bui, > > > > have you considered adjusting xskxceiver for your needs? If yes and you > > decided to go with another test app then what were the issues around it? > > > > This is yet another approach for xsk testing where we already have a > > test framework. > > Hi, > > I haven't tried much hard to adapt xskxceiver. I did have a look at > xskxceiver but I felt the supported topology is not suitable for my need. To > test the receiving side in virtio-net, I use Qemu to set up virtio-net in > the guest and vhost-net in the host side. The sending side is in the host > and the receiving is in the guest so I can't figure out how to do that with > xskxceiver. I see - couldn't the python side be executing xdpsock then instead of your own app? I wouldn't like to end up with several xsk tools for testing data path on different environments. > > Thanks, > Quang Minh. > > >
