Cathy Zhou wrote:
> Rajagopal Kunhappan wrote:
>> 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?
>>
> It is a global ce driver specific variable. It is hard to predict 
> whether other third-party drivers can do the same thing.
>
>>> 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.
>
> I am curious, how to know the intr CPU at the plumb time?

See mac_intr_cpuid() in mac_soft_ring_fanout_enable() function in 
uts/common/io/mac/mac_soft_ring.c in crossbow-gate.

-krgopi
>>
>>>
>>> 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.
>
> But it doesn't help for the case of ce (or other physical NIC 
> drivers). Because unlike tun, which knows for sure that soft-ring 
> should not be enabled.
>
> Thanks
> - Cathy
>
>>
>> -krgopi
>>>
>>> Thanks
>>> - Cathy
>>>
>>> _________________________________
>>> clearview-discuss mailing list
>>> clearview-discuss at opensolaris.org
>>
>> _________________________________
>> clearview-discuss mailing list
>> clearview-discuss at opensolaris.org
>

Reply via email to