Re: [Bloat] "BBR" TCP patches submitted to linux kernel

[Mikael Abrahamsson <swmike@swm.pp.se>]

On Thu, 29 Sep 2016, Aaron Wood wrote:

> While you think 3.10 is old, in my experience it's still seen as cutting 
> edge by many.  RHEL is still only at 3.10.  And routers are using much 
> older 3.x kernels.  There's a huge lag between what the "enterprise" 
> crowd is running in production, and what you guys are developing on. 
> Because "stability".
>
> It's been one of my major frustrations (especially on the embedded side 
> where 3.x kernels are still considered 'new' and 2.6.x is 'trusted').

State of affairs are actually improving. What I'm seeing from several SoC 
vendors is that they're moving from a "new kernel every 3 years, and we'll 
choose a 2 year old kernel when doing the work so it'll be 5 years old by 
the time a new one comes around, with the result that a lot of devices 
are on 2.6.26, 3.2 and 3.4), to a model where they actually do a new 
kernel every 6 months, and they'll choose a kernel that's around 12-18 
months old at that time.

This is of course not great, but it's an improvement. I'm pushing for SoC 
vendors to actually upstream their patches as much as possible and support 
creation of kernel version independent HAL/API in the kernel that they can 
write their drivers for.

So if you know any netdev people, please tell them to be supportive when 
SoC vendors come and want changes done to the kernel to support for 
instance hw packet accelerators. We want this done right of course (so we 
can live with it for the next 5-10 years at least), but this is very 
important that it gets done.

This of course has interesting effects for AQM, since with packet 
accelerators you're taking the kernel pretty much out of the data path as 
soon as the hardware is programmed... but that's a different but related 
struggle to make sure that these aren't as bloated as yesteryears 
implementations.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se