From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Cc: Toshiaki Makita <toshiaki.makita1@gmail.com>,
netdev@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Jesper Dangaard Brouer <brouer@redhat.com>
Subject: Re: [PATCH v3 bpf-next 3/8] veth: Avoid drops by oversized packets when XDP is enabled
Date: Tue, 24 Jul 2018 12:10:15 -0700 [thread overview]
Message-ID: <20180724121015.5d9edbf3@cakuba.netronome.com> (raw)
In-Reply-To: <709ccfa0-fcd8-bd48-1e85-2960bbe232dd@lab.ntt.co.jp>
On Tue, 24 Jul 2018 18:39:09 +0900, Toshiaki Makita wrote:
> On 2018/07/24 10:56, Toshiaki Makita wrote:
> > On 2018/07/24 9:27, Jakub Kicinski wrote:
> >> On Mon, 23 Jul 2018 00:13:03 +0900, Toshiaki Makita wrote:
> >>> From: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >>>
> >>> All oversized packets including GSO packets are dropped if XDP is
> >>> enabled on receiver side, so don't send such packets from peer.
> >>>
> >>> Drop TSO and SCTP fragmentation features so that veth devices themselves
> >>> segment packets with XDP enabled. Also cap MTU accordingly.
> >>>
> >>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >>
> >> Is there any precedence for fixing up features and MTU like this? Most
> >> drivers just refuse to install the program if settings are incompatible.
> >
> > I don't know any precedence. I can refuse the program on installing it
> > when features and MTU are not appropriate. Is it preferred?
> > Note that with current implementation wanted_features are not touched so
> > features will be restored when the XDP program is removed. MTU will not
> > be restored though, as I do not remember the original MTU.
>
> I just recalled that virtio_net used to refused XDP when guest offload
> features are incompatible but now it dynamically fixup them on
> installing an XDP program.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f93522ffab2d46a36b57adf324a54e674fc9536
That's slightly different AFAIU, because the virtio features weren't
really controllable at runtime at all. I'm not dead set on leaving the
features be, but I just want to make sure we think this through
properly before we commit to any magic behaviour for ever...
Taking a quick glance at the MTU side, it seems that today if someone
decides to set MTU on one side of a veth pair the packets will simply
get dropped. So the MTU coupling for XDP doesn't seem in line with
existing behaviour of veth, not only other XDP drivers.
next prev parent reply other threads:[~2018-07-24 20:18 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-22 15:13 [PATCH v3 bpf-next 0/8] veth: Driver XDP Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 1/8] net: Export skb_headers_offset_update Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 2/8] veth: Add driver XDP Toshiaki Makita
2018-07-24 0:23 ` Jakub Kicinski
2018-07-24 1:47 ` Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 3/8] veth: Avoid drops by oversized packets when XDP is enabled Toshiaki Makita
2018-07-24 0:27 ` Jakub Kicinski
2018-07-24 1:56 ` Toshiaki Makita
2018-07-24 9:39 ` Toshiaki Makita
2018-07-24 19:10 ` Jakub Kicinski [this message]
2018-07-25 4:22 ` Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 4/8] veth: Handle xdp_frames in xdp napi ring Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 5/8] veth: Add ndo_xdp_xmit Toshiaki Makita
2018-07-24 0:19 ` kbuild test robot
2018-07-24 1:59 ` Toshiaki Makita
2018-07-24 0:33 ` kbuild test robot
2018-07-24 1:02 ` Jakub Kicinski
2018-07-24 2:11 ` Toshiaki Makita
2018-07-24 13:58 ` Tariq Toukan
2018-07-24 2:24 ` Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 6/8] xdp: Add a flag for disabling napi_direct of xdp_return_frame in xdp_mem_info Toshiaki Makita
2018-07-24 1:22 ` Jakub Kicinski
2018-07-24 2:43 ` Toshiaki Makita
2018-07-24 3:38 ` Jakub Kicinski
2018-07-24 4:02 ` Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 7/8] veth: Add XDP TX and REDIRECT Toshiaki Makita
2018-07-22 15:13 ` [PATCH v3 bpf-next 8/8] veth: Support per queue XDP ring Toshiaki Makita
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=20180724121015.5d9edbf3@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=ast@kernel.org \
--cc=brouer@redhat.com \
--cc=daniel@iogearbox.net \
--cc=makita.toshiaki@lab.ntt.co.jp \
--cc=netdev@vger.kernel.org \
--cc=toshiaki.makita1@gmail.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 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).