[e2e] Question about fast path / slow path and IPv6

[Cannara]

Sam, look at the Intel IXP2400/2800, the Vitesse IQ2200, the various IBM,
Motorola network processors, and even things like Astute Networks' processor. 
Yes, many silicon startups failed, because, as with .coms, there were too
many, but some have completed excellent products and some successful vendors
(Intel, IBM, Motorola...) aren't even startups at all!

These run in Cisco & other gear now, and have been handling a full 4Gb/s of
Enet pkts per chip, doing IPv4 lookups, etc. for a couple of years now.  The
10Gb/s NPUs are delayed, due to market, but still being done.  In any case,
unlike our workstations, they dedicate upwards of 4 individual, independent
processors to handling incoming pkts from several different physical
interfaces.  Some applications in security actually do so much pkt processing,
they chain several NPUs in series -- Intruvert uses 4, iPolicy has up to 13,
etc.  Your SGI won't match that.

In fact, everyone writing about networking and protocols these days should
study what NPUs exist and what their architects have designed into them --
some were designed in university research, some as a result of corporate
research, or a combination, but all with regard to how best to handle the
things routers & switches have to do all day.

Now, they all have a system coprocessor for all the configuration and
management (IOS, SNMP...), something like a MIPS running VxWorks, etc.  If the
firmware designer has decided that anything goes on slow path, it goes onto an
NPU queue that the coprocessor sees.  How fast the coprocessor deals with
theis queue and requeues its results depends entirely on that part of the
system and its software, which is typically compiled from C/C++ and running at
a lower clock rate than the NPUs.  If you want an SGI as a slow path machine,
great.  If you don't need SNMP requests handled at OC768 line speed, then
maybe not, but in any case, the slow path will be slower than what is provided
by the true multiprocessor NPU associated with it in the system.

In any case, and this is important, there are no standards to determine what
pkts go onto queues serviced by the "slow path".  This is unfortunate, in the
same sense that there's no source & version control in the Internet in
general, but most of the folks writing the code are well outside the Internet
fold anyway.  The saving grace may be that vendors do license their
nonproprietary portions of system code from respectable network-software
vendors, like Level7, etc.

Alex

Sam Manthorpe wrote:
> 
> Is there really any significant difference between slow and fast
> paths these days?  Do people still implement 'fast' path and is it
> still considered worthwile to do so?  i.e. my desktop's slow path
> will take on your fast path:-)   Seems to me that the silicon start-up
> companies tried to take refuge in TCP a few years ago and that
> just didn't pan out.
> 
> > > > Is IP fast path / slow path processing (for packets carrying
> > > > IP options) similar for IPv4 and IPv6 in most current routers?
> 
> I don't know about router companies, but if you are routing
> through any IPv6 version of IRIX on an SGI machine the
> overhead is identical for v4 or v6, and if you have
> one of the more expensive varieties the machine
> will be able to achieve throughputs in the order of
> 10GB/s linespeed, using the obligatory slow path.
> 
> -- Sam
> 
> > >
> > > The answer depends *entirely* on which hardware one is talking about.  > >
> > > Some products can handle IP packets (with or without options)
> > > at wire speed (usually because this is done in hardware).
> > >
> > > Other products cannot do so -- in which case only packets without
> > > options are "fast path" and packets with options are "slow path".
> > > This last case includes all (or nearly all) routers that use
> > > CPU-based packet forwarding.
> > >
> > > "Most" could mean the the largest-volume deployments of a single
> > > router model, in which case ask your nearest vendor C salesperson
> > > what they do.  I'm assuming "most" means "most vendors" in the
> > > quoted text above.
> > >
> > > Ran
> > > rja at extremenetworks.com
> >
> >
> >