On 2021-02-01 5:25 PM, Florian Westphal wrote:
Roi Dayan <r...@nvidia.com> wrote:
TCP initial timeout is one minute, UDP 30 seconds.
That should surely be enough to do flow_offload_add (which extends
the timeout)?
Yes, flow_offload_add() extends the timeout. but it needs to finish.
Maybe something is doing flow_offload_add() for unconfirmed conntrack?
In unconfirmed conntrack case, ct->timeout is absolute timeout value, e.g. for
tcp it will be set to 60 * HZ.
When I hit the issue I printed jiffies and ct->timeout and saw they are
the same or very close but not an absolute number.
Thats strange, for new flows they should not be close at all.
UDP sets a 30 second timeout, TCP sets a 60 second initial timeout.
Do you think rhashtable_insert_fast() in flow_offload_add() blocks for
dozens of seconds?
I'm not sure. but its not only that but also the time to be in
established state as only then we offload.
Thats about the only thing I can see between 'offload bit gets set'
and 'timeout is extended' in flow_offload_add() that could at least
spend *some* time.
We hit this issue before more easily and pushed this fix
4203b19c2796 netfilter: flowtable: Set offload timeout when adding flow
This fix makes sense to me.
I just noted we didn't test correctly Pablo's suggestion instead of
to check the bit and extend the timeout in ctnetlink_dump_table() and
ct_seq_show() like GC does.
We replaced nf_conntrack module but not nf_conntrack_netlink and tested
with conntrack -L.
We redo the test and replaced correct modules and it looks ok now.
We still need to run the long test to be sure but is that still
a good option as a fix?
