From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Cc: Oz Shlomo <ozsh@nvidia.com>,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org,
Saeed Mahameed <saeedm@nvidia.com>,
Paul Blakey <paulb@nvidia.com>
Subject: Re: [PATCH nf-next] netfilter: flowtable: separate replace, destroy and stats to different workqueues
Date: Wed, 24 Mar 2021 02:38:10 +0100 [thread overview]
Message-ID: <20210324013810.GA5861@salvia> (raw)
In-Reply-To: <YFjdb7DveNOolSTr@horizon.localdomain>
Hi Marcelo,
On Mon, Mar 22, 2021 at 03:09:51PM -0300, Marcelo Ricardo Leitner wrote:
> On Wed, Mar 03, 2021 at 05:11:47PM +0100, Pablo Neira Ayuso wrote:
[...]
> > Or probably make the cookie unique is sufficient? The cookie refers to
> > the memory address but memory can be recycled very quickly. If the
> > cookie helps to catch the reorder scenario, then the conntrack id
> > could be used instead of the memory address as cookie.
>
> Something like this, if I got the idea right, would be even better. If
> the entry actually expired before it had a chance of being offloaded,
> there is no point in offloading it to then just remove it.
It would be interesting to explore this idea you describe. Maybe a
flag can be set on stale objects, or simply remove the stale object
from the offload queue. So I guess it should be possible to recover
control on the list of pending requests as a batch that is passed
through one single queue_work call.
next prev parent reply other threads:[~2021-03-24 1:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-03 12:59 [PATCH nf-next] netfilter: flowtable: separate replace, destroy and stats to different workqueues Oz Shlomo
2021-03-03 16:11 ` Pablo Neira Ayuso
2021-03-22 18:09 ` Marcelo Ricardo Leitner
2021-03-24 1:38 ` Pablo Neira Ayuso [this message]
2021-03-24 11:24 ` Oz Shlomo
2021-03-24 21:20 ` Marcelo Ricardo Leitner
2021-03-25 8:46 ` Oz Shlomo
2021-03-26 13:51 ` Marcelo Ricardo Leitner
2021-03-17 23:36 ` Pablo Neira Ayuso
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=20210324013810.GA5861@salvia \
--to=pablo@netfilter.org \
--cc=marcelo.leitner@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=ozsh@nvidia.com \
--cc=paulb@nvidia.com \
--cc=saeedm@nvidia.com \
/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.