Re: AF_XDP umem and jumbo frames?

[Johannes Berg <johannes@sipsolutions.net>]

On Sun, 2018-10-07 at 18:13 +0200, Jesper Dangaard Brouer wrote:

> One thing I realize is that people on this list, are perhaps not
> familiar how NIC RX (via DMA) works.  On RX, we cannot know the RX
> packet size up-front.  Thus, when filling the NIC RX-ring memory slots,
> then we have to allocated room for the "worse-case", e.g. 9000Bytes is
> minimum 3x4K=12K, and due to page-alloc limits min 4x4K=16K.  Thus,
> regardless of packet length the alloc size is the same.  (I will not go
> into detail on how different drivers tries to reduce this mem-overhead,
> but only say that those tricks costs CPU cycles).

Isn't all that generally only true if the NIC has no capability for
split packets? Some (wireless) NICs will - afaict - simply split the
larger packets into multiple single DMA descriptors (pages).

Obviously then that isn't contiguous memory, but it seems that part
could be solved by "mumble mumble something like rewriting eBPF accesses
at skb->data+4k to virtual memory" - which yes, would be *tremendously*
expensive once your program actually does that, but shouldn't actually
cause the general case to be worse off?

(Yes, I also realize that there's a question of being able to prove that
the access is >=4k, but in general I'd assume you can prove that it's
significantly less than 4k and thus not punt to such a slow-path)

johannes