All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Larysa Zaremba <larysa.zaremba@intel.com>
Cc: "Vladimir Oltean" <vladimir.oltean@nxp.com>,
	bpf@vger.kernel.org, "Claudiu Manoil" <claudiu.manoil@nxp.com>,
	"Wei Fang" <wei.fang@nxp.com>,
	"Clark Wang" <xiaoning.wang@nxp.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Tony Nguyen" <anthony.l.nguyen@intel.com>,
	"Przemek Kitszel" <przemyslaw.kitszel@intel.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>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Song Liu" <song@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"KP Singh" <kpsingh@kernel.org>, "Hao Luo" <haoluo@google.com>,
	"Jiri Olsa" <jolsa@kernel.org>, "Simon Horman" <horms@kernel.org>,
	"Shuah Khan" <shuah@kernel.org>,
	"Alexander Lobakin" <aleksander.lobakin@intel.com>,
	"Maciej Fijalkowski" <maciej.fijalkowski@intel.com>,
	"Bastien Curutchet (eBPF Foundation)"
	<bastien.curutchet@bootlin.com>,
	"Tushar Vyavahare" <tushar.vyavahare@intel.com>,
	"Jason Xing" <kernelxing@tencent.com>,
	"Ricardo B. Marlière" <rbm@suse.com>,
	"Eelco Chaudron" <echaudro@redhat.com>,
	"Lorenzo Bianconi" <lorenzo@kernel.org>,
	"Toke Hoiland-Jorgensen" <toke@redhat.com>,
	imx@lists.linux.dev, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	linux-kselftest@vger.kernel.org,
	"Aleksandr Loktionov" <aleksandr.loktionov@intel.com>
Subject: Re: [PATCH bpf 6/6] net: enetc: use truesize as XDP RxQ info frag_size
Date: Fri, 6 Feb 2026 18:57:35 -0800	[thread overview]
Message-ID: <20260206185735.787fb0e5@kernel.org> (raw)
In-Reply-To: <aYWoBRmt-lcM_JkG@soc-5CG4396X81.clients.intel.com>

On Fri, 6 Feb 2026 09:36:21 +0100 Larysa Zaremba wrote:
> > FWIW my feeling is that instead of nickel and diming leftover space 
> > in the frags if someone actually cared about growing mbufs we should
> > have the helper allocate a new page from the PP and append it to the
> > shinfo. Much simpler, "infinite space", and works regardless of the
> > driver. I don't mean that to suggest you implement it, purely to point
> > out that I think nobody really uses positive offsets.. So we can as
> > well switch more complicated drivers back to xdp_rxq_info_reg().
> 
> As Vladimir has mentioned, if the driver does not use header split, frags will 
> have a tailroom of a size of skb_shared_info, so tail growing does work in 
> practice.
> 
> Allocating a page_pool buffer (given XDP queue has one attached) is certainly an 
> option, although I am not sure if anyone needs it. Furthermore, growing tail 
> would still fail for a single-buf case.

sbuf is a different code path, sbuf has precise frame_sz per frame,
not a single value in rxq, no? Don't mean to argue, just making sure
my mental model is correct ;)

WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Larysa Zaremba <larysa.zaremba@intel.com>
Cc: "Vladimir Oltean" <vladimir.oltean@nxp.com>,
	bpf@vger.kernel.org, "Claudiu Manoil" <claudiu.manoil@nxp.com>,
	"Wei Fang" <wei.fang@nxp.com>,
	"Clark Wang" <xiaoning.wang@nxp.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Tony Nguyen" <anthony.l.nguyen@intel.com>,
	"Przemek Kitszel" <przemyslaw.kitszel@intel.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>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Song Liu" <song@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"KP Singh" <kpsingh@kernel.org>, "Hao Luo" <haoluo@google.com>,
	"Jiri Olsa" <jolsa@kernel.org>, "Simon Horman" <horms@kernel.org>,
	"Shuah Khan" <shuah@kernel.org>,
	"Alexander Lobakin" <aleksander.lobakin@intel.com>,
	"Maciej Fijalkowski" <maciej.fijalkowski@intel.com>,
	"Bastien Curutchet (eBPF Foundation)"
	<bastien.curutchet@bootlin.com>,
	"Tushar Vyavahare" <tushar.vyavahare@intel.com>,
	"Jason Xing" <kernelxing@tencent.com>,
	"Ricardo B. Marlière" <rbm@suse.com>,
	"Eelco Chaudron" <echaudro@redhat.com>,
	"Lorenzo Bianconi" <lorenzo@kernel.org>,
	"Toke Hoiland-Jorgensen" <toke@redhat.com>,
	imx@lists.linux.dev, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
	linux-kselftest@vger.kernel.org,
	"Aleksandr Loktionov" <aleksandr.loktionov@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH bpf 6/6] net: enetc: use truesize as XDP RxQ info frag_size
