crossbow discuss - Aug 2006 - Re: [clearview-discuss] Re: softmac performance

Cathy Zhou wrote:
>> Note that we are planning to revisit the GLDv3 locking as part of 
>> Crossbow.
>>
> Is this targgeted to improve performance?
The main goal is to accomodate the new data paths needed for Crossbow, 
as well as simplifying the locking architecture.
>> During the design review last year I also had a comment on the 
>> possible negative performance impact on having only one DL_PROMISC_SAP 
>> stream, which would disable the optimization that most DLPI drivers 
>> implement by saving a pointer to the IPv4 and IPv6 streams. This issue 
>> was not addressed by the design back then, and I don''t know if
it was
>> looked at again as part of the softmac performance work.
>>
> I think the DL_PROMISC_SAP might disable the optimization of the 
> underlying driver, but it is not the main issue here:
> 
> On the recieve-side, the code path is roughly:
> 
>
legacy_device_rput()->putnext()->softmac_rput()->mac_rx()->i_dls_link_rx()->ip_input().
> 
> 
> By removing all locks, loops in mac_rx() and i_dls_link_rx(), the 
> performance can improve from %-8 to %-0.9
> 
> Disabling the ipq_fastpath in legacy device might contribute to that 
> %0.9, but there is bigger issue than that.
What is not clear to me is why you seem to be focusing on the GLDv3 code 
path when you are disabling a common optimization done by existing DLPI 
drivers. It seems that doing an analysis of the lack of that 
optimization and its performance impact would be a useful step to take 
before revisiting the GLDv3 code path.

Nicolas.
> 
> Thanks
> - Cathy
-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

> What is not clear to me is why you seem to be focusing on the GLDv3 code 
 > path when you are disabling a common optimization done by existing DLPI 
 > drivers. It seems that doing an analysis of the lack of that 
 > optimization and its performance impact would be a useful step to take 
 > before revisiting the GLDv3 code path.

The data we obtained from the Sun Analyzer tools made it very clear that
most of the receive time is spent in the GLDv3 codepaths -- and that
overhead will be there regardless of the driver optimizations, no?

-- 
meem

Peter Memishian wrote:
>  > What is not clear to me is why you seem to be focusing on the GLDv3
code
>  > path when you are disabling a common optimization done by existing
DLPI
>  > drivers. It seems that doing an analysis of the lack of that 
>  > optimization and its performance impact would be a useful step to
take
>  > before revisiting the GLDv3 code path.
> 
> The data we obtained from the Sun Analyzer tools made it very clear that
> most of the receive time is spent in the GLDv3 codepaths -- and that
> overhead will be there regardless of the driver optimizations, no?
I didn''t see that particular information in the data that has been 
shared as part of previous emails to this thread. Would it be possible 
to share it with the list? Sorry if I missed it.

Nicolas.

-- 
Nicolas Droux, Solaris Kernel Networking
Sun Microsystems, Inc. http://blogs.sun.com/droux

> > The data we obtained from the Sun Analyzer tools made it very clear
that
 > > most of the receive time is spent in the GLDv3 codepaths -- and that
 > > overhead will be there regardless of the driver optimizations, no?
 > 
 > I didn''t see that particular information in the data that has
been
 > shared as part of previous emails to this thread. Would it be possible 
 > to share it with the list? Sorry if I missed it.

Oops -- I think it wasn''t included in this thread.  Cathy, can you
provide
the relevant information?

-- 
meem