Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-10-03 Thread Tom Psyborg
On 30/09/2018, Hans Dedecker  wrote:
> On Sun, Sep 30, 2018 at 12:53 AM Stefan Lippers-Hollmann 
> wrote:
>>
>> Hi
>>
>> On 2018-09-29, Torbjorn Jansson wrote:
>> > checkbox for hw offloading shows up for a fraction of a second when page
>> > is
>> > loaded but then it disappears.
>> > so i take it luci removes it dynamically or something at page load.
>>
>> flow-offloading has only beenbackported to kernel 4.14, if your target
>> is still on an older kernel (e.g. ar71xx is still on kernel 4.9), it
>> isn't available.
> In release 19.01 targets will be moved to kernel 4.14 including ar71xx see
> [1].
> Currently ar71xx has already support for kernel 4.14 [2] but the
> default version is 4.9 atm

that is fine as long as 4.9 is supported too since its LTS

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-30 Thread Hans Dedecker
On Sun, Sep 30, 2018 at 12:53 AM Stefan Lippers-Hollmann  wrote:
>
> Hi
>
> On 2018-09-29, Torbjorn Jansson wrote:
> > checkbox for hw offloading shows up for a fraction of a second when page is
> > loaded but then it disappears.
> > so i take it luci removes it dynamically or something at page load.
>
> flow-offloading has only beenbackported to kernel 4.14, if your target
> is still on an older kernel (e.g. ar71xx is still on kernel 4.9), it
> isn't available.
In release 19.01 targets will be moved to kernel 4.14 including ar71xx see [1].
Currently ar71xx has already support for kernel 4.14 [2] but the
default version is 4.9 atm

[1] http://lists.infradead.org/pipermail/openwrt-adm/2018-August/000863.html
[2] 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=318e19ba6755105bb6cc19937d8fff26cbd2cc6f

Hans
>
> Regards
> Stefan Lippers-Hollmann
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Stefan Lippers-Hollmann
Hi

On 2018-09-29, Torbjorn Jansson wrote:
> checkbox for hw offloading shows up for a fraction of a second when page is 
> loaded but then it disappears.
> so i take it luci removes it dynamically or something at page load.

flow-offloading has only beenbackported to kernel 4.14, if your target 
is still on an older kernel (e.g. ar71xx is still on kernel 4.9), it 
isn't available.

Regards
Stefan Lippers-Hollmann

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Rosen Penev


> On Sep 29, 2018, at 14:42, Torbjorn Jansson 
>  wrote:
> 
> On 2018-09-29 23:21, Rosen Penev wrote:
>>> On Sep 29, 2018, at 14:14, Torbjorn Jansson 
>>>  wrote:
>>> 
>>> On 2018-09-29 21:55, Rosen Penev wrote:
> On Sep 29, 2018, at 12:09, Jérôme Benoit  wrote:
> 
>> Le 29/09/2018 à 16:56, Felix Fietkau a écrit :
>> 
>> Flow offloading (as implemented in OpenWrt on 4.14) supports both
>> hardware offload and generic software offload for routing and NAT.
>> SFE is not necessary anymore.
>> 
> So you've made a backport of
> https://www.kernel.org/doc/Documentation/networking/nf_flowtable.txt to
> 4.14 in OpenWRT ?
 Yes. The OpenWrt version is potted to iptables and achieves something 
 similar to SFE. Hence my curiosity.
 Hardware NAT of float is only supported in mt7621 currently. qca8k (Some 
 atheros switches) will be next I believe. We’ll see.
>>> 
>>> "of float" = offload, right?
>>> a bit off-topic for this thread but if hw nat offloading is supported on 
>>> mt7621 whats the requirements for getting it to work?
>> Yes. iPhone autocorrect is worse than Android.
>> Just enable in the Firewall settings in LuCI.
> checkbox for hw offloading shows up for a fraction of a second when page is 
> loaded but then it disappears.
> so i take it luci removes it dynamically or something at page load.
> 
> so all i have is software flow offloading.
Which you need to check to enable hardware. That’s when it shows up.

The modules are all there in a normal installation. Really old config files 
will need them though. There was a commit that made them default for all 
devices considered to be “routers”.
> 
> any specific modules or packages i need to install on my erx-sfp?
> or do i need newer release of openwrt maybe?
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Torbjorn Jansson

On 2018-09-29 23:21, Rosen Penev wrote:




On Sep 29, 2018, at 14:14, Torbjorn Jansson 
 wrote:

On 2018-09-29 21:55, Rosen Penev wrote:

On Sep 29, 2018, at 12:09, Jérôme Benoit  wrote:


Le 29/09/2018 à 16:56, Felix Fietkau a écrit :

Flow offloading (as implemented in OpenWrt on 4.14) supports both
hardware offload and generic software offload for routing and NAT.
SFE is not necessary anymore.


So you've made a backport of
https://www.kernel.org/doc/Documentation/networking/nf_flowtable.txt to
4.14 in OpenWRT ?

Yes. The OpenWrt version is potted to iptables and achieves something similar 
to SFE. Hence my curiosity.
Hardware NAT of float is only supported in mt7621 currently. qca8k (Some 
atheros switches) will be next I believe. We’ll see.


"of float" = offload, right?
a bit off-topic for this thread but if hw nat offloading is supported on mt7621 
whats the requirements for getting it to work?

Yes. iPhone autocorrect is worse than Android.

Just enable in the Firewall settings in LuCI.

checkbox for hw offloading shows up for a fraction of a second when page is 
loaded but then it disappears.

so i take it luci removes it dynamically or something at page load.

so all i have is software flow offloading.

any specific modules or packages i need to install on my erx-sfp?
or do i need newer release of openwrt maybe?

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Rosen Penev


> On Sep 29, 2018, at 14:14, Torbjorn Jansson 
>  wrote:
> 
> On 2018-09-29 21:55, Rosen Penev wrote:
>>> On Sep 29, 2018, at 12:09, Jérôme Benoit  wrote:
>>> 
 Le 29/09/2018 à 16:56, Felix Fietkau a écrit :
 
 Flow offloading (as implemented in OpenWrt on 4.14) supports both
 hardware offload and generic software offload for routing and NAT.
 SFE is not necessary anymore.
 
>>> So you've made a backport of
>>> https://www.kernel.org/doc/Documentation/networking/nf_flowtable.txt to
>>> 4.14 in OpenWRT ?
>> Yes. The OpenWrt version is potted to iptables and achieves something 
>> similar to SFE. Hence my curiosity.
>> Hardware NAT of float is only supported in mt7621 currently. qca8k (Some 
>> atheros switches) will be next I believe. We’ll see.
> 
> "of float" = offload, right?
> a bit off-topic for this thread but if hw nat offloading is supported on 
> mt7621 whats the requirements for getting it to work?
Yes. iPhone autocorrect is worse than Android.

Just enable in the Firewall settings in LuCI.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Torbjorn Jansson

On 2018-09-29 21:55, Rosen Penev wrote:




On Sep 29, 2018, at 12:09, Jérôme Benoit  wrote:


Le 29/09/2018 à 16:56, Felix Fietkau a écrit :

Flow offloading (as implemented in OpenWrt on 4.14) supports both
hardware offload and generic software offload for routing and NAT.
SFE is not necessary anymore.


So you've made a backport of
https://www.kernel.org/doc/Documentation/networking/nf_flowtable.txt to
4.14 in OpenWRT ?

Yes. The OpenWrt version is potted to iptables and achieves something similar 
to SFE. Hence my curiosity.

Hardware NAT of float is only supported in mt7621 currently. qca8k (Some 
atheros switches) will be next I believe. We’ll see.


"of float" = offload, right?
a bit off-topic for this thread but if hw nat offloading is supported on mt7621 
whats the requirements for getting it to work?


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Rosen Penev


> On Sep 29, 2018, at 12:09, Jérôme Benoit  wrote:
> 
>> Le 29/09/2018 à 16:56, Felix Fietkau a écrit :
>> 
>> Flow offloading (as implemented in OpenWrt on 4.14) supports both
>> hardware offload and generic software offload for routing and NAT.
>> SFE is not necessary anymore.
>> 
> So you've made a backport of
> https://www.kernel.org/doc/Documentation/networking/nf_flowtable.txt to
> 4.14 in OpenWRT ?
Yes. The OpenWrt version is potted to iptables and achieves something similar 
to SFE. Hence my curiosity.

Hardware NAT of float is only supported in mt7621 currently. qca8k (Some 
atheros switches) will be next I believe. We’ll see.
> 
> ++
> 
> -- 
> Jérôme Benoit aka fraggle
> Piment Noir - https://piment-noir.org
> OpenPGP Key ID : 27B535D3
> Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3
> 
> 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Jérôme Benoit
Le 29/09/2018 à 16:56, Felix Fietkau a écrit :
>
> Flow offloading (as implemented in OpenWrt on 4.14) supports both
> hardware offload and generic software offload for routing and NAT.
> SFE is not necessary anymore.
>
So you've made a backport of
https://www.kernel.org/doc/Documentation/networking/nf_flowtable.txt to
4.14 in OpenWRT ?

