All of lore.kernel.org
 help / color / mirror / Atom feed
From: Edward Cree <ecree@solarflare.com>
To: Paul Blakey <paulb@mellanox.com>,
	Saeed Mahameed <saeedm@mellanox.com>,
	"Oz Shlomo" <ozsh@mellanox.com>,
	Jakub Kicinski <jakub.kicinski@netronome.com>,
	Vlad Buslov <vladbu@mellanox.com>,
	David Miller <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Jiri Pirko <jiri@mellanox.com>, Roi Dayan <roid@mellanox.com>
Subject: Re: [PATCH net-next ct-offload 03/13] net/sched: act_ct: Support restoring conntrack info on skbs
Date: Fri, 6 Mar 2020 13:16:39 +0000	[thread overview]
Message-ID: <7b4bb63d-45f5-b28b-f866-a097d20ae743@solarflare.com> (raw)
In-Reply-To: <1583422468-8456-4-git-send-email-paulb@mellanox.com>

On 05/03/2020 15:34, Paul Blakey wrote:
> Provide an API to restore the ct state pointer.
>
> This may be used by drivers to restore the ct state if they
> miss in tc chain after they already did the hardware connection
> tracking action (ct_metadata action).
>
> For example, consider the following rule on chain 0 that is in_hw,
> however chain 1 is not_in_hw:
>
> $ tc filter add dev ... chain 0 ... \
>   flower ... action ct pipe action goto chain 1
>
> Packets of a flow offloaded (via nf flow table offload) by the driver
> hit this rule in hardware, will be marked with the ct metadata action
> (mark, label, zone) that does the equivalent of the software ct action,
> and when the packet jumps to hardware chain 1, there would be a miss.
>
> CT was already processed in hardware. Therefore, the driver's miss
> handling should restore the ct state on the skb, using the provided API,
> and continue the packet processing in chain 1.
IMNSHO this demonstrates why hardware should do all-or-nothingoffload,
 in the cases where it can't perform the whole filtering it should
 provide the unmodified packet so that SW can start over from a clean
 state.
But as long as these epicycles don't affect drivers for such HW, I guess
 I can't object too hard to them being added.

  reply	other threads:[~2020-03-06 13:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 15:34 [PATCH net-next ct-offload 00/13] Introduce connection tracking offload Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 01/13] netfilter: flowtable: Add API for registering to flow table events Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 02/13] net/sched: act_ct: Instantiate flow table entry actions Paul Blakey
2020-03-05 23:11   ` David Miller
2020-03-06 13:23     ` Paul Blakey
2020-03-06 11:35   ` Edward Cree
2020-03-06 13:22     ` Paul Blakey
2020-03-06 13:45       ` Marcelo Ricardo Leitner
2020-03-06 14:55       ` Edward Cree
2020-03-08  9:41         ` Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 03/13] net/sched: act_ct: Support restoring conntrack info on skbs Paul Blakey
2020-03-06 13:16   ` Edward Cree [this message]
2020-03-05 15:34 ` [PATCH net-next ct-offload 04/13] net/sched: act_ct: Support refreshing the flow table entries Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 05/13] net/sched: act_ct: Enable hardware offload of flow table entires Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 06/13] net/mlx5: E-Switch, Introduce global tables Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 07/13] net/mlx5: E-Switch, Add support for offloading rules with no in_port Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 08/13] net/mlx5: E-Switch, Support getting chain mapping Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 09/13] flow_offload: Add flow_match_ct to get rule ct match Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 10/13] net/mlx5e: CT: Introduce connection tracking Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 11/13] net/mlx5e: CT: Offload established flows Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 12/13] net/mlx5e: CT: Handle misses after executing CT action Paul Blakey
2020-03-05 15:34 ` [PATCH net-next ct-offload 13/13] net/mlx5e: CT: Support clear action Paul Blakey

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=7b4bb63d-45f5-b28b-f866-a097d20ae743@solarflare.com \
    --to=ecree@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=jakub.kicinski@netronome.com \
    --cc=jiri@mellanox.com \
    --cc=netdev@vger.kernel.org \
    --cc=ozsh@mellanox.com \
    --cc=paulb@mellanox.com \
    --cc=roid@mellanox.com \
    --cc=saeedm@mellanox.com \
    --cc=vladbu@mellanox.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.