netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: alexandre.ferrieux@orange.com
Cc: netfilter-devel@vger.kernel.org
Subject: Re: nfnetlink_queue -- why linear lookup ?
Date: Sat, 14 Aug 2021 23:01:03 +0200	[thread overview]
Message-ID: <20210814210103.GG607@breakpoint.cc> (raw)
In-Reply-To: <11790_1628855682_61165D82_11790_25_1_3f865faa-9fd8-40aa-6e49-5d85dd596b5b@orange.com>

alexandre.ferrieux@orange.com <alexandre.ferrieux@orange.com> wrote:
>   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) ?

Because when this was implemented "highly asynchronous" was not on the
radar.  All users of this (that I know of) do in-order verdicts.

  reply	other threads:[~2021-08-14 21:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13 11:55 nfnetlink_queue -- why linear lookup ? alexandre.ferrieux
2021-08-14 21:01 ` Florian Westphal [this message]
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=20210814210103.GG607@breakpoint.cc \
    --to=fw@strlen.de \
    --cc=alexandre.ferrieux@orange.com \
    --cc=netfilter-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).