On Wed, Aug 16, 2006 at 12:30:29PM -0400, Jeff Garzik wrote:
Linas Vepstas wrote:
The recent set of low-waterark patches for the spider result in a
Let's not reinvented NAPI, shall we...
??
I was under the impression that NAPI was for the receive side only.
This round of patches were for
Linas Vepstas wrote:
I was under the impression that NAPI was for the receive side only.
That depends on the driver implementation.
Jeff
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 16 Aug 2006 16:34:31 -0400
Linas Vepstas wrote:
I was under the impression that NAPI was for the receive side only.
That depends on the driver implementation.
What Jeff is trying to say is that TX reclaim can occur in
the NAPI poll routine,
On Thu, Aug 17, 2006 at 12:16:46AM +0200, Arnd Bergmann wrote:
Am Wednesday 16 August 2006 23:32 schrieb David Miller:
Can spidernet be told these kinds of parameters? N packets or
X usecs?
It can not do exactly this but probably we can get close to it by
Why would you want o do this? It
From: [EMAIL PROTECTED] (Linas Vepstas)
Date: Wed, 16 Aug 2006 18:30:28 -0500
Why would you want o do this? It seems like a cruddier strategy
than what we can already do (which is to never get an transmit
interrupt, as long as the kernel can shove data into the device fast
enough to keep
On Thu, Aug 17, 2006 at 01:03:20AM +0200, Arnd Bergmann wrote:
Could well be related to latencies when going to the remote
node for descriptor DMAs. Have you tried if the hch's NUMA
patch or using numactl makes a difference here?
No. I guess I should try.
sounds like the right approach
Please apply and forward upstream. This patch requires the previous
sequence of 4 spidernet patches to be applied.
--linas
The recent set of low-waterark patches for the spider result in a
significant amount of computing being done in an interrupt context.
This patch moves this to a bottom
Linas Vepstas wrote:
Please apply and forward upstream. This patch requires the previous
sequence of 4 spidernet patches to be applied.
--linas
The recent set of low-waterark patches for the spider result in a
significant amount of computing being done in an interrupt context.
This patch
Am Wednesday 16 August 2006 22:46 schrieb David Miller:
I'm not familiar with the spidernet TX side interrupt capabilities
so I can't say whether that is something that can be directly
implied. In fact, I get the impression that spidernet is limited
in some way and that's where all the
From: Arnd Bergmann [EMAIL PROTECTED]
Date: Wed, 16 Aug 2006 23:24:46 +0200
We first had an interrupt per descriptor, then got rid of all TX
interrupts and replaced them by timers to reduce the interrupt load,
but reducing throughput in the case where user space sleeps on a full
socket
On Wed, Aug 16, 2006 at 01:46:40PM -0700, David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Wed, 16 Aug 2006 16:34:31 -0400
Linas Vepstas wrote:
I was under the impression that NAPI was for the receive side only.
That depends on the driver implementation.
What Jeff is
Am Wednesday 16 August 2006 23:32 schrieb David Miller:
Can spidernet be told these kinds of parameters? N packets or
X usecs?
It can not do exactly this but probably we can get close to it by
1.) Setting a one-time interrupt to fire x*10µs after putting a
packet into the TX queue.
and
From: Arnd Bergmann [EMAIL PROTECTED]
Date: Thu, 17 Aug 2006 00:16:46 +0200
Am Wednesday 16 August 2006 23:32 schrieb David Miller:
Can spidernet be told these kinds of parameters? N packets or
X usecs?
It can not do exactly this but probably we can get close to it by
Oh, you can only
Am Thursday 17 August 2006 00:29 schrieb David Miller:
Didn't you say spidernet's facilities were sophisticated? :)
This Tigon3 stuff is like 5+ year old technology.
I was rather overwhelmed by the 34 different interrupts that
the chip can create, that does not mean they chose the right
events
On Wed, Aug 16, 2006 at 11:24:46PM +0200, Arnd Bergmann wrote:
it only
seems to be hard to make it go fast using any of them.
Last round of measurements seemed linear for packet sizes between
60 and 600 bytes, suggesting that the hardware can handle a
maximum of 120K descriptors/second,
Am Thursday 17 August 2006 00:55 schrieb Linas Vepstas:
it only
seems to be hard to make it go fast using any of them.
Last round of measurements seemed linear for packet sizes between
60 and 600 bytes, suggesting that the hardware can handle a
maximum of 120K descriptors/second,
Linas Vepstas wrote:
On Wed, Aug 16, 2006 at 11:24:46PM +0200, Arnd Bergmann wrote:
it only
seems to be hard to make it go fast using any of them.
Last round of measurements seemed linear for packet sizes between
60 and 600 bytes, suggesting that the hardware can handle a
maximum of 120K
On Wed, Aug 16, 2006 at 04:32:52PM -0700, David Miller wrote:
From: [EMAIL PROTECTED] (Linas Vepstas)
Why would you want to do this? It seems like a cruddier strategy
than what we can already do (which is to never get an transmit
interrupt, as long as the kernel can shove data into the
18 matches
Mail list logo
