Re: nfnetlink_queue -- why linear lookup ?

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

 





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.

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

_________________________________________________________________________________________________________________________

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