lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 20 Aug 2020 09:47:04 +0200 From: Jesper Dangaard Brouer <brouer@...hat.com> To: John Fastabend <john.fastabend@...il.com> Cc: Jakub Kicinski <kuba@...nel.org>, Lorenzo Bianconi <lorenzo.bianconi@...hat.com>, Lorenzo Bianconi <lorenzo@...nel.org>, netdev@...r.kernel.org, bpf@...r.kernel.org, davem@...emloft.net, echaudro@...hat.com, sameehj@...zon.com, brouer@...hat.com, Eric Dumazet <eric.dumazet@...il.com> Subject: Re: [PATCH net-next 6/6] net: mvneta: enable jumbo frames for XDP On Wed, 19 Aug 2020 14:58:05 -0700 John Fastabend <john.fastabend@...il.com> wrote: > Jakub Kicinski wrote: > > On Wed, 19 Aug 2020 22:22:23 +0200 Lorenzo Bianconi wrote: > > > > On Wed, 19 Aug 2020 15:13:51 +0200 Lorenzo Bianconi wrote: > > > > > Enable the capability to receive jumbo frames even if the interface is > > > > > running in XDP mode > > > > > > > > > > Signed-off-by: Lorenzo Bianconi <lorenzo@...nel.org> > > > > > > > > Hm, already? Is all the infra in place? Or does it not imply > > > > multi-buffer. > > > > > > with this series mvneta supports xdp multi-buff on both rx and tx sides (XDP_TX > > > and ndo_xpd_xmit()) so we can remove MTU limitation. > > > > Is there an API for programs to access the multi-buf frames? > > Hi Lorenzo, > > This is not enough to support multi-buffer in my opinion. I have the > same comment as Jakub. We need an API to pull in the multiple > buffers otherwise we break the ability to parse the packets and that > is a hard requirement to me. I don't want to lose visibility to get > jumbo frames. > > At minimum we need a bpf_xdp_pull_data() to adjust pointer. In the > skmsg case we use this, > > bpf_msg_pull_data(u32 start, u32 end, u64 flags) > > Where start is the offset into the packet and end is the last byte we > want to adjust start/end pointers to. This way we can walk pages if > we want and avoid having to linearize the data unless the user actual > asks us for a block that crosses a page range. Smart users then never > do a start/end that crosses a page boundary if possible. I think the > same would apply here. > > XDP by default gives you the first page start/end to use freely. If > you need to parse deeper into the payload then you call bpf_msg_pull_data > with the byte offsets needed. I agree that we need a helper like this. (I also think Daniel have proposed this before). This would also be useful for Eric Dumazet / Google's header-split use-case[1]. As I understood from his talk[1], the NIC HW might not always split the packet correctly (due to HW limits). This helper could solve part of this challenge. [1] https://netdevconf.info/0x14/session.html?talk-the-path-to-tcp-4k-mtu-and-rx-zerocopy -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer
Powered by blists - more mailing lists