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, 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1975820/+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
