All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net-next 0/3] net/sched: Pass originating device to drivers offloading ct connection
@ 2022-01-03 11:44 Paul Blakey
  2022-01-03 11:44 ` [PATCH net-next 1/3] net/sched: act_ct: Fill offloading tuple iifidx Paul Blakey
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Paul Blakey @ 2022-01-03 11:44 UTC (permalink / raw)
  To: Paul Blakey, dev, netdev, Saeed Mahameed, Cong Wang,
	Jamal Hadi Salim, Pravin B Shelar, davem, Jiri Pirko,
	Jakub Kicinski, Marcelo Ricardo Leitner
  Cc: Oz Shlomo, Vlad Buslov, Roi Dayan

Hi,

Currently, drivers register to a ct zone that can be shared by multiple
devices. This can be inefficient for the driver to offload, as it
needs to handle all the cases where the tuple can come from,
instead of where it's most likely will arive from.

For example, consider the following tc rules:
tc filter add dev dev1 ... flower action ct commit zone 5 \
   action mirred egress redirect dev dev2

tc filter add dev dev2 ... flower action ct zone 5 \
   action goto chain chain 2
tc filter add dev dev2 ... flower ct_state +trk+est ... \
   action mirred egress redirect dev dev1

Both dev2 and dev1 register to the zone 5 flow table (created
by act_ct). A tuple originating on dev1, going to dev2, will
be offloaded to both devices, and both will need to offload
both directions, resulting in 4 total rules. The traffic
will only hit originiating tuple on dev1, and reply tuple
on dev2.

By passing the originating device that created the connection
with the tuple, dev1 can choose to offload only the originating
tuple, and dev2 only the reply tuple. Resulting in a more
efficient offload.

The first patch adds an act_ct nf conntrack extension, to
temporarily store the originiating device from the skb before
offloading the connection once the connection is established.
Once sent to offload, it fills the tuple originating device.

The second patch get this information from tuples
which pass in openvswitch.

The third patch is Mellanox driver ct offload implementation using
this information to provide a hint to firmware of where this
offloaded tuple packets will arrive from (LOCAL or UPLINK port),
and thus increase insertion rate.

Paul Blakey (3):
  net/sched: act_ct: Fill offloading tuple iifidx
  net: openvswitch: Fill act ct extension
  net/mlx5: CT: Set flow source hint from provided tuple device

 drivers/net/ethernet/mellanox/mlx5/core/dev.c |  2 +-
 .../ethernet/mellanox/mlx5/core/en/tc_ct.c    | 51 +++++++++++++++++--
 .../ethernet/mellanox/mlx5/core/mlx5_core.h   |  1 +
 include/net/netfilter/nf_conntrack_act_ct.h   | 50 ++++++++++++++++++
 include/net/netfilter/nf_conntrack_extend.h   |  4 ++
 net/netfilter/nf_conntrack_core.c             |  6 ++-
 net/openvswitch/conntrack.c                   |  6 +++
 net/sched/act_ct.c                            | 27 ++++++++++
 8 files changed, 141 insertions(+), 6 deletions(-)
 create mode 100644 include/net/netfilter/nf_conntrack_act_ct.h

-- 
2.30.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-01-04 12:20 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-03 11:44 [PATCH net-next 0/3] net/sched: Pass originating device to drivers offloading ct connection Paul Blakey
2022-01-03 11:44 ` [PATCH net-next 1/3] net/sched: act_ct: Fill offloading tuple iifidx Paul Blakey
2022-01-03 11:44 ` [PATCH net-next 2/3] net: openvswitch: Fill act ct extension Paul Blakey
2022-01-03 11:44 ` [PATCH net-next 3/3] net/mlx5: CT: Set flow source hint from provided tuple device Paul Blakey
2022-01-04 12:20 ` [PATCH net-next 0/3] net/sched: Pass originating device to drivers offloading ct connection patchwork-bot+netdevbpf

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.