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: <20210122011834.GA25356@salvia>
Date:   Fri, 22 Jan 2021 02:18:34 +0100
From:   Pablo Neira Ayuso <pablo@...filter.org>
To:     Oz Shlomo <ozsh@...dia.com>
Cc:     Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
        Roi Dayan <roid@...dia.com>, Saeed Mahameed <saeed@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        Paul Blakey <paulb@...dia.com>,
        Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [net-next 08/15] net/mlx5e: CT: Preparation for offloading
 +trk+new ct rules

Hi Oz,

On Wed, Jan 20, 2021 at 06:09:48PM +0200, Oz Shlomo wrote:
> On 1/14/2021 11:50 PM, Marcelo Ricardo Leitner wrote:
> > 
> > Thoughts?
> > 
> 
> I wonder if we should develop a generic mechanism to optimize CT software
> for a use case that is faulty by design.
> This has limited value for software as it would only reduce the conntrack
> table size (packet classification is still required).
> However, this feature may have a big impact on hardware offload.
> Normally hardware offload relies on software to handle new connections.
> Causing all new connections to be processed by software.
> With this patch the hardware may autonomously set the +new connection state
> for the relevant connections.

Could you fix this issue with unidirectional flows by checking for
IPS_CONFIRMED status bit? The idea is to hardware offload the entry
after the first packet goes through software successfully. Then, there
is no need to wait for the established state that requires to see
traffic in both directions.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