dummynet dropping too many packets
rihad
rihad at mail.ru
Thu Oct 15 16:15:39 UTC 2009
Robert Watson wrote:
>
> 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.
>
Thanks, but as I haven't ever played with DTrace before, but for the
sake of FreeBSD and for our own sake, could you or someone else provide
me with a step-by-step tutorial on how to do exactly that? I hear
GENERIC kernel lacks DTrace support, so I must rebuild it with
KDTRACE_HOOKS enabled? Does such support hurt normal performance while
dtrace is not being used? I'm a bit afraid of experimenting on a
production box belonging to a business I do not own.
Meanwhile today I've emailed David Christensen <davidch at broadcom.com>
mentioned in the bce source code, asking him if it's ok to change that
value.
> 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
>
>
More information about the freebsd-net
mailing list