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
Jesse Brandeburg a écrit :
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
I believe this is a hardware bug, but super-micro is being slow
to respond...
I have tried various different kernels based around an FC2 system,
and all of them hang when I have a dual port Intel pro/1000 NIC
in slot 5. Slot 6 works, and a single port NIC in slot 5 works. I
tried two different
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
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 ker
From: John Ronciak <[EMAIL PROTECTED]>
Date: Wed, 7 Dec 2005 16:09:21 -0800
> On 12/7/05, David S. Miller <[EMAIL PROTECTED]> wrote:
>
> I think Jesse's data and recommendation of only keeping the #1, #2
> and #5 prefetches seem like the right thing to do with data to back
> it up. It also goes a
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 only keeping
the #1, #2
On Thu, 2005-08-12 at 00:13 +0100, Stefan Rompf wrote:
> It is the result of our long discussion. However I must admit that it
> represents what Jamal and I agreed on with compromises towards Krzysztof, but
> Thomas and Krzysztof still disagree with some parts. Anyway I think it should
> be app
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 07 Dec 2005 18:50:03 -0500
> ok, sorry this stuck in my mind and i had to go back and find this
> email.
> What Dave explained in terms of accounting makes sense - and there could
> be a relationship with what you are saying with UDP. or maybe not ;->
Th
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
From: Jesse Brandeburg <[EMAIL PROTECTED]>
Date: Wed, 7 Dec 2005 15:06:04 -0800 (Pacific Standard Time)
> in no case did the prefetch hurt anything on this box.
Keyword, "this box".
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
M
On Wed, 2005-07-12 at 13:47 -0800, John Ronciak wrote:
> 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 copy
On Wed, 2005-07-12 at 15:06 -0800, Jesse Brandeburg wrote:
> On Wed, 7 Dec 2005, David S. Miller wrote:
[..]
> Okay, so I tested with just pktgen sending to a machine with a PCI Express
> Intel 82571 server adapter. The stack is just discarding the data, no
> routing.
>
Where are you discardi
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.
P
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 establ
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 fl
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, sp
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
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 perfo
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 c
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 k
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
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 quest
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 perf
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
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.
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 l
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 ra
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
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 syst
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
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. :-/
Assumi
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 i
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
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 swi
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 + e1000-
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 sw
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 o
On Wed, Dec 07, 2005 at 11:16:22AM -0800, Jean Tourrilhes wrote:
> Well, the burning question is : Is it possible to include your
> Atheros driver in the Linux kernel ? Meaning, will it be released, and
> will it contain a binary blob ?
If that were possible, it would have been released wit
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
> > disabl
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 co
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
On 12/7/05, Robert Olsson <[EMAIL PROTECTED]> wrote:
> Thanks for this discussion. It comes in handy as I have to prepare
> for a new distro for our network stuff. Right now it seems like
> e1000 6.2.15 can be used but with HW-flow disabled, cpybrk disabled
> and only with the two first prefetches
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 cros
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
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 a
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
Stefan Rompf <[EMAIL PROTECTED]> writes:
> Yes, my patch bases on yours and Thomas' work. You're both welcome to add
> your
> signed-off lines.
That was trivial and I don't demand credit here. I just answered
Jamal's question.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "
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 C
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 a
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
* jamal <[EMAIL PROTECTED]> 2005-12-07 07:56
> How is this different, conceptually, from any other flag setting being
> lost - for example a promisc or admin up/down?
> In other words if you want to reliably transmit state, shouldnt the
> "responsible system" have to worry about the reliability?
>
On Wednesday 07 December 2005 00:19, you wrote:
> From: Harald Welte <[EMAIL PROTECTED]>
> Date: Tue, 6 Dec 2005 20:40:47 +0530
>
> > I'm also in favor of merging the devicescape code, but I don't see it
> > happening without somebody taking care to provide all the required
> > levels of interface
On Wed, 2005-07-12 at 09:05 +0100, Thomas Graf wrote:
> The implementation of the rule "if admin status down operational status
> should be down" only exists in the sysfs code. I would absolutely favour
> one clear interface representing the operational status of an interface.
>
> The transition
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
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
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.
> > >
> > > Fr
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
>
> copybreak
Stefan,
This looks better with every iteration, I'm still lacking a few minor
things though:
The implementation of the rule "if admin status down operational status
should be down" only exists in the sysfs code. I would absolutely favour
one clear interface representing the operational status of
59 matches
Mail list logo
