From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 07:09:09 2010 Return-Path: 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 CE3891065695 for ; Mon, 15 Nov 2010 07:09:09 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id A4CBC8FC15 for ; Mon, 15 Nov 2010 07:09:09 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id oAF7Ac3f023039; Sun, 14 Nov 2010 23:10:38 -0800 (PST) (envelope-from mahan@mahan.org) Message-ID: <4CE0DC93.1070204@mahan.org> Date: Sun, 14 Nov 2010 23:09:07 -0800 From: Patrick Mahan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Jack Vogel References: <4CDF09BD.3050509@mahan.org> <4CDF4AE6.5070507@mahan.org> <4CDF5D24.5000801@sentex.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: Debugging em(4) driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 07:09:09 -0000 On 11/13/2010 09:08 PM, Jack Vogel wrote: > The stats changed quite a bit for 8.1, they are much more informative now, > and they can be collected from anywhere not just the console. > > I don't quite understand what you are trying to do, debug an em problem > or just debug a problematic situation by using em?? > > Mike is right, the driver in HEAD has some significant fixes and would be > the best thing to use. > We were noticing a lot of slow down on the link between the two HPs. I would start a normal ping between the two boxes, start the traffic generation and I would see the ping's completely stop, even though I could see I was still getting traffic on the em(4) interface. Once the pings stop, we eventually started seeing failure in our network app that needs to query it's peer. It would timeout trying to send a notification message to it's peer. I wanted to see if there was a failure somewhere in the interface layer such as dropping packets. Plus I wanted to ensure the ringbuffer em(4) was using wasn't starving for packets. Patrick