Date: Wed, 30 Oct 2013 10:48:31 -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-VmonW=LQ32_XNP0GnQ=gehLO0Lf8APPHF5jpT-SjRGSw7MQ@mail.gmail.com> In-Reply-To: <5270F101.6020701@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> <CAJ-Vmo=6thETmTDrPYRjwNTEQaTWkSTKdRYN3eRw5xVhsvr5RQ@mail.gmail.com> <5270F101.6020701@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 October 2013 04:44, Andre Oppermann <andre@freebsd.org> wrote: >> 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. > > > The stack can't possibly know about all these differences in current > and future technologies and requirements. That's why this decision > should be pushed into the L3/L2 mapping/encapsulation and driver layer. That's why you split it. You allow the upper layers (things like altq) to track things like per-IP, per-traffic-class traffic and tag things appropriate. You then let some software queue implement the queue discipline and only drain frames to the hardware at a rate that's fast enough to keep up with the hardware, and no faster. Why? Because if you have new traffic come along from a new client, it may be higher priority than the traffic queued to the hardware. But it's at the same QoS level as what's currently queued to the hardware, or map to the same physical queue. So yes, we do need that split for a lot of cases. There will be bare-metal cases for highly low latency but if we implement the correct queue API here it'll just collapse down to either NULL, or just the existing software queue in front of the DMA rings to avoid locking overhead. Thanks, -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonW=LQ32_XNP0GnQ=gehLO0Lf8APPHF5jpT-SjRGSw7MQ>