Cathy Zhou wrote: > 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.
Quick question: How are taskq's enabled and disabled on ce? Is it through a global variable or something? Are there NICs other than ce that does this? > 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. Yes, you could do that but this mechanism is going to change in Crossbow. In Crossbow, there is no ip_soft_ring_assignment(). Instead a new routine will take the dip (macp->m_dip) and return the intr CPU thereby helping to do the soft ring assignments at plumb time itself. > > 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. This is better. -krgopi > > Thanks > - Cathy > > _________________________________ > clearview-discuss mailing list > clearview-discuss at opensolaris.org