++

-- 
Jérôme Benoit aka fraggle
Piment Noir - https://piment-noir.org
OpenPGP Key ID : 27B535D3
Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3




signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Felix Fietkau
On 2018-09-28 15:54, Marko Ratkaj wrote:
> Hi all,
> 
> On Fri, Sep 28, 2018 at 3:14 PM Jerome BENOIT  wrote:
>> > They may not be able to push lots of bandwidth, but if you have
>> > <~100Mbps internet they don't need to. If you have >~200Mbps internet
>> > for example with DOCSIS3.1 provider, then you probably need a newer
>> > dual-core device to take advantage of it.
>>
>> Is there any work in OpenWRT targeted at integrating Linux forwarding
>> fastpath in the official build ?
>> There are out-of-tree patches and builds floating around and nowadays 1
>> GB/s fiber internet access is very common is developed countries, and
>> the router is then becoming the bottleneck in many case.
> 
> With my colleagues I have already started this effort and plan to
> share patches to OpenWrt as soon as the work is ready. The plan is to
> present this on OpenWrt summit in our talk "State of fast path
> networking in Linux" as well [1]. Part of this activity is my pull
> request for 4.19 inclusion [2]. If there are other activities around
> this space please reach out to speed up the process.
Is your work integrated with flow offloading in any way, or are you
working on yet another different solution?

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Felix Fietkau
On 2018-09-29 10:53, Jérôme Benoit wrote:
> Le 28/09/2018 à 18:55, Rosen Penev a écrit :
>>
>> So in kernel 4.17 I believe landed flow offloading support. This 
>> accomplishes something similar to SFE while being a proper upstream 
>> solution. This is already implemented in OpenWrt.
> 
> flow offloading for NAT is different from SFE :
> 
> In the first case, you offload the NATing algorithm work to the hardware
> that support it, which narrow a lot the supported targets.
> In the second case, you optimize the NATing algorithm Linux kernel
> implementation for all targets, it's a software and generic optimization.  
Flow offloading (as implemented in OpenWrt on 4.14) supports both
hardware offload and generic software offload for routing and NAT.
SFE is not necessary anymore.

- Felix

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Jérôme Benoit
Le 29/09/2018 à 10:57, Sebastian Moeller a écrit :
>>> So in kernel 4.17 I believe landed flow offloading support. This 
>>> accomplishes something similar to SFE while being a proper upstream 
>>> solution. This is already implemented in OpenWrt.
>> flow offloading for NAT is different from SFE :
>>
>> In the first case, you offload the NATing algorithm work to the hardware
>> that support it, which narrow a lot the supported targets.
>> In the second case, you optimize the NATing algorithm Linux kernel
>> implementation for all targets, it's a software and generic optimization.  
>   As far as I can tell, SFE ans friends gain their speed advantage mainly 
> by being less generic that the main kernel, so speaking of an optimization 
> seems problematic. Because the reached better routing/NATing/whatever 
> typically is quite fickle and might for example not be compatible with 
> traffic shaping...

It's an implementation issue of the forwarding fastpath inside the Linux
kernel. Someone already stated here that other firmware that propose
forwarding fastpath as an option that is not compatible with other
features like netfilter, which is a showstopper, exists.

Honestly, I've not followed lately the status of openfastpath or SFE or
friends but I'm pretty their end goal is not to enable fastpath in the
Linux networking stack at the cost of other features ... but to offer an
alternative to the default slowpath in the first place, and then to
enable the fastpath for flows that have the criterion to "follow" it.   

Regards,

-- 
Jérôme Benoit aka fraggle
Piment Noir - https://piment-noir.org
OpenPGP Key ID : 27B535D3
Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3




signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Sebastian Moeller
Dear Jérôme,

> On Sep 29, 2018, at 10:53, Jérôme Benoit  wrote:
> 
> Le 28/09/2018 à 18:55, Rosen Penev a écrit :
>> 
>> So in kernel 4.17 I believe landed flow offloading support. This 
>> accomplishes something similar to SFE while being a proper upstream 
>> solution. This is already implemented in OpenWrt.
> 
> flow offloading for NAT is different from SFE :
> 
> In the first case, you offload the NATing algorithm work to the hardware
> that support it, which narrow a lot the supported targets.
> In the second case, you optimize the NATing algorithm Linux kernel
> implementation for all targets, it's a software and generic optimization.  

