On Fri, 15 Sep 2000, Bogdan Costescu wrote:
> On Thu, 14 Sep 2000, jamal wrote:
>
> The 3Com cards can generate this interrupt, however this is not used in
> current 3c59x.c. I suggested this to Andrew, but he is already worried
> about the current interrupt rate and unhappy that 3Com cards do not
> provide hardware support for Rx mitigation.
>
> An ideea might be to combine Rx early interrupts with some kind of
> software timer-based mitigation.
Only the timer runs at HZ granularity ;-<
> IMHO this has 2 advantages:
> - because of the overhead that Andrew pointed out, by the time the CPU
> reaches the ISR code and the skbuff allocation is done, the entire packet
> might already be transferred;
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. If you are waiting for 640 bytes
more that is ~5 microsecs or say 10microsecs for average 1000 bytes
in a LAN. For a 10mbps connection ~100microsecs. But we dont have problems
with 10Mbps.
I think this is an interesting heuristic to use. the 20Msec given by
Andrew appears to me to be x86 specific and processor dependent though.
Can you guarantee it on a 600Mhz Alpha processor?
This is just one of those schemes which are useful in my opinion for
quick header inspection: While the packet is still coming in, you have
enough data to make a call. 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.
Instead of using full-rx interupts as is done today, it will make sense to
receive mid-interupts so that you are ready for the above scheme. I know,
i know Linux is a general purpose OS.
> however, a check has to be done to assure
> that the packet was not dropped by the hardware and you try to fit a
> packet in a skbuff sized for the previous packet (in case several packets
> can be transferred during the "overhead" time)
Most of the schemes like that dont drop the packet once you receive
partial pieces. Other incoming packets will be dropped though if no space.
cheers,
jamal
-
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 : Fri Sep 15 2000 - 21:00:25 EST