Nicolas Droux wrote: > > > Peter Memishian wrote: >> > I think the GLDv3 code will become more complicated no matter which >> approach > we take. >> >> Hopefully not too much so -- but let's try going with this approach. > > Which approach are you refering too here? The locking rewack?
I think Meem meant that we should try to optimize the GLDv3 code path in order to improve the overhead GLDv3 layer introduces. > Note that > we are planning to revisit the GLDv3 locking as part of Crossbow. > Is this targgeted to improve performance? > Did you already try measuring the impact of enabling direct function > calls between the softmac and IP? This would require splitting the > existing poll capability, where direct function calls and packet > chaining would be always enabled for all GLDv3 devices, and the POLL > capability would be enabled only when the underlying MAC supports the > blanking entry point. > Yes. We enabled the direct function calls on the send side, by having a empty blanking function. But as you might see in my another mail, the data shows that the overhead is introduced by the GLDv3 layer on the receive side. > 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. Thanks - Cathy
