All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>,
	John Fastabend <john.fastabend@gmail.com>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>,
	bpf@vger.kernel.org, netdev@vger.kernel.org, davem@davemloft.net,
	kuba@kernel.org, ast@kernel.org, daniel@iogearbox.net,
	shayagr@amazon.com, dsahern@kernel.org, brouer@redhat.com,
	echaudro@redhat.com, jasowang@redhat.com,
	alexander.duyck@gmail.com, saeed@kernel.org,
	maciej.fijalkowski@intel.com, magnus.karlsson@intel.com,
	tirthendu.sarkar@intel.com, toke@redhat.com
Subject: Re: [PATCH v19 bpf-next 12/23] bpf: add multi-buff support to the bpf_xdp_adjust_tail() API
Date: Mon, 06 Dec 2021 09:16:58 -0800	[thread overview]
Message-ID: <61ae458a58d73_88182082b@john.notmuch> (raw)
In-Reply-To: <Ya4nI6DKPmGOpfMf@lore-desk>

Lorenzo Bianconi wrote:
> > Lorenzo Bianconi wrote:
> > > From: Eelco Chaudron <echaudro@redhat.com>
> > > 
> > > This change adds support for tail growing and shrinking for XDP multi-buff.
> > > 
> > > When called on a multi-buffer packet with a grow request, it will work
> > > on the last fragment of the packet. So the maximum grow size is the
> > > last fragments tailroom, i.e. no new buffer will be allocated.
> > > A XDP mb capable driver is expected to set frag_size in xdp_rxq_info data
> > > structure to notify the XDP core the fragment size. frag_size set to 0 is
> > > interpreted by the XDP core as tail growing is not allowed.
> > > Introduce __xdp_rxq_info_reg utility routine to initialize frag_size field.
> > > 
> > > When shrinking, it will work from the last fragment, all the way down to
> > > the base buffer depending on the shrinking size. It's important to mention
> > > that once you shrink down the fragment(s) are freed, so you can not grow
> > > again to the original size.
> > > 
> > > Acked-by: Jakub Kicinski <kuba@kernel.org>
> > > Co-developed-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > Signed-off-by: Eelco Chaudron <echaudro@redhat.com>
> > > ---

[...]

pasting full function here to help following along.

+
+static int bpf_xdp_mb_shrink_tail(struct xdp_buff *xdp, int offset)
+{
+	struct skb_shared_info *sinfo = xdp_get_shared_info_from_buff(xdp);
+	int i, n_frags_free = 0, len_free = 0;
+
+	if (unlikely(offset > (int)xdp_get_buff_len(xdp) - ETH_HLEN))
+		return -EINVAL;
+
+	for (i = sinfo->nr_frags - 1; i >= 0 && offset > 0; i--) {
+		skb_frag_t *frag = &sinfo->frags[i];
+		int size = skb_frag_size(frag);
+		int shrink = min_t(int, offset, size);
+
+		len_free += shrink;
+		offset -= shrink;
+
+		if (unlikely(size == shrink)) {
+			struct page *page = skb_frag_page(frag);
+
+			__xdp_return(page_address(page), &xdp->rxq->mem,
+				     false, NULL);
+			n_frags_free++;
+		} else {
+			skb_frag_size_set(frag, size - shrink);
+			break;
+		}
+	}
+	sinfo->nr_frags -= n_frags_free;
+	sinfo->xdp_frags_size -= len_free;
+
+	if (unlikely(offset > 0)) {
+		xdp_buff_clear_mb(xdp);
+		xdp->data_end -= offset;
+	}
+
+	return 0;
+}
+

> > 
> > hmm whats the case for offset to != 0? Seems with initial unlikely
> > check and shrinking while walking backwards through the frags it
> > should be zero? Maybe a comment would help?
> 
> Looking at the code, offset can be > 0 here whenever we reduce the mb frame to
> a legacy frame (so whenever offset will move the boundary into the linear
> area).

But still missing if we need to clear the mb bit or not when we shrink down
to a single frag. I think its fine, but worth double checking. As an example
consider I shrink 2k from a 3k pkt with two frags, one full 2k and another
1k extra,

On the first run through,

 i = 1;
 offset = 2k

+	for (i = sinfo->nr_frags - 1; i >= 0 && offset > 0; i--) {
+		skb_frag_t *frag = &sinfo->frags[i];
+		int size = skb_frag_size(frag);
+		int shrink = min_t(int, offset, size);

shrink = 1k; // min_t(int, offset, size) -> size

+
+		len_free += shrink;
+		offset -= shrink;

offset = 1k

+		if (unlikely(size == shrink)) {
+			struct page *page = skb_frag_page(frag);
+
+			__xdp_return(page_address(page), &xdp->rxq->mem,
+				     false, NULL);
+			n_frags_free++;

Will free the frag

Then next run through

i = 0;
offset = 1k;

+		skb_frag_t *frag = &sinfo->frags[i];
+		int size = skb_frag_size(frag);
+		int shrink = min_t(int, offset, size);

shrink = 1k; // min_t(int, offset, size) -> offset

+
+		len_free += shrink;
+		offset -= shrink;

offset = 0k

+
+		if (unlikely(size == shrink)) { ...
+		} else {
+			skb_frag_size_set(frag, size - shrink);
+			break;
+		}

Then later there is the check 'if (unlikely(offset > 0) { ...}', but that
wont hit this case and we shrunk it back to a single frag. Did we want
to clear the mb in this case? I'm not seeing how it harms things to have
the mb bit set just trying to follow code here.

Would offset > 0 indicate we weren't able to shrink the xdp buff enough
for some reason. Need some coffee perhaps.

Thanks,
John

  reply	other threads:[~2021-12-06 17:17 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30 11:52 [PATCH v19 bpf-next 00/23] mvneta: introduce XDP multi-buffer support Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 01/23] net: skbuff: add size metadata to skb_shared_info for xdp Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 02/23] xdp: introduce flags field in xdp_buff/xdp_frame Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 03/23] net: mvneta: update mb bit before passing the xdp buffer to eBPF layer Lorenzo Bianconi
