On Wed, Mar 03, 2021 at 05:11:47PM +0100, Pablo Neira Ayuso wrote: > Hi, > > On Wed, Mar 03, 2021 at 02:59:53PM +0200, Oz Shlomo wrote: > > Currently the flow table offload replace, destroy and stats work items are > > executed on a single workqueue. As such, DESTROY and STATS commands may > > be backloged after a burst of REPLACE work items. This scenario can bloat > > up memory and may cause active connections to age. > > > > Instatiate add, del and stats workqueues to avoid backlogs of non-dependent > > actions. Provide sysfs control over the workqueue attributes, allowing > > userspace applications to control the workqueue cpumask. > > Probably it would be good to place REPLACE and DESTROY in one single > queue so workqueues don't race? In case connections are quickly > created and destroyed, we might get an out of order execution, instead > of: > > REPLACE -> DESTROY -> REPLACE > > events could be reordered to: > > REPLACE -> REPLACE -> DESTROY > > So would it work for you if REPLACE and DESTROY go into one single > workqueue and stats go into another? > > Or probably make the cookie unique is sufficient? The cookie refers to > the memory address but memory can be recycled very quickly. If the > cookie helps to catch the reorder scenario, then the conntrack id > could be used instead of the memory address as cookie. Something like this, if I got the idea right, would be even better. If the entry actually expired before it had a chance of being offloaded, there is no point in offloading it to then just remove it. Marcelo
