Eugene Grosbein wrote:
On Tue, Oct 06, 2009 at 08:28:35PM +0500, rihad wrote:
I don't think net.inet.ip.intr_queue_maxlen is relevant to this problem,
as net.inet.ip.intr_queue_drops is normally zero or very close to it at
all times.
When net.isr.direct is 1, this queue is used very seldom.
Would you change it to 0, it will be used extensively.
Ah, ok, thanks. I'll try that tomorrow.
But still...
Try setting net.isr.direct to 0 and make large net.inet.ip.intr_queue_maxlen.
This way, one of your cores may run bce's thread, enqueue incoming
packets and return to work immediately. The rest of processing may be
performed by another kernel thread, hopefully using another core.
Just to see if this changes anything. top -S should help here too.
It isn't the incoming bce0 losing packets, but rather the outgoing bce1,
which is almost idle interrupt-wise:
29 root 1 -68 - 0K 16K CPU1 1 223:39 55.86%
irq256: bce0
31 root 1 -68 - 0K 16K WAIT 2 19:27 4.10%
irq257: bce1
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
