On Sun, Aug 15, 2021 at 03:32:30PM +0200, alexandre.ferrieux@xxxxxxxxxx wrote: > On 8/15/21 3:07 PM, Pablo Neira Ayuso wrote: > > On Sun, Aug 15, 2021 at 02:17:08PM +0200, alexandre.ferrieux@xxxxxxxxxx wrote: > > [...] > > > So, the only way forward would be a separate hashtable on ids. > > > > Using the rhashtable implementation is fine for this, it's mostly > > boilerplate code that is needed to use it and there are plenty of > > examples in the kernel tree if you need a reference. > > Thanks, that's indeed pretty simple. I was just worried that people would > object to adding even the slightest overhead (hash_add/hash_del) to the > existing code path, that satisfies 99% of uses (LIFO). What do you think ? It should be possible to maintain both the list and the hashtable, AFAICS, the batch callback still needs the queue_list. > > > PS: what is the intended dominant use case for batch verdicts ? > > > > Issuing a batch containing several packets helps to amortize the > > cost of the syscall. > > Yes, but that could also be achieved by passing an array of ids. You mean, one single sendmsg() with several netlink messages, that would also work to achieve a similar batching effect. > The extra constraint of using a (contiguous) range means that there > is no outlier. This seems to imply that ranges are no help when > flows are multiplexed. Or maybe, the assumption was that bursts tend > to be homogeneous ? What is your usecase?
