Re: freebsd router



--- "Matthew D. Fuller"
<fullermd@xxxxxxxxxxxxxxx> 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
_______________________________________________
freebsd-isp@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-isp
To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: Changes in the network interface queueing handoff model
    ... layer output routine via ifp->if_outputwith the ifnet pointer, packet, ... as ARP), and hands off to the ifnet driver via a call to IFQ_HANDOFF, ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-arch)
  • Re: Changes in the network interface queueing handoff model
    ... bouncing around for some time is a restructuring of the network interface packet transmission API to reduce the number of locking operations and allow network device drivers increased control of the queueing behavior. ... to "start" output by the driver. ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-net)
  • Re: Changes in the network interface queueing handoff model
    ... bouncing around for some time is a restructuring of the network interface packet transmission API to reduce the number of locking operations and allow network device drivers increased control of the queueing behavior. ... to "start" output by the driver. ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-arch)
  • Changes in the network interface queueing handoff model
    ... 5BOne of the ideas that I, Scott Long, and a few others have been bouncing around for some time is a restructuring of the network interface packet transmission API to reduce the number of locking operations and allow network device drivers increased control of the queueing behavior. ... to "start" output by the driver. ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-arch)
  • Changes in the network interface queueing handoff model
    ... 5BOne of the ideas that I, Scott Long, and a few others have been bouncing around for some time is a restructuring of the network interface packet transmission API to reduce the number of locking operations and allow network device drivers increased control of the queueing behavior. ... to "start" output by the driver. ... encapsulation and wrapping, and notifies the hardware. ... The ifnet layer send queue is becoming decreasingly useful over time. ...
    (freebsd-net)