> > > Add core AF_XDP support for chunk sizes larger than PAGE_SIZE. This
> > > enables sending/receiving jumbo ethernet frames up to the theoretical
> > > maxiumum of 64 KiB. For chunk sizes > PAGE_SIZE, the UMEM is required
> > > to consist of HugeTLB VMAs (and be hugepage aligned). Initially, only
> > > SKB mode is usable pending future driver work.
> >
> > Hmm, interesting. So how does this interact with XDP multibuf?
>
> To me it currently does not interact with mbuf in any way as it is enabled
> only for skb mode which linearizes the skb from what i see.
>
> I'd like to hear more about Kal's use case - Kal do you use AF_XDP in SKB
> mode on your side?
Our use-case is to receive jumbo Ethernet frames up to 9000 bytes with
AF_XDP in zero-copy mode. This patchset is a step in this direction.
At the very least, it lets you test out the feature in SKB mode
pending future driver support. Currently, XDP multi-buffer does not
support AF_XDP at all. It could support it in theory, but I think it
would need some UAPI design work and a bit of implementation work.
Also, I think that the approach taken in this patchset has some
advantages over XDP multi-buffer:
(1) It should be possible to achieve higher performance
(a) because the packet data is kept together
(b) because you need to acquire and validate less descriptors
and touch the queue pointers less often.
(2) It is a nicer user-space API.
(a) Since the packet data is all available in one linear
buffer. This may even be a requirement to avoid an extra copy if the
data must be handed off contiguously to other code.
The disadvantage of this patchset is requiring the user to allocate
HugeTLB pages which is an extra complication.
I am not sure if this patchset would need to interact with XDP
multi-buffer at all directly. Does anyone have anything to add here?
What other intermediate steps are needed to get to ZC? I think drivers
would already be able to support this now?
Kal
