Kal Cutter Conley <kal.conley@xxxxxxxxxxx> writes: >> >> Well, I'm mostly concerned with having two different operation and >> configuration modes for the same thing. We'll probably need to support >> multibuf for AF_XDP anyway for the non-ZC path, which means we'll need >> to create a UAPI for that in any case. And having two APIs is just going >> to be more complexity to handle at both the documentation and >> maintenance level. > > I don't know if I would call this another "API". This patchset doesn't > change the semantics of anything. It only lifts the chunk size > restriction when hugepages are used. Furthermore, the changes here are > quite small and easy to understand. The four sentences added to the > documentation shouldn't be too concerning either. :-) Well, you mentioned yourself that: > The disadvantage of this patchset is requiring the user to allocate > HugeTLB pages which is an extra complication. In addition, presumably when using this mode, the other XDP actions (XDP_PASS, XDP_REDIRECT to other targets) would stop working unless we add special handling for that in the kernel? We'll definitely need to handle that somehow... > In 30 years when everyone finally migrates to page sizes >= 64K the > maintenance burden will drop to zero. Knock wood. :-) Haha, right, but let's make sure we have something that is consistent in the intervening decades, shall we? ;) >> It *might* be worth it to do this if the performance benefit is really >> compelling, but, well, you'd need to implement both and compare directly >> to know that for sure :) > > What about use-cases that require incoming packet data to be > contiguous? Without larger chunk sizes, the user is forced to allocate > extra space per packet and copy the data. This defeats the purpose of > ZC. What use cases would that be, exactly? Presumably this is also a performance issue? Which goes back to me asking for benchmarks :) -Toke
