On Wed, Aug 01, 2012 at 08:40:52PM +0200, Hartmut Knaack wrote: > Hi, > my impression is, that a kernel version makes it into trunk if it is either a > long term kernel, or it brings essential new functions. For 3.3 this was most > certainly the introduction of BQL code. Keeping in mind that our main targets > are network routers, the bufferbloat issue probably concerns most of the > maintainers.
I have been away from my mail for a while. Van Jacobson gave a great talk about bufferbloat, BQL, codel, and fq_codel at last week's ietf meeting. Well worth watching. At the end he outlines the deployment problems in particular. http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF84_TSVAREA&chapter=part_3 Far more interesting than this email! While we have made great progress towards addressing bufferbloat in openwrt, it is only barely addressed in the openwrt QoS system, (it would be nice if fq_codel ran on all interfaces with BQL support), BQL support only exists for a few drivers in the openwrt tree... And fixing wifi with similar techniques is going to take months and months longer to do, even if we could get the chipset makers focused on the problem. http://www.bufferbloat.net/projects/cerowrt/wiki/Fq_Codel_on_Wireless So the upcoming 3.3 release of openwrt is a start, only, towards fixing bufferbloat. I'm very happy we made so much progress in a year, with perhaps another year of effort and we'll have it thoroughly licked in linux and in openwrt. That leads towards difficult decision-making for declaring a "stable" release this year for openwrt. The current trunk of openwrt is unquestionably better than last years release, and deserves wider use. As for the long term support issue for 3.3, it does concern me very much that 3.3 is already EOL'd. I would like it if openwrt planned on a stable release on the next go-round built around a kernel that has long term support (perhaps 3.8?). I do note that openwrt's "3.3" is not actually 3.3 to a large extent, it has wireless-next, and the fq_codel implementation from linux 3.5, and tons and tons of patches for driver and chipset support that haven't made it up to mainline. There are 160 generic linux patches, and for the ar71xx architecture *alone* there are 136 patches, and 95 new driver related files. It would be good if efforts were expended to merge up the enormous patch burden into the kernel mainline, so as to make it easier to move openwrt forward in conjuction with it. The patch burden is the enormous problem impeding progress forward, and makes bi-directional patching from the Linux kernel head much harder as time goes by... The patch burden and driver collisions in the arm world got so bad 2 years ago that linaro was formed to fix it. That effort has largely been successful and it would help a lot to do something similar here. It would be my hope that those that build products around openwrt would recognise this infrastructural problem and step up. (side note, the bufferbloat.net effort has loaned 4 boxes to the buildbot system and it would be very helpful in terms of cycle time if the buildbot cluster could be even more dramatically expanded) IMHO, I think it's worth creating a stable release now, but also working hard towards being able to create another stable release on a new kernel base *this year* - which is going to be hard due to these other problems. > > Emmanuel Deloget schrieb: > > Hello, > > > > I understand that a lot of effort has been pushed in making > > Linux 3.3 the trunk kernel, and I understand that I probably > > missed long (IRC?) discussions on this very subject, but since > > 3.3.8 is going to be the last supported kernel in the 3.3.x > > branch it might be a good idea to move on to another, more > > recent kernel version - and to do it slightly better. Not > > that anything is really bad, but there were obviously better > > choices that 3.3 at the time it came up. > > > > _______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
