Re: [WIP][PATCHES] Network xmit batching

[jamal <hadi@cyberus.ca>]

On Fri, 2007-08-06 at 16:09 +0400, Evgeniy Polyakov wrote:
> On Fri, Jun 08, 2007 at 07:31:07AM -0400, jamal (hadi@cyberus.ca) 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