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.toshi...@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.toshi...@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.
