On Mon, Aug 16, 2021 at 12:53:33PM +0200, alexandre.ferrieux@xxxxxxxxxx wrote: > > > On 8/16/21 11:05 AM, Pablo Neira Ayuso wrote: > > On Sun, Aug 15, 2021 at 08:47:04PM +0200, alexandre.ferrieux@xxxxxxxxxx wrote: > > > > > > > > > [...] to maintain the hashtable, we need to bother the "normal" code path > > > with hash_add/del. Not much, but still, some overhead... > > > > Probably you can collect some numbers to make sure this is not a > > theoretical issue. > > 'k, will do :) > > > > Yes, a full spectrum of batching methods are possible. If we're to minimize > > > the number of bytes crossing the kernel/user boundary though, an array of > > > ids looks like the way to go (4 bytes per packet, assuming uint32 ids). > > > > Are you proposing a new batching mechanism? > > Well, the problem is backwards compatibility. Indeed I'd propose more > flexible batching via an array of ids instead of a maxid. But the main added > value of this flexibility is to enable reused-small-integers ids, like file > descriptors. As long as the maxid API remains in place, this is impossible. OK, I'll compare this to the sendmsg() call including several netlink messages once you send your patch. > > > That being said, the Doxygen of the userland nfqueue API mentions being > > > DEPRECATED... So what is the recommended replacement ? > > > > What API are you refering to specifically? > > I'm referring to the nfq API documented here: > > https://www.netfilter.org/projects/libnetfilter_queue/doxygen/html/group__Queue.html > > It starts with "Queue handling [DEPRECATED]"... libmnl is preferred these days, specifically for advanced stuff. I've been getting reports from users about this old API: It is simple enough and people don't have to deal with netlink details to get packets from the kernel for simple stuff. Probably we should turn this deprecation into using libmnl and the helpers that libnetfilter_queue provides is recommended. Or translate this old API to use libmnl behind the curtain.
