[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200923102124.4f54aadf@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Wed, 23 Sep 2020 10:21:24 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: saeed@...nel.org
Cc: "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
Saeed Mahameed <saeedm@...dia.com>
Subject: Re: [pull request][net-next 00/15] mlx5 Connection Tracking in NIC
mode
On Tue, 22 Sep 2020 23:24:23 -0700 saeed@...nel.org 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.
Am I understanding correctly that you're talking "switchdev mode" vs
legacy mode?
Could you add a little bit more color about use cases and challenges?
What happens to the rules installed in "NIC mode" when you switch to
"switchdev mode"? IIUC you don't recreated netdevs on switch, right?
Powered by blists - more mailing lists