As far as I can tell, SFE ans friends gain their speed advantage mainly 
by being less generic that the main kernel, so speaking of an optimization 
seems problematic. Because the reached better routing/NATing/whatever typically 
is quite fickle and might for example not be compatible with traffic shaping...

Best Regards
Sebastian

> 
> -- 
> Jérôme Benoit aka fraggle
> Piment Noir - https://piment-noir.org
> OpenPGP Key ID : 27B535D3
> Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-29 Thread Jérôme Benoit
Le 28/09/2018 à 18:55, Rosen Penev a écrit :
>
> So in kernel 4.17 I believe landed flow offloading support. This accomplishes 
> something similar to SFE while being a proper upstream solution. This is 
> already implemented in OpenWrt.

flow offloading for NAT is different from SFE :

In the first case, you offload the NATing algorithm work to the hardware
that support it, which narrow a lot the supported targets.
In the second case, you optimize the NATing algorithm Linux kernel
implementation for all targets, it's a software and generic optimization.  

-- 
Jérôme Benoit aka fraggle
Piment Noir - https://piment-noir.org
OpenPGP Key ID : 27B535D3
Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3




signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread Rosen Penev


> On Sep 28, 2018, at 07:20, Jerome BENOIT  wrote:
> 
> 
>>> Is there any work in OpenWRT targeted at integrating Linux forwarding
>>> fastpath in the official build ?
>>> There are out-of-tree patches and builds floating around and nowadays 1
>>> GB/s fiber internet access is very common is developed countries, and
>>> the router is then becoming the bottleneck in many case.
>> With my colleagues I have already started this effort and plan to
>> share patches to OpenWrt as soon as the work is ready. The plan is to
>> present this on OpenWrt summit in our talk "State of fast path
>> networking in Linux" as well [1]. Part of this activity is my pull
>> request for 4.19 inclusion [2]. If there are other activities around
>> this space please reach out to speed up the process.
> 
> Great. I do no have closely followed the Linux kernel development lately but 
> the need for the 4.19 version in OpenWRT for fastpath forwarding is because 
> the SFE code have been upstreamed is that version ?
> Or because the latest SFE patches are against that version ?
> 
> The only related work that I'm aware of is 
> https://github.com/gwlim/Fast-Path-LEDE-OpenWRT but I do not think the author 
> have tried to include it upstream.
So in kernel 4.17 I believe landed flow offloading support. This accomplishes 
something similar to SFE while being a proper upstream solution. This is 
already implemented in OpenWrt.

Is there something that I’m missing here?
> 
> Cheers.
> 
> -- 
> Jérôme Benoit aka fraggle
> Piment Noir - https://piment-noir.org
> OpenPGP Key ID : 27B535D3
> Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3
> 
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread Jerome BENOIT



Is there any work in OpenWRT targeted at integrating Linux forwarding
fastpath in the official build ?
There are out-of-tree patches and builds floating around and nowadays 1
GB/s fiber internet access is very common is developed countries, and
the router is then becoming the bottleneck in many case.

With my colleagues I have already started this effort and plan to
share patches to OpenWrt as soon as the work is ready. The plan is to
present this on OpenWrt summit in our talk "State of fast path
networking in Linux" as well [1]. Part of this activity is my pull
request for 4.19 inclusion [2]. If there are other activities around
this space please reach out to speed up the process.


Great. I do no have closely followed the Linux kernel development lately 
but the need for the 4.19 version in OpenWRT for fastpath forwarding is 
because the SFE code have been upstreamed is that version ?

Or because the latest SFE patches are against that version ?

The only related work that I'm aware of is 
https://github.com/gwlim/Fast-Path-LEDE-OpenWRT but I do not think the 
author have tried to include it upstream.


Cheers.

--
Jérôme Benoit aka fraggle
Piment Noir - https://piment-noir.org
OpenPGP Key ID : 27B535D3
Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread Marko Ratkaj
Hi all,

On Fri, Sep 28, 2018 at 3:14 PM Jerome BENOIT  wrote:
> > They may not be able to push lots of bandwidth, but if you have
> > <~100Mbps internet they don't need to. If you have >~200Mbps internet
> > for example with DOCSIS3.1 provider, then you probably need a newer
> > dual-core device to take advantage of it.
>
> Is there any work in OpenWRT targeted at integrating Linux forwarding
> fastpath in the official build ?
> There are out-of-tree patches and builds floating around and nowadays 1
> GB/s fiber internet access is very common is developed countries, and
> the router is then becoming the bottleneck in many case.

