> > > There is no point in using it for transmit since the Linux
> > > TCP stack currently doesn't support this.
> >
> > Hmm... Are you sure? Until now I thought exaclty the same with opposite
> > sign. 8) Namely: there are no reasons to awake the feature in TCP,
> > because no drivers support this.
>
> There are a few drivers that could support it if the stack allowed it. :)
> One of them is the starfire driver, for example.
Many modern Fast Ethernet NICs support this too. The 3com 3c905 and 905A do
not, but the 905B and 905C do.
Countless other 'good' chipsets also support it too, eg Intel Etherexpress.
There is a slight latency drawback, in that the NIC can't start transmitting
the packet onto the wire until the whole packet is in the onboard RAM, and
the checksum computed (early transmits). This is a latency vs processor
issue, but usually considered a win.
In an ideal world, this could be compile or run-time tunable, so you could
favour latency over processor time (optimize for network speed etc). The
extra latency is probably marginal with fast ethernet though.
I wonder how 3com implemented all this in their own linux driver.........
There are lots of tweak to be made :o) .
Dan
__________________________
Daniel J Blueman
Undergraduate - BSc Computing Science
UMIST university - Manchester
Direct line: 0161 933 3569
Mobile: 07775 583766
Email: daniel.j.blueman@stud.umist.ac.uk
SMS: daniel.j.blueman@sms.genie.co.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:14 EST