[PATCH] iperf3: update to version 3.1.5 and download via git

[Christian Lamparter]

Hello,

On Monday, January 30, 2017 12:43:40 PM CET Daniel Engberg wrote:
> On 2017-01-15 22:06, Daniel Engberg wrote:
> > On 2017-01-15 21:56, Christian Lamparter wrote:
> >> On Sunday, January 15, 2017 9:25:28 PM CET Daniel Engberg wrote:
> >>> Thanks for submitting a patch but can you please outline why we would
> >>> want to switch from a tarball release to a git repo pull for iperf3?
> >>> 
> >> 
> >> Actually, it's in the commit. It saves a couple of KiB since we can 
> >> switch to
> >> xz along the way too. As for iperf 3.1.5 this is:
> >> 
> >> 550862 Bytes for iperf-3.1.5.tar.gz
> >> 
> >> vs.
> >> 
> >> 400468 Bytes for 
> >> iperf-3.1.5-a46d5aec9726e196e86ab192c3f77dea6a3beb8e.tar.xz
> >> 
> >> That's around 27% savings of bandwidth. Because once it's uploaded
> >> onto the mirror
> >> the download methods will pick it from there - instead of the listed 
> >> address.
> >> 
> >> Anyway, if you have your own idea of how to do it: Then just make a
> >> patch as well.
> >> 
> >> Regards,
> >> Christian
> > 
> > I'm all for saving space and bandwidth but as far as I know the common
> > practice is to use tarballs where it makes sense (ie pretty much
> > everywhere) and upstream download mirrors/sites. Directing all users
> > to the LEDE "backup" mirror is not a desirable outcome as there's no
> > official xz package. That's just my point of view.
> > 
> > Regards,
> > Daniel Engberg
> I just wanted to information you (as asked by mkresin) that I've 
> submitted a pr on GitHub 
> (https://github.com/lede-project/source/pull/755) that uses the release 
> tarball which is considered to be the preferred way for this package.

Let's hope so :).

> Something completely different, great work on the ipq4xx stuff. Any 
> plans on upstreaming it?
Depends. Most of / all the platform code and the important drivers would
need to be upstream. As far as I can tell, there's little progress on the
ipq40xx. It's rotting since Matthew McClintock left QCA. Maybe it will
pick up a bit once the devices are getting more common... But people might
as well just skip it (for 2.5G/5G and VHT160).

The apm821xx was way easier to add. As it had full kernel support from
the get go and the big DMA and SATA patches were all backports.

Regards,
Christian