From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Jesper Dangaard Brouer <brouer@redhat.com>,
John Fastabend <john.fastabend@gmail.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org,
Daniel Borkmann <borkmann@iogearbox.net>,
maze@google.com, lmb@cloudflare.com, shaun@tigera.io,
Lorenzo Bianconi <lorenzo@kernel.org>,
marek@cloudflare.com, eyal.birger@gmail.com
Subject: Re: [PATCH bpf-next V3 0/6] bpf: New approach for BPF MTU handling
Date: Tue, 13 Oct 2020 16:37:34 -0700 [thread overview]
Message-ID: <20201013233734.6z3uyrlr43s7etay@ast-mbp> (raw)
In-Reply-To: <20201013160726.367e3871@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Tue, Oct 13, 2020 at 04:07:26PM -0700, Jakub Kicinski wrote:
> On Tue, 13 Oct 2020 22:40:09 +0200 Jesper Dangaard Brouer wrote:
> > > FWIW I took a quick swing at testing it with the HW I have and it did
> > > exactly what hardware should do. The TX unit entered an error state
> > > and then the driver detected that and reset it a few seconds later.
> >
> > The drivers (i40e, mlx5, ixgbe) I tested with didn't entered an error
> > state, when getting packets exceeding the MTU. I didn't go much above
> > 4K, so maybe I didn't trigger those cases.
>
> You probably need to go above 16k to get out of the acceptable jumbo
> frame size. I tested ixgbe by converting TSO frames to large TCP frames,
> at low probability.
how about we set __bpf_skb_max_len() to jumbo like 8k and be done with it.
I guess some badly written driver/fw may still hang with <= 8k skb
that bpf redirected from one netdev with mtu=jumbo to another
netdev with mtu=1500, but then it's really a job of the driver/fw
to deal with it cleanly.
I think checking skb->tx_dev->mtu for every xmited packet is not great.
For typical load balancer it would be good to have MRU 1500 and MTU 15xx.
Especially if it's internet facing. Just to drop all known big
packets in hw via MRU check.
But the stack doesn't have MRU vs MTU distinction and XDP_TX doesn't
adhere to MTU. xdp_data_hard_end is the limit.
So xdp already allows growing the packet beyond MTU.
I think upgrading artificial limit in __bpf_skb_max_len() to 8k will
keep it safe enough for all practical cases and will avoid unnecessary
checks and complexity in xmit path.
next prev parent reply other threads:[~2020-10-14 9:23 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 14:08 [PATCH bpf-next V3 0/6] bpf: New approach for BPF MTU handling Jesper Dangaard Brouer
2020-10-08 14:09 ` [PATCH bpf-next V3 1/6] bpf: Remove MTU check in __bpf_skb_max_len Jesper Dangaard Brouer
2020-10-09 16:12 ` Daniel Borkmann
2020-10-09 18:26 ` Maciej Żenczykowski
2020-10-10 10:25 ` Jesper Dangaard Brouer
2020-10-08 14:09 ` [PATCH bpf-next V3 2/6] bpf: bpf_fib_lookup return MTU value as output when looked up Jesper Dangaard Brouer
2020-10-09 4:05 ` David Ahern
2020-10-08 14:09 ` [PATCH bpf-next V3 3/6] bpf: add BPF-helper for MTU checking Jesper Dangaard Brouer
2020-10-09 23:29 ` Maciej Żenczykowski
2020-10-21 11:32 ` Jesper Dangaard Brouer
2020-10-12 15:54 ` Lorenz Bauer
2020-10-08 14:09 ` [PATCH bpf-next V3 4/6] bpf: make it possible to identify BPF redirected SKBs Jesper Dangaard Brouer
2020-10-09 16:47 ` Daniel Borkmann
2020-10-09 18:33 ` Maciej Żenczykowski
2020-10-10 11:09 ` Jesper Dangaard Brouer
2020-10-12 21:04 ` Maciej Żenczykowski
2020-10-08 14:09 ` [PATCH bpf-next V3 5/6] bpf: drop MTU check when doing TC-BPF redirect to ingress Jesper Dangaard Brouer
2020-10-09 23:17 ` Maciej Żenczykowski
2020-10-08 14:09 ` [PATCH bpf-next V3 6/6] net: inline and splitup is_skb_forwardable Jesper Dangaard Brouer
2020-10-09 16:33 ` [PATCH bpf-next V3 0/6] bpf: New approach for BPF MTU handling Jakub Kicinski
2020-10-09 20:49 ` John Fastabend
2020-10-09 21:07 ` Alexei Starovoitov
2020-10-09 21:57 ` Maciej Żenczykowski
2020-10-09 23:00 ` Jakub Kicinski
2020-10-10 10:44 ` Jesper Dangaard Brouer
2020-10-10 16:32 ` Jakub Kicinski
2020-10-10 23:52 ` John Fastabend
2020-10-11 23:30 ` Jakub Kicinski
2020-10-13 20:40 ` Jesper Dangaard Brouer
2020-10-13 23:07 ` Jakub Kicinski
2020-10-13 23:37 ` Alexei Starovoitov [this message]
2020-10-13 23:54 ` Maciej Żenczykowski
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=20201013233734.6z3uyrlr43s7etay@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=borkmann@iogearbox.net \
--cc=bpf@vger.kernel.org \
--cc=brouer@redhat.com \
--cc=eyal.birger@gmail.com \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=lmb@cloudflare.com \
--cc=lorenzo@kernel.org \
--cc=marek@cloudflare.com \
--cc=maze@google.com \
--cc=netdev@vger.kernel.org \
--cc=shaun@tigera.io \
/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