NACK: [SRU][J:linux-bluefield][PATCH v1 0/7] net/sched: act_ct: offload UDP NEW connections

Andrei Gherzan andrei.gherzan at canonical.com
Mon May 15 15:17:28 UTC 2023


On 23/05/14 09:23AM, Tony Duan wrote:
> BugLink: https://bugs.launchpad.net/bugs/2019264
> 
> SRU Justification:
> 
> [Impact]
> 
> * This patch adds support for to offload single sided UDP connections by offloading only one side, and offloading the second side when/if it comes.
> 
> [Fix]
> 
> * cherry-pick df25455e5a489764508942b77b77de8f550e92cd df25455 netfilter: nf_conntrack: allow early drop of offloaded UDP conns
>   backport 6a9bad0069cf306f3df6ac53cf02438d4e15f296 6a9bad0 net/sched: act_ct: offload UDP NEW connections
>   cherry-pick d5774cb6c55c8721c2daf57cc5e5345e3af286ea d5774cb net/sched: act_ct: set ctinfo in meta action depending on ct state
>   cherry-pick 1a441a9b8be8849957a01413a144f84932c324cb 1a441a9 netfilter: flowtable: cache info of last offload
>   cherry-pick 8f84780b84d645d6e35467f4a6f3236b20d7f4b2 8f84780 netfilter: flowtable: allow unidirectional rules
>   cherry-pick 0eb5acb16418898c3d813e2c2d59a7ea7763a824 0eb5acb netfilter: flowtable: fixup UDP timeout depending on ct state
>   cherry-pick 29744a10c59ede4f996c0c893127ac11bcc85c0c 29744a1 net: flow_offload: provision conntrack info in ct_metadata

All the above apply cleanly except for the backport (expected).

Checking the backported patch, it looks like the "(Paul: GRE is not 
supported and do not change)" line explains the backport
dealing with the IPPROTO_GRE conflict. I expect a more detailed
description here to aid reviews.

Also, the format for this extra metadata is: "[name: text]". This
line is expected to follow the "backport" line immediately.

> [Test Plan]
> 
> * Create OVS bridge with 2 devices mlx5 rep devices.
> Enable HW offload and configure regular connection tracking OpenFlow rules:
> 
> e.g:
>     ovs-ofctl del-flows br-ovs
>     ovs-ofctl add-flow br-ovs arp,actions=normal
>     ovs-ofctl add-flow br-ovs "table=0, ip,ct_state=-trk actions=ct(table=1)"
>     ovs-ofctl add-flow br-ovs "table=1, ip,ct_state=+trk+new actions=ct(commit),normal"
>     ovs-ofctl add-flow br-ovs "table=1, ip,ct_state=+trk+est, actions=normal"
> 
> Run a UDP single sided connection, e.g iperf without a server:
> on mlx5 VF2 iperf -t 1 -c <ip>-u -b 10pps
> 
> Optional: In different terminal, while traffic is running, check for offload:
> tcpdump -nnepi <RELEVANT_MLX5_REP> udp
> and see no iperf udp packets.
> 
> Dump conntrack with relevant ip:
> cat /proc/net/nf_conntrack | grep -i <ip> | grep "\[UNREPLIED\]" | grep -q "\[OFFLOAD\]"
> 
> If tuple appears, tuple was offloaded, yet unreplied.
> 
> [Where problems could occur]
> 
> * Without this patch, it does not support UDP connections offloading
> 
> [Other Info]
> 
> * nothing
> 
> Vlad Buslov (7):
>   net: flow_offload: provision conntrack info in ct_metadata
>   netfilter: flowtable: fixup UDP timeout depending on ct state
>   netfilter: flowtable: allow unidirectional rules
>   netfilter: flowtable: cache info of last offload
>   net/sched: act_ct: set ctinfo in meta action depending on ct state
>   net/sched: act_ct: offload UDP NEW connections
>   netfilter: nf_conntrack: allow early drop of offloaded UDP conns
> 
>  drivers/net/ethernet/mellanox/mlx5/core/en/tc_ct.c |  4 ++
>  .../net/ethernet/netronome/nfp/flower/conntrack.c  | 24 +++++++++
>  include/net/netfilter/nf_flow_table.h              |  8 +--
>  net/netfilter/nf_conntrack_core.c                  | 11 ++--
>  net/netfilter/nf_flow_table_core.c                 |  5 +-
>  net/netfilter/nf_flow_table_inet.c                 |  2 +-
>  net/netfilter/nf_flow_table_offload.c              | 18 ++++---
>  net/sched/act_ct.c                                 | 59 ++++++++++++++++------
>  8 files changed, 98 insertions(+), 33 deletions(-)
> 
> -- 
> 1.8.3.1

-- 
Andrei Gherzan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20230515/f8655f69/attachment.sig>


More information about the kernel-team mailing list