Re: [PATCH net 1/1] netfilter: conntrack: Check offload bit on table dump
From: Roi Dayan <hidden>
Date: 2021-02-02 17:12:38
On 2021-02-01 5:25 PM, Florian Westphal wrote:
Roi Dayan [off-list ref] wrote:quoted
quoted
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.quoted
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.quoted
We hit this issue before more easily and pushed this fix 4203b19c2796 netfilter: flowtable: Set offload timeout when adding flowThis 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?