Claudio Jeker wrote:
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.

I know, honestly I was dreaming a bit here out of frustrations.

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.

Thanks. At a minimum, it's something to look carefully about.

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

Many thanks for the more detailed informations!

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.

I didn't expect that to be easy or fix in a snap, or having anyone working on it. I really wanted to know the path and logic of it for my own knowledge and understanding.

On a side note however, would a mini sponsor hacketon specific to this subject be of any interest to anyone? Just asking, no flame please.

Thanks again.

Daniel

Reply via email to