[Kernel-packages] [Bug 2034578] Re: Support IPSEC full offload implementation
** Merge proposal linked: https://code.launchpad.net/~bodong-wang/ubuntu/+source/linux-bluefield/+git/jammy/+merge/450970 -- 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/2034578 Title: Support IPSEC full offload implementation Status in linux-bluefield package in Ubuntu: New Bug description: Summary: Align Kernel IPsec Full offload implementation in the DPU to the upstream Full offload in all components: OFED, Strongswan, etc. This is in order for DPU Kernel IPsec to include policy offload and be fully aligned to what CX Kernel customers will use. How to test: Host 1: /opt/mellanox/iproute2/sbin/devlink dev eswitch set pci/:03:00.0 mode legacy echo 'dmfs' > /sys/bus/pci/devices/:03:00.0/net/p0/compat/devlink/steering_mode echo 'full' > /sys/class/net/p0/compat/devlink/ipsec_mode /opt/mellanox/iproute2/sbin/devlink dev eswitch set pci/:03:00.0 mode switchdev BF on host 1: /opt/mellanox/iproute2/sbin/ip xfrm policy add src 196.234.181.165 dst 196.234.182.166 dir out tmpl src 196.234.181.165/16 dst 196.234.182.166/16 proto esp reqid 0xefa83812 mode transport priority 10 /opt/mellanox/iproute2/sbin/ip xfrm policy add src 196.234.182.166 dst 196.234.181.165 dir in tmpl src 196.234.182.166/16 dst 196.234.181.165/16 proto esp reqid 0x63a7db74 mode transport priority 10 /opt/mellanox/iproute2/sbin/ip xfrm policy add src 196.234.182.166 dst 196.234.181.165 dir fwd tmpl src 196.234.182.166/16 dst 196.234.181.165/16 proto esp reqid 0x63a7db74 mode transport priority 10 /opt/mellanox/iproute2/sbin/ip xfrm state add src 196.234.181.165/16 dst 196.234.182.166/16 proto esp spi 0xefa83812 reqid 0xefa83812 mode transport aead 'rfc4106(gcm(aes))' 0xe2fe3857301d8f72b5d71d295a462ef21868e407 128 offload packet dev p0 dir out sel src 196.234.181.165/16 dst 196.234.182.166/16 flag esn replay-window 32 /opt/mellanox/iproute2/sbin/ip xfrm state add src 196.234.182.166/16 dst 196.234.181.165/16 proto esp spi 0x63a7db74 reqid 0x63a7db74 mode transport aead 'rfc4106(gcm(aes))' 0xe916c4d0db1886e8c877b023e8cebef53b4d2d0f 128 offload packet dev p0 dir in sel src 196.234.182.166/16 dst 196.234.181.165/16 flag esn replay-window 32 Start OVS and set following configure on BF: /usr/bin/ovs-vsctl set Open_vSwitch . other_config:hw-offload=true /usr/bin/ovs-vsctl set Open_vSwitch . other_config:max-idle=30 Host2: /opt/mellanox/iproute2/sbin/devlink dev eswitch set pci/:03:00.1 mode legacy echo 'dmfs' > /sys/bus/pci/devices/:03:00.1/net/p1/compat/devlink/steering_mode echo 'full' > /sys/class/net/p1/compat/devlink/ipsec_mode /opt/mellanox/iproute2/sbin/devlink dev eswitch set pci/:03:00.1 mode switchdev BF on host 2: /opt/mellanox/iproute2/sbin/ip xfrm policy add src 196.234.182.166 dst 196.234.181.165 dir out tmpl src 196.234.182.166/16 dst 196.234.181.165/16 proto esp reqid 0xefa83812 mode transport priority 10 /opt/mellanox/iproute2/sbin/ip xfrm policy add src 196.234.181.165 dst 196.234.182.166 dir in tmpl src 196.234.181.165/16 dst 196.234.182.166/16 proto esp reqid 0x63a7db74 mode transport priority 10 /opt/mellanox/iproute2/sbin/ip xfrm policy add src 196.234.181.165 dst 196.234.182.166 dir fwd tmpl src 196.234.181.165/16 dst 196.234.182.166/16 proto esp reqid 0x63a7db74 mode transport priority 10 /opt/mellanox/iproute2/sbin/ip xfrm state add src 196.234.181.165 dst 196.234.182.166 proto esp spi 0xefa83812 reqid 0xefa83812 mode transport aead 'rfc4106(gcm(aes))' 0xe2fe3857301d8f72b5d71d295a462ef21868e407 128 offload packet dev p0 dir out sel src 196.234.181.165/16 dst 196.234.182.166/16 flag esn replay-window 32 /opt/mellanox/iproute2/sbin/ip xfrm state add src 196.234.181.165 dst 196.234.182.166 proto esp spi 0x63a7db74 reqid 0x63a7db74 mode transport aead 'rfc4106(gcm(aes))' 0xe916c4d0db1886e8c877b023e8cebef53b4d2d0f 128 offload packet dev p0 dir in sel src 196.234.181.165/16 dst 196.234.182.166/16 flag esn replay-window 32 Start OVS and set following configure on BF: /usr/bin/ovs-vsctl set Open_vSwitch . other_config:hw-offload=true /usr/bin/ovs-vsctl set Open_vSwitch . other_config:max-idle=30 Send the traffic between host 1 and host 2 and check IPsec counters in "ethtool -S" statistics on both BF. How to fix: Need to backport a series of xfrm patches into BlueField 5.15 kernel, from 6.0 upstream kernel. Patches needed for 5.15 kernel: afe9e47 xfrm: fix conflict for netdev and tx stats 6aff54d xfrm: don't skip free of empty state in acquire policy 692fecb xfrm: delete offloaded policy 91b6276 xfrm: Support UDP encapsulation in packet offload mode 69e168a xfrm: add missed call to delete offloaded policies 9724724 xfrm: release all offloaded policy memory e57b7ec xfrm: don't require advance ESN callback for packet
[Kernel-packages] [Bug 2032378] Re: Devlink backport: fix race and lock issue
** Merge proposal linked: https://code.launchpad.net/~bodong-wang/ubuntu/+source/linux-bluefield/+git/jammy/+merge/450916 -- 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/2032378 Title: Devlink backport: fix race and lock issue Status in linux-bluefield package in Ubuntu: New Bug description: Summary: machine get stuck if try to switch to switchdev mode while toggling ns over BF kernel. This is due to missing lock refactor series devlink and driver from kernel 6.0 How to test: 1. Configure SRIOV 2. Enable switchdev mode 3. Devlink reload 4. Add/Del network namespace Note: Need to run the test multiple times to reproduce the issue. How to fix: Need to backport a series of devlink patches into BlueField 5.15 kernel, from 6.0 upstream kernel. Patches needed for 5.4/5.15 kernel: First series: 367dfa121205^..f0680ef0f949 second series: 5502e8712c9b^..c90005b5f75c Also needed: 644a66c60f02 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2032378/+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
[Kernel-packages] [Bug 2025396] Re: kdump/kexec does not work when UEFI secureboot and kernel lockdown enabled
Any update on this issue? Do we have ETA to have it addressed? -- 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/2025396 Title: kdump/kexec does not work when UEFI secureboot and kernel lockdown enabled Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) We've found that for Jammy 5.15 and also 5.4.0-1049 kernel running on Bluefield, the kdump doesn't work when enabling secure boot[1]. * How to test Make sure kernel config: CONFIG_SECURITY_LOCKDOWN_LSM=y CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_IN_SECURE_BOOT=y The kdump kernel we use is actually signed correctly # file /boot/vmlinuz-5.15.0-1015-bluefield /boot/vmlinuz-5.15.0-1015-bluefield: gzip compressed data, was "vmlinuz-5.15.0 1015-bluefield.efi.signed", # kdump-config show DUMP_MODE:kdump USE_KDUMP:1 KDUMP_SYSCTL: kernel.panic_on_oops=1 KDUMP_COREDIR:/var/crash crashkernel addr: 0xcfe0 /boot/vmlinuz-5.4.0-1049-bluefield kdump initrd: /boot/initrd.img-5.4.0-1049-bluefield current state:Not ready to kdump kdump-tools.service - Kernel crash dump capture service Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2023-04-13 19:21:01 UTC; 4 days ago Process: 1975 ExecStart=/etc/init.d/kdump-tools start (code=exited, status=0/SUCCESS) Main PID: 1975 (code=exited, status=0/SUCCESS) Apr 13 19:20:59 br2-004-a-dpu.nd-sjc6w.nvmetal.net systemd[1]: Starting Kernel crash dump capture serv> Apr 13 19:20:59 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[1975]: Starting kdump-tools: Apr 13 19:20:59 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[2184]: * Creating symlink /var/lib/kdu> Apr 13 19:20:59 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[2184]: * Creating symlink /var/lib/kdu> Apr 13 19:21:01 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[2525]: syscall kexec_file_load not avai> Apr 13 19:21:01 br2-004-a-dpu.nd-sjc6w.nvmetal.net kdump-tools[2184]: * failed to load kdump kernel * Possible reason Currently, a problem faced by arm64 is if a kernel image is signed by a MOK key, loading it via the kexec_file_load() system call would be rejected with the error in dmesg "Lockdown: kexec: kexec of unsigned images is restricted; see man kernel_lockdown.7". I backported the two below [2]: 0d519cadf751 arm64: kexec_file: use more system keyrings to verify kernel image signature c903dae8941d kexec, KEYS: make the code in bzImage64_verify_sig generic However still kdump/kexec fails due to lockdown [ 353.298348] Lockdown: kexec: kexec of unsigned images is restricted; see man kernel_lockdown.7 [ 364.833004] audit: type=1400 audit(1686619435.331:16): apparmor="STATUS" operation="profile_load" profile="unconfined" name="cri-containerd.apparmor.d" pid=15407 comm="apparmor_parser" If I disable kernel lockdown (CONFIG_SECURITY_LOCKDOWN_LSM=n), then kexec works ok. But this is not an acceptable workaround. * How to fix I got it working (secure boot + lockdown config enabled + kdump/kexec) using kernel v6.4 on bluefield, which means if we backport properly, mostly missing some arch/arm64/ patches, to BlueField 5.15 kernel, we can get it working. Reference 1. https://docs.nvidia.com/networking/display/BlueFieldDPUOSv392/UEFI%20Secure%20Boot 2. https://www.spinics.net/lists/arm-kernel/msg979554.html 3. https://mjg59.dreamwidth.org/50577.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2025396/+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
[Kernel-packages] [Bug 2017600] [NEW] Move CONFIG_NF_CONNTRACK to build in
Public bug reported: SRU Justifications: The bpf helper bpf_ct_lookup_tcp is defined under #if IS_BUILTIN(CONFIG_NF_CONNTRACK). To work with BPF, this is needed. How to test: Test XDP BPF What could be break: N/A ** 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/2017600 Title: Move CONFIG_NF_CONNTRACK to build in Status in linux-bluefield package in Ubuntu: New Bug description: SRU Justifications: The bpf helper bpf_ct_lookup_tcp is defined under #if IS_BUILTIN(CONFIG_NF_CONNTRACK). To work with BPF, this is needed. How to test: Test XDP BPF What could be break: N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2017600/+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
[Kernel-packages] [Bug 2013758] [NEW] Add support for 200G/400G speed to bond
Public bug reported: SRU Justification: [Impact] * 5.4 kernel can't work with bond for 200G/400G NIC [Fix] * cherry pick the commits to support 200G/400G [Test Plan] * Test on 200G/400G bond ** 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/2013758 Title: Add support for 200G/400G speed to bond Status in linux-bluefield package in Ubuntu: New Bug description: SRU Justification: [Impact] * 5.4 kernel can't work with bond for 200G/400G NIC [Fix] * cherry pick the commits to support 200G/400G [Test Plan] * Test on 200G/400G bond To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2013758/+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
[Kernel-packages] [Bug 1998938] Re: Add support for CT accounting stats
Feature is not available yet. Need to verify after https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2008136 ** Tags removed: verification-needed-focal -- 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/1998938 Title: Add support for CT accounting stats Status in linux-bluefield package in Ubuntu: New Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug(s) Add CT accounting stats per flow for TC CT rules. This is only available when nf_conn_acct is enabled so it won’t affect performance when not enabled. * Brief explanation of fixes Cherry-pick. No adaptation. First commit for SW, second commit of HW offloaded rules. * How to test Enable nf_conn_acct and check ct stats. * What it could break. Nothing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1998938/+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
[Kernel-packages] [Bug 1995004] Re: Increase stability with connection tracking offload
This bug is not presenting on 5.15 kernel. ** Changed in: linux-bluefield (Ubuntu Jammy) Status: Fix Committed => Invalid -- 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/1995004 Title: Increase stability with connection tracking offload Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Released Status in linux-bluefield source package in Jammy: Invalid Bug description: * Explain the bug(s) Currently qdisc ingress handling (sch_handle_ingress()) doesn't set a return value and it is left to the old return value of the caller (__netif_receive_skb_core()) which is RX drop, so if the packet is consumed, caller will stop and return this value as if the packet was dropped. Also, include set of patches to increase stability with connection tracking offload, including reduced cpu load and possible deadlock on cleanup. * What it could break. Packet on egress tc rule forwarding to a ingress tc rule will drop. High cpu load. Possible deadlock on cleanup. * How to test Run connection tracking hw offload scenario with millions of flows, check cpu load, test cleanup and readd scenarios. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1995004/+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
[Kernel-packages] [Bug 2006397] [NEW] nft_lookup crash when running DDOS attack
Public bug reported:
* Explain the bug
Running DDOS test on tcp port 22 will trigger kernel crash.
* Brief explanation of fixes
Do not update stateful expressions if lookup is inverted
* How to test
Configuration nftables with config file below:
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0
jump filter_ssh
}
chain filter_ssh {
tcp dport { 22 } ct state new accept
}
}
* {22}: {} is mandatory to repro
If we don’t add {}, nft_lookup_eval function is never called and kernel crush
isn’t reproduced.
Then apply nft by doing:
# nft -f temp_nftables.conf
Start hping3 from peer:
# hping3 -I {Host Device} -p 22 -d 52 {SmartNIC IP Address} --flood
DPU side will crash with kernel call trace without this fix.
** 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/2006397
Title:
nft_lookup crash when running DDOS attack
Status in linux-bluefield package in Ubuntu:
New
Bug description:
* Explain the bug
Running DDOS test on tcp port 22 will trigger kernel crash.
* Brief explanation of fixes
Do not update stateful expressions if lookup is inverted
* How to test
Configuration nftables with config file below:
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0
jump filter_ssh
}
chain filter_ssh {
tcp dport { 22 } ct state new accept
}
}
* {22}: {} is mandatory to repro
If we don’t add {}, nft_lookup_eval function is never called and kernel crush
isn’t reproduced.
Then apply nft by doing:
# nft -f temp_nftables.conf
Start hping3 from peer:
# hping3 -I {Host Device} -p 22 -d 52 {SmartNIC IP Address} --flood
DPU side will crash with kernel call trace without this fix.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2006397/+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
[Kernel-packages] [Bug 1995004] Re: Increase stability with connection tracking offload
** Changed in: linux-bluefield (Ubuntu Focal) Status: Confirmed => Fix Committed ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1995004 Title: Increase stability with connection tracking offload Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Status in linux-bluefield source package in Jammy: Fix Committed Bug description: * Explain the bug(s) Currently qdisc ingress handling (sch_handle_ingress()) doesn't set a return value and it is left to the old return value of the caller (__netif_receive_skb_core()) which is RX drop, so if the packet is consumed, caller will stop and return this value as if the packet was dropped. Also, include set of patches to increase stability with connection tracking offload, including reduced cpu load and possible deadlock on cleanup. * What it could break. Packet on egress tc rule forwarding to a ingress tc rule will drop. High cpu load. Possible deadlock on cleanup. * How to test Run connection tracking hw offload scenario with millions of flows, check cpu load, test cleanup and readd scenarios. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1995004/+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
[Kernel-packages] [Bug 1995004] Re: Increase stability with connection tracking offload
** Changed in: linux-bluefield (Ubuntu Focal) Status: Fix Committed => Confirmed -- 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/1995004 Title: Increase stability with connection tracking offload Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Confirmed Status in linux-bluefield source package in Jammy: Fix Committed Bug description: * Explain the bug(s) Currently qdisc ingress handling (sch_handle_ingress()) doesn't set a return value and it is left to the old return value of the caller (__netif_receive_skb_core()) which is RX drop, so if the packet is consumed, caller will stop and return this value as if the packet was dropped. Also, include set of patches to increase stability with connection tracking offload, including reduced cpu load and possible deadlock on cleanup. * What it could break. Packet on egress tc rule forwarding to a ingress tc rule will drop. High cpu load. Possible deadlock on cleanup. * How to test Run connection tracking hw offload scenario with millions of flows, check cpu load, test cleanup and readd scenarios. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1995004/+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
[Kernel-packages] [Bug 2002361] [NEW] allow per-net notifier to follow netdev into namespace
Public bug reported:
* Explain the bug(s)
There is possible deadlock during reload mlxsw into initial netns made possible
by commit:
328fbe747ad4 ("net: Close race between {un, }register_netdevice_notifier() and
setup_net()/cleanup_net()").
* Brief explanation of fixes
Introduce dev_net variant that is basically per-net notifier with an
extension that re-registers the per-net notifier upon netdev namespace
change. Basically the per-net notifier follows the netdev into
namespace.
* How to test
# chroot /host nsenter -t 1 -n devlink dev reload ${port} netns ${NS}
* What it could break
none
** 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/2002361
Title:
allow per-net notifier to follow netdev into namespace
Status in linux-bluefield package in Ubuntu:
New
Bug description:
* Explain the bug(s)
There is possible deadlock during reload mlxsw into initial netns made
possible by commit:
328fbe747ad4 ("net: Close race between {un, }register_netdevice_notifier()
and setup_net()/cleanup_net()").
* Brief explanation of fixes
Introduce dev_net variant that is basically per-net notifier with an
extension that re-registers the per-net notifier upon netdev namespace
change. Basically the per-net notifier follows the netdev into
namespace.
* How to test
# chroot /host nsenter -t 1 -n devlink dev reload ${port} netns ${NS}
* What it could break
none
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/2002361/+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
[Kernel-packages] [Bug 1998938] [NEW] Add support for CT accounting stats
Public bug reported: * Explain the bug(s) Add CT accounting stats per flow for TC CT rules. This is only available when nf_conn_acct is enabled so it won’t affect performance when not enabled. * Brief explanation of fixes Cherry-pick. No adaptation. First commit for SW, second commit of HW offloaded rules. * How to test Enable nf_conn_acct and check ct stats. * What it could break. Nothing. ** Affects: linux-bluefield (Ubuntu) Importance: Undecided Status: New ** Summary changed: - Add support for CT accounting stats. First commit for SW, second commit of HW offloaded rules. + Add support for CT accounting stats -- 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/1998938 Title: Add support for CT accounting stats Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) Add CT accounting stats per flow for TC CT rules. This is only available when nf_conn_acct is enabled so it won’t affect performance when not enabled. * Brief explanation of fixes Cherry-pick. No adaptation. First commit for SW, second commit of HW offloaded rules. * How to test Enable nf_conn_acct and check ct stats. * What it could break. Nothing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1998938/+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
[Kernel-packages] [Bug 1998857] [NEW] tick/rcu: Stop allowing RCU_SOFTIRQ in idle
Public bug reported: * Explain the bug RCU_SOFTIRQ used to be special in that it could be raised on purpose within the idle path to prevent from stopping the tick. Some code still prevents from unnecessary warnings related to this specific behaviour while entering in dynticks-idle mode. However the nohz layout has changed quite a bit in ten years, and the removal of CONFIG_RCU_FAST_NO_HZ has been the final straw to this safe-conduct. Now the RCU_SOFTIRQ vector is expected to be raised from sane places. * Brief explanation of fixes Stop allowing RCU_SOFTIRQ in idle * How to test In boot dmesg, the warning should be gone. * What it could break. N/A ** 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/1998857 Title: tick/rcu: Stop allowing RCU_SOFTIRQ in idle Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug RCU_SOFTIRQ used to be special in that it could be raised on purpose within the idle path to prevent from stopping the tick. Some code still prevents from unnecessary warnings related to this specific behaviour while entering in dynticks-idle mode. However the nohz layout has changed quite a bit in ten years, and the removal of CONFIG_RCU_FAST_NO_HZ has been the final straw to this safe-conduct. Now the RCU_SOFTIRQ vector is expected to be raised from sane places. * Brief explanation of fixes Stop allowing RCU_SOFTIRQ in idle * How to test In boot dmesg, the warning should be gone. * What it could break. N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1998857/+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
[Kernel-packages] [Bug 1995004] Re: Increase stability with connection tracking offload
** Summary changed: - Fix return value of qdisc ingress handling on success + Increase stability with connection tracking offload ** Description changed: - SRU Justification: + * Explain the bug(s) - net: Fix return value of qdisc ingress handling on success - - * Explain the bug(s) - Currently qdisc ingress handling (sch_handle_ingress()) doesn't set a return value and it is left to the old return value of the caller (__netif_receive_skb_core()) which is RX drop, so if the packet is consumed, caller will stop and return this value as if the packet was dropped. - - * brief explanation of fixes - - Fix that by setting the return value to RX success if - the packet was handled successfully. - + + Also, include set of patches to increase stability with connection + tracking offload, including reduced cpu load and possible deadlock on + cleanup. + + * What it could break. + + Packet on egress tc rule forwarding to a ingress tc rule will drop. + High cpu load. Possible deadlock on cleanup. + * How to test - - Commit msg has the steps. - - * What it could break. - - Packet on egress tc rule forwarding to a ingress tc rule will drop. - - - SRU Justification: - - netfilter: conntrack: annotate data-races around ct->timeout - netfilter: conntrack: remove unneeded nf_ct_put - netfilter: conntrack: convert to refcount_t api - netfilter: flowtable: Make sure GC works periodically in idle system - netfilter: flowtable: avoid possible false sharing - netfilter: flowtable: fix excessive hw offload attempts after failure - netfilter: nf_flowtable: expose nf_flow_table_gc_cleanup() - netfilter: flowtable: add function to invoke garbage collection immediately - netfilter: flowtable: fix stuck flows on cleanup due to pending work - - - * Explain the bug(s) - - Set of patches to increase stability with connection tracking offload, - including reduced cpu load and possible deadlock on cleanup. - - * brief explanation of fixes - - Fix that by setting the return value to RX success if - the packet was handled successfully. - - * How to test - - Run connection tracking hw offload scenario with millions of flows, check cpu load, test cleanup and readd scenarios. - - * What it could break. - - High cpu load. Possible deadlock on cleanup. + Run connection tracking hw offload scenario with millions of flows, + check cpu load, test cleanup and readd scenarios. -- 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/1995004 Title: Increase stability with connection tracking offload Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) Currently qdisc ingress handling (sch_handle_ingress()) doesn't set a return value and it is left to the old return value of the caller (__netif_receive_skb_core()) which is RX drop, so if the packet is consumed, caller will stop and return this value as if the packet was dropped. Also, include set of patches to increase stability with connection tracking offload, including reduced cpu load and possible deadlock on cleanup. * What it could break. Packet on egress tc rule forwarding to a ingress tc rule will drop. High cpu load. Possible deadlock on cleanup. * How to test Run connection tracking hw offload scenario with millions of flows, check cpu load, test cleanup and readd scenarios. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1995004/+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
[Kernel-packages] [Bug 1995004] [NEW] Fix return value of qdisc ingress handling on success
Public bug reported: SRU Justification: net: Fix return value of qdisc ingress handling on success * Explain the bug(s) Currently qdisc ingress handling (sch_handle_ingress()) doesn't set a return value and it is left to the old return value of the caller (__netif_receive_skb_core()) which is RX drop, so if the packet is consumed, caller will stop and return this value as if the packet was dropped. * brief explanation of fixes Fix that by setting the return value to RX success if the packet was handled successfully. * How to test Commit msg has the steps. * What it could break. Packet on egress tc rule forwarding to a ingress tc rule will drop. SRU Justification: netfilter: conntrack: annotate data-races around ct->timeout netfilter: conntrack: remove unneeded nf_ct_put netfilter: conntrack: convert to refcount_t api netfilter: flowtable: Make sure GC works periodically in idle system netfilter: flowtable: avoid possible false sharing netfilter: flowtable: fix excessive hw offload attempts after failure netfilter: nf_flowtable: expose nf_flow_table_gc_cleanup() netfilter: flowtable: add function to invoke garbage collection immediately netfilter: flowtable: fix stuck flows on cleanup due to pending work * Explain the bug(s) Set of patches to increase stability with connection tracking offload, including reduced cpu load and possible deadlock on cleanup. * brief explanation of fixes Fix that by setting the return value to RX success if the packet was handled successfully. * How to test Run connection tracking hw offload scenario with millions of flows, check cpu load, test cleanup and readd scenarios. * What it could break. High cpu load. Possible deadlock on cleanup. ** 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/1995004 Title: Fix return value of qdisc ingress handling on success Status in linux-bluefield package in Ubuntu: New Bug description: SRU Justification: net: Fix return value of qdisc ingress handling on success * Explain the bug(s) Currently qdisc ingress handling (sch_handle_ingress()) doesn't set a return value and it is left to the old return value of the caller (__netif_receive_skb_core()) which is RX drop, so if the packet is consumed, caller will stop and return this value as if the packet was dropped. * brief explanation of fixes Fix that by setting the return value to RX success if the packet was handled successfully. * How to test Commit msg has the steps. * What it could break. Packet on egress tc rule forwarding to a ingress tc rule will drop. SRU Justification: netfilter: conntrack: annotate data-races around ct->timeout netfilter: conntrack: remove unneeded nf_ct_put netfilter: conntrack: convert to refcount_t api netfilter: flowtable: Make sure GC works periodically in idle system netfilter: flowtable: avoid possible false sharing netfilter: flowtable: fix excessive hw offload attempts after failure netfilter: nf_flowtable: expose nf_flow_table_gc_cleanup() netfilter: flowtable: add function to invoke garbage collection immediately netfilter: flowtable: fix stuck flows on cleanup due to pending work * Explain the bug(s) Set of patches to increase stability with connection tracking offload, including reduced cpu load and possible deadlock on cleanup. * brief explanation of fixes Fix that by setting the return value to RX success if the packet was handled successfully. * How to test Run connection tracking hw offload scenario with millions of flows, check cpu load, test cleanup and readd scenarios. * What it could break. High cpu load. Possible deadlock on cleanup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1995004/+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
[Kernel-packages] [Bug 1982980] [NEW] store the last executed chain also for clsact egress
Public bug reported:
* Explain the bug(s)
Misses on multi chain tc egress rules that are offloaded from ovs datapath
rules (ct rules on ovs' internal port devices)
will restart from recirc_id(0) again in OvS dp, instead of recirc_id that
matches where we left off
in tc (ovs recirc_id should be equal tc chain).
* brief explanation of fixes
Set the tc skb extension that stores the last executed tc chain which ovs reads
on misses to
set the starting recirc_id from.
* How to test
Setup ovs with ovs offload enabled, and add ip to internal port, example with
veth device:
function config_veth() {
local ns=$1
local ip=$2
local peer=${ns}_peer
local veth=${ns}_veth
echo "Create namespace $ns, veths: hv $veth <-> ns $peer ($ip)"
ip netns add $ns
ip link del $veth &>/dev/null
ip link add $veth type veth peer name $peer
ip link set $veth up
ip link set $peer netns $ns
ip netns exec $ns ifconfig $peer $ip/24 mtu 1400 up
}
IP1="7.7.7.1"
IP2="7.7.7.2"
config_veth ns0 $IP1
ifconfig ovs-br $IP2
ovs-vsctl add-br ovs-br
ovs-vsctl add-port ovs-br ns0_veth
ovs-vsctl add-port ovs-br ns1_veth
Add openflow rules and check if packets arriving to table=0 (default table
that corrosponds to recirc_id(0))
have ct mark that was only set if a later table was executed. Add a
unsupported offload action (in this case group), so we
will have miss from offloaded tc rules to ovs dp:
ovs-ofctl del-flows ovs-br
ovs-ofctl -O OpenFlow12 add-group ovs-br
'group_id=2,type=select,bucket=ct(commit,zone=1,table=2)'
ovs-ofctl add-flow ovs-br "table=0, arp, action=normal"
ovs-ofctl add-flow ovs-br "table=0, ip, +trk, actions=drop"
#bad flow
ovs-ofctl add-flow ovs-br "table=0, ip, -trk, actions=ct(commit,table=1)"
#good flow
ovs-ofctl add-flow ovs-br "table=1, in_port=1, actions=group:2"
ovs-ofctl add-flow ovs-br "table=2, ip, actions=normal"
run udp/tcp traffic from default ns 7.7.7.1 to ns1 7.7.7.2 and
check ovs-appctl dpctl/dump-flows
if bug occurs there should be a drop rule, because we got to recirc_id(0)
after missing in tc, and tc
already did the -trk ct(commit...) rule, so packet should be tracked (+trk)
when missed to ovs.
* What it could break.
Running the wrong datapath rules in OvS datapath.
** 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/1982980
Title:
store the last executed chain also for clsact egress
Status in linux-bluefield package in Ubuntu:
New
Bug description:
* Explain the bug(s)
Misses on multi chain tc egress rules that are offloaded from ovs datapath
rules (ct rules on ovs' internal port devices)
will restart from recirc_id(0) again in OvS dp, instead of recirc_id that
matches where we left off
in tc (ovs recirc_id should be equal tc chain).
* brief explanation of fixes
Set the tc skb extension that stores the last executed tc chain which ovs
reads on misses to
set the starting recirc_id from.
* How to test
Setup ovs with ovs offload enabled, and add ip to internal port, example
with veth device:
function config_veth() {
local ns=$1
local ip=$2
local peer=${ns}_peer
local veth=${ns}_veth
echo "Create namespace $ns, veths: hv $veth <-> ns $peer ($ip)"
ip netns add $ns
ip link del $veth &>/dev/null
ip link add $veth type veth peer name $peer
ip link set $veth up
ip link set $peer netns $ns
ip netns exec $ns ifconfig $peer $ip/24 mtu 1400 up
}
IP1="7.7.7.1"
IP2="7.7.7.2"
config_veth ns0 $IP1
ifconfig ovs-br $IP2
ovs-vsctl add-br ovs-br
ovs-vsctl add-port ovs-br ns0_veth
ovs-vsctl add-port ovs-br ns1_veth
Add openflow rules and check if packets arriving to table=0 (default table
that corrosponds to recirc_id(0))
have ct mark that was only set if a later table was executed. Add a
unsupported offload action (in this case group), so we
will have miss from offloaded tc rules to ovs dp:
ovs-ofctl del-flows ovs-br
ovs-ofctl -O OpenFlow12 add-group ovs-br
'group_id=2,type=select,bucket=ct(commit,zone=1,table=2)'
ovs-ofctl add-flow ovs-br "table=0, arp, action=normal"
ovs-ofctl add-flow ovs-br "table=0, ip, +trk, actions=drop"
#bad flow
ovs-ofctl add-flow ovs-br "table=0, ip, -trk, actions=ct(commit,table=1)"
#good flow
ovs-ofctl add-flow ovs-br "table=1, in_port=1, actions=group:2"
ovs-ofctl add-flow ovs-br "table=2, ip, actions=normal"
run udp/tcp traffic from default ns 7.7.7.1 to ns1 7.7.7.2 and
check ovs-appctl dpctl/dump-flows
if bug occurs there
[Kernel-packages] [Bug 1978967] [NEW] Fix XFRM flags validity check
Public bug reported: * Explain the bug(s) commit a3ca11eec78 introduced a flags validity check for XFRM , the check excluded flag XFRM_OFFLOAD_FULL from the check hence the flag is being blocked from getting to the kernel space. The above is preventing IPsec states from being added with the full_offload option. * Brief explanation of fixes The commit restricted unknown flags from being configured from user space by adding a validity check, since the Bluefield feature added such a flag , the fix expands the validity check to include this flag which is added only in Bluefield kernel . * How to test Need to make sure that configuring IPsec with full_offload option using IProute2 can be done successfully with no issues. (Not getting the RTNETLINK answers: Invalid argument error anymore) * What it could break. NA, this patch allows a specific flag to get passed to the kernel space, the kernel was using this flag already however after validity check got introduced the flag just got blocked from getting to the kernel. ** 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/1978967 Title: Fix XFRM flags validity check Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) commit a3ca11eec78 introduced a flags validity check for XFRM , the check excluded flag XFRM_OFFLOAD_FULL from the check hence the flag is being blocked from getting to the kernel space. The above is preventing IPsec states from being added with the full_offload option. * Brief explanation of fixes The commit restricted unknown flags from being configured from user space by adding a validity check, since the Bluefield feature added such a flag , the fix expands the validity check to include this flag which is added only in Bluefield kernel . * How to test Need to make sure that configuring IPsec with full_offload option using IProute2 can be done successfully with no issues. (Not getting the RTNETLINK answers: Invalid argument error anymore) * What it could break. NA, this patch allows a specific flag to get passed to the kernel space, the kernel was using this flag already however after validity check got introduced the flag just got blocked from getting to the kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1978967/+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
[Kernel-packages] [Bug 1974096] Re: cls_flower: Fix inability to match GRE/IPIP packets
Need to revert this patch as it introduces a new issue for IPSec. -- 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/1974096 Title: cls_flower: Fix inability to match GRE/IPIP packets Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug When a packet of a new flow arrives in openvswitch kernel module, it dissects the packet and passes the extracted flow key to ovs-vswtichd daemon. If hw- offload configuration is enabled, the daemon creates a new TC flower entry to bypass openvswitch kernel module for the flow (TC flower can also offload flows to NICs but this time that does not matter). In this processing flow, I found the following issue in cases of GRE/IPIP packets. When ovs_flow_key_extract() in openvswitch module parses a packet of a new GRE (or IPIP) flow received on non-tunneling vports, it extracts information of the outer IP header for ip_proto/src_ip/dst_ip match keys. This means ovs-vswitchd creates a TC flower entry with IP protocol/addresses match keys whose values are those of the outer IP header. OTOH, TC flower, which uses flow_dissector (different parser from openvswitch module), extracts information of the inner IP header. * How to test The following flow is an example to describe the issue in more detail. <--- Outer IP -> <-- Inner IP --> +--+--+--+--+--+--+ | ip_proto | src_ip | dst_ip | ip_proto | src_ip | dst_ip | | 47 (GRE) | 192.168.10.1 | 192.168.10.2 | 6 (TCP) | 10.0.0.1 | 10.0.0.2 | +--+--+--+--+--+--+ In this case, TC flower entry and extracted information are shown as below: - ovs-vswitchd creates TC flower entry with: - ip_proto: 47 - src_ip: 192.168.10.1 - dst_ip: 192.168.10.2 - TC flower extracts below for IP header matches: - ip_proto: 6 - src_ip: 10.0.0.1 - dst_ip: 10.0.0.2 Thus, GRE or IPIP packets never match the TC flower entry, as each dissector behaves differently. IMHO, the behavior of TC flower (flow dissector) does not look correct, as ip_proto/src_ip/dst_ip in TC flower match means the outermost IP header information except for GRE/IPIP cases. This patch adds a new flow_dissector flag FLOW_DISSECTOR_F_STOP_BEFORE_ENCAP which skips dissection of the encapsulated inner GRE/IPIP header in TC flower classifier. * What it could break. N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1974096/+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
[Kernel-packages] [Bug 1975820] [NEW] remove offload_pickup sysctl again
Public bug reported: * Explain the feature These two sysctls were added because the hardcoded defaults (2 minutes, tcp, 30 seconds, udp) turned out to be too low for some setups. They appeared in 5.14-rc1 so it should be fine to remove it again. Note: they patch was introduced before the Linux kernel was released. Marcelo convinced me that there should be no difference between a flow that was offloaded vs. a flow that was not wrt. timeout handling. Thus the default is changed to those for TCP established and UDP stream, 5 days and 120 seconds, respectively. Marcelo also suggested to account for the timeout value used for the offloading, this avoids increase beyond the value in the conntrack- sysctl and will also instantly expire the conntrack entry with altered sysctls. Example: nf_conntrack_udp_timeout_stream=60 nf_flowtable_udp_timeout=60 This will remove offloaded udp flows after one minute, rather than two. An earlier version of this patch also cleared the ASSURED bit to allow nf_conntrack to evict the entry via early_drop (i.e., table full). However, it looks like we can safely assume that connection timed out via HW is still in established state, so this isn't needed. Quoting Oz: [..] the hardware sends all packets with a set FIN flags to sw. [..] Connections that are aged in hardware are expected to be in the established state. In case it turns out that back-to-sw-path transition can occur for 'dodgy' connections too (e.g., one side disappeared while software-path would have been in RETRANS timeout), we can adjust this later. * 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" Establish a TCP and UDP connection and let it reach the hardware aging timeout. The offload timeout is controlled with the following sysctl parameters: net.netfilter.nf_flowtable_tcp_timeout = 30 net.netfilter.nf_flowtable_udp_timeout = 30 After the connection has aged it should return to [ASSURED] state with the following timeout: TCP: net.netfilter.nf_conntrack_tcp_timeout_established (= 432000) - net.netfilter.nf_flowtable_tcp_timeout (=30) UDP: net.netfilter.nf_conntrack_udp_timeout_stream (= 120) - net.netfilter.nf_flowtable_udp_timeout (= 30) * What it could break. N/A ** 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/1975820 Title: remove offload_pickup sysctl again Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the feature These two sysctls were added because the hardcoded defaults (2 minutes, tcp, 30 seconds, udp) turned out to be too low for some setups. They appeared in 5.14-rc1 so it should be fine to remove it again. Note: they patch was introduced before the Linux kernel was released. Marcelo convinced me that there should be no difference between a flow that was offloaded vs. a flow that was not wrt. timeout handling. Thus the default is changed to those for TCP established and UDP stream, 5 days and 120 seconds, respectively. Marcelo also suggested to account for the timeout value used for the offloading, this avoids increase beyond the value in the conntrack- sysctl and will also instantly expire the conntrack entry with altered sysctls. Example: nf_conntrack_udp_timeout_stream=60 nf_flowtable_udp_timeout=60 This will remove offloaded udp flows after one minute, rather than two. An earlier version of this patch also cleared the ASSURED bit to allow nf_conntrack to evict the entry via early_drop (i.e., table full). However, it looks like we can safely assume that connection timed out via HW is still in established state, so this isn't needed. Quoting Oz: [..] the hardware sends all packets with a set FIN flags to sw. [..] Connections that are aged in hardware are expected to be in the established state. In case it turns out that back-to-sw-path transition can occur for 'dodgy' connections too (e.g., one side disappeared while software- path would have been in RETRANS timeout), we can adjust this later. * 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,
[Kernel-packages] [Bug 1975649] [NEW] flowtable: fix TCP flow teardown
Public bug reported: * Explain the feature This patch addresses three possible problems: 1. ct gc may race to undo the timeout adjustment of the packet path, leaving the conntrack entry in place with the internal offload timeout (one day). 2. ct gc removes the ct because the IPS_OFFLOAD_BIT is not set and the CLOSE timeout is reached before the flow offload del. 3. tcp ct is always set to ESTABLISHED with a very long timeout in flow offload teardown/delete even though the state might be already CLOSED. Also as a remark we cannot assume that the FIN or RST packet is hitting flow table teardown as the packet might get bumped to the slow path in nftables. This patch resets IPS_OFFLOAD_BIT from flow_offload_teardown(), so conntrack handles the tcp rst/fin packet which triggers the CLOSE/FIN state transition. Moreover, return the connection's ownership to conntrack upon teardown by clearing the offload flag and fixing the established timeout value. The flow table GC thread will asynchonrnously free the flow table and hardware offload entries. Before this patch, the IPS_OFFLOAD_BIT remained set for expired flows on which is also misleading since the flow is back to classic conntrack path. If nf_ct_delete() removes the entry from the conntrack table, then it calls nf_ct_put() which decrements the refcnt. This is not a problem because the flowtable holds a reference to the conntrack object from flow_offload_alloc() path which is released via flow_offload_free(). This patch also updates nft_flow_offload to skip packets in SYN_RECV state. Since we might miss or bump packets to slow path, we do not know what will happen there while we are still in SYN_RECV, this patch postpones offload up to the next packet which also aligns to the existing behaviour in tc-ct. flow_offload_teardown() does not reset the existing tcp state from flow_offload_fixup_tcp() to ESTABLISHED anymore, packets bump to slow path might have already update the state to CLOSE/FIN. * How to test Adding the following flows to the OVS bridge in DPU OS: # ovs-ofctl add-flow ovsbr1 "table=0, ip,ct_state=-trk, actions=ct(table=1)" # ovs-ofctl add-flow ovsbr1 "table=1, ip,ct_state=+new, actions=ct(commit),normal" # ovs-ofctl add-flow ovsbr1 "table=1, ip,ct_state=-new, actions=normal" Start netserver on SUT: # netserver -p 5007 Start multiple TCP_CRR tests on peer: # count=1;while [ $count -lt 10 ]; do screen -d -m netperf -t TCP_CRR -H 11.0.0.2 -l 360 -- -r 1 -O " MIN_LAETENCY, MAX_LATENCY, MEAN_LATENCY, P90_LATENCY, P99_LATENCY ,P999_LATENCY,P_LATENCY,STDDEV_LATENCY ,THROUGHPUT ,THROUGHPUT_UNITS "; count=`expr $count + 1`; done A huge number of connections will be established and tear down. After the tests, some of them are not aged out: # From /proc/net/nf_conntrack in DPU OS ipv4 2 tcp 6 86354 LAST_ACK src=11.0.0.1 dst=11.0.0.2 sport=35862 dport=46797 src=11.0.0.2 dst=11.0.0.1 sport=46797 dport=35862 [ASSURED] mark=0 zone=0 use=2 ipv4 2 tcp 6 86354 LAST_ACK src=11.0.0.1 dst=11.0.0.2 sport=35862 dport=46797 src=11.0.0.2 dst=11.0.0.1 sport=46797 dport=35862 [ASSURED] mark=0 zone=0 use=2 ipv4 2 tcp 6 86354 LAST_ACK src=11.0.0.1 dst=11.0.0.2 sport=35862 dport=46797 src=11.0.0.2 dst=11.0.0.1 sport=46797 dport=35862 [ASSURED] mark=0 zone=0 use=2 The issue is usually reproduced after running the for several times. * What it could break. N/A ** 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/1975649 Title: flowtable: fix TCP flow teardown Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the feature This patch addresses three possible problems: 1. ct gc may race to undo the timeout adjustment of the packet path, leaving the conntrack entry in place with the internal offload timeout (one day). 2. ct gc removes the ct because the IPS_OFFLOAD_BIT is not set and the CLOSE timeout is reached before the flow offload del. 3. tcp ct is always set to ESTABLISHED with a very long timeout in flow offload teardown/delete even though the state might be already CLOSED. Also as a remark we cannot assume that the FIN or RST packet is hitting flow table teardown as the packet might get bumped to the slow path in nftables. This patch resets IPS_OFFLOAD_BIT from flow_offload_teardown(), so conntrack handles the tcp rst/fin packet which triggers the CLOSE/FIN state transition. Moreover, return the connection's ownership to conntrack upon teardown by clearing the offload flag and fixing the established timeout value. The flow table GC thread will asynchonrnously free the flow table and hardware offload entries. Before this patch, the IPS_OFFLOAD_BIT remained set for expired flows on which is also misleading
[Kernel-packages] [Bug 1974096] [NEW] cls_flower: Fix inability to match GRE/IPIP packets
Public bug reported: * Explain the bug When a packet of a new flow arrives in openvswitch kernel module, it dissects the packet and passes the extracted flow key to ovs-vswtichd daemon. If hw- offload configuration is enabled, the daemon creates a new TC flower entry to bypass openvswitch kernel module for the flow (TC flower can also offload flows to NICs but this time that does not matter). In this processing flow, I found the following issue in cases of GRE/IPIP packets. When ovs_flow_key_extract() in openvswitch module parses a packet of a new GRE (or IPIP) flow received on non-tunneling vports, it extracts information of the outer IP header for ip_proto/src_ip/dst_ip match keys. This means ovs-vswitchd creates a TC flower entry with IP protocol/addresses match keys whose values are those of the outer IP header. OTOH, TC flower, which uses flow_dissector (different parser from openvswitch module), extracts information of the inner IP header. * How to test The following flow is an example to describe the issue in more detail. <--- Outer IP -> <-- Inner IP --> +--+--+--+--+--+--+ | ip_proto | src_ip | dst_ip | ip_proto | src_ip | dst_ip | | 47 (GRE) | 192.168.10.1 | 192.168.10.2 | 6 (TCP) | 10.0.0.1 | 10.0.0.2 | +--+--+--+--+--+--+ In this case, TC flower entry and extracted information are shown as below: - ovs-vswitchd creates TC flower entry with: - ip_proto: 47 - src_ip: 192.168.10.1 - dst_ip: 192.168.10.2 - TC flower extracts below for IP header matches: - ip_proto: 6 - src_ip: 10.0.0.1 - dst_ip: 10.0.0.2 Thus, GRE or IPIP packets never match the TC flower entry, as each dissector behaves differently. IMHO, the behavior of TC flower (flow dissector) does not look correct, as ip_proto/src_ip/dst_ip in TC flower match means the outermost IP header information except for GRE/IPIP cases. This patch adds a new flow_dissector flag FLOW_DISSECTOR_F_STOP_BEFORE_ENCAP which skips dissection of the encapsulated inner GRE/IPIP header in TC flower classifier. * What it could break. N/A ** 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/1974096 Title: cls_flower: Fix inability to match GRE/IPIP packets Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug When a packet of a new flow arrives in openvswitch kernel module, it dissects the packet and passes the extracted flow key to ovs-vswtichd daemon. If hw- offload configuration is enabled, the daemon creates a new TC flower entry to bypass openvswitch kernel module for the flow (TC flower can also offload flows to NICs but this time that does not matter). In this processing flow, I found the following issue in cases of GRE/IPIP packets. When ovs_flow_key_extract() in openvswitch module parses a packet of a new GRE (or IPIP) flow received on non-tunneling vports, it extracts information of the outer IP header for ip_proto/src_ip/dst_ip match keys. This means ovs-vswitchd creates a TC flower entry with IP protocol/addresses match keys whose values are those of the outer IP header. OTOH, TC flower, which uses flow_dissector (different parser from openvswitch module), extracts information of the inner IP header. * How to test The following flow is an example to describe the issue in more detail. <--- Outer IP -> <-- Inner IP --> +--+--+--+--+--+--+ | ip_proto | src_ip | dst_ip | ip_proto | src_ip | dst_ip | | 47 (GRE) | 192.168.10.1 | 192.168.10.2 | 6 (TCP) | 10.0.0.1 | 10.0.0.2 | +--+--+--+--+--+--+ In this case, TC flower entry and extracted information are shown as below: - ovs-vswitchd creates TC flower entry with: - ip_proto: 47 - src_ip: 192.168.10.1 - dst_ip: 192.168.10.2 - TC flower extracts below for IP header matches: - ip_proto: 6 - src_ip: 10.0.0.1 - dst_ip: 10.0.0.2 Thus, GRE or IPIP packets never match the TC flower entry, as each dissector behaves differently. IMHO, the behavior of TC flower (flow dissector) does not look correct, as ip_proto/src_ip/dst_ip in TC flower match means the outermost
[Kernel-packages] [Bug 1968751] [NEW] Devlink wasn't enabled from common config
Public bug reported: * Explain the feature A pull request was submitted for March SRU at: https://code.launchpad.net/~bodong-wang/ubuntu/+source/linux- bluefield/+git/version-seeds/+merge/416211 However, CONFIG_NET_DEVLINK was mistakenly removed when merging. This breaks all switchdev configurations. * How to test Any devlink command, e.g: # devlink dev eswitch show pci/:03:00.0 * What it could break N/A ** 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/1968751 Title: Devlink wasn't enabled from common config Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the feature A pull request was submitted for March SRU at: https://code.launchpad.net/~bodong-wang/ubuntu/+source/linux- bluefield/+git/version-seeds/+merge/416211 However, CONFIG_NET_DEVLINK was mistakenly removed when merging. This breaks all switchdev configurations. * How to test Any devlink command, e.g: # devlink dev eswitch show pci/:03:00.0 * What it could break N/A To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1968751/+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
[Kernel-packages] [Bug 1963948] Re: Fix flow table lookup after ct clear or switching zones
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1963948 Title: Fix flow table lookup after ct clear or switching zones Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug Flow table lookup is skipped if packet either went through ct clear action (which set the IP_CT_UNTRACKED flag on the packet), or while switching zones and there is already a connection associated with the packet. This will result in no SW offload of the connection, and the and connection not being removed from flow table with TCP teardown (fin/rst packet). * How to test Create OVS bridge with 2 veth pairs, put each veth peer device in a different namespace - ns0, ns1, and add the other side veth devices (named ns[01]_veth below) to OVS bridge. Configure the namespace devices with an ip, and bring all devices up. Enable HW offload in ovs and configure connection tracking OpenFlow rules that pass via two zones (but drop the FIN packets on the reply side or they will still teardown the connection in second zone from the reply side as it happens first): ovs-ofctl add-flow br-ovs "arp actions=NORMAL" ovs-ofctl add-flow br-ovs "ct_state=-trk,ip,in_port=ns0_veth actions=ct(table=5,zone=5)" ovs-ofctl add-flow br-ovs "ct_state=-trk,tcp,in_port=ns1_veth,tcp_flags=-fin actions=ct(table=8,zone=7)" ovs-ofctl add-flow br-ovs "ct_state=+new+trk,ip,in_port=ns0_veth actions=ct(commit,zone=5),ct(table=7,zone=7)" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,ip,in_port=ns0_veth actions=ct(table=7,zone=7)" ovs-ofctl add-flow br-ovs "ct_state=+new+trk,ip,in_port=ns0_veth actions=ct(commit,zone=7),output:ns1_veth" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,ip,in_port=ns0_veth actions=output:ns1_veth" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,tcp,in_port=ns1_veth actions=ct(table=9,zone=5)" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,tcp,in_port=ns1_veth actions=output:ns0_veth" Run TCP iperf from ns0 namespace to an iperf server on ns1 namepsace with the given ip. After traffic ends, check cat /proc/net/nf_conntrack | grep -i offload If bug occurs, connections will remain offloaded till timeout, otherwise, they will be in teardown state. * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1963948/+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
[Kernel-packages] [Bug 1960575] Re: Pass originating device to drivers offloading ct connection so devices will filter the tuples and offload them more efficiently
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1960575 Title: Pass originating device to drivers offloading ct connection so devices will filter the tuples and offload them more efficiently Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the feature 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. * 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" With SW steering enabled and the above commits (and up to date ofed) tuple insertion rate should be about twice as fast. This can be seen via procfs hw offloaded count while running high traffic: while true; do res=`sudo cat /proc/net/nf_conntrack | grep -i offload` && echo "$res" && echo "$res" | wc -l; done * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1960575/+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
[Kernel-packages] [Bug 1961819] Re: CT: Offload only ASSURED connections
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1961819 Title: CT: Offload only ASSURED connections Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the feature Assured connections are those connections which deemed of "higher quality" and less like to expire than non-assured connections, as they passed some stricter rule (e.g in udp reply + connection lasting more than 2 seconds). This feature offloads only those connections. * 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 short UDP connection (< 2 seconds), e.g: on mlx5 VF1 iperf -s -u on mlx5 VF2 iperf -c -t 1 -u Run longer UDP connection (> 2 seconds), e.g: on mlx5 VF1 iperf -s -u on mlx5 VF2 iperf -c -t 10 -u With the above commit quick lived UDP connections (< 2 seconds) will not be offloaded to the flow table as can be checked by cat /proc/net/nf_conntrack | grep -i offload while connections lasting more than 2 seconds (and of course double sided) will be offloaded. * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1961819/+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
[Kernel-packages] [Bug 1962490] Re: Support VF groups rate limit
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1962490 Title: Support VF groups rate limit Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the feature Managing TX rate of VFs becomes non-trivial task when a big number of VFs are used. This issue can be handled with some grouping mechanism. Currently driver provide two ways to limit TX rate of the VF: TC police action and NDO API callback. Implementation of grouping within this two infrastructures problematic, due to the following: NDO API rate limiting is legacy feature, even though it's available in switchdev mode, and extending it with new abstraction is not good anyway; TC police action is flow based and requires net device with Qdisc on it and implementing this will bring unwanted complications. According to aforesaid devlink is the most appropriate place. * How to test Set tx_max value on the devlink port with a command. For ex.: $ devlink port function rate set pci/:82:00.0/1 tx_max 10gbit or if grouping is required, create rate group with configured tx_max value in a single command and assign port to this group: $ devlink port function rate add pci/:82:00.0/1st_group tx_max 8gbit $ devlink port function rate set pci/:82:00.0/1 tx_max 10gbit parent 1st_group Configuration is done. Run traffic and do measurement. * What it could break. As this pull request backported 130 patches from devlink/netlink, it may break some functionalities from net core layer. Also, the network drivers which are not used by BF are disabled to avoid the fix of conflicts. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1962490/+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
[Kernel-packages] [Bug 1967892] Re: Fix flow table lookup failure with no originating ifindex
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1967892 Title: Fix flow table lookup failure with no originating ifindex Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug After the CT ifindex extension feature, flow table entries are populated with ifindex information which was intended to only be used for HW offload. This tuple ifindex is hashed in the flow table key, so it must be filled for lookup to be successful. But tuple ifindex is only relevant for the netfilter flowtables (nft), so it's not filled in act_ct flow table lookup, resulting in lookup failure, and no SW offload and no offload teardown for TCP connection FIN/RST packets. To fix this, add new tc ifindex field to tuple, which will only be used for offloading, not for lookup, as it will not be part of the tuple hash. * 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" Generate traffic at high rate (e.g. using IXIA). The number of offloaded rules exposed in /sys/kernel/debug/mlx5/\:$BUS\:00.0/ct/offloaded should be in synch the number of generated connections. * What it could break. Perhaps nft offload – it is not part of our tests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1967892/+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
[Kernel-packages] [Bug 1967892] [NEW] Fix flow table lookup failure with no originating ifindex
Public bug reported: * Explain the bug After the CT ifindex extension feature, flow table entries are populated with ifindex information which was intended to only be used for HW offload. This tuple ifindex is hashed in the flow table key, so it must be filled for lookup to be successful. But tuple ifindex is only relevant for the netfilter flowtables (nft), so it's not filled in act_ct flow table lookup, resulting in lookup failure, and no SW offload and no offload teardown for TCP connection FIN/RST packets. To fix this, add new tc ifindex field to tuple, which will only be used for offloading, not for lookup, as it will not be part of the tuple hash. * 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" Generate traffic at high rate (e.g. using IXIA). The number of offloaded rules exposed in /sys/kernel/debug/mlx5/\:$BUS\:00.0/ct/offloaded should be in synch the number of generated connections. * What it could break. Perhaps nft offload – it is not part of our tests ** 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/1967892 Title: Fix flow table lookup failure with no originating ifindex Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug After the CT ifindex extension feature, flow table entries are populated with ifindex information which was intended to only be used for HW offload. This tuple ifindex is hashed in the flow table key, so it must be filled for lookup to be successful. But tuple ifindex is only relevant for the netfilter flowtables (nft), so it's not filled in act_ct flow table lookup, resulting in lookup failure, and no SW offload and no offload teardown for TCP connection FIN/RST packets. To fix this, add new tc ifindex field to tuple, which will only be used for offloading, not for lookup, as it will not be part of the tuple hash. * 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" Generate traffic at high rate (e.g. using IXIA). The number of offloaded rules exposed in /sys/kernel/debug/mlx5/\:$BUS\:00.0/ct/offloaded should be in synch the number of generated connections. * What it could break. Perhaps nft offload – it is not part of our tests To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1967892/+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
[Kernel-packages] [Bug 1963948] [NEW] Fix flow table lookup after ct clear or switching zones
Public bug reported: * Explain the bug Flow table lookup is skipped if packet either went through ct clear action (which set the IP_CT_UNTRACKED flag on the packet), or while switching zones and there is already a connection associated with the packet. This will result in no SW offload of the connection, and the and connection not being removed from flow table with TCP teardown (fin/rst packet). * How to test Create OVS bridge with 2 veth pairs, put each veth peer device in a different namespace - ns0, ns1, and add the other side veth devices (named ns[01]_veth below) to OVS bridge. Configure the namespace devices with an ip, and bring all devices up. Enable HW offload in ovs and configure connection tracking OpenFlow rules that pass via two zones (but drop the FIN packets on the reply side or they will still teardown the connection in second zone from the reply side as it happens first): ovs-ofctl add-flow br-ovs "arp actions=NORMAL" ovs-ofctl add-flow br-ovs "ct_state=-trk,ip,in_port=ns0_veth actions=ct(table=5,zone=5)" ovs-ofctl add-flow br-ovs "ct_state=-trk,tcp,in_port=ns1_veth,tcp_flags=-fin actions=ct(table=8,zone=7)" ovs-ofctl add-flow br-ovs "ct_state=+new+trk,ip,in_port=ns0_veth actions=ct(commit,zone=5),ct(table=7,zone=7)" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,ip,in_port=ns0_veth actions=ct(table=7,zone=7)" ovs-ofctl add-flow br-ovs "ct_state=+new+trk,ip,in_port=ns0_veth actions=ct(commit,zone=7),output:ns1_veth" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,ip,in_port=ns0_veth actions=output:ns1_veth" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,tcp,in_port=ns1_veth actions=ct(table=9,zone=5)" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,tcp,in_port=ns1_veth actions=output:ns0_veth" Run TCP iperf from ns0 namespace to an iperf server on ns1 namepsace with the given ip. After traffic ends, check cat /proc/net/nf_conntrack | grep -i offload If bug occurs, connections will remain offloaded till timeout, otherwise, they will be in teardown state. * What it could break. NA ** 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/1963948 Title: Fix flow table lookup after ct clear or switching zones Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug Flow table lookup is skipped if packet either went through ct clear action (which set the IP_CT_UNTRACKED flag on the packet), or while switching zones and there is already a connection associated with the packet. This will result in no SW offload of the connection, and the and connection not being removed from flow table with TCP teardown (fin/rst packet). * How to test Create OVS bridge with 2 veth pairs, put each veth peer device in a different namespace - ns0, ns1, and add the other side veth devices (named ns[01]_veth below) to OVS bridge. Configure the namespace devices with an ip, and bring all devices up. Enable HW offload in ovs and configure connection tracking OpenFlow rules that pass via two zones (but drop the FIN packets on the reply side or they will still teardown the connection in second zone from the reply side as it happens first): ovs-ofctl add-flow br-ovs "arp actions=NORMAL" ovs-ofctl add-flow br-ovs "ct_state=-trk,ip,in_port=ns0_veth actions=ct(table=5,zone=5)" ovs-ofctl add-flow br-ovs "ct_state=-trk,tcp,in_port=ns1_veth,tcp_flags=-fin actions=ct(table=8,zone=7)" ovs-ofctl add-flow br-ovs "ct_state=+new+trk,ip,in_port=ns0_veth actions=ct(commit,zone=5),ct(table=7,zone=7)" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,ip,in_port=ns0_veth actions=ct(table=7,zone=7)" ovs-ofctl add-flow br-ovs "ct_state=+new+trk,ip,in_port=ns0_veth actions=ct(commit,zone=7),output:ns1_veth" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,ip,in_port=ns0_veth actions=output:ns1_veth" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,tcp,in_port=ns1_veth actions=ct(table=9,zone=5)" ovs-ofctl add-flow br-ovs "ct_state=+est+trk,tcp,in_port=ns1_veth actions=output:ns0_veth" Run TCP iperf from ns0 namespace to an iperf server on ns1 namepsace with the given ip. After traffic ends, check cat /proc/net/nf_conntrack | grep -i offload If bug occurs, connections will remain offloaded till timeout, otherwise, they will be in teardown state. * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1963948/+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
[Kernel-packages] [Bug 1962490] [NEW] Support VF groups rate limit
Public bug reported: * Explain the feature Managing TX rate of VFs becomes non-trivial task when a big number of VFs are used. This issue can be handled with some grouping mechanism. Currently driver provide two ways to limit TX rate of the VF: TC police action and NDO API callback. Implementation of grouping within this two infrastructures problematic, due to the following: NDO API rate limiting is legacy feature, even though it's available in switchdev mode, and extending it with new abstraction is not good anyway; TC police action is flow based and requires net device with Qdisc on it and implementing this will bring unwanted complications. According to aforesaid devlink is the most appropriate place. * How to test Set tx_max value on the devlink port with a command. For ex.: $ devlink port function rate set pci/:82:00.0/1 tx_max 10gbit or if grouping is required, create rate group with configured tx_max value in a single command and assign port to this group: $ devlink port function rate add pci/:82:00.0/1st_group tx_max 8gbit $ devlink port function rate set pci/:82:00.0/1 tx_max 10gbit parent 1st_group Configuration is done. Run traffic and do measurement. * What it could break. As this pull request backported 130 patches from devlink/netlink, it may break some functionalities from net core layer. Also, the network drivers which are not used by BF are disabled to avoid the fix of conflicts. ** 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/1962490 Title: Support VF groups rate limit Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the feature Managing TX rate of VFs becomes non-trivial task when a big number of VFs are used. This issue can be handled with some grouping mechanism. Currently driver provide two ways to limit TX rate of the VF: TC police action and NDO API callback. Implementation of grouping within this two infrastructures problematic, due to the following: NDO API rate limiting is legacy feature, even though it's available in switchdev mode, and extending it with new abstraction is not good anyway; TC police action is flow based and requires net device with Qdisc on it and implementing this will bring unwanted complications. According to aforesaid devlink is the most appropriate place. * How to test Set tx_max value on the devlink port with a command. For ex.: $ devlink port function rate set pci/:82:00.0/1 tx_max 10gbit or if grouping is required, create rate group with configured tx_max value in a single command and assign port to this group: $ devlink port function rate add pci/:82:00.0/1st_group tx_max 8gbit $ devlink port function rate set pci/:82:00.0/1 tx_max 10gbit parent 1st_group Configuration is done. Run traffic and do measurement. * What it could break. As this pull request backported 130 patches from devlink/netlink, it may break some functionalities from net core layer. Also, the network drivers which are not used by BF are disabled to avoid the fix of conflicts. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1962490/+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
[Kernel-packages] [Bug 1961819] [NEW] CT: Offload only ASSURED connections
Public bug reported: * Explain the feature Assured connections are those connections which deemed of "higher quality" and less like to expire than non-assured connections, as they passed some stricter rule (e.g in udp reply + connection lasting more than 2 seconds). This feature offloads only those connections. * 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 short UDP connection (< 2 seconds), e.g: on mlx5 VF1 iperf -s -u on mlx5 VF2 iperf -c -t 1 -u Run longer UDP connection (> 2 seconds), e.g: on mlx5 VF1 iperf -s -u on mlx5 VF2 iperf -c -t 10 -u With the above commit quick lived UDP connections (< 2 seconds) will not be offloaded to the flow table as can be checked by cat /proc/net/nf_conntrack | grep -i offload while connections lasting more than 2 seconds (and of course double sided) will be offloaded. * What it could break. NA ** 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/1961819 Title: CT: Offload only ASSURED connections Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the feature Assured connections are those connections which deemed of "higher quality" and less like to expire than non-assured connections, as they passed some stricter rule (e.g in udp reply + connection lasting more than 2 seconds). This feature offloads only those connections. * 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 short UDP connection (< 2 seconds), e.g: on mlx5 VF1 iperf -s -u on mlx5 VF2 iperf -c -t 1 -u Run longer UDP connection (> 2 seconds), e.g: on mlx5 VF1 iperf -s -u on mlx5 VF2 iperf -c -t 10 -u With the above commit quick lived UDP connections (< 2 seconds) will not be offloaded to the flow table as can be checked by cat /proc/net/nf_conntrack | grep -i offload while connections lasting more than 2 seconds (and of course double sided) will be offloaded. * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1961819/+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
[Kernel-packages] [Bug 1960575] [NEW] Pass originating device to drivers offloading ct connection so devices will filter the tuples and offload them more efficiently
Public bug reported: * Explain the feature 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. * 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" With SW steering enabled and the above commits (and up to date ofed) tuple insertion rate should be about twice as fast. This can be seen via procfs hw offloaded count while running high traffic: while true; do res=`sudo cat /proc/net/nf_conntrack | grep -i offload` && echo "$res" && echo "$res" | wc -l; done * What it could break. NA ** 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/1960575 Title: Pass originating device to drivers offloading ct connection so devices will filter the tuples and offload them more efficiently Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the feature 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. * How to test Create
[Kernel-packages] [Bug 1960427] [NEW] Add inner_ipproto into sec_path
Public bug reported: * Explain the bug(s) The inner_ipproto saves the inner IP protocol of the plain text packet. This allows vendor's IPsec feature making offload decision at skb's features_check and configuring hardware at ndo_start_xmit. For example, ConnectX6-DX IPsec device needs the plaintext's IP protocol to support partial checksum offload on VXLAN/GENEVE packet over IPsec transport mode tunnel * Brief explanation of fixes As this data unrelated to the specific driver (the inner ip protocol of the plain text) then it makes sense to provide it in the xfrm stack layer to avoid code duplication in various drivers and do it on the fly in the xfrm layer instead of reparse the packet at the driver layer. * How to test Need to make sure that the code compiles post this change, run TCP encapsulated traffic (for example using vxlan) when IPSec crypto offload with transport mode is configured * What it could break. NA, this function adds data to a new field introduced to struct xfrm_offload, so if not used it have no effect and it is assigned in stack and used in driver so if driver does not used it then no effect. ** 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/1960427 Title: Add inner_ipproto into sec_path Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) The inner_ipproto saves the inner IP protocol of the plain text packet. This allows vendor's IPsec feature making offload decision at skb's features_check and configuring hardware at ndo_start_xmit. For example, ConnectX6-DX IPsec device needs the plaintext's IP protocol to support partial checksum offload on VXLAN/GENEVE packet over IPsec transport mode tunnel * Brief explanation of fixes As this data unrelated to the specific driver (the inner ip protocol of the plain text) then it makes sense to provide it in the xfrm stack layer to avoid code duplication in various drivers and do it on the fly in the xfrm layer instead of reparse the packet at the driver layer. * How to test Need to make sure that the code compiles post this change, run TCP encapsulated traffic (for example using vxlan) when IPSec crypto offload with transport mode is configured * What it could break. NA, this function adds data to a new field introduced to struct xfrm_offload, so if not used it have no effect and it is assigned in stack and used in driver so if driver does not used it then no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1960427/+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
[Kernel-packages] [Bug 1960430] [NEW] IPsec tunnel mode fix inner_ipproto setting in sec_path
Public bug reported: * Explain the bug(s) current code implementation did not handle the case where IPsec is used in tunnel mode. * Brief explanation of fixes As in case of IPsec tunnel mode the skb->encapsulation bit is not set in case of non-encapsulated packet (As TCP and UDP), then inner IP protocol won’t be set, change code behavior to do so also in case of IPsec Tunnel mode * How to test Need to make sure that the code compiles post this change, run TCP traffic when IPSec crypto offload with tunnel mode is configured * What it could break. NA, this function adds data to a new field introduced to struct xfrm_offload, so if not used it have no effect and it is assigned in stack and used in driver so if driver does not used it then no effect. ** 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/1960430 Title: IPsec tunnel mode fix inner_ipproto setting in sec_path Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) current code implementation did not handle the case where IPsec is used in tunnel mode. * Brief explanation of fixes As in case of IPsec tunnel mode the skb->encapsulation bit is not set in case of non-encapsulated packet (As TCP and UDP), then inner IP protocol won’t be set, change code behavior to do so also in case of IPsec Tunnel mode * How to test Need to make sure that the code compiles post this change, run TCP traffic when IPSec crypto offload with tunnel mode is configured * What it could break. NA, this function adds data to a new field introduced to struct xfrm_offload, so if not used it have no effect and it is assigned in stack and used in driver so if driver does not used it then no effect. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1960430/+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
[Kernel-packages] [Bug 1958299] [NEW] Support CIFS for CUDA
Public bug reported: SRU Justification To do cusparse performance testing, need to mount huge test files with cifs. With cifs-utils installed on BF system, cifs mount still could not be processed, as CIFS module is not enabled from kernel. ** 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/1958299 Title: Support CIFS for CUDA Status in linux-bluefield package in Ubuntu: New Bug description: SRU Justification To do cusparse performance testing, need to mount huge test files with cifs. With cifs-utils installed on BF system, cifs mount still could not be processed, as CIFS module is not enabled from kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1958299/+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
[Kernel-packages] [Bug 1957807] [NEW] Fix ct_state nat matching and nat action not being executed
Public bug reported: * Explain the bug Netfilter conntrack maintains NAT flags per connection indicating whether NAT was configured for the connection. Openvswitch maintains NAT flags on the per packet flow key ct_state field, indicating whether NAT was actually executed on the packet. When a packet misses from tc to ovs the conntrack NAT flags are set. However, NAT was not necessarily executed on the packet because the connection's state might still be in NEW state. As such, openvswitch wrongly assumes that NAT was executed and sets an incorrect flow key NAT flags. This can lead to incorrect matching on ct_state nat flags, and nat not being executed by ovs. * How to test Create OVS bridge (br-ovs below) with 2 devices $dev1, $dev2 (can be any devices), with hw offload enabled. Configure NAT connection tracking OpenFlow rules which would only be partially offloaded to tc/hw because of dp_hash/hash (groups in openflow) not being offloaded, so we would have misses from tc to ovs: ovs-ofctl del-flows br-ovs ovs-ofctl add-flow br-ovs arp,actions=normal ovs-ofctl -O OpenFlow12 add-group ovs-br \ 'group_id=2,type=select,bucket=ct(table=4,zone=5,nat(src=1.1.1.128),commit)' #rules ovs-ofctl del-flows ovs-br ovs-ofctl add-flow ovs-br "table=0, arp, action=normal" ovs-ofctl add-flow ovs-br "table=0, ip, nw_src=1.1.1.1 actions=ct(zone=5,table=1,nat)" ovs-ofctl add-flow ovs-br "table=1, in_port=1, actions=group:2" ovs-ofctl add-flow ovs-br "table=4, ip, nw_src=1.1.1.128 actions=2" #good flow ovs-ofctl add-flow ovs-br "table=4, ip, nw_src=1.1.1.1 actions=drop" #bad flow Run single sided UDP traffic from $dev1 to $dev2, and observe source nat not being done, and hit of drop rule in table=4. With the fix, the src nat will be done, and table=4 rule which matches new ip (128) will be hit. * What it could break. NA ** 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/1957807 Title: Fix ct_state nat matching and nat action not being executed Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug Netfilter conntrack maintains NAT flags per connection indicating whether NAT was configured for the connection. Openvswitch maintains NAT flags on the per packet flow key ct_state field, indicating whether NAT was actually executed on the packet. When a packet misses from tc to ovs the conntrack NAT flags are set. However, NAT was not necessarily executed on the packet because the connection's state might still be in NEW state. As such, openvswitch wrongly assumes that NAT was executed and sets an incorrect flow key NAT flags. This can lead to incorrect matching on ct_state nat flags, and nat not being executed by ovs. * How to test Create OVS bridge (br-ovs below) with 2 devices $dev1, $dev2 (can be any devices), with hw offload enabled. Configure NAT connection tracking OpenFlow rules which would only be partially offloaded to tc/hw because of dp_hash/hash (groups in openflow) not being offloaded, so we would have misses from tc to ovs: ovs-ofctl del-flows br-ovs ovs-ofctl add-flow br-ovs arp,actions=normal ovs-ofctl -O OpenFlow12 add-group ovs-br \ 'group_id=2,type=select,bucket=ct(table=4,zone=5,nat(src=1.1.1.128),commit)' #rules ovs-ofctl del-flows ovs-br ovs-ofctl add-flow ovs-br "table=0, arp, action=normal" ovs-ofctl add-flow ovs-br "table=0, ip, nw_src=1.1.1.1 actions=ct(zone=5,table=1,nat)" ovs-ofctl add-flow ovs-br "table=1, in_port=1, actions=group:2" ovs-ofctl add-flow ovs-br "table=4, ip, nw_src=1.1.1.128 actions=2" #good flow ovs-ofctl add-flow ovs-br "table=4, ip, nw_src=1.1.1.1 actions=drop" #bad flow Run single sided UDP traffic from $dev1 to $dev2, and observe source nat not being done, and hit of drop rule in table=4. With the fix, the src nat will be done, and table=4 rule which matches new ip (128) will be hit. * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1957807/+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
[Kernel-packages] [Bug 1946266] Re: Add psample tunnel support and also two fixes for psample issues.
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1946266 Title: Add psample tunnel support and also two fixes for psample issues. Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug(s) Fix psample compilation issue and add tunnel support * brief explanation of fixes Enhance psample * How to test Add tc rule with tunnel and sample actions and run traffic. Verify sample traffic on the sample interface. * What it could break. psample could be broke as new function is enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1946266/+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
[Kernel-packages] [Bug 1944390] Re: Fix ignoring ct state match of OVS offload to TC/HW
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1944390 Title: Fix ignoring ct state match of OVS offload to TC/HW Status in linux-bluefield package in Ubuntu: New Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug When using OVS with tc to offload connection tracking flows, if user matches on ct_state other then trk and est, such as ct_state +rpl, it will be silently ignored by TC/HW and might result in wrong actions being executed. * How to test Create OVS bridge with 2 devices $dev1, $dev2 (can be any devices) Enable HW offload and configure connection tracking OpenFlow rules which match on ct_state +rpl and do different actions based on that match. 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-rpl, actions=$dev1" ovs-ofctl add-flow br-ovs "table=1, ip,ct_state=+trk+est+rpl, actions=$dev2" With commits, ovs dump-flows (or tc show on devs) will have ct_state +rpl match, and without they don't have, meaning the match is ignored. * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1944390/+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
[Kernel-packages] [Bug 1946393] Re: Fix byte count on fragmented packets in tc ct action
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1946393 Title: Fix byte count on fragmented packets in tc ct action Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug First fragmented packets (frag offset = 0) byte len is zeroed when stolen by ip_defrag(). And since act_ct update the stats only afterwards (at end of execute), bytes aren't correctly accounted for such packets. * How to test Create OVS bridge with 2 devices $dev1, $dev2 (can be any devices) Enable HW offload and configure connection tracking OpenFlow rules as below 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 fragmented icmp ping traffic (e.g ping -s 2000) dump ovs rules (ovs-appctl dpctl/dump-flows), observe byte count on frag=first rule: ct_state(-trk),recirc_id(0),in_port(2),eth_type(0x0800),ipv4(proto=1,frag=first), packets:10, bytes:13960, used:1.370s, actions:ct(zone=1),recirc(0x1) bytes would be zero if bug occurs. * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1946393/+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
[Kernel-packages] [Bug 1946393] [NEW] Fix byte count on fragmented packets in tc ct action
Public bug reported: * Explain the bug First fragmented packets (frag offset = 0) byte len is zeroed when stolen by ip_defrag(). And since act_ct update the stats only afterwards (at end of execute), bytes aren't correctly accounted for such packets. * How to test Create OVS bridge with 2 devices $dev1, $dev2 (can be any devices) Enable HW offload and configure connection tracking OpenFlow rules as below 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 fragmented icmp ping traffic (e.g ping -s 2000) dump ovs rules (ovs-appctl dpctl/dump-flows), observe byte count on frag=first rule: ct_state(-trk),recirc_id(0),in_port(2),eth_type(0x0800),ipv4(proto=1,frag=first), packets:10, bytes:13960, used:1.370s, actions:ct(zone=1),recirc(0x1) bytes would be zero if bug occurs. * What it could break. NA ** 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/1946393 Title: Fix byte count on fragmented packets in tc ct action Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug First fragmented packets (frag offset = 0) byte len is zeroed when stolen by ip_defrag(). And since act_ct update the stats only afterwards (at end of execute), bytes aren't correctly accounted for such packets. * How to test Create OVS bridge with 2 devices $dev1, $dev2 (can be any devices) Enable HW offload and configure connection tracking OpenFlow rules as below 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 fragmented icmp ping traffic (e.g ping -s 2000) dump ovs rules (ovs-appctl dpctl/dump-flows), observe byte count on frag=first rule: ct_state(-trk),recirc_id(0),in_port(2),eth_type(0x0800),ipv4(proto=1,frag=first), packets:10, bytes:13960, used:1.370s, actions:ct(zone=1),recirc(0x1) bytes would be zero if bug occurs. * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1946393/+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
[Kernel-packages] [Bug 1946266] [NEW] Add psample tunnel support and also two fixes for psample issues.
Public bug reported: * Explain the bug(s) Fix psample compilation issue and add tunnel support * brief explanation of fixes Enhance psample * How to test Add tc rule with tunnel and sample actions and run traffic. Verify sample traffic on the sample interface. * What it could break. psample could be broke as new function is enabled ** 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/1946266 Title: Add psample tunnel support and also two fixes for psample issues. Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) Fix psample compilation issue and add tunnel support * brief explanation of fixes Enhance psample * How to test Add tc rule with tunnel and sample actions and run traffic. Verify sample traffic on the sample interface. * What it could break. psample could be broke as new function is enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1946266/+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
[Kernel-packages] [Bug 1944390] [NEW] Fix ignoring ct state match of OVS offload to TC/HW
Public bug reported: * Explain the bug When using OVS with tc to offload connection tracking flows, if user matches on ct_state other then trk and est, such as ct_state +rpl, it will be silently ignored by TC/HW and might result in wrong actions being executed. * How to test Create OVS bridge with 2 devices $dev1, $dev2 (can be any devices) Enable HW offload and configure connection tracking OpenFlow rules which match on ct_state +rpl and do different actions based on that match. 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-rpl, actions=$dev1" ovs-ofctl add-flow br-ovs "table=1, ip,ct_state=+trk+est+rpl, actions=$dev2" With commits, ovs dump-flows (or tc show on devs) will have ct_state +rpl match, and without they don't have, meaning the match is ignored. * What it could break. NA ** 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/1944390 Title: Fix ignoring ct state match of OVS offload to TC/HW Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug When using OVS with tc to offload connection tracking flows, if user matches on ct_state other then trk and est, such as ct_state +rpl, it will be silently ignored by TC/HW and might result in wrong actions being executed. * How to test Create OVS bridge with 2 devices $dev1, $dev2 (can be any devices) Enable HW offload and configure connection tracking OpenFlow rules which match on ct_state +rpl and do different actions based on that match. 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-rpl, actions=$dev1" ovs-ofctl add-flow br-ovs "table=1, ip,ct_state=+trk+est+rpl, actions=$dev2" With commits, ovs dump-flows (or tc show on devs) will have ct_state +rpl match, and without they don't have, meaning the match is ignored. * What it could break. NA To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1944390/+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
[Kernel-packages] [Bug 1941803] [NEW] Add the upcoming BlueField-3 device ID
Public bug reported: SRU Justification: Add device ID for BlueField-3 * Explain the bug(s) Not a bug * How to test System should recognize BlueField-3 from lspci * What it could break. Nothing will break ** 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/1941803 Title: Add the upcoming BlueField-3 device ID Status in linux-bluefield package in Ubuntu: New Bug description: SRU Justification: Add device ID for BlueField-3 * Explain the bug(s) Not a bug * How to test System should recognize BlueField-3 from lspci * What it could break. Nothing will break To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1941803/+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
[Kernel-packages] [Bug 1940872] [NEW] Fix fragmentation support for TC connection tracking
Public bug reported: * Explain the bug(s) When using OVS with tc to offload connection tracking flows, sending udp/icmp fragmented traffic will cause call trace with NULL dereference. [ 7229.433005] Modules linked in: act_tunnel_key act_csum act_pedit xt_nat netconsole rpcsec_gss_krb5 act_ct nf_flow_table xt_conntrack xt_MASQUERADE nf_conntrack_netlink xt_addrtype iptable_filter iptable_nat bpfilter br_netfilter bridge overlay sbsa_gwdt xfrm_user xfrm_algo target_core_mod ipmi_devintf ipmi_msghandler mst_pciconf(OE) 8021q garp stp mrp llc act_skbedit act_mirred ib_ipoib(OE) geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink act_gact cls_flower sch_ingress openvswitch nsh nf_conncount nf_nat ib_umad(OE) binfmt_misc dm_multipath mlx5_ib(OE) uio_pdrv_genirq uio mlxbf_pmc mlxbf_pka mlx_trio bluefield_edac mlx_bootctl(OE) sch_fq_codel rdma_ucm(OE) ib_uverbs(OE) rdma_cm(OE) iw_cm(OE) ib_cm(OE) ib_core(OE) ip_tables ipv6 crc_ccitt btrfs zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor xor_neon raid6_pq raid1 raid0 mlx5_core(OE) crct10dif_ce mlxfw(OE) psample mlxdevm(OE) auxiliary(OE) mlx_compat(OE) i2c_mlxbf(OE) [ 7229.433074] gpio_mlxbf2(OE) mlxbf_gige(OE) aes_neon_bs aes_neon_blk [last unloaded: mst_pci] [ 7229.433083] CPU: 4 PID: 1602 Comm: handler6 Tainted: G OE 5.4.0-1017-bluefield #20-Ubuntu [ 7229.433085] Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.7.1-7-g9964f06 Aug 5 2021 [ 7229.433087] pstate: 6005 (nZCv daif -PAN -UAO) [ 7229.433101] pc : inet_frag_rbtree_purge+0x58/0x88 [ 7229.433103] lr : inet_frag_rbtree_purge+0x6c/0x88 [ 7229.433104] sp : 800013273500 [ 7229.433105] x29: 800013273500 x28: 00037b899e80 [ 7229.433107] x27: 0018 x26: 0003b6da2228 [ 7229.433109] x25: 0003b6da2200 x24: 80001191e140 [ 7229.433111] x23: 80001191e140 x22: 00037d6a56a8 [ 7229.433113] x21: x20: 0300 [ 7229.433114] x19: 0001 x18: [ 7229.433116] x17: x16: [ 7229.433118] x15: x14: 8944e960 [ 7229.433119] x13: 0001 x12: 8944e5e0 [ 7229.433121] x11: 0008 x10: [ 7229.433123] x9 : x8 : 0003b97ab3c0 [ 7229.433124] x7 : x6 : 5464ccee [ 7229.433126] x5 : 800010be50a8 x4 : fe000dd9d820 [ 7229.433127] x3 : 8025 x2 : fe000dd9d820 [ 7229.433129] x1 : x0 : [ 7229.433131] Call trace: [ 7229.433134] inet_frag_rbtree_purge+0x58/0x88 [ 7229.433138] ip_frag_queue+0x2d0/0x610 [ 7229.433139] ip_defrag+0xd0/0x170 [ 7229.433156] ovs_ct_execute+0x3f8/0x720 [openvswitch] [ 7229.433160] Unable to handle kernel paging request at virtual address 000100d0 [ 7229.433166] do_execute_actions+0x7b4/0xa80 [openvswitch] [ 7229.433167] Mem abort info: [ 7229.433172] ovs_execute_actions+0x74/0x188 [openvswitch] [ 7229.433173] ESR = 0x9604 [ 7229.433178] ovs_packet_cmd_execute+0x228/0x2a8 [openvswitch] [ 7229.433180] EC = 0x25: DABT (current EL), IL = 32 bits [ 7229.433183] genl_family_rcv_msg+0x1a4/0x3d8 [ 7229.433184] SET = 0, FnV = 0 [ 7229.433186] genl_rcv_msg+0x64/0xd8 * brief explanation of fixes The series contains 7 patches from upstream which fix act_ct handling of fragmented Packets. * How to test Create OVS bridge with 2 representors (uplink and BlueField representor for example). Enable HW offload and configure connection tracking OpenFlow rules. Send udp/icmp traffic from the VF with packet size larger then MTU. Without the commits, call trace will appear in dmesg. * What it could break. Bug fix, doesn't break other functionality ** 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/1940872 Title: Fix fragmentation support for TC connection tracking Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) When using OVS with tc to offload connection tracking flows, sending udp/icmp fragmented traffic will cause call trace with NULL dereference. [ 7229.433005] Modules linked in: act_tunnel_key act_csum act_pedit xt_nat netconsole rpcsec_gss_krb5 act_ct nf_flow_table xt_conntrack xt_MASQUERADE nf_conntrack_netlink xt_addrtype iptable_filter iptable_nat bpfilter br_netfilter bridge overlay sbsa_gwdt xfrm_user xfrm_algo target_core_mod ipmi_devintf ipmi_msghandler mst_pciconf(OE) 8021q garp stp mrp llc act_skbedit act_mirred ib_ipoib(OE) geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink act_gact cls_flower sch_ingress openvswitch nsh nf_conncount nf_nat ib_umad(OE) binfmt_misc dm_multipath mlx5_ib(OE)
[Kernel-packages] [Bug 1940448] [NEW] CT state not reset when packet redirected to different port
Public bug reported: * Explain the bug(s) CT state not reset when packet redirected to different port, thus making it possible to match rules with wrong ct state on the other port. * brief explanation of fixes Reset ct state when redirecting to a different port. The sauce fix being reverted and should apply the upstream fix to catch all cases correctly. * How to test tc qdisc add dev veth0 clsact # The same with "action mirred egress mirror dev veth1" or "action mirred ingress redirect dev veth1" tc filter add dev veth0 egress chain 1 protocol ip flower ct_state +trk action mirred ingress mirror dev veth1 tc filter add dev veth0 egress chain 0 protocol ip flower ct_state -inv action ct commit action goto chain 1 tc qdisc add dev veth1 clsact tc filter add dev veth1 ingress chain 0 protocol ip flower ct_state +trk action drop ping & tc -s filter show dev veth1 ingress With command 'tc -s filter show', we can find the pkts were dropped on veth1. * What it could break. Wrong matching. Traffic failure when redirecting to different ports and there are more rules to match on the other port. ** 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/1940448 Title: CT state not reset when packet redirected to different port Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) CT state not reset when packet redirected to different port, thus making it possible to match rules with wrong ct state on the other port. * brief explanation of fixes Reset ct state when redirecting to a different port. The sauce fix being reverted and should apply the upstream fix to catch all cases correctly. * How to test tc qdisc add dev veth0 clsact # The same with "action mirred egress mirror dev veth1" or "action mirred ingress redirect dev veth1" tc filter add dev veth0 egress chain 1 protocol ip flower ct_state +trk action mirred ingress mirror dev veth1 tc filter add dev veth0 egress chain 0 protocol ip flower ct_state -inv action ct commit action goto chain 1 tc qdisc add dev veth1 clsact tc filter add dev veth1 ingress chain 0 protocol ip flower ct_state +trk action drop ping & tc -s filter show dev veth1 ingress With command 'tc -s filter show', we can find the pkts were dropped on veth1. * What it could break. Wrong matching. Traffic failure when redirecting to different ports and there are more rules to match on the other port. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1940448/+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
[Kernel-packages] [Bug 1938818] Re: Add support for packet-per-second policing
** Changed in: linux-bluefield (Ubuntu) Assignee: (unassigned) => Bodong Wang (bodong-wang) -- 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/1938818 Title: Add support for packet-per-second policing Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) It’s a missing feature in current kernel. * brief explanation of fixes Cherry-pick and backport the related patches from upstream kernel. * How to test Add tc filter rule with police action, and check it is offloaded. For example: tc filter add dev enp8s0f0_0 ingress protocol ip flower \ dst_mac b8:ce:f6:7b:d9:24 \ action police pkts_rate 1000 pkts_burst 100 conform-exceed drop/pipe \ action mirred egress redirect dev enp8s0f0 * What it could break. New feature, doesn't break existing features. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1938818/+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
[Kernel-packages] [Bug 1938818] [NEW] Add support for packet-per-second policing
Public bug reported: * Explain the bug(s) It’s a missing feature in current kernel. * brief explanation of fixes Cherry-pick and backport the related patches from upstream kernel. * How to test Add tc filter rule with police action, and check it is offloaded. For example: tc filter add dev enp8s0f0_0 ingress protocol ip flower \ dst_mac b8:ce:f6:7b:d9:24 \ action police pkts_rate 1000 pkts_burst 100 conform-exceed drop/pipe \ action mirred egress redirect dev enp8s0f0 * What it could break. New feature, doesn't break existing features. ** 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/1938818 Title: Add support for packet-per-second policing Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) It’s a missing feature in current kernel. * brief explanation of fixes Cherry-pick and backport the related patches from upstream kernel. * How to test Add tc filter rule with police action, and check it is offloaded. For example: tc filter add dev enp8s0f0_0 ingress protocol ip flower \ dst_mac b8:ce:f6:7b:d9:24 \ action police pkts_rate 1000 pkts_burst 100 conform-exceed drop/pipe \ action mirred egress redirect dev enp8s0f0 * What it could break. New feature, doesn't break existing features. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1938818/+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
[Kernel-packages] [Bug 1935584] Re: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1935584 Title: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug(s) When using ovs internal port with tc the redirect rules to internal port is back to ingress instead of egress. When we reinsert the skb we start from chain 0 but it could be ct state already set so matching rules on the internal port queue would miss. * brief explanation of fixes When reinserting skb back to ingress queue to restart tc classification then also reset ct. * How to test The setup was created by using ovn and testing iperf traffic from host container to VF pod. The result was ip set on the ovs bridge netdev (internal port) The rules were from rep to eventually the internal port and internal port to rep. The rules were with ct actions and chains tc-policy was set to skip-hw. Without the commit the traffic doesn’t work when hw-offload was true (offload to tc sw only) but does work with hw-offload false (ovs dp). * What it could break. Traffic not working in some cases using internal ports and CT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1935584/+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
[Kernel-packages] [Bug 1934819] Re: Fix err check for nf_conntrack_confirm
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1934819 Title: Fix err check for nf_conntrack_confirm Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug(s) Conntrack confirm operation wasn't checked, this could result in accepting packet which should be dropped. * brief explanation of fixes Match behavior of ovs and netfilter. Drop the packets which are not accepted. * How to test First observe packets accepted with status of NF_DROP without the fix. Then observe packets are correctly dropped with the patch. * What it could break. Nothing breaks, but fixing security hole. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934819/+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
[Kernel-packages] [Bug 1934401] Re: Control netfilter flow table timeouts via sysctl
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1934401 Title: Control netfilter flow table timeouts via sysctl Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug(s) TCP and UDP connections may be offloaded from nf conntrack to nf flow table. Offloaded connections are aged after 30 seconds of inactivity. Once aged, ownership is returned to conntrack with a hard coded tcp/udp pickup time of 120/30 seconds, after which the connection may be deleted. The current hard-coded pickup intervals may introduce a very aggressive aging policy. For example, offloaded tcp connections in established state will timeout from nf conntrack after just 150 seconds of inactivity, instead of 5 days. In addition, the hard-coded 30 second offload timeout period can significantly increase the hardware insertion rate requirements in some use cases. * Brief explanation of fixes This patchset provides the user with the ability to configure protocol specific offload timeout and pickup intervals via sysctl. The first and second patches revert the existing non-upstream solution. The next two patches introduce the sysctl configuration for tcp and udp protocols. The last patch modifies nf flow table aging mechanisms to use the configured time intervals. * How to test Control tcp/udp connection timeout using the following sysctl parameters: net.netfilter.nf_flowtable_tcp_pickup = 120 net.netfilter.nf_flowtable_tcp_timeout = 30 net.netfilter.nf_flowtable_udp_pickup = 30 net.netfilter.nf_flowtable_udp_timeout = 30 * What it could break. Existing configuration scripts – not kernel related To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934401/+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
[Kernel-packages] [Bug 1934499] Re: New BPF helpers to query conntrack and to generate/validate SYN cookies
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1934499 Title: New BPF helpers to query conntrack and to generate/validate SYN cookies Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: Ticket for the patch series that adds new BPF helpers to query conntrack and to generate SYN cookies for forwarded connections. * Explain the bug(s) This patch series aims to accelerate iptables synproxy module with XDP. The stage that generates and checks SYN cookies is stateless and can be implemented in XDP. * Brief explanation of fixes The series first cherry picked multiple upstream patches from xdp/bpf to support the new BPF helpers. Then it adds new BPF helpers on top of those upstream patches. * bpf_ct_lookup_tcp to lookup CT status of a TCP connection. * bpf_tcp_raw_gen_syncookie to generate SYN cookies without a listening socket on the same host (to be used with iptables synproxy module). * bpf_tcp_raw_check_syncookie to check SYN cookies generated by the previos helper (to be used with iptables synproxy module). * bpf_tcp_raw_gen_tscookie to generate timestamp cookies, which encode additional information like SACK permission, ECN support, window scale. The format is compatible with iptables synproxy module. These new helpers allow to accelerate the iptables synproxy module. This series also includes some dependency patches backported from upstream. * How to test Use an XDP application that generates and checks SYN cookies, leveraging the new helpers. * What it could break. Nothing should be broken, only new functionality is added, and some patches are backported from upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934499/+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
[Kernel-packages] [Bug 1934822] Re: Possible memory leak of flow_block_cb
** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1934822 Title: Possible memory leak of flow_block_cb Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: Fix Committed Bug description: * Explain the bug(s) When cleaning up the nf_table in tcf_ct_flow_table_cleanup_work there is no guarantee that the callback list, added to by nf_flow_table_offload_add_cb, is empty. This means that it is possible that the flow_block_cb memory allocated will be lost. * brief explanation of fixes Fix this by iterating the list and freeing the flow_block_cb entries before freeing the nf_table entry (via freeing ct_ft). * How to test With mlx5 driver registers flow block callback, cleaning up rule with action ct frees the ct_ft but with memory leak. * What it could break. Nothing breaks, memory leak is fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934822/+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
[Kernel-packages] [Bug 1935584] [NEW] Fix host to pod traffic with ovn cluster using ovs internal port and tc offload
Public bug reported: * Explain the bug(s) When using ovs internal port with tc the redirect rules to internal port is back to ingress instead of egress. When we reinsert the skb we start from chain 0 but it could be ct state already set so matching rules on the internal port queue would miss. * brief explanation of fixes When reinserting skb back to ingress queue to restart tc classification then also reset ct. * How to test The setup was created by using ovn and testing iperf traffic from host container to VF pod. The result was ip set on the ovs bridge netdev (internal port) The rules were from rep to eventually the internal port and internal port to rep. The rules were with ct actions and chains tc-policy was set to skip-hw. Without the commit the traffic doesn’t work when hw-offload was true (offload to tc sw only) but does work with hw-offload false (ovs dp). * What it could break. Traffic not working in some cases using internal ports and CT. ** Affects: linux-bluefield (Ubuntu) Importance: Undecided Assignee: Bodong Wang (bodong-wang) Status: In Progress ** Changed in: linux-bluefield (Ubuntu) Assignee: (unassigned) => Bodong Wang (bodong-wang) ** Changed in: linux-bluefield (Ubuntu) Status: New => In Progress -- 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/1935584 Title: Fix host to pod traffic with ovn cluster using ovs internal port and tc offload Status in linux-bluefield package in Ubuntu: In Progress Bug description: * Explain the bug(s) When using ovs internal port with tc the redirect rules to internal port is back to ingress instead of egress. When we reinsert the skb we start from chain 0 but it could be ct state already set so matching rules on the internal port queue would miss. * brief explanation of fixes When reinserting skb back to ingress queue to restart tc classification then also reset ct. * How to test The setup was created by using ovn and testing iperf traffic from host container to VF pod. The result was ip set on the ovs bridge netdev (internal port) The rules were from rep to eventually the internal port and internal port to rep. The rules were with ct actions and chains tc-policy was set to skip-hw. Without the commit the traffic doesn’t work when hw-offload was true (offload to tc sw only) but does work with hw-offload false (ovs dp). * What it could break. Traffic not working in some cases using internal ports and CT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1935584/+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
[Kernel-packages] [Bug 1934499] Re: New BPF helpers to query conntrack and to generate/validate SYN cookies
** Merge proposal linked: https://code.launchpad.net/~bodong-wang/ubuntu/+source/linux-bluefield/+git/version-seeds/+merge/405286 -- 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/1934499 Title: New BPF helpers to query conntrack and to generate/validate SYN cookies Status in linux-bluefield package in Ubuntu: In Progress Bug description: Ticket for the patch series that adds new BPF helpers to query conntrack and to generate SYN cookies for forwarded connections. * Explain the bug(s) This patch series aims to accelerate iptables synproxy module with XDP. The stage that generates and checks SYN cookies is stateless and can be implemented in XDP. * Brief explanation of fixes The series first cherry picked multiple upstream patches from xdp/bpf to support the new BPF helpers. Then it adds new BPF helpers on top of those upstream patches. * bpf_ct_lookup_tcp to lookup CT status of a TCP connection. * bpf_tcp_raw_gen_syncookie to generate SYN cookies without a listening socket on the same host (to be used with iptables synproxy module). * bpf_tcp_raw_check_syncookie to check SYN cookies generated by the previos helper (to be used with iptables synproxy module). * bpf_tcp_raw_gen_tscookie to generate timestamp cookies, which encode additional information like SACK permission, ECN support, window scale. The format is compatible with iptables synproxy module. These new helpers allow to accelerate the iptables synproxy module. This series also includes some dependency patches backported from upstream. * How to test Use an XDP application that generates and checks SYN cookies, leveraging the new helpers. * What it could break. Nothing should be broken, only new functionality is added, and some patches are backported from upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934499/+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
[Kernel-packages] [Bug 1934499] Re: New BPF helpers to query conntrack and to generate/validate SYN cookies
** Merge proposal linked: https://code.launchpad.net/~bodong-wang/ubuntu/+source/linux-bluefield/+git/version-seeds/+merge/405285 -- 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/1934499 Title: New BPF helpers to query conntrack and to generate/validate SYN cookies Status in linux-bluefield package in Ubuntu: In Progress Bug description: Ticket for the patch series that adds new BPF helpers to query conntrack and to generate SYN cookies for forwarded connections. * Explain the bug(s) This patch series aims to accelerate iptables synproxy module with XDP. The stage that generates and checks SYN cookies is stateless and can be implemented in XDP. * Brief explanation of fixes The series first cherry picked multiple upstream patches from xdp/bpf to support the new BPF helpers. Then it adds new BPF helpers on top of those upstream patches. * bpf_ct_lookup_tcp to lookup CT status of a TCP connection. * bpf_tcp_raw_gen_syncookie to generate SYN cookies without a listening socket on the same host (to be used with iptables synproxy module). * bpf_tcp_raw_check_syncookie to check SYN cookies generated by the previos helper (to be used with iptables synproxy module). * bpf_tcp_raw_gen_tscookie to generate timestamp cookies, which encode additional information like SACK permission, ECN support, window scale. The format is compatible with iptables synproxy module. These new helpers allow to accelerate the iptables synproxy module. This series also includes some dependency patches backported from upstream. * How to test Use an XDP application that generates and checks SYN cookies, leveraging the new helpers. * What it could break. Nothing should be broken, only new functionality is added, and some patches are backported from upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934499/+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
[Kernel-packages] [Bug 1934822] [NEW] Possible memory leak of flow_block_cb
Public bug reported: * Explain the bug(s) When cleaning up the nf_table in tcf_ct_flow_table_cleanup_work there is no guarantee that the callback list, added to by nf_flow_table_offload_add_cb, is empty. This means that it is possible that the flow_block_cb memory allocated will be lost. * brief explanation of fixes Fix this by iterating the list and freeing the flow_block_cb entries before freeing the nf_table entry (via freeing ct_ft). * How to test With mlx5 driver registers flow block callback, cleaning up rule with action ct frees the ct_ft but with memory leak. * What it could break. Nothing breaks, memory leak is fixed. ** Affects: linux-bluefield (Ubuntu) Importance: Undecided Assignee: Bodong Wang (bodong-wang) Status: In Progress ** Changed in: linux-bluefield (Ubuntu) Status: New => In Progress ** Changed in: linux-bluefield (Ubuntu) Assignee: (unassigned) => Bodong Wang (bodong-wang) -- 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/1934822 Title: Possible memory leak of flow_block_cb Status in linux-bluefield package in Ubuntu: In Progress Bug description: * Explain the bug(s) When cleaning up the nf_table in tcf_ct_flow_table_cleanup_work there is no guarantee that the callback list, added to by nf_flow_table_offload_add_cb, is empty. This means that it is possible that the flow_block_cb memory allocated will be lost. * brief explanation of fixes Fix this by iterating the list and freeing the flow_block_cb entries before freeing the nf_table entry (via freeing ct_ft). * How to test With mlx5 driver registers flow block callback, cleaning up rule with action ct frees the ct_ft but with memory leak. * What it could break. Nothing breaks, memory leak is fixed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934822/+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
[Kernel-packages] [Bug 1934819] Re: Fix err check for nf_conntrack_confirm
** Changed in: linux-bluefield (Ubuntu) Status: New => In Progress ** Changed in: linux-bluefield (Ubuntu) Assignee: (unassigned) => Bodong Wang (bodong-wang) -- 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/1934819 Title: Fix err check for nf_conntrack_confirm Status in linux-bluefield package in Ubuntu: In Progress Bug description: * Explain the bug(s) Conntrack confirm operation wasn't checked, this could result in accepting packet which should be dropped. * brief explanation of fixes Match behavior of ovs and netfilter. Drop the packets which are not accepted. * How to test First observe packets accepted with status of NF_DROP without the fix. Then observe packets are correctly dropped with the patch. * What it could break. Nothing breaks, but fixing security hole. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934819/+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
[Kernel-packages] [Bug 1934819] [NEW] Fix err check for nf_conntrack_confirm
Public bug reported: * Explain the bug(s) Conntrack confirm operation wasn't checked, this could result in accepting packet which should be dropped. * brief explanation of fixes Match behavior of ovs and netfilter. Drop the packets which are not accepted. * How to test First observe packets accepted with status of NF_DROP without the fix. Then observe packets are correctly dropped with the patch. * What it could break. Nothing breaks, but fixing security hole. ** 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/1934819 Title: Fix err check for nf_conntrack_confirm Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) Conntrack confirm operation wasn't checked, this could result in accepting packet which should be dropped. * brief explanation of fixes Match behavior of ovs and netfilter. Drop the packets which are not accepted. * How to test First observe packets accepted with status of NF_DROP without the fix. Then observe packets are correctly dropped with the patch. * What it could break. Nothing breaks, but fixing security hole. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934819/+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
[Kernel-packages] [Bug 1934313] Re: Export xfrm_policy_lookup_bytype function
** Description changed: - Export policy lookup function so drivers could lookup a policy that - match specific criteria. + * Explain the bug(s) + The Xfrm stack holds the SPD for both offloaded and non offloaded IPsec flows, for offloaded flows the driver might need to access this SPD. + + * Brief explanation of fixes + As the XFRM stack already implements a function as described, expose it outside of xfrm stack so various drivers could access it. + + * How to test + Need to make sure that the code compiles post this change, this method is not used directly by user space + + * What it could break. + NA, this patch just expose a function which up until now was static, furthermore this function have no side effects upon invocation as it is just for query purposes ** Description changed: * Explain the bug(s) The Xfrm stack holds the SPD for both offloaded and non offloaded IPsec flows, for offloaded flows the driver might need to access this SPD. * Brief explanation of fixes As the XFRM stack already implements a function as described, expose it outside of xfrm stack so various drivers could access it. * How to test Need to make sure that the code compiles post this change, this method is not used directly by user space * What it could break. - NA, this patch just expose a function which up until now was static, furthermore this function have no side effects upon invocation as it is just for query purposes + Nothing should be break. This patch just expose a function which up until now was static, furthermore this function have no side effects upon invocation as it is just for query purposes -- 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/1934313 Title: Export xfrm_policy_lookup_bytype function Status in linux-bluefield package in Ubuntu: Invalid Status in linux-bluefield source package in Focal: In Progress Bug description: * Explain the bug(s) The Xfrm stack holds the SPD for both offloaded and non offloaded IPsec flows, for offloaded flows the driver might need to access this SPD. * Brief explanation of fixes As the XFRM stack already implements a function as described, expose it outside of xfrm stack so various drivers could access it. * How to test Need to make sure that the code compiles post this change, this method is not used directly by user space * What it could break. Nothing should be break. This patch just expose a function which up until now was static, furthermore this function have no side effects upon invocation as it is just for query purposes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934313/+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
[Kernel-packages] [Bug 1934499] Re: New BPF helpers to query conntrack and to generate/validate SYN cookies
** Changed in: linux-bluefield (Ubuntu) Status: New => In Progress -- 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/1934499 Title: New BPF helpers to query conntrack and to generate/validate SYN cookies Status in linux-bluefield package in Ubuntu: In Progress Bug description: Ticket for the patch series that adds new BPF helpers to query conntrack and to generate SYN cookies for forwarded connections. * Explain the bug(s) This patch series aims to accelerate iptables synproxy module with XDP. The stage that generates and checks SYN cookies is stateless and can be implemented in XDP. * Brief explanation of fixes The series first cherry picked multiple upstream patches from xdp/bpf to support the new BPF helpers. Then it adds new BPF helpers on top of those upstream patches. * bpf_ct_lookup_tcp to lookup CT status of a TCP connection. * bpf_tcp_raw_gen_syncookie to generate SYN cookies without a listening socket on the same host (to be used with iptables synproxy module). * bpf_tcp_raw_check_syncookie to check SYN cookies generated by the previos helper (to be used with iptables synproxy module). * bpf_tcp_raw_gen_tscookie to generate timestamp cookies, which encode additional information like SACK permission, ECN support, window scale. The format is compatible with iptables synproxy module. These new helpers allow to accelerate the iptables synproxy module. This series also includes some dependency patches backported from upstream. * How to test Use an XDP application that generates and checks SYN cookies, leveraging the new helpers. * What it could break. Nothing should be broken, only new functionality is added, and some patches are backported from upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934499/+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
[Kernel-packages] [Bug 1934499] Re: New BPF helpers to query conntrack and to generate/validate SYN cookies
** Description changed: Ticket for the patch series that adds new BPF helpers to query conntrack and to generate SYN cookies for forwarded connections. * Explain the bug(s) This patch series aims to accelerate iptables synproxy module with XDP. The stage that generates and checks SYN cookies is stateless and can be implemented in XDP. * Brief explanation of fixes - This patch series adds new BPF helpers: + The series first cherry picked multiple upstream patches from xdp/bpf to support + the new BPF helpers. + + Then it adds new BPF helpers on top of those upstream patches. * bpf_ct_lookup_tcp to lookup CT status of a TCP connection. * bpf_tcp_raw_gen_syncookie to generate SYN cookies without a listening socket on the same host (to be used with iptables synproxy module). * bpf_tcp_raw_check_syncookie to check SYN cookies generated by the previos helper (to be used with iptables synproxy module). * bpf_tcp_raw_gen_tscookie to generate timestamp cookies, which encode additional information like SACK permission, ECN support, window scale. The format is compatible with iptables synproxy module. These new helpers allow to accelerate the iptables synproxy module. This series also includes some dependency patches backported from upstream. * How to test Use an XDP application that generates and checks SYN cookies, leveraging the new helpers. * What it could break. Nothing should be broken, only new functionality is added, and some - patches are backported from upstream. CONFIG_NF_CONNTRACK is changed - from m to y, which is also not expected to break existing functionality. + patches are backported from upstream. -- 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/1934499 Title: New BPF helpers to query conntrack and to generate/validate SYN cookies Status in linux-bluefield package in Ubuntu: New Bug description: Ticket for the patch series that adds new BPF helpers to query conntrack and to generate SYN cookies for forwarded connections. * Explain the bug(s) This patch series aims to accelerate iptables synproxy module with XDP. The stage that generates and checks SYN cookies is stateless and can be implemented in XDP. * Brief explanation of fixes The series first cherry picked multiple upstream patches from xdp/bpf to support the new BPF helpers. Then it adds new BPF helpers on top of those upstream patches. * bpf_ct_lookup_tcp to lookup CT status of a TCP connection. * bpf_tcp_raw_gen_syncookie to generate SYN cookies without a listening socket on the same host (to be used with iptables synproxy module). * bpf_tcp_raw_check_syncookie to check SYN cookies generated by the previos helper (to be used with iptables synproxy module). * bpf_tcp_raw_gen_tscookie to generate timestamp cookies, which encode additional information like SACK permission, ECN support, window scale. The format is compatible with iptables synproxy module. These new helpers allow to accelerate the iptables synproxy module. This series also includes some dependency patches backported from upstream. * How to test Use an XDP application that generates and checks SYN cookies, leveraging the new helpers. * What it could break. Nothing should be broken, only new functionality is added, and some patches are backported from upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934499/+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
[Kernel-packages] [Bug 1934499] Re: New BPF helpers to query conntrack and to generate/validate SYN cookies
** Changed in: linux-bluefield (Ubuntu) Assignee: (unassigned) => Bodong Wang (bodong-wang) -- 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/1934499 Title: New BPF helpers to query conntrack and to generate/validate SYN cookies Status in linux-bluefield package in Ubuntu: New Bug description: Ticket for the patch series that adds new BPF helpers to query conntrack and to generate SYN cookies for forwarded connections. * Explain the bug(s) This patch series aims to accelerate iptables synproxy module with XDP. The stage that generates and checks SYN cookies is stateless and can be implemented in XDP. * Brief explanation of fixes This patch series adds new BPF helpers: * bpf_ct_lookup_tcp to lookup CT status of a TCP connection. * bpf_tcp_raw_gen_syncookie to generate SYN cookies without a listening socket on the same host (to be used with iptables synproxy module). * bpf_tcp_raw_check_syncookie to check SYN cookies generated by the previos helper (to be used with iptables synproxy module). * bpf_tcp_raw_gen_tscookie to generate timestamp cookies, which encode additional information like SACK permission, ECN support, window scale. The format is compatible with iptables synproxy module. These new helpers allow to accelerate the iptables synproxy module. This series also includes some dependency patches backported from upstream. * How to test Use an XDP application that generates and checks SYN cookies, leveraging the new helpers. * What it could break. Nothing should be broken, only new functionality is added, and some patches are backported from upstream. CONFIG_NF_CONNTRACK is changed from m to y, which is also not expected to break existing functionality. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934499/+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
[Kernel-packages] [Bug 1934401] [NEW] Control netfilter flow table timeouts via sysctl
Public bug reported: * Explain the bug(s) TCP and UDP connections may be offloaded from nf conntrack to nf flow table. Offloaded connections are aged after 30 seconds of inactivity. Once aged, ownership is returned to conntrack with a hard coded tcp/udp pickup time of 120/30 seconds, after which the connection may be deleted. The current hard-coded pickup intervals may introduce a very aggressive aging policy. For example, offloaded tcp connections in established state will timeout from nf conntrack after just 150 seconds of inactivity, instead of 5 days. In addition, the hard-coded 30 second offload timeout period can significantly increase the hardware insertion rate requirements in some use cases. * Brief explanation of fixes This patchset provides the user with the ability to configure protocol specific offload timeout and pickup intervals via sysctl. The first and second patches revert the existing non-upstream solution. The next two patches introduce the sysctl configuration for tcp and udp protocols. The last patch modifies nf flow table aging mechanisms to use the configured time intervals. * How to test Control tcp/udp connection timeout using the following sysctl parameters: net.netfilter.nf_flowtable_tcp_pickup = 120 net.netfilter.nf_flowtable_tcp_timeout = 30 net.netfilter.nf_flowtable_udp_pickup = 30 net.netfilter.nf_flowtable_udp_timeout = 30 * What it could break. Existing configuration scripts – not kernel related ** 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/1934401 Title: Control netfilter flow table timeouts via sysctl Status in linux-bluefield package in Ubuntu: New Bug description: * Explain the bug(s) TCP and UDP connections may be offloaded from nf conntrack to nf flow table. Offloaded connections are aged after 30 seconds of inactivity. Once aged, ownership is returned to conntrack with a hard coded tcp/udp pickup time of 120/30 seconds, after which the connection may be deleted. The current hard-coded pickup intervals may introduce a very aggressive aging policy. For example, offloaded tcp connections in established state will timeout from nf conntrack after just 150 seconds of inactivity, instead of 5 days. In addition, the hard-coded 30 second offload timeout period can significantly increase the hardware insertion rate requirements in some use cases. * Brief explanation of fixes This patchset provides the user with the ability to configure protocol specific offload timeout and pickup intervals via sysctl. The first and second patches revert the existing non-upstream solution. The next two patches introduce the sysctl configuration for tcp and udp protocols. The last patch modifies nf flow table aging mechanisms to use the configured time intervals. * How to test Control tcp/udp connection timeout using the following sysctl parameters: net.netfilter.nf_flowtable_tcp_pickup = 120 net.netfilter.nf_flowtable_tcp_timeout = 30 net.netfilter.nf_flowtable_udp_pickup = 30 net.netfilter.nf_flowtable_udp_timeout = 30 * What it could break. Existing configuration scripts – not kernel related To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934401/+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
[Kernel-packages] [Bug 1934313] [NEW] Export xfrm_policy_lookup_bytype function
Public bug reported: Export policy lookup function so drivers could lookup a policy that match specific criteria. ** 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/1934313 Title: Export xfrm_policy_lookup_bytype function Status in linux-bluefield package in Ubuntu: New Bug description: Export policy lookup function so drivers could lookup a policy that match specific criteria. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1934313/+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
