[Kernel-packages] [Bug 1960575] Re: Pass originating device to drivers offloading ct connection so devices will filter the tuples and offload them more efficiently
This bug was fixed in the package linux-bluefield - 5.4.0-1035.38 --- linux-bluefield (5.4.0-1035.38) focal; urgency=medium * focal/linux-bluefield: 5.4.0-1035.38 -proposed tracker (LP: #1969372) * mlxbf-gige: sync up with upstreamed version (LP: #1969233) - SAUCE: Revert "UBUNTU: SAUCE: Fix OOB handling RX packets in heavy traffic" - SAUCE: Revert "UBUNTU: SAUCE: mlxbf_gige: update driver version to 1.25" - SAUCE: Revert "UBUNTU: SAUCE: mlxbf_gige: clear valid_polarity upon open" - SAUCE: Revert "UBUNTU: SAUCE: mlxbf_gige: add interrupt counts to "ethtool -S"" - SAUCE: Revert "UBUNTU: SAUCE: mlxbf-gige: add ethtool mlxbf_gige_set_ringparam" - SAUCE: Revert "UBUNTU: SAUCE: mlxbf-gige: add driver version" - mlxbf_gige: clear valid_polarity upon open - net: mellanox: mlxbf_gige: Replace non-standard interrupt handling - SAUCE: mlxbf-gige: add driver version - SAUCE: mlxbf_gige: add interrupt counts to "ethtool -S" - SAUCE: mlxbf-gige: add ethtool mlxbf_gige_set_ringparam - SAUCE: Fix OOB handling RX packets in heavy traffic * linux-bluefield: Fix build failure in mlxbf_gige (LP: #1969374) - gpiolib: acpi: Allow to find GpioInt() resource by name and index linux-bluefield (5.4.0-1034.37) focal; urgency=medium * focal/linux-bluefield: 5.4.0-1034.37 -proposed tracker (LP: #1968766) * Devlink wasn't enabled from common config (LP: #1968751) - [Config] Bluefield: Enable CONFIG_NET_DEVLINK - [Config] Bluefield: Enable dummy config options NET_VENDOR_BROADCOM and PAGE_POOL linux-bluefield (5.4.0-1033.36) focal; urgency=medium * focal/linux-bluefield: 5.4.0-1033.36 -proposed tracker (LP: #1967369) * Fix flow table lookup failure with no originating ifindex (LP: #1967892) - net/sched: act_ct: Fix flow table lookup failure with no originating ifindex * Fix OOB handling RX packets in heavy traffic (LP: #1964984) - SAUCE: Fix OOB handling RX packets in heavy traffic * Pass originating device to drivers offloading ct connection so devices will filter the tuples and offload them more efficiently (LP: #1960575) - net: openvswitch: Be liberal in tcp conntrack. - net/sched: act_ct: Fill offloading tuple iifidx - net: openvswitch: Fill act ct extension * Fix flow table lookup after ct clear or switching zones (LP: #1963948) - net/sched: act_ct: Fix flow table lookup after ct clear or switching zones * CT: Offload only ASSURED connections (LP: #1961819) - net/sched: act_ct: Offload only ASSURED connections * Sync up gpio interrupt handling with upstreamed version (LP: #1965017) - Revert "UBUNTU: SAUCE: gpio-mlxbf2.c: Fix setting the gpio direction to output" - Revert "UBUNTU: SAUCE: gpio-mlxbf2.c: remove phy interrupt" - Revert "UBUNTU: SAUCE: gpio-mlxbf2: Cleanup and use generic gpio_irq_chip struct" - Revert "UBUNTU: SAUCE: gpio-mlxbf2.c: Support soft reset gpio interrupt" - Revert "UBUNTU: SAUCE: gpio-mlxbf2.c: fix spinlock bug and using uninitialized work" - Revert "UBUNTU: SAUCE: gpio: Add irq support for gpio-mlxbf2" - gpio: mlxbf2: remove unused including - gpio: mlxbf2: fix return value check in mlxbf2_gpio_get_lock_res() - gpio: mlxbf2: Fix sleeping while holding spinlock - gpio: gpio-mlxbf2: Tell the compiler that ACPI functions may not be use - gpio: gpio-mlxbf2.c: Provide __releases() annotation to stop confusing Sparse - gpio: mlxbf2: Convert to device PM ops - gpio: mlxbf2: Drop wrong use of ACPI_PTR() - gpio: mlxbf2: Use devm_platform_ioremap_resource() - gpio: mlxbf2: Use DEFINE_RES_MEM_NAMED() helper macro - gpio: mlxbf2.c: Add check for bgpio_init failure - gpio: mlxbf2: Introduce IRQ support - SAUCE: gpio-mlxbf2.c: Add version and fix SPDX-License_Identifier - SAUCE: i2c-mlxbf.c: remove IRQF_ONESHOT flag - [Config] bluefield: CONFIG_POWER_MLXBF=m - SAUCE: Add power driver to handle reset interrupt and low power mode interrupt * Support VF groups rate limit (LP: #1962490) - [Config] Bluefield: disable inbox drivers which are not used - devlink: Allow large formatted message of binary output - devlink: add support for reporter recovery completion - devlink: add macro for "fw.psid" - devlink: move devlink documentation to subfolder - devlink: correct misspelling of snapshot - devlink: Add layer 3 generic packet traps - devlink: Add layer 3 generic packet exception traps - devlink: Add non-routable packet trap - devlink: Add tunnel generic packet traps - devlink: Add overlay source MAC is multicast trap - devlink: add macro for "fw.roce" - devlink: Force enclosing array on binary fmsg data - devlink: add ACL generic packet traps - devlink: add trap metadata type for cookie - devlink: extend devlink_trap_report() to accept cookie and pass - devlink: promote
[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 1960575] Re: Pass originating device to drivers offloading ct connection so devices will filter the tuples and offload them more efficiently
This bug is awaiting verification that the linux-bluefield/5.4.0-1033.36 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: 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/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 1960575] Re: Pass originating device to drivers offloading ct connection so devices will filter the tuples and offload them more efficiently
** Changed in: linux-bluefield (Ubuntu Focal) Status: In Progress => Fix Committed -- 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 1960575] Re: Pass originating device to drivers offloading ct connection so devices will filter the tuples and offload them more efficiently
** Also affects: linux-bluefield (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: linux-bluefield (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: linux-bluefield (Ubuntu Focal) Status: New => In Progress ** Changed in: linux-bluefield (Ubuntu Focal) Assignee: (unassigned) => Bodong Wang (bodong-wang) ** Changed in: linux-bluefield (Ubuntu) Status: New => 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/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: In Progress 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