With my colleagues I have already started this effort and plan to
share patches to OpenWrt as soon as the work is ready. The plan is to
present this on OpenWrt summit in our talk "State of fast path
networking in Linux" as well [1]. Part of this activity is my pull
request for 4.19 inclusion [2]. If there are other activities around
this space please reach out to speed up the process.

Thanks,
Marko Ratkaj

[1] https://openwrtsummit.wordpress.com/schedule-2018/
[2] https://github.com/openwrt/openwrt/pull/1386

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread Jerome BENOIT

Hello,


They may not be able to push lots of bandwidth, but if you have 
<~100Mbps internet they don't need to. If you have >~200Mbps internet 
for example with DOCSIS3.1 provider, then you probably need a newer 
dual-core device to take advantage of it.


Is there any work in OpenWRT targeted at integrating Linux forwarding 
fastpath in the official build ?
There are out-of-tree patches and builds floating around and nowadays 1 
GB/s fiber internet access is very common is developed countries, and 
the router is then becoming the bottleneck in many case.


--
Jérôme Benoit aka fraggle
Piment Noir - https://piment-noir.org
OpenPGP Key ID : 27B535D3
Key fingerprint : B799 BBF6 8EC8 911B B8D7 CDBC C3B1 92C6 27B5 35D3


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-28 Thread John Crispin


On 28/09/2018 06:35, Eric Luehrsen wrote:

On 09/27/2018 04:22 PM, Hauke Mehrtens wrote:

On 09/26/2018 09:38 AM, Koen Vandeputte wrote:



On 2018-09-23 00:42, Hauke Mehrtens wrote:

Hi,

We talked about plans for the next OpenWrt releases in this mail 
thread:

http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html
This mail is more or less a summary of the conclusions, this is still
open for change especially the dates as this depends on people having
time to do the work.

The next release, lets call it OpenWrt 19.01, should happen in January
2019, we would branch off from master in December 2018. This is the
current plan, but based on past experience it could also happen later.

OpenWrt 19.01 will ship with kernel 4.14 only, we encourage 
everyone to
update the targets to kernel 4.14, support for kernel 4.19 will 
probably

be added to OpenWrt master soon, but we will not select it as the
default kernel for any target till OpenWrt 19.01 is branched off, 
to get

more testing on 4.14. The release after 19.01, which should happen in
late summer 2019, should then use kernel 4.19 only.

For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl
already got some upgrades after the 18.06 release and could get some
more updates.

We are currently working on updating the wireless drivers and getting
them closer to upstream. The wireless driver in OpenWrt 19.01 will be
taken from kernel 4.19 or later and we want to update them more
frequently in master.

Otherwise we will have the normal changes in all places like with 
every

release.

LEDE 17.01 will get security updates and occasional bug fixes till
OpenWrt 19.01 was released, but we encourage everyone to upgrade to
18.06 to get full security support already now, as especially some of
the packages are not well maintained any more.

Hauke



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Hi Hauke,
Hi All,

Some targets are still on (EOL) kernel 3.18 today.
This kernel also still exists by the grace of Greg K-H but could be
dropped any moment.

I've bumped it a few times (untested) just for the sake of security
updates.
But afaict, nobody attempted/requested to update these to a newer 
kernel

version.

These targets were also dropped in 18.06 branch.
Maybe we should also consider dropping support for these targets in 
master?



adm5120
xburst
mcs814x
au1000
ppc40x
adm8668
ppc44x


I vote for removing them if on one wants to take care of these targets.
If something breaks kernel < 4.9 I anyway do not care any more.

Hauke


Considering that OpenWrt is volunteer spare time and hobby support, it 
is probably prudent to aggressively drop old and less popular targets. 
Considering 802.11ax is around the corner and (ac) is well 
established, it won't be hard to find for example ath79 compatible 
devices in (ac) or (n) as either new-overstock or used. They may not 
be able to push lots of bandwidth, but if you have <~100Mbps internet 
they don't need to. If you have >~200Mbps internet for example with 
DOCSIS3.1 provider, then you probably need a newer dual-core device to 
take advantage of it. Bottom line is it probably won't hurt to drop 
many targets, because small budget users will still have plenty to 
chose from.


Eric

can we mark them as broken now and when we release move them to a target 
feed. that will allow people to still use them in custom builds for 6-12 
months without us having to worry about them.


    John




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-27 Thread Eric Luehrsen

