Re: workqueue for pr_input

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Thu, Jan 26, 2017 at 10:29 AM, Darren Reed <darrenr%netbsd.org@localhost> 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