netdev - Re: [WIP][PATCHES] Network xmit batching

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 08 Jun 2007 09:07:47 -0400
From:	jamal <hadi@...erus.ca>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	Krishna Kumar2 <krkumar2@...ibm.com>,
	Gagan Arneja <gaagaan@...il.com>, netdev@...r.kernel.org,
	Rick Jones <rick.jones2@...com>,
	Sridhar Samudrala <sri@...ibm.com>,
	David Miller <davem@...emloft.net>,
	Robert Olsson <Robert.Olsson@...a.slu.se>
Subject: Re: [WIP][PATCHES] Network xmit batching

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


-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html