On 09/27/2018 04:22 PM, Hauke Mehrtens wrote:

On 09/26/2018 09:38 AM, Koen Vandeputte wrote:



On 2018-09-23 00:42, Hauke Mehrtens wrote:

Hi,

We talked about plans for the next OpenWrt releases in this mail thread:
http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html
This mail is more or less a summary of the conclusions, this is still
open for change especially the dates as this depends on people having
time to do the work.

The next release, lets call it OpenWrt 19.01, should happen in January
2019, we would branch off from master in December 2018. This is the
current plan, but based on past experience it could also happen later.

OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to
update the targets to kernel 4.14, support for kernel 4.19 will probably
be added to OpenWrt master soon, but we will not select it as the
default kernel for any target till OpenWrt 19.01 is branched off, to get
more testing on 4.14. The release after 19.01, which should happen in
late summer 2019, should then use kernel 4.19 only.

For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl
already got some upgrades after the 18.06 release and could get some
more updates.

We are currently working on updating the wireless drivers and getting
them closer to upstream. The wireless driver in OpenWrt 19.01 will be
taken from kernel 4.19 or later and we want to update them more
frequently in master.

Otherwise we will have the normal changes in all places like with every
release.

LEDE 17.01 will get security updates and occasional bug fixes till
OpenWrt 19.01 was released, but we encourage everyone to upgrade to
18.06 to get full security support already now, as especially some of
the packages are not well maintained any more.

Hauke



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Hi Hauke,
Hi All,

Some targets are still on (EOL) kernel 3.18 today.
This kernel also still exists by the grace of Greg K-H but could be
dropped any moment.

I've bumped it a few times (untested) just for the sake of security
updates.
But afaict, nobody attempted/requested to update these to a newer kernel
version.

These targets were also dropped in 18.06 branch.
Maybe we should also consider dropping support for these targets in master?


adm5120
xburst
mcs814x
au1000
ppc40x
adm8668
ppc44x


I vote for removing them if on one wants to take care of these targets.
If something breaks kernel < 4.9 I anyway do not care any more.

Hauke


Considering that OpenWrt is volunteer spare time and hobby support, it 
is probably prudent to aggressively drop old and less popular targets. 
Considering 802.11ax is around the corner and (ac) is well established, 
it won't be hard to find for example ath79 compatible devices in (ac) or 
(n) as either new-overstock or used. They may not be able to push lots 
of bandwidth, but if you have <~100Mbps internet they don't need to. If 
you have >~200Mbps internet for example with DOCSIS3.1 provider, then 
you probably need a newer dual-core device to take advantage of it. 
Bottom line is it probably won't hurt to drop many targets, because 
small budget users will still have plenty to chose from.


Eric

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-27 Thread Hauke Mehrtens
On 09/26/2018 09:38 AM, Koen Vandeputte wrote:
> 
> 
> On 2018-09-23 00:42, Hauke Mehrtens wrote:
>> Hi,
>>
>> We talked about plans for the next OpenWrt releases in this mail thread:
>> http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html
>> This mail is more or less a summary of the conclusions, this is still
>> open for change especially the dates as this depends on people having
>> time to do the work.
>>
>> The next release, lets call it OpenWrt 19.01, should happen in January
>> 2019, we would branch off from master in December 2018. This is the
>> current plan, but based on past experience it could also happen later.
>>
>> OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to
>> update the targets to kernel 4.14, support for kernel 4.19 will probably
>> be added to OpenWrt master soon, but we will not select it as the
>> default kernel for any target till OpenWrt 19.01 is branched off, to get
>> more testing on 4.14. The release after 19.01, which should happen in
>> late summer 2019, should then use kernel 4.19 only.
>>
>> For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl
>> already got some upgrades after the 18.06 release and could get some
>> more updates.
>>
>> We are currently working on updating the wireless drivers and getting
>> them closer to upstream. The wireless driver in OpenWrt 19.01 will be
>> taken from kernel 4.19 or later and we want to update them more
>> frequently in master.
>>
>> Otherwise we will have the normal changes in all places like with every
>> release.
>>
>> LEDE 17.01 will get security updates and occasional bug fixes till
>> OpenWrt 19.01 was released, but we encourage everyone to upgrade to
>> 18.06 to get full security support already now, as especially some of
>> the packages are not well maintained any more.
>>
>> Hauke
>>
>>
>>
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> Hi Hauke,
> Hi All,
> 
> Some targets are still on (EOL) kernel 3.18 today.
> This kernel also still exists by the grace of Greg K-H but could be
> dropped any moment.
> 
> I've bumped it a few times (untested) just for the sake of security
> updates.
> But afaict, nobody attempted/requested to update these to a newer kernel
> version.
> 
> These targets were also dropped in 18.06 branch.
> Maybe we should also consider dropping support for these targets in master?
> 
> 
> adm5120
> xburst
> mcs814x
> au1000
> ppc40x
> adm8668
> ppc44x

