In message <41AF62A1.3020500@netbsd.ro>,
Mihai CHELARU writes
>> I use broadcom pci-x cards (bge) BCM5702X.

If it were me, I'd try 5703s (or fewer 5704s) instead.
Or posssibly the PCIe cards, if you're using --current. 

>> For what I see there is a problem with IRQ limit in NetBSD. On other 
>> machine I have a pgsql that sometimes goes also at around 30k IRQs/sec 

What's an pgsql when it's at home?

>> and also suddenly reboots (don't ask me what that pgsql is doing there, 
>> some strange half-page select that is driving that multi-proc machine 
>> into nuts - 30k tlb shootdowns IRQs).
>> 
>
>Btw, is it normal to act like this when it's bombarded with packets ?

[[ trace showing irregular returns from sleep() under high packet load]]


If you're trying to handle close to 1 frame per interrupt, I dont find
it particularly surprising.  Both the NIC driver interrupt-handler and
the lower levels of the networking stack (ethernet demux up to
ipintrq) are handled at high priority. Under very heavy packet-arrival
load, those can quite easily block out user-level code, or even
in-kernel callout queues.

I suggest you try using sysctl to increase net.inet.ip.ifq.maxlen from
its default value of 50 to 256 or threabouts, then try tweaking the
undocumented(?) sysctl hw.bge.rx_lvl to values between 3 and 5.  If at
all possible do the tweaking from a local serial line, not a network
connection.

You haven't told us anything about the packet traffic you're
generating.  If you're flooding a software router with tinygrams, you
should expect poor performance compared to a hardware-based switch or
router (and you should also allocate even larger values for
net.inet.ip.ifq.maxlen).  If you send mostly large packets, NetBSD on
(for example) newish server-class i386 hardware should handily keep up
with a gigabit wire speed.

Crashees of any kind are abnormal; if you really see a crash, please
send a PR, including the kinds of details we've been asking for here. 
The contents of /var/run/dmesg.boot would also be helpful.