netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saeed Mahameed <saeed@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [pull request][net-next 00/15] mlx5 Connection Tracking in NIC mode
Date: Wed, 23 Sep 2020 11:23:53 -0700	[thread overview]
Message-ID: <34193ee66f39b7fd28cd732ff95b00ed1bbbb065.camel@kernel.org> (raw)
In-Reply-To: <20200923102124.4f54aadf@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>

On Wed, 2020-09-23 at 10:21 -0700, Jakub Kicinski wrote:
> On Tue, 22 Sep 2020 23:24:23 -0700 saeed@kernel.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.
> 

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.





      reply	other threads:[~2020-09-23 18:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23  6:24 [pull request][net-next 00/15] mlx5 Connection Tracking in NIC mode saeed
2020-09-23  6:24 ` [net-next 01/15] net/mlx5: Refactor multi chains and prios support saeed
2020-09-23  6:24 ` [net-next 02/15] net/mlx5: Allow ft level ignore for nic rx tables saeed
2020-09-23  6:24 ` [net-next 03/15] net/mlx5e: Tc nic flows to use mlx5_chains flow tables saeed
2020-09-23  6:24 ` [net-next 04/15] net/mlx5e: Split nic tc flow allocation and creation saeed
2020-09-23  6:24 ` [net-next 05/15] net/mlx5: Refactor tc flow attributes structure saeed
2020-09-23 17:18   ` Jakub Kicinski
2020-09-23 18:24     ` Saeed Mahameed
2020-09-23  6:24 ` [net-next 06/15] net/mlx5e: Add tc chains offload support for nic flows saeed
2020-09-23  6:24 ` [net-next 07/15] net/mlx5e: rework ct offload init messages saeed
2020-09-23  6:24 ` [net-next 08/15] net/mlx5e: Support CT offload for tc nic flows saeed
2020-09-23  6:24 ` [net-next 09/15] net/mlx5e: CT: Use the same counter for both directions saeed
2020-09-23  6:24 ` [net-next 10/15] net/mlx5e: TC: Remove unused parameter from mlx5_tc_ct_add_no_trk_match() saeed
2020-09-23  6:24 ` [net-next 11/15] net/mlx5e: Keep direct reference to mlx5_core_dev in tc ct saeed
2020-09-23  6:24 ` [net-next 12/15] net/mlx5e: IPsec: Use kvfree() for memory allocated with kvzalloc() saeed
2020-09-23  6:24 ` [net-next 13/15] net/mlx5e: Use kfree() to free fd->g in accel_fs_tcp_create_groups() saeed
2020-09-23  6:24 ` [net-next 14/15] net/mlx5: simplify the return expression of mlx5_ec_init() saeed
2020-09-23  6:24 ` [net-next 15/15] net/mlx5: remove unreachable return saeed
2020-09-23 17:21 ` [pull request][net-next 00/15] mlx5 Connection Tracking in NIC mode Jakub Kicinski
2020-09-23 18:23   ` Saeed Mahameed [this message]

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=34193ee66f39b7fd28cd732ff95b00ed1bbbb065.camel@kernel.org \
    --to=saeed@kernel.org \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).