I vote for removing them if on one wants to take care of these targets.
If something breaks kernel < 4.9 I anyway do not care any more.

Hauke



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-26 Thread Hartmut Knaack
Koen Vandeputte schrieb am 26.09.2018 um 09:38:
 
> These targets were also dropped in 18.06 branch.
> Maybe we should also consider dropping support for these targets in master?
> 
> 
> adm5120

I started working on this target last year, but had to focus on other
topics meanwhile. Still, I would not like to give up on this one.



0x03684A18FAC89148.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-26 Thread Koen Vandeputte




On 2018-09-23 00:42, Hauke Mehrtens wrote:

Hi,

We talked about plans for the next OpenWrt releases in this mail thread:
http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html
This mail is more or less a summary of the conclusions, this is still
open for change especially the dates as this depends on people having
time to do the work.

The next release, lets call it OpenWrt 19.01, should happen in January
2019, we would branch off from master in December 2018. This is the
current plan, but based on past experience it could also happen later.

OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to
update the targets to kernel 4.14, support for kernel 4.19 will probably
be added to OpenWrt master soon, but we will not select it as the
default kernel for any target till OpenWrt 19.01 is branched off, to get
more testing on 4.14. The release after 19.01, which should happen in
late summer 2019, should then use kernel 4.19 only.

For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl
already got some upgrades after the 18.06 release and could get some
more updates.

We are currently working on updating the wireless drivers and getting
them closer to upstream. The wireless driver in OpenWrt 19.01 will be
taken from kernel 4.19 or later and we want to update them more
frequently in master.

Otherwise we will have the normal changes in all places like with every
release.

LEDE 17.01 will get security updates and occasional bug fixes till
OpenWrt 19.01 was released, but we encourage everyone to upgrade to
18.06 to get full security support already now, as especially some of
the packages are not well maintained any more.

Hauke



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Hi Hauke,
Hi All,

Some targets are still on (EOL) kernel 3.18 today.
This kernel also still exists by the grace of Greg K-H but could be 
dropped any moment.


I've bumped it a few times (untested) just for the sake of security updates.
But afaict, nobody attempted/requested to update these to a newer kernel 
version.


These targets were also dropped in 18.06 branch.
Maybe we should also consider dropping support for these targets in master?


adm5120
xburst
mcs814x
au1000
ppc40x
adm8668
ppc44x



The other items mentioned in the planning sound logical and sane to me.

Regards,

Koen

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-23 Thread Philip Prindeville


> On Sep 22, 2018, at 4:42 PM, Hauke Mehrtens  wrote:
> 
> Signed PGP part
> Hi,
> 
> We talked about plans for the next OpenWrt releases in this mail thread:
> http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html
> This mail is more or less a summary of the conclusions, this is still
> open for change especially the dates as this depends on people having
> time to do the work.
> 
> The next release, lets call it OpenWrt 19.01, should happen in January
> 2019, we would branch off from master in December 2018. This is the
> current plan, but based on past experience it could also happen later.
> 
> OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to
> update the targets to kernel 4.14, support for kernel 4.19 will probably
> be added to OpenWrt master soon, but we will not select it as the
> default kernel for any target till OpenWrt 19.01 is branched off, to get
> more testing on 4.14. The release after 19.01, which should happen in
> late summer 2019, should then use kernel 4.19 only.
> 
> For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl
> already got some upgrades after the 18.06 release and could get some
> more updates.
> 
> We are currently working on updating the wireless drivers and getting
> them closer to upstream. The wireless driver in OpenWrt 19.01 will be
> taken from kernel 4.19 or later and we want to update them more
> frequently in master.
> 
> Otherwise we will have the normal changes in all places like with every
> release.
> 
> LEDE 17.01 will get security updates and occasional bug fixes till
> OpenWrt 19.01 was released, but we encourage everyone to upgrade to
> 18.06 to get full security support already now, as especially some of
> the packages are not well maintained any more.
> 
> Hauke
> 


