RE: iSCSI CRC: A CRC-checking example

[Robert Snively <rsnively@Brocade.COM>]

I've only been following this discussion loosely, but
it seems to me that the Ethernet byte and bit ordering
is dictated by a series of hardware choices made long ago.
On the other hand, the iSCSI byte and bit ordering is
taken from (or placed in) memory in a contiguous
byte/bit stream which is basically big-endian, regardless
of how it happens to be manipulated by the attached
processor.

I would imagine that we would choose the bit and byte
ordering convenient to the DMAing of the data into and
from memory.  I believe that most of these functions will
wind up in hardware that delivers a big-endian byte stream
to a TCP processor.  

So I would have expected that we would avoid any choice that
makes that less convenient.  The Ethernet approach to those
bytes would strike me as being the second-least convenient
approach.  Clearly, throwing hardware at this could correct
for that inconvenience, but it seems to me that any
optimizations we make should focus on what we want to do, not
what Ethernet did.

Bob

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Thursday, August 23, 2001 3:31 PM
> To: sanjay_goyal@ivivity.com; ips@ece.cmu.edu
> Subject: RE: iSCSI CRC: A CRC-checking example
> 
> 
> From a practical standpoint, using the same implementation framework
> (for lack of a better word) as Ethernet reduces the opportunity
> to get this wrong - a designer who's done an Ethernet CRC does
> the same thing with the new CRC polynomial and the result works.
> 
> If this aspect of CRC usage "ain't broke", I would think
> that "don't fix it" is the preferred course of action ;-).
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Douglas Otis [mailto:dotis@sanlight.net]
> > Sent: Thursday, August 23, 2001 5:43 PM
> > To: Sanjay Goyal; 'CAVANNA,VICENTE V (A-Roseville,ex1)'
> > Cc: ips@ece.cmu.edu
> > Subject: RE: iSCSI CRC: A CRC-checking example
> > 
> > 
> > Sanjay,
> > 
> > In short, the reflected table is likely to require fewer 
> instructions to
> > implement a lookup than a non-reflected table.  Secondly, 
> if the processor
> > is Little Endian, then the result is already in network 
> order without byte
> > swapping.  Obviously this last point only helps if you are 
> using a Little
> > Endian processor but this happens only once per packet 
> whereas the lookup
> > may happen every byte.  Third, the inverted store improves 
> the sensitivity
> > to the packet length.  All these Ethernet techniques seems 
> to be good
> > things.  One difference however is the polynomial.
> > 
> > Doug
> > 
> > > The last line says
> > >  "but I suppose it is advantageous to do things the ethernet way."
> > > May I know in what ways it would be advantageous.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
>