On Thu, Jan 26, 2017 at 10:29 AM, Darren Reed <[email protected]> wrote: > Apologies all for the blob of text :( > > I resent with better formatting but that's likely in a spam queue > somewhere... > > So I'll try and summarise in a readable fashion: > > (1) patch introduces new locks for per-packet processing when the > architectural goal is lock-less. What would this patch look like if done > to be lock-less? > (2) queuing has a memory cost. There are DoS attacks introduced that > need to be mitigated. > (4) does workqueue and this patch suggest that <sys/queue.h> needs > enhancing for optimal processing of lists?
http://www.netbsd.org/~ozaki-r/workqueue-pr_input-percpu.diff As per your comment, I changed the patch: (i) introduced percpu queues and removed the lock and (ii) introduced the hard limit to each queue to mitigate DoS, which is the same as other input queues such as pktqueue and if_input percpuq. As a side effect of the change, the overhead reduced to 10 usec for a single packet pingpong and for flooding the overhead is now negligible, I guess, thanks to bulk packet processing per one workqueue activation. > (3) do all packets need this workqueue approach or only some? Can > selective queuing help with (2)? Workqueue is used only for ICMP/ICMPv6/CARP and packets on fast paths aren't affected by the change. Even for the affected packets, the influence by the change is small now by the above improvement. We might be able to use workqueue selectively per packet types say ICMP message types, but there is a concern; it will introduce packet reordering between packets (e.g., ICMP messages). I think we should avoid the behavior, though I'm not sure the impact of the reordering. And I don't so much like to introduce such an exceptional behavior in the middle of the packet handling (pr_input is modestly a feasible place to do, I think). Thanks, ozaki-r
