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
