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

From: Patrick Klos <[email-masked]>
Date: Tue, 20 Jun 2000 12:28:04 -0400

>> >> What are the typical instruction set extension on
>> >> a CPU so that implementing TCP/IP/UDP network stacks
>> >> would be more efficient?
>> >
>> >add-with-carry is a nice instruction; it makes it somewhat faster to do IP
>> >checksums...
>> 
>> I got the impression the original poster was asking for real extensions -
>> not items that are already available on most processors.  Maybe I'm wrong.
>> 
>> If I were building a processor with TCP/UDP/IP specific extensions, I'd
>> probably add some of the following:
>> 
>> 1)  Checksum register/instructions:
>> 
>>         Compute standard checksum on a range of bytes (useful to
>>         check IP header checksum).
>> 
>>         Copy and compute standard checksum (useful when collecting
>>         pieces of a packet before sending it).
>
>Better if done by a DMA.

Sure, if you have DMA.  A DMA controller that could compute a running
checksum would be cool.

>>         Initialize checksum (used to extract pseudo-header and compute
>>         checksum on it).
>> 
>>     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.

Ones complement add is already very easy to do with existing processors.
I'm talking about instructions that automatically add to a checksum as
a packet's contents are being copied (since they very often are unless
you have scatter-gather hardware to collect up the pieces of a packet,
in which case your other suggestion would work out).
 
>> 2)  Keep in mind similar extensions to support the possibility of
>>     IPv6.
>
>Or lack of similar extensions. I.e., in IPv6, checksum of a range of
>bytes becomes much less useful for header manipulations; checksum of
>large quantities of data should be combined with DMA where possible.
>
>> 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. 

Yes, it assumes mbufs.  It also assumes that a TCP stack for this special
processor would be optimized for this processor.  Most TCP stacks have
some notion similar to mbufs to help minimize copying packet contents
all over the place.  My suggestion is just to capitalize on a version of
that notion to speed up access to packet contents when necessary.
============================================================================
    Patrick Klos                           Email: [email-masked]
    Klos Technologies, Inc.                Web:   http://www.klos.com/
============================================================================

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Jun 2000 10:09:27 -0700

> Sure, if you have DMA.  A DMA controller that could compute a running

We implemented one here at ISI in 1996, and it was based on emulating in
multiple chips what other DMA designers had already done. Not so much
cool, as cold.

> in which case your other suggestion would work out).

Given typical processor pipelines, the arithmetic 'carry-add' is masked
by the bubble generated by the data move anyway.

> that notion to speed up access to packet contents when necessary.

Lisp processors tried this before, and it works. You can build deep data
structure knowledge into the processor if you want. While this is useful
for the scatter-gather DMA, why is it useful for a processor to be able
to do?

(and if I already have a scatter-gather DMA, and I already optimize my
kernel data structure to use the DMA's notation, how much do I win by
doing this too?)

Joe