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  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]
Date:   Wed, 23 Sep 2020 11:23:53 -0700
From:   Saeed Mahameed <>
To:     Jakub Kicinski <>
Cc:     "David S. Miller" <>,
Subject: Re: [pull request][net-next 00/15] mlx5 Connection Tracking in NIC

On Wed, 2020-09-23 at 10:21 -0700, Jakub Kicinski wrote:
> On Tue, 22 Sep 2020 23:24:23 -0700 wrote:
> > This series adds the support for connection tracking in NIC mode,
> > and attached to this series some trivial cleanup patches.
> > 
> > For more information please see tag log below.
> > 
> > Please pull and let me know if there is any problem.
> > This series includes mlx5 updates
> > 
> > 1) Add support for Connection Tracking offload in NIC mode.
> >  1.1) Refactor current flow steering chains infrastructure and
> >       updates TC nic mode implementation to use flow table chains.
> >  1.2) Refactor current Connection Tracking (CT) infrastructure to
> > not
> >       assume E-switch backend, and make the CT layer agnostic to
> >       underlying steering mode (E-Switch/NIC)
> >  1.3) Plumbing to support CT offload in NIC mode.
> > 
> > 2) Trivial code cleanups.
> I'm surprised you need so much surgery here.

Well, we have this problem with most of our switchdev features.. 
the main issue is Switch model vs NIC model, it is not an easy task to
write the offloads to work on any model transparently, since the model
is different so HW configuration will be different, we are lucky in
this series we managed to re-use 95% of the CT code .. 

> Am I understanding correctly that you're talking "switchdev mode" vs
> legacy mode?

Not exactly legacy, Connection tracking for single NIC mode is the
actual use case no sriov involved.

But yes we are taking a feature that was only supported on switchdev
mode and now can also work in single NIC mode.

> Could you add a little bit more color about use cases and challenges?

Will add it to v2.

> What happens to the rules installed in "NIC mode" when you switch to
> "switchdev mode"? IIUC you don't recreated netdevs on switch, right?

We still recreate netdevs, so everything is flushed when netdev is
unregistered, we have an upcoming series that will re-use the same
netdev to become the uplink representor in switchdev mode, in such case
we will block any mode changes until user removes all the TC rules.

Powered by blists - more mailing lists