From owner-freebsd-pf@freebsd.org Wed Aug 10 12:42:34 2016 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53685BB3936 for ; Wed, 10 Aug 2016 12:42:34 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D32717BD for ; Wed, 10 Aug 2016 12:42:34 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [150.158.232.205] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 298CD1F164; Wed, 10 Aug 2016 14:42:32 +0200 (CEST) From: "Kristof Provost" To: "Radek =?utf-8?q?Krej=C4=8Da?=" Cc: "freebsd-pf@freebsd.org" Subject: Re: Max altq bandwidth 4.26 Gbit Date: Wed, 10 Aug 2016 14:42:30 +0200 Message-ID: <93494711-31C3-4BC8-B310-48882BF8CA74@FreeBSD.org> In-Reply-To: References: <13955BA9-910E-4C4A-B86A-5A355F8A10C9@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6044) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2016 12:42:34 -0000 On 10 Aug 2016, at 14:38, Radek Krejča wrote: > I have changed bandwidth to 100%, 90% or 95%. Syntax OK, but value > stops at 1.27Gbit (it looks, that 1Gbit is default) > > When I give ifconfig, I see: > > media: Ethernet autoselect (10Gbase-SR ) > > It looks that "autodetection" of pf is broken to. > I was afraid of that. I think the issue there is that when pf asks for the speed of the interface it puts a 64-bit value in a 32-bit field, so the resulting value is incorrect. Please do file a bug, because you’ve discovered a real problem and I’d hate for it to get forgotten about. Regards, Kristof