[dpdk-dev] DPDK and Link-time Optimizations

[dpdk-dev] DPDK and Link-time Optimizations

[Mattias Rönnblom]

Hi.

Did anyone on the list successfully build DPDK with GCC Link-time 
Optimizations (LTO) enabled? I tried and failed a while back, although 
the detailed reasons of my failure eludes me for the moment.

If LTO builds would work "out of the box", DPDK could gradually migrate 
from away from having static inline functions in the header files.

Those interested squeezing out as much performance as possible would 
build with LTO (and static linking), and those applications who cared 
more about independent upgrades would use dynamic linking and non-LTO 
builds. With the extra cost of using DPDK as a shared library 
(-fPIC-compiled code, more expensive TLS accesses etc), I'm guessing 
this is the case already today.

Regards,
	Mattias

[dpdk-dev] DPDK and Link-time Optimizations

[Mattias Rönnblom]

Hi.

Did anyone on the list successfully build DPDK with GCC Link-time 
Optimizations (LTO) enabled? I tried and failed a while back, although 
the detailed reasons of my failure eludes me for the moment.

If LTO builds would work "out of the box", DPDK could gradually migrate 
from away from having static inline functions in the header files.

Those interested squeezing out as much performance as possible would 
build with LTO (and static linking), and those applications who cared 
more about independent upgrades would use dynamic linking and non-LTO 
builds. With the extra cost of using DPDK as a shared library 
(-fPIC-compiled code, more expensive TLS accesses etc), I'm guessing 
this is the case already today.

Regards,
	Mattias

Re: [dpdk-dev] DPDK and Link-time Optimizations

[Stephen Hemminger]

On Mon, 29 Apr 2019 18:39:47 +0200
Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:

> Hi.
> 
> Did anyone on the list successfully build DPDK with GCC Link-time 
> Optimizations (LTO) enabled? I tried and failed a while back, although 
> the detailed reasons of my failure eludes me for the moment.
> 
> If LTO builds would work "out of the box", DPDK could gradually migrate 
> from away from having static inline functions in the header files.
> 
> Those interested squeezing out as much performance as possible would 
> build with LTO (and static linking), and those applications who cared 
> more about independent upgrades would use dynamic linking and non-LTO 
> builds. With the extra cost of using DPDK as a shared library 
> (-fPIC-compiled code, more expensive TLS accesses etc), I'm guessing 
> this is the case already today.
> 
> Regards,
> 	Mattias

I tried (and it worked) in the past. But you have to be consistent
about always using the same flags.  LTO also really makes compiler
a pig and you need multiple Gig of memory.

Re: [dpdk-dev] DPDK and Link-time Optimizations

[Stephen Hemminger]

On Mon, 29 Apr 2019 18:39:47 +0200
Mattias Rönnblom <mattias.ronnblom@ericsson.com> wrote:

> Hi.
> 
> Did anyone on the list successfully build DPDK with GCC Link-time 
> Optimizations (LTO) enabled? I tried and failed a while back, although 
> the detailed reasons of my failure eludes me for the moment.
> 
> If LTO builds would work "out of the box", DPDK could gradually migrate 
> from away from having static inline functions in the header files.
> 
> Those interested squeezing out as much performance as possible would 
> build with LTO (and static linking), and those applications who cared 
> more about independent upgrades would use dynamic linking and non-LTO 
> builds. With the extra cost of using DPDK as a shared library 
> (-fPIC-compiled code, more expensive TLS accesses etc), I'm guessing 
> this is the case already today.
> 
> Regards,
> 	Mattias

I tried (and it worked) in the past. But you have to be consistent
about always using the same flags.  LTO also really makes compiler
a pig and you need multiple Gig of memory.

Re: [dpdk-dev] DPDK and Link-time Optimizations

[Thomas Monjalon]

29/04/2019 18:39, Mattias Rönnblom:
> If LTO builds would work "out of the box", DPDK could gradually migrate 
> from away from having static inline functions in the header files.
> 
> Those interested squeezing out as much performance as possible would 
> build with LTO (and static linking), and those applications who cared 
> more about independent upgrades would use dynamic linking and non-LTO 
> builds. With the extra cost of using DPDK as a shared library 
> (-fPIC-compiled code, more expensive TLS accesses etc), I'm guessing 
> this is the case already today.

That's an interesting point of view.

For info, LTO is merged now.

I would like to see some benchmarks about
LTO static vs shared vs shared without inlines.
Then we could decide what to do with inline functions.