Re: nfnetlink_queue -- why linear lookup ?

[Duncan Roe <duncan_roe@optusnet.com.au>]

On Mon, Aug 16, 2021 at 12:53:33PM +0200, alexandre.ferrieux@orange.com wrote:
>
>
> On 8/16/21 11:05 AM, Pablo Neira Ayuso wrote:
> > On Sun, Aug 15, 2021 at 08:47:04PM +0200, alexandre.ferrieux@orange.com 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.
>
> > > 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]"...
>
The deprecated functions are not going away, it's just not recommended to use
them in new code.

The replacements are the non-deprecated functions.

Here's a bit of background: libnetfilter_queue is essentially a blend of 2
separate libraries. The older (and deprecated) library uses libnfnetlink to
communicate with the kernel. The newer (current) library uses libmnl to
communicate with the kernel. You either use functions from one library or the
other: they don't mix.

libnetfilter_queue is a wrapper for all libnfnetlink functions except
nfnl_rcvbufsiz(), while it only provides helpers for *some* libmnl functions.

The main new feature of the current libnetfilter_queue library is a suite of
helpers for packet mangling. These manage checksums and other required header
manipulation for ipv4 & ipv6 and the upb & tcp transport layers. Current
libnetfilter_queue also provides inclusion of a mangled packet in a verdict -
not available from the deprecated library AFAICS.

Current libnetfilter_queue doesn't provide batch verdicts. I don't know why -
perhaps Pablo can elaborate.

Userland support for any new featuer would normally go into libmnl.

Cheers ... Duncan.