Re: nfnetlink_queue -- why linear lookup ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/15/21 4:12 PM, Pablo Neira Ayuso wrote:
On Sun, Aug 15, 2021 at 03:32:30PM +0200, alexandre.ferrieux@xxxxxxxxxx wrote:
>>
[...] 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.

Yes, but to maintain the hashtable, we need to bother the "normal" code path with hash_add/del. Not much, but still, some overhead...

> > 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.


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).

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?


For O(1) lookup:

My primary motivation is for transparent proxies and userland qdiscs. In both cases, specific packets must be held for some time and reinjected at a later time which is not computed by a simple, fixed delay, but rather triggered by some external event.

My secondary motivation is that the netfilter queue is a beautifully asynchronous mechanism, and absolutely nothing in its definition limits it to the dumb FIFO-of-instantaneous-drop-decisions that seems to dominate sample code.

For the deprecation of id-range-based batching:

It seems that as soon as two different packet streams are muxed in the queue, one deserving verdict A and the other verdict B, contiguous id ranges of a given verdict may be very small. But I realize I'm 20 years late to complain :)

That being said, the Doxygen of the userland nfqueue API mentions being DEPRECATED... So what is the recommended replacement ?

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.




[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux