[PATCH v7 2/2] net/af_xdp: Refactor af_xdp_tx_zc

[Maryam Tahhan]

On Sat 1 Feb 2025, 10:03 Ariel Otilibili, <ariel.otilibili at 6wind.com> wrote:

> Both legs of the loop share the same logic: the common parts are about
> reserving and filling both address and length into the description.
>
> This is moved into reserve_and_fill().
>
> Bugzilla ID: 1440
> Suggested-by: Maryam Tahhan <mtahhan at redhat.com>
> Signed-off-by: Ariel Otilibili <ariel.otilibili at 6wind.com>
> ---
>  drivers/net/af_xdp/rte_eth_af_xdp.c | 62 ++++++++++++++++-------------
>  1 file changed, 34 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
> b/drivers/net/af_xdp/rte_eth_af_xdp.c
> index 092bcb73aa0a..840a12dbf508 100644
> --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> @@ -536,6 +536,31 @@ kick_tx(struct pkt_tx_queue *txq, struct
> xsk_ring_cons *cq)
>                 }
>  }
>
> +static inline struct xdp_desc *
> +reserve_and_fill(struct pkt_tx_queue *txq, struct rte_mbuf *mbuf,
> +                struct xsk_umem_info *umem)
> +{
> +       struct xdp_desc *desc = NULL;
> +       uint32_t *idx_tx = NULL;
>

Took me a while to spot this but this needs to be a uint32_t not a pointer
to uint32_t, because xsk_ring_prod__reserve() does not allocate memory for
idx_tx it just expects to dereference a pointer to a uint32_t to store the
index...

+       uint64_t addr, offset;
> +
> +       if (!xsk_ring_prod__reserve(&txq->tx, 1, idx_tx))
> +               goto out;
> +
> +       desc = xsk_ring_prod__tx_desc(&txq->tx, *idx_tx);
> +       desc->len = mbuf->pkt_len;
> +
> +       addr = (uint64_t)mbuf - (uint64_t)umem->buffer
> +               - umem->mb_pool->header_size;
> +       offset = rte_pktmbuf_mtod(mbuf, uint64_t) - (uint64_t)mbuf
> +               + umem->mb_pool->header_size;
> +       offset = offset << XSK_UNALIGNED_BUF_OFFSET_SHIFT;
> +       desc->addr = addr | offset;
> +
> +out:
> +       return desc;
> +}
> +
> <snip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/stable/attachments/20250206/009a2ac5/attachment.htm>