[lkml]   [2000]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: zero-copy TCP


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

> 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.


> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> Please read the FAQ at
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:3.214 / U:1.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site