Date: Tue, 29 Oct 2013 14:03:40 -0700 From: Navdeep Parhar <np@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org>, Luigi Rizzo <rizzo@iet.unipi.it> Cc: Randall Stewart <rrs@lakerest.net>, "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: MQ Patch. Message-ID: <527022AC.4030502@FreeBSD.org> In-Reply-To: <52701D8B.8050907@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>
index | next in thread | previous in thread | raw e-mail
On 10/29/13 13:41, Andre Oppermann wrote: > Let me jump in here and explain roughly the ideas/path I'm exploring > in creating and eventually implementing a big picture for drivers, > queues, queue management, various QoS and so on: > > Situation: We're still mostly based on the old 4.4BSD IFQ model with > a couple of work-arounds (sndring, drbr) and the bit-rotten ALTQ we > have in tree aren't helpful at all. > > Steps: > > 1. take the soft-queuing method out of the ifnet layer and make it > a property of the driver, so that the upper stack (or actually > protocol L3/L2 mapping/encapsulation layer) calls (*if_transmit) > without any queuing at that point. It then is up to the driver > to decide how it multiplexes multi-core access to its queue(s) > and how they are configured. It would work out much better if the kernel was aware of the number of tx queues of a multiq driver and explicitly selected one in if_transmit. The driver has no information on the CPU affinity etc. of the applications generating the traffic; the kernel does. In general, the kernel has a much better "global view" of the system and some of the stuff currently in the drivers really should move up into the stack. Regards, Navdeephome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?527022AC.4030502>