Messages in this thread | | | From | "Daniel J Blueman" <> | Subject | Re: Gigabit Linux Server Bottlenecks | Date | Wed, 9 Feb 2000 00:35:27 -0000 |
| |
> > > 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/
| |