"Fast Switching" or NIC-to-NIC communications AND channel bonding discouragement

[Robert Olsson]

Brian Dushaw writes:
 > When compiling the kernel recently, I noticed the option for "fast
 > switching" for faster communications when connected NIC-to-NIC.  The
 > help sez the "tulip" supports this.  I enabled this option, but
 > the communication speed (checked via netperf) is unchanged.  Is there
 > some other voodoo, some goat to be burned, to enable the "fast 
 > switching"?  I have the Linksys LNE100TX cards and the tulip driver
 > from the supplied floppy (other drivers seem to not to work so well with
 > this card).
¨
 Hello!

 There is no support for "fast switching" in the current tulip.c neither
 2.2 or 2.3 kernels. The 2.1 kernels had a tulip version with the "fast 
 switching" code. I consider Alexey Kuznetsov as inventor and he did the
 the additions to tulip.c as well. This work was not included the in the
 stock tulip.c or other drivers either but it's another story.

 Anyway "fast switching" is really fast we have done lots experimenting
 with this. But consider FS just for plain routers were no filtering
 and QoS handling is needed. FS improves the packet per second performance.
 Packets are more or less DMA'ed from NIC-to-NIC.
 
 From my head I can give you some performance numbers with linux routing 
 between two tulip NIC's and smallest packets 64 bytes.
 (PII ~400 Mhz ~100 Mhz bus geunine fast ethernet tulip chips)
 
 Normal path       :   ~40 KPPS
 Fast switching patch: ~147 KPPS

 Well I should say that in FS we use skb recycling as well. I don't remember
 the throughput without skb recycling in FS path.

 I should say we seem differences between tulip and tulip clones. I've seen
 chip that is not capable of filling a fast ethernet with smallest packets.

 But one should also realize that 147 KPPS is "very" high number. We and 
 other universities use Linux routers in our routing core. So far we have
 seem about 10 KPPS as maximum so "Normal path" is still fine us.

 And use UDP with forwarding tests and just count packet throughput
 in the router. With medium size packets you should saturate a the
 100 Mbps ethernet pipe unless something is broken.

 The only easy way find out if there is still CPU in the router is to
 time a loop (while(1)) during the test. Any ideas are welcome.
 Tell me if you want to try the driver we play with.


						--ro
 


-------------------------------------------------------------------
To unsubscribe send a message body containing "unsubscribe"
to linux-tulip-request@beowulf.org