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