Date: Thu, 15 Oct 2009 13:36:48 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: rihad <rihad@mail.ru> Cc: freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets Message-ID: <alpine.BSF.2.00.0910151332080.94713@fledge.watson.org> In-Reply-To: <4AD6D99E.10805@mail.ru> References: <4AD6D99E.10805@mail.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0910151332080.94713>