Rajagopal Kunhappan wrote: > 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 meant that mac_do_rx() needs to see whether the packets come from the interrupt context, and switch to other fast-paths, such as DLD_CAPAB_DIRECT or DLD_CAPAB_POLL fast path.
I think that involves updating the rx callback function pointers. - Cathy > 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 >>>> >>
