On Thu, 15 Oct 2009, rihad wrote:
meaning that USABLE_TX_BD is expected to be smaller than MAX_TX_BD. What if
MAX_TX_BD is itself way smaller than 1024, which I'll eventually set
ifq_drv_maxlen to? Can a driver guru please comment on this? 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, and order a darn expensive Intel 10 Gige card, but it
won't hurt to ask beforehand.
Depending on your tolerance for experimentalism, it might be useful to use
DTrace to confirm our interpretation of events. The way I'd do this is to add
an instrumentation point (using SDT) to the points where the statistics of
interest are getting bumped, and then profile using DTrace for a bit with the
following script:
the:event:name:here
{
@data[stack()] = count();
}
Let it run for 30-60 seconds, and you should get back a report on the
frequency of each possible code path to generate the statistic. We believe
that the drops are a result of bursts of packets from dummynet, in which case
the dominant trace should be to dummynet timers. It would be interesting to
see if that's right.
If I get a chance, I'll spend a few minutes today looking at a more general
patch to make it easy to use DTrace with network stack error points.
Robert
_______________________________________________
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"
