On 12/6/05, Robert Olsson [EMAIL PROTECTED] wrote:
jamal writes:
Results:
kernel 2.6.11.7: 446Kpps
kernel 2.6.14: 452kpps
kernel 2.6.14 with e1000-6.2.15: 470Kpps
Kernel 2.6.14 with e1000-6.2.15 but rx copybreak commented out: 460Kpps
copybreaks help you..
Arnd Bergmann [EMAIL PROTECTED] wrote on 12/06/2005 11:23:39 AM:
On Dinsdag 06 Dezember 2005 01:59, Paul Mackerras wrote:
Arnd Bergmann writes:
Uploading the device firmware may fail if wrong input data
was provided by the user. This checks for the condition.
From: [EMAIL
On Tue, 2005-06-12 at 23:33 -0700, Grant Grundler wrote:
On Tue, Dec 06, 2005 at 06:08:35PM -0500, jamal wrote:
All load goes onto CPU#0. I didnt try to tune or balance anything
so the numbers could be better than those noted here
ok - that's fair. I suspect the hyperthreading case is one
On Wed, 2005-07-12 at 00:18 -0800, Jesse Brandeburg wrote:
On 12/6/05, Robert Olsson [EMAIL PROTECTED] wrote:
jamal writes:
Results:
kernel 2.6.11.7: 446Kpps
kernel 2.6.14: 452kpps
kernel 2.6.14 with e1000-6.2.15: 470Kpps
Kernel 2.6.14 with e1000-6.2.15
On 12/7/05, jamal [EMAIL PROTECTED] wrote:
It is possible it will help some traffic setups to turn it on, however,
forever you had it as off. So people who need it know how to turn it on.
The sudden change of behavior that was questionable and btw it is not
documented either.
Well it's
Grant Grundler wrote:
Yes - his results indicated copybreak hurt perf on the AMD box.
h...
Jeff
-
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
On Wed, Dec 07, 2005 at 07:41:29AM -0500, jamal wrote:
ok - that's fair. I suspect the hyperthreading case is one where
binding the IRQs to particule CPUs is necessary to reproduce
the results.
Note: I didnt bind anything. The p4/xeon starts with routing everything
to CPU#0 - i just
jamal [EMAIL PROTECTED] writes:
How is this different, conceptually, from any other flag setting being
lost - for example a promisc or admin up/down?
How do you lose promisc or admin up/down flag setting? Do you mean
userspace listening? It has to poll then.
In other words if you want to
jamal writes:
copybreaks help you..
Thanks for running these tests, so far it mostly validates that for
the general case the copybreak and prefetch benefits things.
I dont know what you would call a general case. Pick two modern boards
as in these tests:
I'll add some
On Tue, Dec 06, 2005 at 02:47:28PM -0800, jt wrote:
MadWifi stack :
drivers using it : MadWifi (non GPL)
drivers in progress : FreeHAL Atheros, Prism54 softMAC, ural-ralink
Sam kindly pointed out that my statement above may be
confusing. It should read :
MadWifi stack :
Robert,
Very interesting results - i would like to comment; but let me post my
results first.
I recompiled all kernels from scratch and made sure that flow control
was off in all cases.
I still test with two flows .. will get to something like 32K flows
perhaps tommorow (keeping my fingers
John Ronciak wrote:
As far as copybreak goes, we knew it probably won't help routing type
test with small packets. Robert's test shows it really only hurts
where it seems to be CPU bound, which makes sense. This can be
disable at compile time by setting E1000_CB_LENGHT to 2K which means
that
On Wed, 2005-07-12 at 14:27 -0500, Jeff Garzik wrote:
John Ronciak wrote:
As far as copybreak goes, we knew it probably won't help routing type
test with small packets. Robert's test shows it really only hurts
where it seems to be CPU bound, which makes sense. This can be
disable at
On 12/7/05, Jeff Garzik [EMAIL PROTECTED] wrote:
So... under load, copybreak causes e1000 to fall over more rapidly than
no-copybreak?
If so, it sounds like copybreak should be disabled by default, and/or a
runtime switched added for it.
I wouldn't say fall over. With small packet only
On Tue, Dec 06, 2005 at 11:11:02PM -0800, Jouni Malinen wrote:
On Tue, Dec 06, 2005 at 02:47:28PM -0800, Jean Tourrilhes wrote:
DeviceScape stack :
drivers using it : ?
potential drivers : hostap, ipw2100, ipw2200, r8180, adm8211
It's mainly used with Atheros chipsets nowadays,
On Wed, 2005-07-12 at 11:48 -0800, John Ronciak wrote:
On 12/7/05, Jeff Garzik [EMAIL PROTECTED] wrote:
So... under load, copybreak causes e1000 to fall over more rapidly than
no-copybreak?
If so, it sounds like copybreak should be disabled by default, and/or a
runtime switched added
jamal writes:
Kernel 2.6.14 + e1000-6.2.15 prefetch off copybreak off: 451Kpps
kernel 2.6.14 + e1000-6.2.15 prefetch off copybreak on: 450Kpps
This pretty close to the results I got today in the single flow test
I even noticed a little win w. the copy-break on.
Kernel 2.6.14 +
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 07 Dec 2005 14:27:50 -0500
If so, it sounds like copybreak should be disabled by default, and/or a
runtime switched added for it.
This logic applies to all drivers, though. If you're cpu loaded,
then yes copying the packets will require more cpu
jamal a écrit :
On Wed, 2005-07-12 at 11:48 -0800, John Ronciak wrote:
On 12/7/05, Jeff Garzik [EMAIL PROTECTED] wrote:
So... under load, copybreak causes e1000 to fall over more rapidly than
no-copybreak?
If so, it sounds like copybreak should be disabled by default, and/or a
runtime
From: jamal [EMAIL PROTECTED]
Date: Wed, 07 Dec 2005 14:44:53 -0500
so thats conclusion one. Copybreak oughta be off by default. People
who think it is useful can turn it on.
I disagree, the socket buffering side effects of non-copybreak
are severe especially during loss handling where it is
From: John Ronciak [EMAIL PROTECTED]
Date: Wed, 7 Dec 2005 11:48:46 -0800
Copybreak probably shouldn't be used in routing use cases.
I think even this is arguable, routers route a lot more than
small 64-byte frames. Unfortunately, that is what everyone
uses for packet rate tests. :-/
Assuming
From: jamal [EMAIL PROTECTED]
Date: Wed, 07 Dec 2005 15:23:57 -0500
I am no longer sure that your results on copybreak for host bound
packets can be trusted anymore. All your copybreak was doing was making
the prefetch look good according to my tests.
For the host bound case, copybreak is
John Ronciak writes:
If so, it sounds like copybreak should be disabled by default, and/or a
runtime switched added for it.
I wouldn't say fall over. With small packet only tests (the ones
being run for this exercise) _all_ packets are being copied which is
why when the system
On Wed, 2005-07-12 at 21:50 +0100, Robert Olsson wrote:
jamal writes:
Kernel 2.6.14 + e1000-6.2.15 prefetch off copybreak off: 451Kpps
kernel 2.6.14 + e1000-6.2.15 prefetch off copybreak on: 450Kpps
This pretty close to the results I got today in the single flow test
I even noticed
On Wed, 2005-07-12 at 21:59 +0100, Eric Dumazet wrote:
jamal a écrit :
Eric Dumazet [EMAIL PROTECTED] theorized there may be some value in
copybreak if you are host bound. I only seen it as an unnecessary pain
really.
In my case, my production servers are usually ram bounded, not
On Wed, 2005-07-12 at 13:06 -0800, David S. Miller wrote:
From: jamal [EMAIL PROTECTED]
Date: Wed, 07 Dec 2005 15:23:57 -0500
I am no longer sure that your results on copybreak for host bound
packets can be trusted anymore. All your copybreak was doing was making
the prefetch look good
On 12/7/05, David S. Miller [EMAIL PROTECTED] wrote:
Regardless of the decision, it's incorrect to point out e1000
specifically as many other Linux networking drivers do copybreak too
and I've always public advocated for copybreak to be used by drivers
due to the socket buffering issue.
From: jamal [EMAIL PROTECTED]
Date: Wed, 07 Dec 2005 16:37:10 -0500
I think there is value for prefetch - just not the way the current patch
has it. Something less adventorous as suggested by Robert would make a
lot more sense.
Looking at the e1000 patch in question again, it may be doing a
On 12/7/05, jamal [EMAIL PROTECTED] wrote:
On the prefetch, i think would you agree now that it is problematic?
Sorry, I don't agree.
I just showed that if i changed the cycle of execution between the
moment the prefecth gets issued to the moment the data gets used we get
different
David S. Miller a écrit :
From: jamal [EMAIL PROTECTED]
Date: Wed, 07 Dec 2005 16:37:10 -0500
I think there is value for prefetch - just not the way the current patch
has it. Something less adventorous as suggested by Robert would make a
lot more sense.
Looking at the e1000 patch in
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 07 Dec 2005 23:04:04 +0100
Another try could be to do some benchmarks about NET_IP_ALIGN being a valid
optimization nowadays :
Maybe setting it to 0 in e1000 driver could give better results.
Could somebody give it a try ?
NET_IP_ALIGN is a
From: John Ronciak [EMAIL PROTECTED]
Date: Wed, 7 Dec 2005 13:56:29 -0800
The different between the cases was not significant and the
prefetching cases were better than no prefetching. Again, still no
detriment to performance.
I still think what e1000 is doing is way too aggressive.
I know
On Wed, 2005-07-12 at 14:09 -0800, David S. Miller wrote:
From: John Ronciak [EMAIL PROTECTED]
Date: Wed, 7 Dec 2005 13:56:29 -0800
The different between the cases was not significant and the
prefetching cases were better than no prefetching. Again, still no
detriment to performance.
On Wed, Dec 07, 2005 at 02:17:16PM -0500, jamal wrote:
...
Note, however that as soon as i turn copybreak off, the numbers go
down ;-
Now for some obtuse theory as to why this happens:
I think the reason that prefetch + copybreak together have higher
numbers is because the copybreak code
On Wed, 2005-07-12 at 14:11 -0800, David S. Miller wrote:
From: Eric Dumazet [EMAIL PROTECTED]
Date: Wed, 07 Dec 2005 23:04:04 +0100
Another try could be to do some benchmarks about NET_IP_ALIGN being a valid
optimization nowadays :
Maybe setting it to 0 in e1000 driver could give
On Wed, 7 Dec 2005, David S. Miller wrote:
The different between the cases was not significant and the
prefetching cases were better than no prefetching. Again, still no
detriment to performance.
I still think what e1000 is doing is way too aggressive.
I know of at least one platform,
From: Grant Grundler [EMAIL PROTECTED]
Date: Wed, 7 Dec 2005 16:01:50 -0700
I would argue the other way around. copybreak would stall and hurt
small packet routing performance if there was no prefetching.
With agressive prefetching, copybreak takes advantage of data that
is already in flight
Hi David,
this patch adds a dormant flag to network devices, RFC2863 operstate derived
from these flags and possibility for userspace interaction. It allows drivers
to signal that a device is unusable for user traffic without disabling
queueing (and therefore the possibility for protocol
Hi David,
this patch adds support to the VLAN driver to translate IF_OPER_DORMANT of the
underlying device to netif_dormant_on(). Beside clean state forwarding, this
allows running independant userspace supplicants on both the real device and
the stacked VLAN. It depends on my RFC2863 patch.
On Monday 05 December 2005 14:31, Jiri Benc wrote:
And Joseph
friends are writing a module to support softmac cards in that framework,
which is one of the most urgently needed things right now, because all
the existing softmac frameworks don't work with that code.
And authors of rtl8180
Michael Wu wrote:
The softmac code that is still in adm8211 is actually based on an early
version of the softmac code that Jouni made for Devicescape. The Devicescape
code does much more useful stuff than the code currently in the kernel. Sure,
I can and have been porting adm8211 to the new
John Ronciak a écrit :
On 12/7/05, David S. Miller [EMAIL PROTECTED] wrote:
Keyword, this box.
We don't disagree and never have with this. It's why we were asking
the question of find us a case where the prefetch shows a detriment to
performance. I think Jesse's data and recommendation of
From: Eric Dumazet [EMAIL PROTECTED]
Date: Thu, 08 Dec 2005 04:47:05 +0100
#4#5 as proposed in the patch can not be a win
+ prefetch(next_skb);
+ prefetch(next_skb-data - NET_IP_ALIGN);
because at the time #5 is done, the CPU dont have in its cache next_skb-data
43 matches
Mail list logo
