From owner-freebsd-net@FreeBSD.ORG  Thu Oct 15 12:36:49 2009
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 86D221065670
	for <freebsd-net@freebsd.org>; Thu, 15 Oct 2009 12:36:49 +0000 (UTC)
	(envelope-from rwatson@FreeBSD.org)
Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 627EE8FC18
	for <freebsd-net@freebsd.org>; Thu, 15 Oct 2009 12:36:49 +0000 (UTC)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41])
	by cyrus.watson.org (Postfix) with ESMTPS id EAF6846B2D;
	Thu, 15 Oct 2009 08:36:48 -0400 (EDT)
Date: Thu, 15 Oct 2009 13:36:48 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
X-X-Sender: robert@fledge.watson.org
To: rihad <rihad@mail.ru>
In-Reply-To: <4AD6D99E.10805@mail.ru>
Message-ID: <alpine.BSF.2.00.0910151332080.94713@fledge.watson.org>
References: <4AD6D99E.10805@mail.ru>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: freebsd-net@freebsd.org
Subject: Re: dummynet dropping too many packets
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2009 12:36:49 -0000


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