On Wed, 2007-05-09 at 22:06 -0700, Mandeep Singh Baines wrote:
> jamal ([EMAIL PROTECTED]) wrote:
> > If you read the paper: There are no issues with high throughput - NAPI
> > kicks in.
> > The challenge to be overcome is at low traffic, if you have a real fast
> > processor your cpu-cycles-used/
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
> faile
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 somethi
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 i
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 it for c
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 know
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 know how this works fo
> 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. Plea
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 shou
- 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 ta
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 b
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 be ok if the socket buffers were huge, bu
- 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 l
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 sendi
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
- 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 in
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
> thinkin
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
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 http://vger.kernel.org/maj
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 tran
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 usin
On 8/29/07, Mandeep Baines <[EMAIL PROTECTED]> wrote:
...
> Unfortunately, the TxIdle interrupt would not free the last odd packet.
> However, if we want to quiet interrupts couldn't the driver just be
> converted NAPI. If this seems reasonable I could work on a patch.
It seems reasonable and that
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 of
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 encoun
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 inte
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 t
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
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 A
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 TX_ID
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-mac
30 matches
Mail list logo
