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

From: Patrick Klos <[email-masked]>
Date: Tue, 20 Jun 2000 13:36:21 -0400

>> Sure, if you have DMA.  A DMA controller that could compute a running
>> checksum would be cool.
>
>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.

Well, I expect (most of) the rest of the world hasn't seen this 
implementation.  Nor am I aware of any processor (i.e. single CPU) that 
has integrated such a feature into it's core.

>> 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).
>
>Given typical processor pipelines, the arithmetic 'carry-add' is masked
>by the bubble generated by the data move anyway.

You appear to be missing the point - the original question asked was "what
instructions could be added to a processor to make coding TCP/IP stacks
more efficient" (if I paraphrased it correctly?).  Maybe this person 
wants to build a new lightweight processor with similar efficiency to
today's complex processors, and target network devices specifically?

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

It could make it easier to have code that says "give me bytes 20 and 21
of this packet" without the code having to walk the mbufs itself.  It
would make it easier to extract data from the packet arbitrarily.

You make it sound as if you don't think there are any possible enhancements
that could be made to a processor to optimize TCP/IP stack implementation?
Maybe the processors you use are not practical for the person who started
this thread??
============================================================================
    Patrick Klos                           Email: [email-masked]
    Klos Technologies, Inc.                Web:   http://www.klos.com/
============================================================================

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Jun 2000 11:57:40 -0700

> has integrated such a feature into it's core.

DMAs have it, typically ones developed for NICs. If you're DMAing data
more than once, you have other places to optimize.

> today's complex processors, and target network devices specifically?

What I'm saying is that computation can be overlapped with data moves
sufficiently that having a separate instruction doesn't make it run any
faster. And (as below) that most of the problems are implementation
related, not due to lack of processor capability.

> >> >> 5)  Built-in "mbuf"s?  I.e. the processor understands a specific scheme
...
> would make it easier to extract data from the packet arbitrarily.

If those bytes aren't simple offsets from a single pointer, then you
have other problems.

> that could be made to a processor to optimize TCP/IP stack implementation?

I think most of the issues of inefficiency are related to implementation
specifics, not the lack of necessary instructions. Just one opinion,
though.

Joe