Date: Thu, 27 Jun 2013 07:42:22 +0200 From: peter@bsdly.net (Peter N. M. Hansteen) To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: freebsd-pf@freebsd.org Subject: Re: PF bugs Message-ID: <87txkkxg75.fsf@deeperthought.bsdly.net> In-Reply-To: <20130625153719.GN1214@FreeBSD.org> (Gleb Smirnoff's message of "Tue, 25 Jun 2013 19:37:19 %2B0400") References: <1371871842.22524.62.camel@localhost> <87ehbuti5u.fsf@deeperthought.bsdly.net> <20130625153719.GN1214@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gleb Smirnoff <glebius@FreeBSD.org> writes: > The number of people who run both OpenBSD and FreeBSD is signficantly > less then number of people who just run FreeBSD and routinely upgrade > it from version to version. I understand that having different syntax > is a PITA for those who run both BSDs, sorry for that. But changing > syntax in FreeBSD would be PITA for a vast majority of people. That's > why many FreeBSD developers are against changing syntax. Breaking people's configs are generally undesirable, but in this case along with the nat and rdr syntax change comes goodies like match, settable state defaults, divert-to, pflow, and various performance-relevant code improvements. On the OpenBSD side, the added features and performance improvements were considered worth the temporary pain of changing NAT and redirection rules (but really, in almost all cases the conversion is trivial, and the really weird setups turn out far more maintainable with the new syntax than the old). > > P> Also, the new queueing subsystem that's now likely to be in OpenBSD > P> 5.5 (to be released May 1st 2014) is likely to be a major feature that > P> I think FreeBSD will want to include as soon as doable. > > While OpenBSD changes struct ifqueue if_snd in the ifnet to > if_snd[nqueues], FreeBSD moves in the direction of killing the queue. > The queue has showed itself as the major bottleneck for high speed > interfaces, and now in FreeBSD all gigabit and 10gig NIC drivers > bypass the ifqueue, it is left only for compatibility. That's why > we don't plan to move back to queues. > >>From my viewpoint the best send scheduling method in the modern world > is utilize multiqueueing that NICs provide. Most high end NICs now do. > We just need some hardware abstraction layer upon that. > > Right now Andre Oppermann is planning a major work on the TX side of > NIC drivers, and I'm pretty sure, he will consider traffic prioritisation. prio (pure priority) specifiable per rule is available by default since OpenBSD 5.0, the first part of a longer term plan to replace ALTQ with traffic shaping that fits better with the more modern code surrounding it (and that's where the array of queues comes from, to implement the always-on priority scheme). Not sure at first blush how much of a conflict there will be between the traffic shaping code that is likely to hit the OpenBSD tree in time for 5.5 (due to be released May 1st 2014), but it would bear looking into I suppose. The diff at http://bulabula.org/diffs/newqueue.diff applied to a recent OpenBSD-current is what is being tested at the moment. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87txkkxg75.fsf>