Hi Hauke,

This reminds me of an issue I’ve run into.  xtables-addons-3.0 will build on 
4.14, but xtables-addons-3.1 requires 4.19 at a minimum.

Is it reasonable to have xtables-addons/Makefile pick a version based on the 
kernel version?

-Philip



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-23 Thread Hauke Mehrtens
On 09/23/2018 08:20 PM, Rosen Penev wrote:
> On Sat, Sep 22, 2018 at 3:43 PM Hauke Mehrtens  wrote:
>>
>> Hi,
>>
>> We talked about plans for the next OpenWrt releases in this mail thread:
>> http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html
>> This mail is more or less a summary of the conclusions, this is still
>> open for change especially the dates as this depends on people having
>> time to do the work.
>>
>> The next release, lets call it OpenWrt 19.01, should happen in January
>> 2019, we would branch off from master in December 2018. This is the
>> current plan, but based on past experience it could also happen later.
>>
>> OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to
>> update the targets to kernel 4.14, support for kernel 4.19 will probably
>> be added to OpenWrt master soon, but we will not select it as the
>> default kernel for any target till OpenWrt 19.01 is branched off, to get
>> more testing on 4.14. The release after 19.01, which should happen in
>> late summer 2019, should then use kernel 4.19 only.
>>
>> For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl
>> already got some upgrades after the 18.06 release and could get some
>> more updates.
> Speaking of which, I request that at least these be merged:
> 
> https://github.com/openwrt/packages/pull/6995
> https://github.com/openwrt/packages/pull/6886
> https://github.com/openwrt/packages/pull/6879
> https://github.com/openwrt/packages/pull/6872
> https://github.com/openwrt/packages/pull/6367
> 
> These are mainly compilation fixes as well as some usability ones (The
> last is needed for LVM2 and fio to work properly).
> 
> There are over 200 pull requests in the packages repository that
> should be ironed out before the release.

I think we have there a problem again.
I have to admit that I do not look to often at the package feed and hope
that someone else takes care. The biggest problem seams to be inactive
maintainers, I think if a maintainer does not react in 3 weeks anyone
can overrule him.

There are also many pull requests where someone requested some changes
and then nothing happens, we should probably close then after some weeks.

Hauke



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: [OpenWrt-Devel] OpenWrt 19.01 plans

2018-09-23 Thread Rosen Penev
On Sat, Sep 22, 2018 at 3:43 PM Hauke Mehrtens  wrote:
>
> Hi,
>
> We talked about plans for the next OpenWrt releases in this mail thread:
> http://lists.infradead.org/pipermail/openwrt-adm/2018-July/000849.html
> This mail is more or less a summary of the conclusions, this is still
> open for change especially the dates as this depends on people having
> time to do the work.
>
> The next release, lets call it OpenWrt 19.01, should happen in January
> 2019, we would branch off from master in December 2018. This is the
> current plan, but based on past experience it could also happen later.
>
> OpenWrt 19.01 will ship with kernel 4.14 only, we encourage everyone to
> update the targets to kernel 4.14, support for kernel 4.19 will probably
> be added to OpenWrt master soon, but we will not select it as the
> default kernel for any target till OpenWrt 19.01 is branched off, to get
> more testing on 4.14. The release after 19.01, which should happen in
> late summer 2019, should then use kernel 4.19 only.
>
> For OpenWrt 19.01 GCC will stay on the 7.X branch, binutils and musl
> already got some upgrades after the 18.06 release and could get some
> more updates.
Speaking of which, I request that at least these be merged:

https://github.com/openwrt/packages/pull/6995
https://github.com/openwrt/packages/pull/6886
https://github.com/openwrt/packages/pull/6879
https://github.com/openwrt/packages/pull/6872
https://github.com/openwrt/packages/pull/6367

These are mainly compilation fixes as well as some usability ones (The
last is needed for LVM2 and fio to work properly).

There are over 200 pull requests in the packages repository that
should be ironed out before the release.
>
> We are currently working on updating the wireless drivers and getting
> them closer to upstream. The wireless driver in OpenWrt 19.01 will be
> taken from kernel 4.19 or later and we want to update them more
> frequently in master.
>
> Otherwise we will have the normal changes in all places like with every
> release.
>
> LEDE 17.01 will get security updates and occasional bug fixes till
> OpenWrt 19.01 was released, but we encourage everyone to upgrade to
> 18.06 to get full security support already now, as especially some of
> the packages are not well maintained any more.
>
> Hauke
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel