On 04/12/15(Fri) 20:45, David Gwynne wrote: > > On 4 Dec 2015, at 7:36 PM, Martin Pieuchot <[email protected]> wrote: > > On 04/12/15(Fri) 12:38, David Gwynne wrote: > >>> On 4 Dec 2015, at 06:44, Alexandr Nedvedicky > >>> <[email protected]> wrote: > >> [...] > >> it might be better to add the task to systq instead of &softnettq. if > >> you're always going to take the kernel lock to send packets then any > >> pending ip_input_process work will end implicitly waiting for the kernel > >> lock too. ideally only mpsafe work should be pushed into the softnettq. > > > > I insisted to keep most of the packets processing in the same context. > > > > I'd rather see efforts to remove those locks and go towards multiples > > softnettq. > > > > It this stage I'm more afraid of two ip_output() running in parallel > > than the possible latency due to reporting an error. > > the context you want is KERNEL_LOCKed at splsoftnet(). you're insisting on > forcing the softnettq to wait to assume that context and blocking work that > doesnt need it.
I don't understand. With fast network cards the network stack is currently bound to the amount of processing a CPU can do holding the kernel lock. As soon as you remove the KERNEL_LOCK from the forwarding path you remove it from this task too. So where's the problem?
