RE: IPS Issues document

[julian_satran@il.ibm.com]

You are right. My only concern was that the "reducing the CPU load" has to
be clearly qualified as having memory load as a target and as such being
inevitable. CPU load in the sense of processor load (and that is what it
sounds like) will raise a lot of alarms and will recall past failures (the
nightmare of maintaining 2 protocol stacks by software or system providers
for off-load adapters and plain vanilla adapters and the fact that in later
machines the load dissipated!).

Regards,
Julo



"Bradley, Mark" <mark_bradley@btc.adaptec.com> on 15/03/2000 21:30:52

Please respond to "Bradley, Mark" <mark_bradley@btc.adaptec.com>

To:   "'julian_satran@il.ibm.com'"
      <julian_satran%ibmil.RSCS@STUTVM1.DE.IBM.COM>, Zachary Amsden
      <zamsden@cthulhu.engr.sgi.com>
cc:   "Bradley, Mark" <mark_bradley@btc.adaptec.com>, ips@ece.cmu.edu (bcc:
      Julian Satran/Haifa/IBM)
Subject:  RE: IPS Issues document




This is sort of an interesting thread.  It sound like the goals
covered so far are:
1)Reduce CPU utilization
2)Minimize copies
3)Acheive low latency
4)Avoid hardware obsolescence/bottlenecking

(...along with, as previously stated of course, using IP as the
transport).  What approaches can meet the above?  BTW, this sounds
like a lot of what was in the Framework draft that was sent out.
  --  markb

> -----Original Message-----
> From: julian_satran@il.ibm.com [mailto:julian_satran@il.ibm.com]
> Sent: Tuesday, March 14, 2000 11:14 PM
> To: Zachary Amsden
> Cc: Bradley, Mark; ips@ece.cmu.edu
> Subject: Re: IPS Issues document
>
>
>
>
> I would like to clarify my comment. I am not contesting the
> fact that CPU
> will get saturated.
> My concern is that CPU load decrease does not justify
> specialized silicon
> for protocol processing
> (as it gets soon out-dated like the 186 NICS) and you have
> the nightmare of
> supporting 2 protocol stacks.  Memory load on the other hand can't be
> solved any other way than by off-loading and reducing copies
> to a minimum.
>
> Regards,
> Julo
>
> Zachary Amsden <zamsden@cthulhu.engr.sgi.com> on 14/03/2000 20:53:41
>
> Please respond to Zachary Amsden <zamsden@cthulhu.engr.sgi.com>
>
> To:   "Bradley, Mark" <mark_bradley@btc.adaptec.com>
> cc:   ips@ece.cmu.edu (bcc: Julian Satran/Haifa/IBM)
> Subject:  Re: IPS Issues document
>
>
>
>
> > Julo, good comments.  My observation is that faster CPU's
> > don't solve the problem.  We have been getting faster CPU's
> > since the beginning of time and the only semi-constant is
> > that we find that the CPU continues to get utilized.  Large
> > MP machines are bought because the processing horsepower
> > is needed for some appl.(s) that consumes it.  Therefore they
> > don't have 'extra' cycles to spare.  Most generic OS's
> > don't support dedicating a processor to specific jobs,
> > either.  Putting a small processor someplace (an IOP) else
> > typically doesn't scale as system processing speed increases,
> > so those often become bottle-necks after some time.  Remember
> > those 186-based networking cards?
> >
> > Bottom line is that % CPU utilization has been, is, and will
> > continue to be an important consideration for some time.
> > It seems we never have enough CPU, memory or disk.  We seem
> > always to find ways to use it up.  (I remember years ago
> > thinking "Wow!  A megabyte on a single platter!  We'll have
> > enough disk space to last 3 or 4 years!!!"  I also recall
> > thinking that a 68020 made for a pretty fast workstation.
> > Now I complain that my dual 450 MHz PC with 128 MB of memory
> > is not fast enough to be a decent office machine next year...
> > :{)   )
>
> I agree completely with that - protocol processing and
> interrupt time alone
> for a 1 Gbps connection can easily saturate a single CPU, even with
> interrupt
> coalescing and many other tricks.  When you move to a 10 Gbps
> connection,
> you
> can't just add more CPUs to deal with the problem, because of
> both cost and
> the fact that you don't get a perfect speedup as you add more
> CPUs.  This
> makes techniques that reduce CPU and bus utilization more valuable as
> network
> speeds increase.
>
> --
> Zachary Amsden  zamsden@engr.sgi.com  3-6919  31-2-510  Core Protocols
>
>
>
>
>