RE: iSCSI CRC: A CRC-checking example

["Douglas Otis" <dotis@sanlight.net>]

Bob,

If there is a hardware implementation at the memory bus level, then the
gates assembled to provide a workable solution will not be greatly affected
by the bit order except of course to accommodate whatever bit order was
defined.  In hardware, the polynomial will play a greater role than the bit
order as this becomes a parallel conversion.  It may mean tightening the
straps on the thinking cap when assigning terms.

Doug

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