Mandeep Singh Baines wrote:
Daniele Venzano ([EMAIL PROTECTED]) wrote:
The patch looks good and I think it can be pushed higher (-mm ?) for some wider
testing. I don't have the hardware available to do some tests myself,
unfortunately, but it would be similar to yours anyway.
I'd like to
jamal wrote:
On Wed, 2007-05-09 at 13:03 +0100, James Chapman wrote:
I have a patch that solves the high interrupt rate problem by keeping
the driver in polled mode longer. It's written for the latest NAPI
version that DaveM posted recently. I'll try to get some time to write
it up and post
On Wed, 2007-05-09 at 14:55 +0100, James Chapman wrote:
Thanks Jamal. Yes, I'd already read your paper. I think my idea is
different to the ideas described in your paper
I am hoping you can pick from the lessons of what has been tried and
failed and the justification for critiqueing
jamal ([EMAIL PROTECTED]) wrote:
On Wed, 2007-05-09 at 14:55 +0100, James Chapman wrote:
Thanks Jamal. Yes, I'd already read your paper. I think my idea is
different to the ideas described in your paper
I am hoping you can pick from the lessons of what has been tried and
failed and
On Mon, 2007-03-09 at 20:20 -0700, Mandeep Singh Baines wrote:
I didn't see much saving in interrupts on my machine (too fast, I guess).
You could try the idea suggested by Dave earlier and just turn interupts
for every nth packet. That should cut down the numbers.
I did see a significant
- Message d'origine -
De: Mandeep Singh Baines [EMAIL PROTECTED]
Date: Mon, 3 Sep 2007 20:20:36 -0700
Sujet: [PATCH] [sis900] convert to NAPI, WAS Re: pktgen terminating condition
Hi Daniele,
Attached is a patch for converting the sis900 driver to NAPI. Please take a
look at let me know
On 9/4/07, jamal [EMAIL PROTECTED] wrote:
On Mon, 2007-03-09 at 20:20 -0700, Mandeep Singh Baines wrote:
I didn't see much saving in interrupts on my machine (too fast, I guess).
You could try the idea suggested by Dave earlier and just turn interupts
for every nth packet. That should cut
Baines [EMAIL PROTECTED]
Date: Mon, 3 Sep 2007 20:20:36 -0700
Sujet: [PATCH] [sis900] convert to NAPI, WAS Re: pktgen terminating condition
Hi Daniele,
Attached is a patch for converting the sis900 driver to NAPI. Please take a
look at let me know what you think. I'm not 100% sure if I'm
terminating condition
I dont know if you followed the discussion - by defering the freeing of
skbs, you will be slowing down socket apps sending from the local
machine. It may be ok if the socket buffers were huge, but that comes at
the cost of system memory (which may not be a big deal)
Do
- Message d'origine -
De: jamal [EMAIL PROTECTED]
Date: Fri, 31 Aug 2007 09:50:03 -0400
Sujet: Re: Re: pktgen terminating condition
I dont know if you followed the discussion - by defering the freeing of
skbs, you will be slowing down socket apps sending from the local
machine. It may
- Message d'origine -
De: Mandeep Baines [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 09:59:42 -0700
Sujet: Re: pktgen terminating condition
Looks good to me given the desire. I would bounce it by whoever the
maintainer is - they may have some insights on the lazy tx prune habit.
+ [EMAIL
On Thu, 2007-30-08 at 22:19 -0700, David Miller wrote:
You could implement this quite simply using skb-destructor.
Thats what i was thinking ..
It will add some atomics, so on weaker pktgen source systems
it might decrease the generators rate.
Indeed. So maybe a config option instead; it
On Fri, 2007-31-08 at 14:17 +0200, Daniele Venzano wrote:
I don't regard the TxOK solution as something usable for mainline, but it has
its
use for the users of pktgen.
I dont know if you followed the discussion - by defering the freeing of
skbs, you will be slowing down socket apps sending
On Wed, 2007-29-08 at 09:59 -0700, Mandeep Baines wrote:
I'll work on a NAPI patch.
It's a GoodThing - go for it.
cheers,
jamal
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Wed, 2007-29-08 at 18:32 +0200, Robert Olsson wrote:
Yes it's synchronization issue... the test is over and we have sent
all pkts to the device but pktgen cannot free the skb for it still
has refcounts.
Ok, right.
I was confusing it with another issue where pktgen could send a lot
From: jamal [EMAIL PROTECTED]
Date: Thu, 30 Aug 2007 08:08:40 -0400
I was confusing it with another issue where pktgen could send a lot of
packets without waiting for them to be freed; there are some drivers
(10G) which may hold onto 8K skbs. A gazillion ooms start spewing ;- My
thinking in
On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
I interpret this to mean that the interrupt gets generates after a packet
is transferred to the TFIFO on the NIC and the next packet in the ring is
NULL.
iow, when tx transits to idle ..
This interrupt gets generates less often
jamal writes:
On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
I think its a good thing pktgen caught this; i am unsure however if it
is doing the right thing. Hoping Robert would respond.
One thing pktgen could do is restrict the amount of outstanding buffers
by using
On 8/29/07, jamal [EMAIL PROTECTED] wrote:
On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
I interpret this to mean that the interrupt gets generates after a packet
is transferred to the TFIFO on the NIC and the next packet in the ring is
NULL.
iow, when tx transits to
Hi,
I am having some trouble using pktgen with certain NICs. When running
pktgen on some NICs, the test stalls because the worker thread is
waiting for the driver to free the last skb. If a send a few pings out
the interface, the worker thread will eventually unblock.
Below is the snippet of
From: Mandeep Singh Baines [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 15:47:18 -0700
It seems that some drivers do not immediately free skbs on transmit
complete. They will hold the skb until there are more packets to
free. One example is the sis900 driver which uses TX_IDLE (tx
state-machine
David Miller wrote:
From: Mandeep Singh Baines [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 15:47:18 -0700
It seems that some drivers do not immediately free skbs on transmit
complete. They will hold the skb until there are more packets to
free. One example is the sis900 driver which uses
From: Rick Jones [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 16:48:24 -0700
Not to defend any one driver, but could it be that the behaviour of TCP
is such that we've not noticed until now?
Does TCP particularly care for an SKB carrying an ACK? For ones carrying
data there would be an ACK
I don't even understand why this needs to be discussed to be honest
with you :-)
Just my (possibly frustrating :) habit of asking questions which help
further my understanding of the code :)
rick jones
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message
On Tue, 2007-28-08 at 17:06 -0700, David Miller wrote:
Devices need to free packets in a deterministic amount of time, no
matter what.
If i understood the driver pointed to - finite amount of time spec is
still met. Seems some interupt is generated (TX_IDLE) when the tx path
gets idle and this
On Tue, 2007-28-08 at 20:28 -0400, jamal wrote:
On Tue, 2007-28-08 at 17:06 -0700, David Miller wrote:
Devices need to free packets in a deterministic amount of time, no
matter what.
If i understood the driver pointed to - finite amount of time spec is
still met. Seems some interupt is
From: Mandeep Singh Baines [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 21:43:52 -0700
Here is what the datasheet has to say about TxIdle:
This event is signaled when the transmit state machine enters the idle state
from a non-idle state. This will happen whenever the state machine encounters
27 matches
Mail list logo
