On Fri, 2007-08-06 at 16:09 +0400, Evgeniy Polyakov wrote: > On Fri, Jun 08, 2007 at 07:31:07AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> But lock is still being hold - or there was no intention to reduce lock > usage? As far as I read Krishna's mail, lock usage was not an issue, so > that hunk probably should be dropped from the analysis. With post 2.6.18 that atomic bit guarantees only one CPU will enter tx path. The lock is only necessary to protect shared resources between tx and rx (which could be simultenously be entered by two CPUs) such as tx ring. Refer to some other thread talking about a possible bug with e1000 in this area. So maybe e1000 is not a good example in this sense. But look at tg3. > > > Without lock that would be wrong - it accesses hardware. > > > > We are achieving the goal of only a single CPU entering that path. Are > > you saying that is not good enough? > > Then why essentially the same code (current batch_xmit callback) > previously was always called with disabled interrupts? Aren't there > some watchdog/link/poll/whatever issues present? not in the e1000 as it stands today. > Something, that anyone can understand :) > For example /proc stats, although it is not very accurate, but it is > really usable parameter from userspace point ov view. which /proc stats? > Btw, what is the size of the packet in pktgen in your tests? Likely it > is small, since result is that good. That can explain alot. There is a per-packet cost involved in that code path. So the more packets/second you can generate the more intensely you can test that path. I believe you will achieve overall better results with large packets. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
