On 2021-02-03 2:50 PM, Florian Westphal wrote:
Roi Dayan <r...@nvidia.com> wrote:
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.
That makes it even more weird. Timeout for established is even larger.
In case of TCP, its days... so I don't understand at all :/
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.
Ok. Extending it there makes sense, but I still don't understand
why newly offloaded flows hit this problem.
Flow offload should never see a 'about to expire' ct entry.
The 'extend timeout from gc' is more to make sure GC doesn't reap
long-lived entries that have been offloaded aeons ago, not 'prevent
new flows from getting zapped...'
I'll add that an extended timeout from gc is if gc actually iterated
this conn since it was created.
I'll investigate this more and try to do more tests.
thanks for the info
