From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Kicinski 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 Message-ID: <20180724121015.5d9edbf3@cakuba.netronome.com> References: <20180722151308.5480-1-toshiaki.makita1@gmail.com> <20180722151308.5480-4-toshiaki.makita1@gmail.com> <20180723172707.74a8acfa@cakuba.netronome.com> <75bacf34-0dd8-a49a-b595-001400f36349@lab.ntt.co.jp> <709ccfa0-fcd8-bd48-1e85-2960bbe232dd@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Toshiaki Makita , netdev@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer To: Toshiaki Makita Return-path: Received: from mail-qk0-f196.google.com ([209.85.220.196]:39231 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388488AbeGXUSO (ORCPT ); Tue, 24 Jul 2018 16:18:14 -0400 Received: by mail-qk0-f196.google.com with SMTP id b5-v6so3345549qkg.6 for ; Tue, 24 Jul 2018 12:10:20 -0700 (PDT) In-Reply-To: <709ccfa0-fcd8-bd48-1e85-2960bbe232dd@lab.ntt.co.jp> Sender: netdev-owner@vger.kernel.org List-ID: 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 > >>> > >>> 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 > >> > >> 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.