Cathy Zhou wrote:
> Rajagopal Kunhappan wrote:
>>
>>
>> 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.
>
> After Crossbow, is it possible to reset the rx function pointer when 
> the packets are not coming from the interrupt thread?

I am not sure I understand what you are saying. Can you tell more about 
your idea?

On the other hand if the question is whether you can disable soft ring 
fanout after you find that the underlying NIC has taskq's, yes, it 
should be possible.

I am in the AMD class this week and so the delayed reply.

-krgopi

> Thanks
> - Cathy
>>
>> -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