> You just told us earlier in the thread that NetWare does direct zero
> copy DMA but thats only half the story obviously. Up until the era of
> Gigabit Ethernet cards there were almost no PCI cards available that
> would do scatter/gather so obviously netware wasn't doing zero copy
Netware does zero copy from its caches because
1. IPX has no checksum except the link layer by default. Its one reason
there used to be file corruption problems with IPX over wans - because
the wan links didnt tend to propogate the ethernet checksum. Similarly
for poorer bridges.
2. IPX has no concept of fragmentation. So you can deal with very simple
3. You are focused on x86, so you can make crass assumptions about things
like cache coherency.
Now Netware (especially 3.x - 4.x is a bit slower) could turn around frames very
fast if they hit its network serving fast paths. In fact they had to. Netware
didnt have windowing until 3.11 where burst mode was added, even that isnt
really windowing but a sort of multi-packet transfer. About that time it also
acquired packet signing (which lost you the zero copy as nobody to my knowledge
built drivers that could do netware packet signing in hardware).
If you are building a pure IPX server then Jeff is describing a sane setup.
The fixed headers on NCP messages mean you can demux the packet, realise its
a read/write and do the cache operation in the IRQ handler, and if you get a
read cache hit or a blank slot in the cache on a write add the data block to the
The I/O size was typically 512-1024 bytes so you couldnt do page flipping, but
since these were all trusted paths nobody I suspect worried to much.
You could build the same architecture with NFS and a very smart card. The acenic
has firmware powerful enough to do the require RPC parsing.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:14 EST