rihad wrote:
For now we've mostly disabled dummynet and the drops have stopped,
thanks to some extra unused bandwidth we have. But this isn't a real
solution, of course, so this weekend I'm going to try the suggestion
made by Robert Watson:
> In the driver init code in if_bce, the following code appears:
>
> ifp->if_snd.ifq_drv_maxlen = USABLE_TX_BD;
> IFQ_SET_MAXLEN(&ifp->if_snd, ifp->if_snd.ifq_drv_maxlen);
> IFQ_SET_READY(&ifp->if_snd);
>
> Which evaluates to a architecture-specific value due to varying
pagesize. You might just try forcing it to 1024.
In a few days I'm going to try it anyway, and if the system locks up
I'll just revert back to the original code >
TIA
Just rebooted with the "ifp->if_snd.ifq_drv_maxlen = 1024;" kernel, all
ok so far. There's currenlty only 1000 or so entries in the ipfw table
and around 350-400 net mbps load, so I'll wait a few hours for the
numbers to grow to >2000 and 460-480 respectively and see if the drops
still occur.
P.S.: BTW, there's a small admin-type inconsistency in FreeBSD 7.1:
/etc/rc.firewall gets executed before values set by /etc/sysctl.conf are
in effect, so "queue 2000" isn't allowed in ipfw pipe rules (as
net.inet.ip.dummynet.pipe_slot_limit is only 100 by default), so the
rules are silently failing without any trace in the log files - I only
saw the errors at the console.
_______________________________________________
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"
