Public bug reported:
* Explain the bug(s)
conntrack -D or conntrack -F doesn't delete offloaded tuples.
* brief explanation of fixes
Add support for to delete offloaded tuples via netlink interface and
userspace conntrack utility.
* How to test
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 connection, e.g:
on mlx5 VF1 iperf -s -u
on mlx5 VF2 iperf -c <ip> -u -t 10
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>
See tuples were offloaded:
ipv4 2 udp 17 src=1.1.1.2 dst=1.1.1.3 sport=56394 dport=5001 packets=2
bytes=112 src=1.1.1.3 dst=1.1.1.2 sport=5001 dport=56394 packets=1777
bytes=665340 [HW_OFFLOAD] mark=0 zone=0 use=3
Flush the tuples:
conntrack -F
Verify tuples are deleted:
cat /proc/net/nf_conntrack | grep -i <ip>
Before fix, the above tuple shows again,
after fix, it's deleted, and shows nothing.
* What it could break.
Conntrack -F / -D not working on offloaded tuples.
** Affects: linux-bluefield (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-bluefield in Ubuntu.
https://bugs.launchpad.net/bugs/2015293
Title:
netfilter: ctnetlink: Support offloaded conntrack entry deletion
Status in linux-bluefield package in Ubuntu:
New
Bug description:
* Explain the bug(s)
conntrack -D or conntrack -F doesn't delete offloaded tuples.
* brief explanation of fixes
Add support for to delete offloaded tuples via netlink interface and
userspace conntrack utility.
* How to test
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 connection, e.g:
on mlx5 VF1 iperf -s -u
on mlx5 VF2 iperf -c <ip> -u -t 10
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>
See tuples were offloaded:
ipv4 2 udp 17 src=1.1.1.2 dst=1.1.1.3 sport=56394 dport=5001 packets=2
bytes=112 src=1.1.1.3 dst=1.1.1.2 sport=5001 dport=56394 packets=1777
bytes=665340 [HW_OFFLOAD] mark=0 zone=0 use=3
Flush the tuples:
conntrack -F
Verify tuples are deleted:
cat /proc/net/nf_conntrack | grep -i <ip>
Before fix, the above tuple shows again,
after fix, it's deleted, and shows nothing.
* What it could break.
Conntrack -F / -D not working on offloaded tuples.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2015293/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
