From owner-freebsd-stable@FreeBSD.ORG Wed Aug 9 10:26:50 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 043A716A4E5 for ; Wed, 9 Aug 2006 10:26:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36DCE43D86 for ; Wed, 9 Aug 2006 10:26:40 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so247748pyc for ; Wed, 09 Aug 2006 03:26:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=kRb4w2FIfX0tbNj6whDhTGZCcoNbF+whDDfDMcA/WPHU3PuE9Z5wxFrVoPOZ4LCqcAnVvK78eJ5GOWQNr1/u8uuTsCmTSpWFAAf+IMcoRFbcZ/oi3K7L2mArJs/x13m64DE9OCfUwfGVT8UBa4tYvB/nVkJs5+acbXM8kNSRy/8= Received: by 10.35.87.8 with SMTP id p8mr1284821pyl; Wed, 09 Aug 2006 03:26:39 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 14sm1795799nzp.2006.08.09.03.26.36; Wed, 09 Aug 2006 03:26:38 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k79AR4qH015342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Aug 2006 19:27:04 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k79AQYDS015340; Wed, 9 Aug 2006 19:26:34 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 9 Aug 2006 19:26:34 +0900 From: Pyun YongHyeon To: Scott Wilson Message-ID: <20060809102634.GD12382@cdnetworks.co.kr> References: <20060808003404.GA5411@cdnetworks.co.kr> <09BFF2FA5EAB4A45B6655E151BBDD90301AB72BF@NT-IRVA-0750.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, "David \(Controller AE\) Christensen" , davidch@freebsd.org, Eric Hodel Subject: Re: RE: Re: Re: bce0: Error mapping mbuf into TX chain! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2006 10:26:50 -0000 On Wed, Aug 09, 2006 at 11:02:37AM +0200, Scott Wilson wrote: > On 8/8/06, David (Controller AE) Christensen wrote: > >> > >> Since BCE_MAX_SEGMENTS is too small I guess it will happen on highly > >> fragmented packets under heavy loads. To simulate the situation > >> you can use m_fragment(9) to fragment the frame in bce_tx_encap(). > >> With m_fragment(9), "ping -f -s 65507 x.x.x.x" may trigger it. > >> > > > >I didn't know about m_fragment before. I'll write a note to myself > >and look at how to add it to the debug path for a future driver > >revision. > > > >> Btw, I've never seen this small number of Tx DMA segments support( > >> BCE_MAX_SEGMENTS == 8) on GigE. Is this hardware limitation? > >> > > > >The real value for BCE_MAX_SEGMENTS should be 16, not 8. I chose 8 as a > >reasonable value to start with. If the number of fragments exceeds 16 > >then we would expect to see performance drop and it is probably faster > >to > >have the OS defragment the packet rather than try to perform so many > >DMAs. > > > > What I don't understand is why the driver stays locked up after it > gets into this mode. I guess that's a separate issue from the low max > segments which is triggering it in the first place? > There are several cases here. 1. Due to lack of free Tx descriptors bus_dmamap_load_mbuf(9) can fail, so loaded DMA map should be unloaded with bus_dmamap_unload(9) in order to reload it after m_defrag(9) call. 2. If m_defrag(9) fail you may want to free m_head as keeping it in queue may result in stuck condition. Since m_defrag(9) can't defragment the mbuf chain you can never send it again if you requeue the mbuf chain. 3. If the second bus_dmamap_load_mbuf(9) fail you should requeue m_head which was alreay modified with m_defrag(9). Just returning error from failure make bce(4) reuse invalud mbuf chain. As a general rule caller of m_defrag(9) should be prepared to cope with modified mbuf chains when it requeues the mbuf chains. -- Regards, Pyun YongHyeon