Messages in this thread | | | Date | Sat, 02 Sep 2000 16:45:46 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: zero-copy TCP |
| |
Alan,
I'm impressed!!! You do understand NetWare architecture very well. Some corrections though.
Alan Cox wrote: > > > 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 > > either. > > 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.
There is a checksum field in IPX, but it always contains xFFFF. Drew always assumed upper layer programs, like NDS, would do heir own checksumming for integrity, and in fact, this is how it's instrumented in NetWare.
> > 2. IPX has no concept of fragmentation. So you can deal with very simple > operations
IPX does do fragmentation, it's just that Linux's doesn't. The fragmentation is handled at the ECB layer and the drivers never see it. IPX headers and responses, in fact, the entire **REAL** IPX interface is completely built around this concept internal to NetWare, and everything is treated like a fragment list.
> > 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.
No it is not. This is where you guys got it wrong. Packet Burst is an **NCP** is does not reside in IPX at all. That's why the implementation in Linux is busted. The window size is variable and keys off of HOW MANY FREE ECBS ARE IN THE SYSTEM. It doe not belong in the IPX/SPX stack, but inside of MARS-NWE proper.
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 > cache.
Correct. This is why it's so damn fast.
> > 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.
576 bytes. Drew came up with this because he did not want to fuck around with handling cases of re-assembly of packets that would cross routers of different frame size. Oddly enough, it's fastr to use smaller packets ith IPX that larger (though this woud seem counterintutive).
> > 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.
Good idea.
Jeff
> > Alan > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |