Jamal,
This is silly. I am not responding to this type of presumptuous and
insulting mails.
Regards,
- KK
J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/25/2007 12:58:20 AM:
> KK,
>
> On Tue, 2007-24-07 at 09:14 +0530, Krishna Kumar2 wrote:
>
> >
> > J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/
KK,
On Tue, 2007-24-07 at 09:14 +0530, Krishna Kumar2 wrote:
>
> J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/23/2007 06:02:01 PM:
> Actually you have not sent netperf results with prep and without prep.
My results were based on pktgen (which i explained as testing the
driver). I think depend
Hi Jamal,
J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/23/2007 06:02:01 PM:
> Yes, and these results were sent to you as well a while back.
> When i get the time when i get back i will look em up in my test machine
> and resend.
Actually you have not sent netperf results with prep and without pr
KK,
On Mon, 2007-23-07 at 10:19 +0530, Krishna Kumar2 wrote:
> Hmmm ? Evgeniy has not even tested my code to find some regression :) And
> you may possibly not find much improvement in E1000 when you run iperf
> (which is what I do) compared to pktgen.
Pktgen is the correct test (or the closest
On Sat, 21 Jul 2007 09:46:19 -0400
jamal <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-20-07 at 08:18 +0100, Stephen Hemminger wrote:
>
> > You may see worse performance with batching in the real world when
> > running over WAN's. Like TSO, batching will generate back to back packet
> > trains that
Hi Jamal,
J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/22/2007 06:21:09 PM:
> My concern is there is no consistency in results. I see improvements on
> something which you say dont. You see improvement in something that
> Evgeniy doesnt etc.
Hmmm ? Evgeniy has not even tested my code to find som
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 07/20/2007 06:24:23 PM:
> Hi Krishna.
>
> On Fri, Jul 20, 2007 at 12:01:49PM +0530, Krishna Kumar
([EMAIL PROTECTED]) wrote:
> > After fine-tuning qdisc and other changes, I modified IPoIB to use this
API,
> > and now get good gains. Summa
KK,
On Sun, 2007-22-07 at 11:57 +0530, Krishna Kumar2 wrote:
> Batching need not be useful for every hardware.
My concern is there is no consistency in results. I see improvements on
something which you say dont. You see improvement in something that
Evgeniy doesnt etc.
There are many knobs an
Hi Jamal,
J Hadi Salim <[EMAIL PROTECTED]> wrote on 07/21/2007 06:48:41 PM:
> >- Use a single qdisc interface to avoid code duplication and reduce
> > maintainability (sch_generic.c size reduces by ~9%).
> >- Has per device configurable parameter to turn on/off batching.
> >- qdi
On Fri, 2007-20-07 at 08:18 +0100, Stephen Hemminger wrote:
> You may see worse performance with batching in the real world when
> running over WAN's. Like TSO, batching will generate back to back packet
> trains that are subject to multi-packet synchronized loss.
Has someone done any study on
I am (have been) under extreme travel mode - so i will have high latency
in follow ups.
On Fri, 2007-20-07 at 12:01 +0530, Krishna Kumar wrote:
> Hi Dave, Roland, everyone,
>
> In May, I had proposed creating an API for sending 'n' skbs to a driver to
> reduce lock overhead, DMA operations, and
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 07/20/2007 06:24:23 PM:
> > After fine-tuning qdisc and other changes, I modified IPoIB to use this
API,
> > and now get good gains. Summary for TCP & No Delay: 1 process improves
for
> > all cases from 1.4% to 49.5%; 4 process has almost
Hi Krishna.
On Fri, Jul 20, 2007 at 12:01:49PM +0530, Krishna Kumar ([EMAIL PROTECTED])
wrote:
> After fine-tuning qdisc and other changes, I modified IPoIB to use this API,
> and now get good gains. Summary for TCP & No Delay: 1 process improves for
> all cases from 1.4% to 49.5%; 4 process has
Stephen Hemminger <[EMAIL PROTECTED]> wrote on 07/20/2007
12:48:48 PM:
> You may see worse performance with batching in the real world when
> running over WAN's. Like TSO, batching will generate back to back packet
> trains that are subject to multi-packet synchronized loss. The problem is
that
>
On Fri, 20 Jul 2007 13:00:25 +0530
Krishna Kumar2 <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> wrote on 07/20/2007
> 12:48:48 PM:
>
> > You may see worse performance with batching in the real world when
> > running over WAN's. Like TSO, batching will generate back to back p
Stephen Hemminger <[EMAIL PROTECTED]> wrote on 07/20/2007
12:48:48 PM:
> You may see worse performance with batching in the real world when
> running over WAN's. Like TSO, batching will generate back to back packet
> trains that are subject to multi-packet synchronized loss. The problem is
that
>
Attached file contains scripts for running tests and parsing results :
(See attached file: scripts.tar)
The result of a 10 run (average) TCP iperf (and 1 netperf for UDP) is
given below.
Thanks,
- KK
-
Test configurat
On Fri, 20 Jul 2007 12:01:49 +0530
Krishna Kumar <[EMAIL PROTECTED]> wrote:
> Hi Dave, Roland, everyone,
>
> In May, I had proposed creating an API for sending 'n' skbs to a driver to
> reduce lock overhead, DMA operations, and specific to drivers that have
> completion notification like IPoIB -
Hi Dave, Roland, everyone,
In May, I had proposed creating an API for sending 'n' skbs to a driver to
reduce lock overhead, DMA operations, and specific to drivers that have
completion notification like IPoIB - reduce completion handling ("[RFC] New
driver API to speed up small packets xmits" @
ht
19 matches
Mail list logo
