Subject: Re: ISA used in TCP/IP/UDP

From: "Narsimharao Nagampalli" <[email-masked]>
Date: Mon, 19 Jun 2000 23:22:18 -0600

Also other areas to look into would be encryption for IPSec and Compression. If we have hardware support for encryption, it would be good.

-Narsi

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 20 Jun 2000 12:28:54 -0600 (MDT)

> From: Joe Touch <[email-masked]>

> ...
> >     Checksum instructions would be supported by several registers:
> > 
> >         Accumulator (the running checksum total)
> >
> >         Checksum offset (where in the "packet" to ignore the data since
> >         the real checksum is stored there).
>
> A simpler solution would be "ones complement add" - a little more than
> add with carry (i.e., there's no carry, it just gets folded in).
> However, all that would save is one instruction each time the checksum
> is read, since intermediate carries can pipelined in.

I don't see the utility of a 1's complement add, if only because its
necessarily fixed width would likely be wrong in many situations.
(yes, the checksum itself is 16 bits wide, but doesn't everyone compute
it in bulk at least 32 bits wide?)

My prejudice is also to checksum with fly-by-DMA.  However, with today's
infinitely fast CPU's (compared to memory) it's not clear what DMA means
or that making your DMA machinery uniquely fancy is the right choice. 
If your DMA engine is some kind of CPU or DSP core, you would want
instructions that don't make the TCP checksum painful, but that's no
more than a carry bit.

If you don't have a carry bit, as is the case in some major RISC
instruction sets, computing the TCP checksum requires twice as many
CPU instructions as it would otherwise for a given width.

> > 5)  Built-in "mbuf"s?  I.e. the processor understands a specific scheme
> >     of chaining buffers to create packets, thus can more efficiently
> >     poke around in a packet for you, rather then your code having to
> >     always do it by hand.
>
> Assumes mbufs. There are versions of TCP that don't rely on that
> structure, and the structure and especially the order of its components
> can be OS and even compiler-specific. 

Some of us have experienced such joys in a single release of a single
operating system (or at least single source tree) built with a single
(cross) compiler.  As 64-bit architectures finally become common and then
when less simplistic choices than long=int=pointer=64-bits are common,
many of us might have such joys.

Mbufs themselves are not hard.  All of the variations I've seen have been
designed to work well with existing simple instructions.
That's why for the classic flavors, there are C macros that expand to
very few instructions for the common operations.
The expensive parts of dealing with mbufs could not be put into reasonable
instructions.  For example, you really don't want single instructions to
fiddle with virtual memory machinery for mbufs.

Special instructions to understand mbufs sound too much like classic CISC
mistakes.  (One of my favorite CISC instructions was the CDC 3000's evaluate-
polynomical.)  It would be nice to think that the lessons learned during
the RISC revolution about gratuitous, because-it-might-be-nice instruction
set geegaws have not been forgotten.
Actually, that sour observation applies to the original question.

Vernon Schryver    [email-masked]