netdev - Re: [PATCH nf-next] netfilter: flowtable: separate replace, destroy and stats to different workqueues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6173dd63-7769-e4a1-f796-889802b0a898@nvidia.com>
Date:   Wed, 24 Mar 2021 13:24:53 +0200
From:   Oz Shlomo <ozsh@...dia.com>
To:     Pablo Neira Ayuso <pablo@...filter.org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
CC:     <netdev@...r.kernel.org>, <netfilter-devel@...r.kernel.org>,
        "Saeed Mahameed" <saeedm@...dia.com>,
        Paul Blakey <paulb@...dia.com>
Subject: Re: [PATCH nf-next] netfilter: flowtable: separate replace, destroy
 and stats to different workqueues

Hi,

On 3/24/2021 3:38 AM, Pablo Neira Ayuso wrote:
> 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.
> 

Removing stale objects is a good optimization for cases when the rate of established connections is 
greater than the hardware offload insertion rate.
However, with a single workqueue design, a burst of del commands may postpone connection offload tasks.
Postponed offloads may cause additional packets to go through software, thus creating a chain effect 
which may diminish the system's connection rate.

Marcelo, AFAIU add/del are synchronized by design since the del is triggered by the gc thread.
A del workqueue item will be instantiated only after a connection is in hardware.