All of lore.kernel.org
 help / color / mirror / Atom feed
From: <alexandre.ferrieux@orange.com>
To: netfilter@vger.kernel.org
Subject: nfnetlink_queue -- why linear lookup ?
Date: Fri, 13 Aug 2021 12:58:17 +0200	[thread overview]
Message-ID: <31544_1628852264_61165028_31544_19_1_cad3915d-c09c-92ce-825e-8bf1dbb43483@orange.com> (raw)

Hello,

In nfnetlink_queue.c, when receiving a verdict for a packet, its entry in the 
queue is looked up linearly:

   find_dequeue_entry(struct nfqnl_instance *queue, unsigned int id)
   {
     ...
     list_for_each_entry(i, &queue->queue_list, list) {
       if (i->id == id) {
         entry = i;
         break;
       }
     }
     ...
   }

As a result, in a situation of "highly asynchronous" verdicts, i.e. when we want 
some packets to linger in the queue for some time before reinjection, the mere 
existence of a large number of such "old packets" may incur a nonnegligible cost 
to the system.

So I'm wondering: why is the list implemented as a simple linked list instead of 
an array directly indexed by the id (like file descriptors) ?

Indeed, the list has a configured max size, the passed id can be bound-checked, 
discarded entries can simply hold a NULL, and id reuse is userspace's 
responsibility. So it looks like the array would yield constant-time lookup with 
no extra risk.

What am I missing ?

Thans in advance,

-Alex

_________________________________________________________________________________________________________________________

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.


             reply	other threads:[~2021-08-13 10:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13 10:58 alexandre.ferrieux [this message]
2021-08-13 11:10 nfnetlink_queue -- why linear lookup ? alexandre.ferrieux
2021-08-13 11:55 alexandre.ferrieux
2021-08-14 21:01 ` Florian Westphal
2021-08-14 21:05   ` alexandre.ferrieux
2021-08-14 21:12     ` Florian Westphal
2021-08-15 12:17       ` alexandre.ferrieux
2021-08-15 13:07         ` Pablo Neira Ayuso
2021-08-15 13:32           ` alexandre.ferrieux
2021-08-15 14:12             ` Pablo Neira Ayuso
2021-08-15 18:47               ` alexandre.ferrieux
2021-08-16  9:05                 ` Pablo Neira Ayuso
2021-08-16 10:53                   ` alexandre.ferrieux
2021-08-16 10:56                     ` Florian Westphal
2021-08-16 11:07                       ` alexandre.ferrieux
2021-08-16 11:19                     ` Pablo Neira Ayuso
2021-08-16 11:42                     ` Duncan Roe
2021-08-16 12:04               ` Duncan Roe
2021-08-16 16:10                 ` Pablo Neira Ayuso
2021-08-16 16:15                   ` Florian Westphal
2021-08-17  4:03                   ` Duncan Roe
2021-08-15 13:33           ` alexandre.ferrieux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=31544_1628852264_61165028_31544_19_1_cad3915d-c09c-92ce-825e-8bf1dbb43483@orange.com \
    --to=alexandre.ferrieux@orange.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.