On Thu, 13 Apr 2023 at 22:52, Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: > > Kal Cutter Conley <kal.conley@xxxxxxxxxxx> writes: > > >> Well, you mentioned yourself that: > >> > >> > The disadvantage of this patchset is requiring the user to allocate > >> > HugeTLB pages which is an extra complication. > > > > It's a small extra complication *for the user*. However, users that > > need this feature are willing to allocate hugepages. We are one such > > user. For us, having to deal with packets split into disjoint buffers > > (from the XDP multi-buffer paradigm) is a significantly more annoying > > complication than allocating hugepages (particularly on the RX side). > > "More annoying" is not a great argument, though. You're basically saying > "please complicate your code so I don't have to complicate mine". And > since kernel API is essentially frozen forever, adding more of them > carries a pretty high cost, which is why kernel developers tend not to > be easily swayed by convenience arguments (if all you want is a more > convenient API, just build one on top of the kernel primitives and wrap > it into a library). > > So you'll need to come up with either (1) a use case that you *can't* > solve without this new API (with specifics as to why that is the case), > or (2) a compelling performance benchmark showing the complexity is > worth it. Magnus indicated he would be able to produce the latter, in > which case I'm happy to be persuaded by the numbers. We will measure it and get back to you. Would be good with some numbers. > In any case, however, the behaviour needs to be consistent wrt the rest > of XDP, so it's not as simple as just increasing the limit (as I > mentioned in my previous email). > > -Toke >