2021-12-06  3:06   ` John Fastabend
2021-12-06 15:11     ` Lorenzo Bianconi
2021-12-06 17:03       ` John Fastabend
2021-12-06 19:26         ` Lorenzo Bianconi
2021-12-06 20:49           ` John Fastabend
2021-11-30 11:52 ` [PATCH v19 bpf-next 04/23] net: mvneta: simplify mvneta_swbm_add_rx_fragment management Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 05/23] net: xdp: add xdp_update_skb_shared_info utility routine Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 06/23] net: marvell: rely on " Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 07/23] xdp: add multi-buff support to xdp_return_{buff/frame} Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 08/23] net: mvneta: add multi buffer support to XDP_TX Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 09/23] bpf: introduce BPF_F_XDP_MB flag in prog_flags loading the ebpf program Lorenzo Bianconi
2021-12-06  3:10   ` John Fastabend
2021-11-30 11:52 ` [PATCH v19 bpf-next 10/23] net: mvneta: enable jumbo frames if the loaded XDP program support mb Lorenzo Bianconi
2021-12-06  3:18   ` John Fastabend
2021-11-30 11:52 ` [PATCH v19 bpf-next 11/23] bpf: introduce bpf_xdp_get_buff_len helper Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 12/23] bpf: add multi-buff support to the bpf_xdp_adjust_tail() API Lorenzo Bianconi
2021-12-06  4:42   ` John Fastabend
2021-12-06 15:07     ` Lorenzo Bianconi
2021-12-06 17:16       ` John Fastabend [this message]
2021-12-06 19:57         ` Lorenzo Bianconi
2021-12-06 20:47           ` John Fastabend
2021-12-07 14:52       ` Eelco Chaudron
2021-11-30 11:52 ` [PATCH v19 bpf-next 13/23] bpf: add multi-buffer support to xdp copy helpers Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 14/23] bpf: move user_size out of bpf_test_init Lorenzo Bianconi
2021-11-30 11:52 ` [PATCH v19 bpf-next 15/23] bpf: introduce multibuff support to bpf_prog_test_run_xdp() Lorenzo Bianconi
2021-11-30 11:53 ` [PATCH v19 bpf-next 16/23] bpf: test_run: add xdp_shared_info pointer in bpf_test_finish signature Lorenzo Bianconi
2021-11-30 11:53 ` [PATCH v19 bpf-next 17/23] bpf: selftests: update xdp_adjust_tail selftest to include multi-buffer Lorenzo Bianconi
2021-11-30 11:53 ` [PATCH v19 bpf-next 18/23] libbpf: Add SEC name for xdp_mb programs Lorenzo Bianconi
2021-12-06 17:47   ` John Fastabend
2021-11-30 11:53 ` [PATCH v19 bpf-next 19/23] bpf: generalise tail call map compatibility check Lorenzo Bianconi
2021-12-06 17:42   ` John Fastabend
2021-12-06 19:23     ` Lorenzo Bianconi
2021-12-07 17:49     ` Toke Høiland-Jørgensen
2021-11-30 11:53 ` [PATCH v19 bpf-next 20/23] net: xdp: introduce bpf_xdp_pointer utility routine Lorenzo Bianconi
2021-11-30 20:38   ` Jakub Kicinski
2021-12-06 18:34   ` John Fastabend
2021-11-30 11:53 ` [PATCH v19 bpf-next 21/23] bpf: selftests: introduce bpf_xdp_{load,store}_bytes selftest Lorenzo Bianconi
2021-11-30 11:53 ` [PATCH v19 bpf-next 22/23] bpf: selftests: add CPUMAP/DEVMAP selftests for xdp multi-buff Lorenzo Bianconi
2021-11-30 11:53 ` [PATCH v19 bpf-next 23/23] xdp: disable XDP_REDIRECT " Lorenzo Bianconi
2021-12-06 17:11   ` Jesper Dangaard Brouer
2021-12-06 19:21     ` Zvi Effron
2021-12-06 20:03       ` Lorenzo Bianconi
2021-12-08 13:07         ` Toke Høiland-Jørgensen
2021-12-06 19:24     ` Lorenzo Bianconi
2021-12-01 13:57 ` [PATCH v19 bpf-next 00/23] mvneta: introduce XDP multi-buffer support Lorenzo Bianconi
2021-12-03  2:10   ` Alexei Starovoitov

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=61ae458a58d73_88182082b@john.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=alexander.duyck@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=echaudro@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kuba@kernel.org \
    --cc=lorenzo.bianconi@redhat.com \
    --cc=lorenzo@kernel.org \
    --cc=maciej.fijalkowski@intel.com \
    --cc=magnus.karlsson@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=saeed@kernel.org \
    --cc=shayagr@amazon.com \
    --cc=tirthendu.sarkar@intel.com \
    --cc=toke@redhat.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 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.