Re: 2nd try

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Tero" == Tero Kivinen <kivinen@iki.fi> writes:

 >> As Paul noted, it is a lot more difficult in hardware, especially
 >> at very high speeds. My experience in designing such devices
 >> convinces

 Tero> I am not hardware person, so I cannot really comment on that,
 Tero> but seeing what else they are currently doing on the hardware I
 Tero> do think it is actually very easy to do on the hardware too
 Tero> (compared to the other things they do there). One easy solution
 Tero> is to put the ARM core or similar processor inside the
 Tero> hardware, add do it partly on software.

You're missing the point.

The issue isn't just logic complexity, but logic complexity is still a
concern.  It's true that current hardware does a lot of stuff, and the
incremental logic complexity may not be all that large.

Then again, in software, fixing a bug takes a few minutes.  In
hardware, it takes at least a few weeks and possibly several months,
not to mention as much as several hundred thousand dollars.  Because
of this, hardware designers are MUCH more concerned about extraneous
complexity than software designers are.  (Arguably, software designers
could benefit from adopting some of that attitude -- the software
products would be more reliable if that were done.  But that's a
different subject...)

The other issues are things like buffering requirements, state storage
requirements, additional bandwidth demand on various buses, the need
to implement timeout mechanisms, etc.

If you need to keep more state, you have to store that somewhere.  You
may find yourself forced to switch from on-chip state storage to
off-chip storage.  That's a very expensive change, because low latency
off-chip storage access is hard to do -- especially as SRAM is
becoming more and more rare.

You may find that you need more bus bandwidth on various data paths.
If those are memory data paths to external memory, you may have to use
more expensive memory than before, or wider memory.  

Putting a CPU core in the hardware isn't a solution.  For one thing,
that's a software solution.  If the performance requirement is high
enough, a software solution doesn't do the job.  Putting software
on-chip doesn't change that very much.  The other issue is that
hooking a software engine into a state machine (hardwired logic)
fastpath is a very nontrivial exercise.  It's already non-trivial to
do things like divert IKE traffic to on-chip CPUs -- but that's far
easier than putting IPsec fast path processing partly in software.

       paul