Date: Fri, 6 Feb 2026 18:57:35 -0800	[thread overview]
Message-ID: <20260206185735.787fb0e5@kernel.org> (raw)
In-Reply-To: <aYWoBRmt-lcM_JkG@soc-5CG4396X81.clients.intel.com>

On Fri, 6 Feb 2026 09:36:21 +0100 Larysa Zaremba wrote:
> > FWIW my feeling is that instead of nickel and diming leftover space 
> > in the frags if someone actually cared about growing mbufs we should
> > have the helper allocate a new page from the PP and append it to the
> > shinfo. Much simpler, "infinite space", and works regardless of the
> > driver. I don't mean that to suggest you implement it, purely to point
> > out that I think nobody really uses positive offsets.. So we can as
> > well switch more complicated drivers back to xdp_rxq_info_reg().
> 
> As Vladimir has mentioned, if the driver does not use header split, frags will 
> have a tailroom of a size of skb_shared_info, so tail growing does work in 
> practice.
> 
> Allocating a page_pool buffer (given XDP queue has one attached) is certainly an 
> option, although I am not sure if anyone needs it. Furthermore, growing tail 
> would still fail for a single-buf case.

sbuf is a different code path, sbuf has precise frame_sz per frame,
not a single value in rxq, no? Don't mean to argue, just making sure
my mental model is correct ;)

  reply	other threads:[~2026-02-07  2:57 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03 10:53 [PATCH bpf 0/6] Address XDP frags having negative tailroom Larysa Zaremba
2026-02-03 10:53 ` [Intel-wired-lan] " Larysa Zaremba
2026-02-03 10:53 ` [PATCH bpf 1/6] xdp: produce a warning when calculated tailroom is negative Larysa Zaremba
2026-02-03 10:53   ` [Intel-wired-lan] " Larysa Zaremba
2026-02-03 12:26   ` Toke Høiland-Jørgensen
2026-02-03 12:26     ` [Intel-wired-lan] " Toke Høiland-Jørgensen
2026-02-03 12:31     ` Larysa Zaremba
2026-02-03 12:31       ` [Intel-wired-lan] " Larysa Zaremba
2026-02-03 12:38       ` Toke Høiland-Jørgensen
2026-02-03 12:38         ` [Intel-wired-lan] " Toke Høiland-Jørgensen
2026-02-03 12:54         ` Larysa Zaremba
2026-02-03 12:54           ` [Intel-wired-lan] " Larysa Zaremba
2026-02-03 13:37           ` Toke Høiland-Jørgensen
2026-02-03 13:37             ` [Intel-wired-lan] " Toke Høiland-Jørgensen
2026-02-04 22:52   ` Martin KaFai Lau
2026-02-04 22:52     ` [Intel-wired-lan] " Martin KaFai Lau
2026-02-03 10:53 ` [PATCH bpf 2/6] ice: fix rxq info registering in mbuf packets Larysa Zaremba
2026-02-03 10:53   ` [Intel-wired-lan] " Larysa Zaremba
2026-02-03 10:53 ` [PATCH bpf 3/6] ice: change XDP RxQ frag_size from DMA write length to truesize Larysa Zaremba
2026-02-03 10:53   ` [Intel-wired-lan] " Larysa Zaremba
2026-02-03 10:53 ` [PATCH bpf 4/6] i40e: use truesize as XDP RxQ info frag_size Larysa Zaremba
2026-02-03 10:53   ` [Intel-wired-lan] " Larysa Zaremba
2026-02-03 10:53 ` [PATCH bpf 5/6] idpf: " Larysa Zaremba
2026-02-03 10:53   ` [Intel-wired-lan] " Larysa Zaremba
2026-02-03 10:53 ` [PATCH bpf 6/6] net: enetc: " Larysa Zaremba
2026-02-03 10:53   ` [Intel-wired-lan] " Larysa Zaremba
2026-02-05  0:59   ` Vladimir Oltean
2026-02-05  0:59     ` [Intel-wired-lan] " Vladimir Oltean
2026-02-05  1:34     ` Jakub Kicinski
2026-02-05  1:34       ` [Intel-wired-lan] " Jakub Kicinski
2026-02-05 12:29       ` Vladimir Oltean
2026-02-05 12:29         ` [Intel-wired-lan] " Vladimir Oltean
2026-02-05 12:41         ` Larysa Zaremba
2026-02-05 12:41           ` [Intel-wired-lan] " Larysa Zaremba
2026-02-05 12:46           ` Vladimir Oltean
2026-02-05 12:46             ` [Intel-wired-lan] " Vladimir Oltean
2026-02-05 13:23             ` Larysa Zaremba
2026-02-05 13:23               ` [Intel-wired-lan] " Larysa Zaremba
2026-02-05 13:40               ` Vladimir Oltean
2026-02-05 13:40                 ` [Intel-wired-lan] " Vladimir Oltean
2026-02-06  1:54                 ` Jakub Kicinski
2026-02-06  1:54                   ` [Intel-wired-lan] " Jakub Kicinski
2026-02-06  8:36                   ` Larysa Zaremba
2026-02-06  8:36                     ` [Intel-wired-lan] " Larysa Zaremba
2026-02-07  2:57                     ` Jakub Kicinski [this message]
2026-02-07  2:57                       ` Jakub Kicinski
2026-02-09  9:46                       ` Larysa Zaremba
2026-02-09  9:46                         ` [Intel-wired-lan] " Larysa Zaremba
2026-02-08 12:59                   ` Vladimir Oltean
2026-02-08 12:59                     ` [Intel-wired-lan] " Vladimir Oltean
2026-02-10 17:27                     ` Dragos Tatulea
2026-02-10 17:27                       ` [Intel-wired-lan] " Dragos Tatulea via Intel-wired-lan
2026-02-04 22:57 ` [PATCH bpf 0/6] Address XDP frags having negative tailroom Martin KaFai Lau
2026-02-04 22:57   ` [Intel-wired-lan] " Martin KaFai Lau
2026-02-05  1:23   ` Jakub Kicinski
2026-02-05  1:23     ` [Intel-wired-lan] " Jakub Kicinski
2026-02-05  1:26 ` Jakub Kicinski
2026-02-05  1:26   ` [Intel-wired-lan] " Jakub Kicinski

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=20260206185735.787fb0e5@kernel.org \
    --to=kuba@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=aleksandr.loktionov@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrii@kernel.org \
    --cc=anthony.l.nguyen@intel.com \
    --cc=ast@kernel.org \
    --cc=bastien.curutchet@bootlin.com \
    --cc=bpf@vger.kernel.org \
    --cc=claudiu.manoil@nxp.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=echaudro@redhat.com \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=haoluo@google.com \
    --cc=hawk@kernel.org \
    --cc=horms@kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kernelxing@tencent.com \
    --cc=kpsingh@kernel.org \
    --cc=larysa.zaremba@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=lorenzo@kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=martin.lau@linux.dev \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=rbm@suse.com \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=toke@redhat.com \
    --cc=tushar.vyavahare@intel.com \
    --cc=vladimir.oltean@nxp.com \
    --cc=wei.fang@nxp.com \
    --cc=xiaoning.wang@nxp.com \
    --cc=yonghong.song@linux.dev \
    /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.