From: "Maciej Żenczykowski" <maze@google.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: John Fastabend <john.fastabend@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
Jesper Dangaard Brouer <brouer@redhat.com>,
bpf <bpf@vger.kernel.org>, Linux NetDev <netdev@vger.kernel.org>,
Daniel Borkmann <borkmann@iogearbox.net>,
Lorenz Bauer <lmb@cloudflare.com>,
Shaun Crampton <shaun@tigera.io>,
Lorenzo Bianconi <lorenzo@kernel.org>,
Marek Majkowski <marek@cloudflare.com>,
Eyal Birger <eyal.birger@gmail.com>
Subject: Re: [PATCH bpf-next V3 0/6] bpf: New approach for BPF MTU handling
Date: Fri, 9 Oct 2020 14:57:23 -0700 [thread overview]
Message-ID: <CANP3RGeiF2-EXGU8Bnt05zbGGL6cMs9VU0P4tprx3zjN-w75FA@mail.gmail.com> (raw)
In-Reply-To: <20201009210744.xa55r6sanggqv5ou@ast-mbp>
On Fri, Oct 9, 2020 at 2:07 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Fri, Oct 09, 2020 at 01:49:14PM -0700, John Fastabend wrote:
> > Jakub Kicinski wrote:
> > > On Thu, 08 Oct 2020 16:08:57 +0200 Jesper Dangaard Brouer wrote:
> > > > V3: Drop enforcement of MTU in net-core, leave it to drivers
> > >
> > > Sorry for being late to the discussion.
> > >
> > > I absolutely disagree. We had cases in the past where HW would lock up
> > > if it was sent a frame with bad geometry.
> > >
> > > We will not be sprinkling validation checks across the drivers because
> > > some reconfiguration path may occasionally yield a bad packet, or it's
> > > hard to do something right with BPF.
> >
> > This is a driver bug then. As it stands today drivers may get hit with
> > skb with MTU greater than set MTU as best I can tell. Generally I
> > expect drivers use MTU to configure RX buffers not sure how it is going
> > to be used on TX side? Any examples? I just poked around through the
> > driver source to see and seems to confirm its primarily for RX side
> > configuration with some drivers throwing the event down to the firmware
> > for something that I can't see in the code?
> >
> > I'm not suggestiong sprinkling validation checks across the drivers.
> > I'm suggesting if the drivers hang we fix them.
>
> +1
>
> I've seen HW that hangs when certain sizes of the packet.
> Like < 68 byte TX where size is one specific constant.
> I don't think it's a job of the stack or the driver to deal with that.
> It's firmware/hw bug.
+1
It's not the job of the core stack, but it *is* the job of the driver
to deal with firmware/hw bugs like this.
Sure fix in hw when you can (next rev), in fw if you can't (and have
fw, can release it, rev it, distribute it), but ultimately that's why
drivers have quirks for various revisions of hw/fw... so you very much
fix bugs like this in driver if needed.
next prev parent reply other threads:[~2020-10-09 21:57 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 [this message]
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
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=CANP3RGeiF2-EXGU8Bnt05zbGGL6cMs9VU0P4tprx3zjN-w75FA@mail.gmail.com \
--to=maze@google.com \
--cc=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=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;
as well as URLs for NNTP newsgroup(s).