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

quoted text
>> 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.

quoted text
> 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!

quoted text
> 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