On Fri, 15 Sep 2000, Bogdan Costescu wrote:
> On Fri, 15 Sep 2000, jamal wrote:
>
> > Only the timer runs at HZ granularity ;-<
>
> Some cards provide their own high resolution timers; latest 3Com cards
> provide several with different purposes (none currently used). The
> question is how many of these also provide the Rx early interrupts.
> You also mentioned an auto-tunable Rx mitigation scheme. How do you
> implement it without using hardware timers ?
>
Oh, the tulip 21143 explicitly has an interupt mitigation timer; this is
for both the tx and rx. But i see you can also use a general purpose timer
on the NIC to simulate mitigation.
disable rx interupts and other sources of noise (eg rx no buf) and set the
timer to wait a certain number of packet times.
Donald's drivers generally have this scheme built in; however, it is a
one-shot mode on rx work overload (mostly there for interupt sharing
according to one of Donald's old posts).
So what you do instead is have a table of these 'mitigation' values[1]
and select the appropriate mitigation value; i.e you have a pointer that
moves up and down the table and based on the load picks the correct
mitigation value.
When Robert Oks the current tulip, you should be able to see how it is
done there.
> > 20Msec is probably too much time. If my math is not wrong, 1 bit time in
> > a 100Mps is 1 ns; 64 bytes is 512ns.
>
> I think your are wrong by a factor of 10 here, 1 bit time at 100Mbps
> should be 10 ns. Then 64 bytes is 5.12 us (u=micro). Anyway, this is
> comparable with the time needed to reach ISR, so you can have several
> (but small number) of packets already waiting for processing.
>
> > You use the period(5-10micros), while waiting
> > for full packet arrival, to make the route decision (lookup etc).
> > i.e this will allow for a better FF; it will not offload things.
>
> Just that you span several layers by doing this, it's not driver specific
> anymore.
I think we should heed Donald's advice on this early rx. I would take
Donald's word for it; he's been there done that. He knows.
eg the PCI burst issues makes a lot of sense. Unless someone with the
right tools (eg PCI bus monitors) might do some measurements and maybe
challenge Donald ;->
cheers,
jamal
[1] the table would look something like:
table[0] == 1 packet per interupt (default); disable timer
table[1] == 2 packets per interupt
table[3] == 3 packets per interupt
.
.
etc.
use 64 bytes as the packet size since it is the smallest ethernet size.
as you pointed out that is 51.2 microsecs. so 102.4 microsecs for table[1]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:13 EST