Date: Tue, 29 Oct 2013 18:43:21 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: "freebsd-net@freebsd.org" <net@freebsd.org>, Luigi Rizzo <rizzo@iet.unipi.it>, Navdeep Parhar <np@freebsd.org>, Randall Stewart <rrs@lakerest.net> Subject: Re: MQ Patch. Message-ID: <CAJ-Vmo=6thETmTDrPYRjwNTEQaTWkSTKdRYN3eRw5xVhsvr5RQ@mail.gmail.com> In-Reply-To: <5270462B.8050305@freebsd.org> References: <40948D79-E890-4360-A3F2-BEC34A389C7E@lakerest.net> <526FFED9.1070704@freebsd.org> <CA%2BhQ2%2BgTc87M0f5pvFeW_GCZDogrLkT_1S2bKHngNcDEBUeZYQ@mail.gmail.com> <52701D8B.8050907@freebsd.org> <527022AC.4030502@FreeBSD.org> <527027CE.5040806@freebsd.org> <5270309E.5090403@FreeBSD.org> <5270462B.8050305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, We can't assume the hardware has deep queues _and_ we can't just hand packets to the DMA engine. Why? Because once you've pushed it into the transmit ring, you can't guarantee / impose any ordering on things. You can't guarantee that you can abort a frame that has been queued because it now breaks the queue rules. That's why we don't want to just have a light wrapper around hardware transmit queues. We give up way too much useful control. I've seen this both when doing wifi (where I absolutely have to have per-node, per-TID queues, far before it hits the hardware) and doing WAN style optimisation, where I want to ensure I only queue a handful of milliseconds of frames to the hardware so I can ensure I can hit QoS requirements (eg there being a large amount of bulk data, then I want to inject some voice traffic that should go out sooner..) Thanks, -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=6thETmTDrPYRjwNTEQaTWkSTKdRYN3eRw5xVhsvr5RQ>