> > 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. :-) In 30 years when everyone finally migrates to page sizes >= 64K the maintenance burden will drop to zero. Knock wood. :-) > > 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.
