On Sat, Dec 03, 2005 at 02:37:59PM -0500, jamal wrote:
> On Sat, 2005-03-12 at 12:00 -0700, Grant Grundler wrote:
> > On Sat, Dec 03, 2005 at 09:20:52AM -0500, jamal wrote:
> > > Ok, so you seem to be saying again that for case #b above, there is no
> > > harm in issuing the prefetch late since the
Ben Greear wrote:
> Al Boldi wrote:
> > Here specifically, ip/ifconfig is implemented upside-down requiring a
> > link/dev to exist for an address to be defined, in effect containing
> > layer 3 inside layer 2, when an address should be allowed to be defined
> > w/o a link/dev much like an app is a
On Sat, 2005-03-12 at 12:00 -0700, Grant Grundler wrote:
> On Sat, Dec 03, 2005 at 09:20:52AM -0500, jamal wrote:
> >
> > Ok, so you seem to be saying again that for case #b above, there is no
> > harm in issuing the prefetch late since the CPU wont issue a second
> > fetch for the address?
>
>
On Sat, Dec 03, 2005 at 09:20:52AM -0500, jamal wrote:
> > That's not quite correct IMHO. The prefetching can get cachelines
> > in-flight which will reduce the CPU stall (in the case the cacheline
> > hasn't arrived before CPU asked for it).
...
> You seem to say that if s/ware schedules a prefetc
Al Boldi wrote:
Here specifically, ip/ifconfig is implemented upside-down requiring a
link/dev to exist for an address to be defined, in effect containing layer 3
inside layer 2, when an address should be allowed to be defined w/o a
link/dev much like an app is allowed to be defined w/o an add
On Sat, 2005-03-12 at 09:39 -0500, jamal wrote:
>
> I am going to go and install Linux (running something else at the
> moment) on this one piece of hardware that i happen to know was
> problematic and try to test like the way Robert did. That will be my
> good deed of the day ;->
I suppose no g
On Sat, 2005-03-12 at 02:25 +0100, Eric Dumazet wrote:
> Note that on a router (ie most packets are not locally delivered), copybreak
> is useless and expensive.
>
> But if most packets are locally delivered (on local TCP or UDP queues), then
> copybreak is a win because less memory is taken by
On Fri, 2005-02-12 at 20:04 -0800, David S. Miller wrote:
> We don't even know the _nature_ of the cases where the e1000 prefetches
> might want to be disabled by a platform. It's therefore impossible
> for us to design any kind of reasonable interface or runtime test.
>
> All evidence shows the
On Fri, 2005-02-12 at 16:53 -0800, Ronciak, John wrote:
> > In this combination of hardware and in this forwarding test
> > copybreak is bad but prefetching helps.
> >
> > e1000 vanilla 1150 kpps
> > e1000 6.2.151084
>
On Fri, 2005-02-12 at 11:04 -0700, Grant Grundler wrote:
> On Thu, Dec 01, 2005 at 09:32:37PM -0500, jamal wrote:
[..]
>
> We've already been down this path before. How and where to prefetch
> is quite dependent on the CPU implementation and workload.
>
[..]
> At the time you did this, I read t
Pekka Savola wrote:
> Al Boldi wrote:
> > Consider this new approach for better address management:
> > 1. Allow the definition of an address pool
> > 2. Relate links to addresses
> > 3. Implement to make things backward-compatible.
> >
> > The obvious benefit here, would be the transparent ability
On 12/3/05, JaniD++ <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > The e1000 driver also has several tunable options for its various
> > features. See drivers/net/e1000/e1000_param.c. Disabling interrupt
> > rate throttling might help.
>
> i have tried this, but did not help. :(
>
> #define DEFAULT_ITR
Using WIRELESS_EXT instead of CONFIG_NET_RADIO is simply ugly.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
net/core/dev.c | 10 --
net/core/net-sysfs.c |8
net/socket.c |9 +++--
3 files changed, 7 insertions(+), 20 deletions(-)
--- linux-2.
WIRELESS_EXT < 18 will never be true in the kernel.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/wireless/ipw2100.c | 434 --
drivers/net/wireless/tiacx/acx_struct.h |5
drivers/net/wireless/tiacx/common.c |4
drivers/net/wireles
This patch contains an attempt to properly build hostap.o without
#incude'ing C files.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/wireless/hostap/Makefile |3
drivers/net/wireless/hostap/hostap.h | 37 +++
drivers/net/wireless/hostap/hostap
David S. Miller a écrit :
I agree with the analysis, but I truly hate knobs. Every new
one we add means it's even more true that you need to be a wizard
to get a Linux box performing optimally.
[rant mode]
Well, I suspect this is the reason why various hash tables (IP route cache,
TCP establi
16 matches
Mail list logo
