On 18/04/16(Mon) 11:33, Mark Kettenis wrote: > [...] > However, this diff uses the same taskq for both the "unlocked" and > "locked" parts. My experience with crypto code was that frequently > grabbing and releasing the kernel lock did affect latency in a bad > way. Some time ago dlg@ had a somewhat similar diff that had a > separate taskq for the "locked" bits. That would avoid blocking of > the "unlocked" bits when the "locked" code is grabbing the kernel > lock. Of course such an approach would probably introduce additional > context switches. Did you consider such an approach?
I don't think this diff will increase the latency because currently softnet interrupts are processed right after dropping the SPL level at the end of the if_input_task loop. I also strongly believe that moving the "locked" bits to another task should be done in a separate step, if at all. The reason is that we did some of the work to make the incoming path run in parallel of the rest of the kernel, not in parallel of itself. So I'd rather wait to not expose too many bugs at once.
