From owner-freebsd-net@FreeBSD.ORG Wed Nov 6 15:01:28 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BB0BDAFE; Wed, 6 Nov 2013 15:01:28 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (lakerest.net [162.235.35.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 734D42565; Wed, 6 Nov 2013 15:01:28 +0000 (UTC) Received: from dhcp-9726.meeting.ietf.org (dhcp-9726.meeting.ietf.org [31.133.151.38]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id rA6F19ic083966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Nov 2013 10:01:11 -0500 (EST) (envelope-from rrs@lakerest.net) Subject: Re: MQ Patch. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Randall Stewart In-Reply-To: Date: Wed, 6 Nov 2013 07:01:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <40948D79-E890-4360-A3F2-BEC34A389C7E@lakerest.net> <526FFED9.1070704@freebsd.org> <13BF1F55-EC13-482B-AF7D-59AE039F877D@lakerest.net> <52701F7E.2060604@freebsd.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1283) Cc: Luigi Rizzo , Andre Oppermann , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:01:28 -0000 The other problem with no software ring is you will have some rough time doing AQM approaches such as Codel. Codel does a head drop, if there is no software ring you must get the hardware to implement the head-drop. Pi on the other hand does tail drop, which is why Cisco is pushing it, = since its much more friendly for both software and hardware queues combined = (which is what Cisco has). Of course Pi has Cisco you can't sue me IPR with it thus the need for a = plugin, but Codel from Van does not have this.. but has that little niggle that it = only works with a queue in software that you can head-drop from . R On Oct 29, 2013, at 2:02 PM, Adrian Chadd wrote: > [snip everything] >=20 > ok, I've reviewed the work. >=20 > TL;DR - it's a clearly correct step in the right direction, but I > think we need to just think it through a tad bit more first. >=20 > There have been queue discipline and queue management discussions in > the past. Randall's work is a good step in that direction. >=20 > I think though that we can take a step back up a little further. >=20 > * In terms of queuing frames into multiple queues - yes, we absolutely > should have an if_transmit() path to the driver that obeys "a" QoS > field in the mbuf and pushes it into the relevant queue - with > randalls work, it's in the driver, but it doesn't _have_ to be; > * In terms of queue servicing and management - we likely need to have > a variety of queue plugins that determine which frame from which queue > gets chosen next to hand to the hardware. The hardware may have > multiple queues! The hardware may have one queue! The application > developer may only want to use one queue! That should be flexible and > easy to plug into things. > * Then we need to support dropping frames during queue and dropping > frames during dequeue (ie, on its way to the hardware). That way we > can implement the currently interesting kinds of queue disciplines (eg > CODEL, etc.) > * Should this be done at the driver layer (ie it's a library that each > driver creates and owns), or as a layer above it, controlling the > network device (ie, the linux queue discipline method.) >=20 > So, my comments: >=20 > * I don't like how it's hard-coding drbr's into the drivers. Yes, the > underlying state should be a drbr for now. But I'd rather we have a > queue discipline plugin API that drivers create an instance of. > * It'll have methods to init/flush the rings, queue a frame into a > ring, dequeue a frame from a ring, be notified of transmit completions > so more work can be done, etc. > * For people who do latency-sensitive things, they can just bypass > this entirely and go straight to the hardware queues without going > through this kind of intermediary queue layer. >=20 > Randall - I think we can take your work and turn it into a net library > that implements your queue management routines. That way we can start > enabling people to tinker with it and replace it if they need to. >=20 > What do you think? > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 ------------------------------ Randall Stewart 803-317-4952 (cell)