From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: <intel-wired-lan@lists.osuosl.org>,
Michal Kubiak <michal.kubiak@intel.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
"Przemek Kitszel" <przemyslaw.kitszel@intel.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
"Alexei Starovoitov" <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Simon Horman <horms@kernel.org>, <bpf@vger.kernel.org>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 14/16] idpf: add support for XDP on Rx
Date: Tue, 8 Apr 2025 17:53:02 +0200 [thread overview]
Message-ID: <Z/VGXryCFSRk7zOT@boxer> (raw)
In-Reply-To: <454272e0-82cf-4f79-be53-a4838dfbbcd7@intel.com>
On Tue, Apr 08, 2025 at 03:28:21PM +0200, Alexander Lobakin wrote:
> From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Date: Tue, 11 Mar 2025 16:50:07 +0100
>
> > On Wed, Mar 05, 2025 at 05:21:30PM +0100, Alexander Lobakin wrote:
> >> Use libeth XDP infra to support running XDP program on Rx polling.
> >> This includes all of the possible verdicts/actions.
> >> XDP Tx queues are cleaned only in "lazy" mode when there are less than
> >> 1/4 free descriptors left on the ring. libeth helper macros to define
> >> driver-specific XDP functions make sure the compiler could uninline
> >> them when needed.
>
> [...]
>
> >> +/**
> >> + * idpf_clean_xdp_irq - Reclaim a batch of TX resources from completed XDP_TX
> >> + * @_xdpq: XDP Tx queue
> >> + * @budget: maximum number of descriptors to clean
> >> + *
> >> + * Returns number of cleaned descriptors.
> >> + */
> >> +static u32 idpf_clean_xdp_irq(void *_xdpq, u32 budget)
> >> +{
> >> + struct libeth_xdpsq_napi_stats ss = { };
> >> + struct idpf_tx_queue *xdpq = _xdpq;
> >> + u32 tx_ntc = xdpq->next_to_clean;
> >> + u32 tx_cnt = xdpq->desc_count;
> >> + struct xdp_frame_bulk bq;
> >> + struct libeth_cq_pp cp = {
> >> + .dev = xdpq->dev,
> >> + .bq = &bq,
> >> + .xss = &ss,
> >> + .napi = true,
> >> + };
> >> + u32 done_frames;
> >> +
> >> + done_frames = idpf_xdpsq_poll(xdpq, budget);
> >
> > nit: maybe pass {tx_ntc, tx_cnt} to the above?
>
> Not folloween... =\
you deref ::next_to_clean and ::desc_count again in idpf_xdpsq_poll() and
you have them derefd here in local vars already so i was just suggesting
to maybe pass them as args but not a big deal
>
> >
> >> + if (unlikely(!done_frames))
> >> + return 0;
> >> +
> >> + xdp_frame_bulk_init(&bq);
> >> +
> >> + for (u32 i = 0; likely(i < done_frames); i++) {
> >> + libeth_xdp_complete_tx(&xdpq->tx_buf[tx_ntc], &cp);
> >> +
> >> + if (unlikely(++tx_ntc == tx_cnt))
> >> + tx_ntc = 0;
> >> + }
> >> +
> >> + xdp_flush_frame_bulk(&bq);
> >> +
> >> + xdpq->next_to_clean = tx_ntc;
> >> + xdpq->pending -= done_frames;
> >> + xdpq->xdp_tx -= cp.xdp_tx;
> >
> > not following this variable. __libeth_xdp_complete_tx() decresases
> > libeth_cq_pp::xdp_tx by libeth_sqe::nr_frags. can you shed more light
> > what's going on here?
>
> libeth_sqe::nr_frags is not the same as skb_shared_info::nr_frags, it
> equals to 1 when there's only 1 fragment.
> Basically, xdp_tx field is the number of pending XDP-non-XSk
> descriptors. When it's zero, we don't traverse Tx descriptors at all
> on XSk completion (thx to splitq).
>
> >
> >> +
> >> + return done_frames;
> >> +}
> >> +
next prev parent reply other threads:[~2025-04-08 15:53 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-05 16:21 [PATCH net-next 00/16] idpf: add XDP support Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 01/16] libeth: convert to netmem Alexander Lobakin
2025-03-06 0:13 ` Mina Almasry
2025-03-11 17:22 ` Alexander Lobakin
2025-03-11 17:43 ` Mina Almasry
2025-03-05 16:21 ` [PATCH net-next 02/16] libeth: support native XDP and register memory model Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 03/16] libeth: add a couple of XDP helpers (libeth_xdp) Alexander Lobakin
2025-03-11 14:05 ` Maciej Fijalkowski
2025-03-17 15:26 ` Alexander Lobakin
2025-03-19 16:19 ` Maciej Fijalkowski
2025-04-01 13:11 ` Alexander Lobakin
2025-04-08 13:38 ` Alexander Lobakin
2025-04-08 13:22 ` Alexander Lobakin
2025-04-08 13:51 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 04/16] libeth: add XSk helpers Alexander Lobakin
2025-03-07 10:15 ` Maciej Fijalkowski
2025-03-12 17:03 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 05/16] idpf: fix Rx descriptor ready check barrier in splitq Alexander Lobakin
2025-03-07 10:17 ` Maciej Fijalkowski
2025-03-12 17:10 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 06/16] idpf: a use saner limit for default number of queues to allocate Alexander Lobakin
2025-03-07 10:32 ` Maciej Fijalkowski
2025-03-12 17:22 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 07/16] idpf: link NAPIs to queues Alexander Lobakin
2025-03-07 10:28 ` Eric Dumazet
2025-03-12 17:16 ` Alexander Lobakin
2025-03-18 17:10 ` Alexander Lobakin
2025-03-07 10:51 ` Maciej Fijalkowski
2025-03-12 17:25 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 08/16] idpf: make complq cleaning dependent on scheduling mode Alexander Lobakin
2025-03-07 11:11 ` Maciej Fijalkowski
2025-03-13 16:16 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 09/16] idpf: remove SW marker handling from NAPI Alexander Lobakin
2025-03-07 11:42 ` Maciej Fijalkowski
2025-03-13 16:50 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 10/16] idpf: add support for nointerrupt queues Alexander Lobakin
2025-03-07 12:10 ` Maciej Fijalkowski
2025-03-13 16:19 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 11/16] idpf: prepare structures to support XDP Alexander Lobakin
2025-03-07 1:12 ` Jakub Kicinski
2025-03-12 14:00 ` [Intel-wired-lan] " Alexander Lobakin
2025-03-07 13:27 ` Maciej Fijalkowski
2025-03-17 14:50 ` Alexander Lobakin
2025-03-19 16:29 ` Maciej Fijalkowski
2025-04-08 13:42 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 12/16] idpf: implement XDP_SETUP_PROG in ndo_bpf for splitq Alexander Lobakin
2025-03-07 14:16 ` Maciej Fijalkowski
2025-03-17 14:58 ` Alexander Lobakin
2025-03-19 16:23 ` Maciej Fijalkowski
2025-03-05 16:21 ` [PATCH net-next 13/16] idpf: use generic functions to build xdp_buff and skb Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 14/16] idpf: add support for XDP on Rx Alexander Lobakin
2025-03-11 15:50 ` Maciej Fijalkowski
2025-04-08 13:28 ` Alexander Lobakin
2025-04-08 15:53 ` Maciej Fijalkowski [this message]
2025-03-05 16:21 ` [PATCH net-next 15/16] idpf: add support for .ndo_xdp_xmit() Alexander Lobakin
2025-03-11 16:08 ` Maciej Fijalkowski
2025-04-08 13:31 ` Alexander Lobakin
2025-03-05 16:21 ` [PATCH net-next 16/16] idpf: add XDP RSS hash hint Alexander Lobakin
2025-03-11 15:28 ` [PATCH net-next 00/16] idpf: add XDP support Alexander Lobakin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z/VGXryCFSRk7zOT@boxer \
--to=maciej.fijalkowski@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.kubiak@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=przemyslaw.kitszel@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).