From owner-freebsd-current@FreeBSD.ORG Thu Dec 20 02:06:27 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D3C616A417 for ; Thu, 20 Dec 2007 02:06:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id E108A13C467 for ; Thu, 20 Dec 2007 02:06:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so5097342waf.3 for ; Wed, 19 Dec 2007 18:06:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=7MMA9D40DPss+i3qPixKcPmmPmluCvecVvViR2Sv24Y=; b=mL+pPjZHe+d2gvlZfhaY+9l21Ozwjz1Heteg4lpLVxXGF4ndmj6gPtac7VQ5iyGaFI4bQCjV7gufikXn0U5AUbSIUetmSMZpNdEsYD0a30vBfb1rk5CS2zVMCY5ftSZTjlbIe2qJcjBLHfACqi8mlIC2KlwjpKRoauEXLbgjBCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=ZrOJg7unPRnAPySXnCR4Q7gguPq1huEtHdFGcZ7E8meZ50/yqT6g1cLB8SZXFlf1Idv3QDi1lpboMcqy+Xo7DTPWU7Vz7GCSPS6o5ZSib4/udM63lqMHwNLA5C9oV3WeKc4G+81muP/Y1u4DaGwYDz0MlXT9nbln3sZ1PgBI53s= Received: by 10.114.135.1 with SMTP id i1mr6284875wad.88.1198116386386; Wed, 19 Dec 2007 18:06:26 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id n32sm11021427wag.2007.12.19.18.06.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2007 18:06:24 -0800 (PST) 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 lBK263WH001800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 11:06:03 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id lBK263UD001799; Thu, 20 Dec 2007 11:06:03 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 20 Dec 2007 11:06:03 +0900 From: Pyun YongHyeon To: Andrey Chernov , current@freebsd.org Message-ID: <20071220020602.GB993@cdnetworks.co.kr> References: <20071219013343.GA38367@nagual.pp.ru> <20071220012521.GA993@cdnetworks.co.kr> <20071220013720.GA91833@nagual.pp.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071220013720.GA91833@nagual.pp.ru> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Question about dev.fxp.0.noflow X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2007 02:06:27 -0000 On Thu, Dec 20, 2007 at 04:37:20AM +0300, Andrey Chernov wrote: > On Thu, Dec 20, 2007 at 10:25:22AM +0900, Pyun YongHyeon wrote: > > On Wed, Dec 19, 2007 at 04:33:44AM +0300, Andrey Chernov wrote: > > > Does anybody know why dev.fxp.0.noflow=1 by default? > > > Is it more proper to set it to 0? (by default or via /etc/sysctl.conf) > > > > > > > Since flow control is valid only when link partner also agrees on > > advertised pause capability on full-duplex media, it needs more work > > in mii/phy driver to advertise correct pause capability. It also needs > > a way to pass negotiated pause capability back to drvier such that > > each drvier should program necessary flow control parameters depending > > on its MAC capability and negociated ones. Just enabling flow control > > on one side have no effect. > > I also found this note in the commit log: > > date: 2003/05/16 01:13:16; author: rwatson; state: Exp; lines: +5 -1 > Add a tunable/sysctl "hw.fxp_noflow" which disables flow control support > on if_fxp cards. When flow control is enabled, if the operating system > doesn't acknowledge the packet buffer filling, the card will begin to > generate ethernet quench packets, but appears to get into a feedback > loop of some sort, hosing local switches. This is a temporary workaround > for 5.1: the ability to configure flow control should probably be > exposed by some or another management interface on ethernet link layer > devices. > > Does it mean card hardware defect or lack of driver support? I.e. is this > phrase > "When flow control is enabled, if the operating system doesn't acknowledge > the packet buffer filling" > still true with latest drivers framework (the note as old as 2003)? > I'm not familiar with fxp(4) but it would be lack of driver support. I can't see any special things on flow control in 82559 datasheet. Also I can hardly believe flow control capability of fxp(4) works as expected because it doesn't check negotiated link capability. At least fxp(4) should have a handler for miibus_statchg method that will decide which pause capability would be activated depending on duplex state/link partner pause capability . -- Regards, Pyun YongHyeon