From: Jakub Kicinski <kuba@kernel.org>
To: Lorenzo Bianconi <lorenzo.bianconi@oss.qualcomm.com>
Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <hawk@kernel.org>,
John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Jose Abreu <Jose.Abreu@synopsys.com>,
Ong Boon Leong <boon.leong.ong@intel.com>,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
bpf@vger.kernel.org, Nicolai Buchwitz <nb@tipi-net.de>
Subject: Re: [PATCH net-next v9] net: stmmac: rework stmmac_rx to support XDP rx multi-buff
Date: Wed, 11 Nov 2026 18:13:41 -0800 [thread overview]
Message-ID: <20261111181341.56706354@kernel.org> (raw)
In-Reply-To: <20261106-stmmac-rx-mb-v9-1-c099c923664b@oss.qualcomm.com>
On Fri, 06 Nov 2026 11:54:19 +0100 Lorenzo Bianconi wrote:
> +static struct sk_buff *stmmac_build_skb(struct xdp_buff *xdp)
> +{
> + struct skb_shared_info *sinfo = xdp_get_shared_info_from_buff(xdp);
> + u32 metasize = xdp->data - xdp->data_meta;
> + struct sk_buff *skb;
> + u8 num_frags = 0;
> +
> + if (unlikely(xdp_buff_has_frags(xdp)))
> + num_frags = sinfo->nr_frags;
> +
> + skb = napi_build_skb(xdp->data_hard_start, xdp->frame_sz);
> + if (!skb)
> + return NULL;
> +
> + skb_mark_for_recycle(skb);
> + skb_reserve(skb, xdp->data - xdp->data_hard_start);
> + skb_put(skb, xdp->data_end - xdp->data);
> + if (metasize)
> + skb_metadata_set(skb, metasize);
> +
> + if (unlikely(xdp_buff_has_frags(xdp)))
> + xdp_update_skb_frags_info(skb, num_frags, sinfo->xdp_frags_size,
> + sinfo->xdp_frags_truesize,
> + xdp_buff_get_skb_flags(xdp));
> + return skb;
> +}
This is almost identical to xdp_build_skb_from_buff(), why not use the
common code?
> +static void
> +stmmac_xdp_put_buff(struct stmmac_rx_queue *rx_q, struct xdp_buff *xdp,
> + bool allow_direct)
> +{
> + struct skb_shared_info *sinfo = xdp_get_shared_info_from_buff(xdp);
> + int i;
> +
> + if (likely(!xdp_buff_has_frags(xdp)))
> + goto out;
> +
> + for (i = 0; i < sinfo->nr_frags; i++)
> + page_pool_put_full_page(rx_q->page_pool,
> + skb_frag_page(&sinfo->frags[i]),
> + allow_direct);
> +out:
> + page_pool_put_full_page(rx_q->page_pool, virt_to_head_page(xdp->data),
> + allow_direct);
> +}
> +
> +static int stmmac_xdp_shrink_tail(struct stmmac_rx_queue *rx_q,
> + struct xdp_buff *xdp, int offset)
> +{
> + struct skb_shared_info *sinfo;
> + int i;
> +
> + if (unlikely(offset < 0 ||
> + offset > (int)xdp_get_buff_len(xdp) - ETH_HLEN))
> + return -EINVAL;
> +
> + if (likely(!xdp_buff_has_frags(xdp))) {
> + xdp->data_end -= offset;
> + return 0;
> + }
> +
> + sinfo = xdp_get_shared_info_from_buff(xdp);
> + for (i = sinfo->nr_frags - 1; i >= 0 && offset > 0; i--) {
> + skb_frag_t *frag = &sinfo->frags[i];
> + int delta = min_t(int, offset, skb_frag_size(frag));
> +
> + if (delta == skb_frag_size(frag)) {
> + /* The whole frag is consumed by the strip: return it
> + * to the page pool right away. Its ring slot still
> + * carries the page DMA address until stmmac_rx_refill()
> + * re-arms it at the end of the NAPI poll. This is
> + * safe because HW cannot touch the slot until then.
> + */
> + page_pool_put_full_page(rx_q->page_pool,
> + skb_frag_page(frag), true);
> + sinfo->nr_frags--;
> + sinfo->xdp_frags_truesize -= xdp->frame_sz;
> + } else {
> + skb_frag_size_sub(frag, delta);
> + }
> +
> + sinfo->xdp_frags_size -= delta;
> + offset -= delta;
> + }
> +
> + if (unlikely(!sinfo->nr_frags)) {
> + xdp_buff_clear_frags_flag(xdp);
> + xdp_buff_clear_frag_pfmemalloc(xdp);
> + xdp->data_end -= offset;
> + }
> +
> + return 0;
> +}
These two OTOH could easily become new common helpers, they seem to do
nothing stmmac specific?
next prev parent reply other threads:[~2026-11-12 2:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 10:54 [PATCH net-next v9] net: stmmac: rework stmmac_rx to support XDP rx multi-buff Lorenzo Bianconi
2026-11-10 13:54 ` netdev-bot+sashiko
2026-11-11 8:45 ` Lorenzo Bianconi
2026-11-12 2:13 ` Jakub Kicinski [this message]
2026-11-12 11:09 ` Lorenzo Bianconi
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=20261111181341.56706354@kernel.org \
--to=kuba@kernel.org \
--cc=Jose.Abreu@synopsys.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=ast@kernel.org \
--cc=boon.leong.ong@intel.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lorenzo.bianconi@oss.qualcomm.com \
--cc=maxime.chevallier@bootlin.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=nb@tipi-net.de \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.