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? 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.