Date: Wed, 6 Nov 2013 07:01:09 -0800 From: Randall Stewart <rrs@lakerest.net> To: Adrian Chadd <adrian@freebsd.org> Cc: Luigi Rizzo <rizzo@iet.unipi.it>, Andre Oppermann <andre@freebsd.org>, "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: MQ Patch. Message-ID: <C10834BF-4478-4051-819D-2849C4A573B5@lakerest.net> In-Reply-To: <CAJ-VmokJaBhZE%2B3ZDsi0Yybuvtb_d7AH_RThCKs4inUM=UQrAQ@mail.gmail.com> References: <40948D79-E890-4360-A3F2-BEC34A389C7E@lakerest.net> <526FFED9.1070704@freebsd.org> <CA%2BhQ2%2BgTc87M0f5pvFeW_GCZDogrLkT_1S2bKHngNcDEBUeZYQ@mail.gmail.com> <13BF1F55-EC13-482B-AF7D-59AE039F877D@lakerest.net> <52701F7E.2060604@freebsd.org> <CAJ-VmokJaBhZE%2B3ZDsi0Yybuvtb_d7AH_RThCKs4inUM=UQrAQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C10834BF-4478-4051-819D-2849C4A573B5>