Thus spake Alan Cox
>> - memory copies.  As I understand it, to switch a packet through a Linux
>> router, there are at least 2 memory copies....the packet is received and
>> stored in the nic buffer...from there it's copied into main memory...I'm
>> assuming the Linux kernel is very efficient and doesn't do any copies of
>> its own...from there its copied into the outgoing nic's packet buffer.

>Most NIC's have only FIFO's . Main memory is their ram buffer. One card DMA's
>it in, the other DMA's it back out when using the fastroute aware tulip
>driver.

OK...even at that though...you're dealing with two DMA's across a PCI
bus compared to what's essentially a single DMA across a much higher bus
speed in most Cisco's.

>> Cisco hardware...being designed with IOS in mind, allows IOS to do zero
>> memory copies....the packet is read from the incoming nic's packet
>> buffer directly out the outgoing nic.

>Benchmarks for the low end ciscos say either they dont or it doesnt matter
>cos we kick them on IP 8)

I can believe that with a 25xx or so...those things only have 68ec030
processors...hardly beefy at all...they're also a very old design (10
years?) at this point.  I suspect the 26xx's (basically the newer
replacement for the 25xx's) will give Linux a really good run for its
money there.  Not that this is terribly significant.

To be really fair though...when you're dealing with packet speeds that
these types of boxes are dealing with (a 25xx can do 2 E1's and a
regular ethernet at wire speed), it doesn't take much to do wire speed,
and latency just isn't that significant.

>> - extensive switching support.  To my understanding, you can't have a
>> linux box with 4 ethernet cards and bridge between eth0 and eth1, and
>> then bridge between eth2, and eth3, and then route between the eth0/1
>> combo and the eth2/3 combo.  IOS handles that with no problem.  Other

>Correct. We don't support fancy switching. Linux is a router it doesnt really
>have any pretense at switching. Measure the latency on a really good cut
>through switch (like the big 3com ones) and you'll see why. For pure switching
>the fancy dedicated hardware stuff beats us flat on latency and I guess always
>will.

Sure...hardware switches are gonna kick butt in switching...that's not
really what I was talking about....you can take a Cisco router, and tell
it to switch in all these ways...and some of these "switching" services
are labeled so because they deal with things at the link layer, but are
really only useful for routers, particularly in that group, VRRP.

To try to pull this back on topic some.  :)  I'd really like to see some
more switching services added to Linux.  VRRP would be one that would be
really useful for folks to routing on Linux.  I'd also like to see the
bridging support extended to be more flexible.  I have a really bizarre
thought that would be really cool to be able to use IMHO.  :)

For a server system (you can do largely the same with a router system,
but my use for this would be for a server system), put two nics in
it...connect each nic to seperate network switches.  Let the nics run
briding code so they participate in spanning tree.  Also "bridge" the
traffic to a loopback or "virtual" interface or so (maybe you can
already do this?  haven't gotten a good answer, don't think so though),
so you can tell daemons and such to bind to the loopback or virtual
interfaces and the system can transparently recover from a dead nic card
or cable, or switch.

I've mentioned this to several people and quite a few of them just
didn't understand what I was getting at...several others thought I was
just weird (which is quite possible, even quite likely I'd say), and a
few thought it was a neat idea.

Anyway...that's out there as a random idea for enhancement.  :)
-- 
Jeff McAdams                            Email: [EMAIL PROTECTED]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]

Reply via email to