On Tue, Feb 27, 2007 at 04:10:05AM -0500, Daniel Ouellet wrote:
> Henning Brauer wrote:
> >use better network cards, or start hacking :)
>
> For the card, I sure know, but it's stat to be pretty darn expensive to
> test what's on the market and new one as well. I fell sometime it would
> be less expensive to have a custom one design using FPGA or something!
Hah. Developing an ueberfast FPGA network card needs at least a manyear of
work and that's a very optimistic prognosis. I guess buying two three
motherbords and a bunch of GigE cards (two or three cards for em, bge,
bnx, sk, msk) will give you a good testbed for figuring out what's best.
>
> As for hacking, I started, but not on that yet anyway.
>
> Thanks for your feedback.
>
> And if that wasn't asking to much, it would be very interesting to know
> what tweak you do to increase the limits some.
>
> One way or an other, will find a way to increase more.
>
There is no mystical knob to push and the network stack enables the
afterburner. Sure there is net.inet.ip.ifq.maxlen that needs to be bumped
up on high speed routers (check against net.inet.ip.ifq.drops to find the
sweet spot) but that's about it.
The normal routing path is about this:
- interface TX interrup
- packet handling in the driver
- netisr queuing
- ip_input()
pf_test()
- ip_forward()
route lookup
- ip_output()
pf_test()
- interface queuing
altq magic
- calling interface start function
- enqueue into the DMA ring
Now somebody needs to sit down and correctly profile what's going on and
then using that data identify the bottlenecks and find solutions to clear
these constrictions. This needs a lot of time, experience and quite some
equipment.
--
:wq Claudio
