Jesper Dangaard Brouer wrote: > Multiple BPF-helpers that can manipulate/increase the size of the SKB uses > __bpf_skb_max_len() as the max-length. This function limit size against > the current net_device MTU (skb->dev->mtu). > > When a BPF-prog grow the packet size, then it should not be limited to the > MTU. The MTU is a transmit limitation, and software receiving this packet > should be allowed to increase the size. Further more, current MTU check in > __bpf_skb_max_len uses the MTU from ingress/current net_device, which in > case of redirects uses the wrong net_device. > > Patch V4 keeps a sanity max limit of SKB_MAX_ALLOC (16KiB). The real limit > is elsewhere in the system. Jesper's testing[1] showed it was not possible > to exceed 8KiB when expanding the SKB size via BPF-helper. The limiting > factor is the define KMALLOC_MAX_CACHE_SIZE which is 8192 for > SLUB-allocator (CONFIG_SLUB) in-case PAGE_SIZE is 4096. This define is > in-effect due to this being called from softirq context see code > __gfp_pfmemalloc_flags() and __do_kmalloc_node(). Jakub's testing showed > that frames above 16KiB can cause NICs to reset (but not crash). Keep this > sanity limit at this level as memory layer can differ based on kernel > config. > > [1] https://github.com/xdp-project/bpf-examples/tree/master/MTU-tests > > V3: replace __bpf_skb_max_len() with define and use IPv6 max MTU size. > > Signed-off-by: Jesper Dangaard Brouer <brouer@xxxxxxxxxx> > --- Acked-by: John Fastabend <john.fastabend@xxxxxxxxx>
