Jamal, Thayne,
I've asked Jeff to go ahead and apply this patch as a way around this
for now. We would liketo see the DITR stay but now have this
performacne problem so we don't want to rip it out. We do however need
a test case to replicate this as we have not been seeing it in our
testing. Please get us those case that break things. We'll have a
better solution longer term based on the test cases (as well as the ones
we normally use of course).
Thanks.
Cheers,
John
> -----Original Message-----
> From: netdev-bounce@xxxxxxxxxxx
> [mailto:netdev-bounce@xxxxxxxxxxx] On Behalf Of Thayne Harbaugh
> Sent: Thursday, August 26, 2004 2:29 PM
> To: Jeff Garzik
> Cc: hadi@xxxxxxxxxx; Venkatesan, Ganesh; netdev@xxxxxxxxxxx;
> Feldman, Scott; Brandeburg, Jesse
> Subject: Re: [PATCH] abysmal e1000 performance (DITR)
>
>
> On Thu, 2004-08-26 at 16:26 -0400, Jeff Garzik wrote:
> > Thayne Harbaugh wrote:
> > > On Thu, 2004-08-26 at 13:55 -0400, jamal wrote:
> > >
> > >>Ganesh,
> > >>
> > >>Can you please make this feature off by default and perhaps
> > >>accesible via ethtool for peopel who want to turn it on.
> > >>I just wasted a few hours and was bitten by this performance-wise.
> > >>Please consider disabling it.
> > >
> > >
> > > This is a *horrible* problem. Even though it's fixable
> by passing a
> > > module parameter, the default bites those that *know*
> about it. We have
> > > had customers bitten by this and customers that have insisted in
> > > swapping all the NICs in a cluster to Broadcom TG3 NICs.
> > >
> > > It's a black eye for Intel and a loss of business -
> that's the opinion
> > > of our customers.
> >
> >
> > If it's so bad we should disable it by default, either via
> the module
> > parameter or via a kernel CONFIG_xxx option.
>
> Yes, it is so bad. The dynamic interrupt setting should be deprecated
> by the use of NAPI.
>
> This is a simple way to disable it, yet still keep the code so that
> someone can enable it if they really wanted it. I, however,
> would just
> as soon see all of the DITR code ripped out.
>
> There are other ways that might be better for dealing with
> it, yet still
> keeping the DITR code viable.
>
> --- drivers/net/e1000/e1000_param.c.broken_ditr 2004-08-26
> 15:40:34.436456736 -0600
> +++ drivers/net/e1000/e1000_param.c 2004-08-26
> 15:49:07.186506880 -0600
> @@ -212,7 +212,7 @@
> #define MAX_TXABSDELAY 0xFFFF
> #define MIN_TXABSDELAY 0
>
> -#define DEFAULT_ITR 1
> +#define DEFAULT_ITR 8000
> #define MAX_ITR 100000
> #define MIN_ITR 100
>
>
>
>
>
|