freebsd router

[Danial Thom]

--- "Matthew D. Fuller"
<fullermd at over-yonder.net> wrote:

> On Wed, Jan 11, 2006 at 06:41:37AM -0800 I
> heard the voice of
> Danial Thom, and lo! it spake thus:
> > 
> > No, that's wrong. Firstly, you CAN do things
> in parallel, but when
> > you chop up the "tasks" in routing you don't
> gain anything, in fact
> > you lose, because it is best done as a single
> task.
> 
> No, because you can route MULTIPLE PACKETS AT
> ONE TIME.  Only the most
> trivial and uninteresting routing tasks move
> packets one at a time
> from one interface to another.  Why should my
> packet coming in em1 and
> going out em3 have to wait until you're done
> with your packet coming
> in em0 and going out em2?  MP is a distinct
> advantage.

because you don't know that the packet on em0 is
going out em1 until after you've processed it so
far that you might as well just send it. And you
don't have different instances of driver code to
access each em port, so you can't do a lot of
things in parallel. You're basically limited in
an MP environment to sucking the packet out of
the ring and throwing it into a queue. In a UP
environment you can process the queue right away;
in MP you might have the other processor suck it
out of the queue, but it can't do it until its
there, and you can't really process another
packet until  you're done with that one, so how
quickly you throw the next one in doesn't really
matter.

Again, you're being idealistic rather than
understanding how things really work.  What
you're referring to is done in high end routers
with intelligent cards than can offload the
routing tasks if the entire transaction is on
that card. But it doesn't apply to a general
purpose MP OS, or more importantly how freebsd
works.
> 
> 
> > I can promise you that 7.0 is far from
> "probably" anything. They are
> > a long way off. Maybe come up with some real
> benchmarks (like the
> > one I suggested in my other post) so you
> won't be bamboozled by the
> > hype so easily.
> 
> Ooh, darn!  All that hype bamboozled its way
> sideways into my tear
> ducts, and now I can't see straight!  Or maybe
> it's just 'cuz I
> actually read -net and -cvs...
> 
>     This work has been shown to increase
> fast-forwarding from ~570
>     kpps to ~750 kpps (note that the same NIC
> hardware seems unable to
>     transmit more than 800 kpps, so this
> increase appears to be
>     limited almost solely by the hardware). 
> Gains have been shown in
>     other workloads, ranging from better
> performance to elimination of
>     over-saturation livelocks.

I can pass a million pps on freebsd 4.x, so
perhaps your *hardware limit* has more to do with
you or them not understanding the test?

Funny that they don't mention packet loss, maybe
they forgot to look? 5.x alleviates livelock by
dumping buckets of packets. In my view, dumping
packets is not acceptable. If you can pass more
packets but you drop a ton of them in the process
then you haven't really achieved anything.

I'm sorry, but you really don't understand what
you're talking about, and yes, you *have been*
bamboozled. Do some tests yourself, because until
you do, you don't *know* anything.

DT

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com