Hi,
I am having trouble to think about a good way to detect that the underlying
legacy driver is using its own taskq mechanism, so that the Nemo soft-ring
should not be used.
But we could detect that when the soft-ring rx data-path is activated. The
function ip_soft_ring_assignment(), which is used to process the first
message chain and do the rx ring to squeue binding, can be used to detect
whether it is current in the interrupt context, and if it is not, it might
due to the underlying driver's taskq mechanism.
Note that today the debug version of ip_soft_ring_assignment() function
already has this logic:
ASSERT(servicing_interrupt());
As you can see, it simply panicks the system if it is not the the interrupt
context.
I am thinking whether we can change the soft ring implementation, and call
ip_input() if we found that the underlying device is passing the packets in
taskq context.
Let me know if you think this approach might work. Then I will talk to krgopi.
I believe something similar can be used by the iptun driver as well (see bug
6561530). But that case should be simpler, that a
MAC_CAPABILITY_NO_SOFT_RING capability can be added to the iptun driver to
not advertise the SOFT_RING DL_capability.
Thanks
- Cathy
