Re: [PATCH] eepro100 - need testers

[Steve Parker <sparker@sparker.net>]

At 05:26 PM 12/4/2001 , Kurt Roeckx wrote:
>On Tue, Dec 04, 2001 at 02:57:35PM -0800, Tim Hockin wrote:
> > -#define TX_RING_SIZE 32
> > -#define RX_RING_SIZE 32
> > +#define TX_RING_SIZE 64
> > +#define RX_RING_SIZE 1024
>
>Why do I have the feeling that you're just changing those values
>so you get less chance of having the problem?  Are there any
>other reason why you change this?  It might even be a good idea
>to test it with lower values.

If you test with lower values, I find that the problem happens so often that
bidirectional TCP bulk throughput tests on 100Mbits/sec ethernet are 
significantly
lower.  As Tim pointed out, the RX ring size is chosen based on being large 
enough
to receive steadily and only require the ISR to come by and empty it once 
every jiffy.
In order to provide good performance and survivability on maximum packet 
rate loads,
it needs to be 1024, although it's moderately good on 512, on my 300MHz K6 
system.



> > -                     } else if ((status & 0x003c) == 0x0008) { /* No 
> resources. */
> > -                             struct RxFD *rxf;
> > -                             printk(KERN_WARNING "%s: card reports no 
> resources.\n",
> > -                                             dev->name);
>
>[...]
>
> > +             switch ((status >> 2) & 0xf) {
> > +             case 0: /* Idle */
> > +                     break;
> > +             case 1: /* Suspended */
> > +             case 2: /* No resources (RxFDs) */
> > +             case 9: /* Suspended with no more RBDs */
> > +             case 10: /* No resources due to no RBDs */
> > +             case 12: /* Ready with no RBDs */
> > +                     speedo_rx_soft_reset(dev);
> > +                     break;
>
>You can also argue that you're trying to fix the problem by
>hiding it.  It would be useful that it still reported the same
>error message, so you can see that if it happens again with the
>patch that it no longer locks up.

The printk significantly reduces TCP throughput on my tests, it doesn't tell me
about an interesting condition, so I removed it.  This state happens any 
time the chip receives
more than a ring buffer full before the ISR can empty it, which is 
something which
is always possible.

And any way, why would you care to know?  Is there something you'ld imagine
doing because you saw the message?


Cheers,

	~sparker