Date: Tue, 29 Oct 2013 14:35:31 -0700 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Andre Oppermann <andre@freebsd.org> Cc: Randall Stewart <rrs@lakerest.net>, "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: MQ Patch. Message-ID: <CA%2BhQ2%2BiLsHXqvk%2BXvECJz-NfKa=5BSz-YjRGYZ%2BBv2Vbtd0Nbw@mail.gmail.com> In-Reply-To: <52701F7E.2060604@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 29, 2013 at 1:50 PM, Andre Oppermann <andre@freebsd.org> wrote: > On 29.10.2013 21:20, Randall Stewart wrote: > >> So, to conclude: i fully support any plan to design something that lets us >>> implement scheduling (and qos, if you want to call it this way) >>> in a reasonable way, but what is in your patch now does not really >>> seem to improve the current situation in any way. >>> >> >> Its a step towards fixing that I am allowed to give. I can see >> why Company's get frustrated with trying to give anything to the project. >> > > Well, that we have a problem in that area is known and acknowledged and > there is active work in this area going on. > > It would be very problematic if every vendor were just to through some > stuff over the fence and have it integrated as is. It would quickly > become very messy. In many specific purpose geared products a number > of shortcuts can be taken that may not be appropriate for a general > purpose OS that does more than routing. > that is exactly the issue. It is not just FreeBSD that has strict policies on what gets accepted. Several times (though mostly in the past) I myself have been suggested to reconsider submissions that were too intrusive or lacking from an architectural point of view. And as much i could have been annoyed, i have to recognise that the criticism was legitimate and eventually led to better implementations. Of course one has much more freedom when playing with a standalone component (say netmap, or a device driver, or SCTP...) which does not interfere with the rest of the kernel, and possibly even fills a hole in the OS. But this is not one of those cases. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BhQ2%2BiLsHXqvk%2BXvECJz-NfKa=5BSz-YjRGYZ%2BBv2Vbtd0Nbw>