28/10/2019 13:12, Andrzej Ostruszka:
> On 10/28/19 9:36 AM, Andrzej Ostruszka wrote:
> > On 10/27/19 12:31 PM, Thomas Monjalon wrote:
> [...]
> >> Should we document its use in rte_function_versioning.h
> >> and versioning.rst?
> >
> > Yes, I think so. I'll add that.
>
> One quick notice. There
On 10/28/19 9:36 AM, Andrzej Ostruszka wrote:
> On 10/27/19 12:31 PM, Thomas Monjalon wrote:
[...]
>> Should we document its use in rte_function_versioning.h
>> and versioning.rst?
>
> Yes, I think so. I'll add that.
One quick notice. There is a slight mismatch between documentation of
VERSION_
28/10/2019 09:36, Andrzej Ostruszka:
> On 10/27/19 12:31 PM, Thomas Monjalon wrote:
> > 18/09/2019 15:32, Ray Kinsella:
> >> this is cool, good work.
> >> comments below.
> >>
> >> On 17/09/2019 08:57, Andrzej Ostruszka wrote:
> >>> --- a/lib/librte_distributor/rte_distributor.c
> >>> +++ b/lib/lib
On 10/27/19 12:31 PM, Thomas Monjalon wrote:
> 18/09/2019 15:32, Ray Kinsella:
>> this is cool, good work.
>> comments below.
>>
>> On 17/09/2019 08:57, Andrzej Ostruszka wrote:
>>> --- a/lib/librte_distributor/rte_distributor.c
>>> +++ b/lib/librte_distributor/rte_distributor.c
>>> @@ -32,7 +32,7
18/09/2019 15:32, Ray Kinsella:
> this is cool, good work.
> comments below.
>
> On 17/09/2019 08:57, Andrzej Ostruszka wrote:
> > --- a/lib/librte_distributor/rte_distributor.c
> > +++ b/lib/librte_distributor/rte_distributor.c
> > @@ -32,7 +32,7 @@ EAL_REGISTER_TAILQ(rte_dist_burst_tailq)
> >
On Thu, Sep 26, 2019 at 05:32:12PM +0200, Andrzej Ostruszka wrote:
> On 9/24/19 2:59 PM, Neil Horman wrote:
> > On Tue, Sep 24, 2019 at 12:25:35PM +0200, Bruce Richardson wrote:
> >> On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote:
> >>> On 9/23/19 6:13 PM, Bruce Richardson wrote:
On 9/24/19 2:59 PM, Neil Horman wrote:
> On Tue, Sep 24, 2019 at 12:25:35PM +0200, Bruce Richardson wrote:
>> On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote:
>>> On 9/23/19 6:13 PM, Bruce Richardson wrote:
[...]
>> The real issue seems to be that the compat.h header has different
On 24/09/2019 13:59, Neil Horman wrote:
> On Tue, Sep 24, 2019 at 12:25:35PM +0200, Bruce Richardson wrote:
>> On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote:
>>> On 9/23/19 6:13 PM, Bruce Richardson wrote:
>>> [...]
However, testing on my system with the meson build, I'm
On Tue, Sep 24, 2019 at 12:25:35PM +0200, Bruce Richardson wrote:
> On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote:
> > On 9/23/19 6:13 PM, Bruce Richardson wrote:
> > [...]
> > > However, testing on my system with the meson build, I'm getting lots of
> > > link errors [See below
On Tue, Sep 24, 2019 at 01:52:23PM +0200, Andrzej Ostruszka wrote:
>
> On 9/24/19 12:25 PM, Bruce Richardson wrote:
> > On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote:
> [...]
> >> PS. IMHO this SHARED_LIB define should be removed from the rte_config.h
> >> and meson.build shoul
On 9/24/19 12:25 PM, Bruce Richardson wrote:
> On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote:
[...]
>> PS. IMHO this SHARED_LIB define should be removed from the rte_config.h
>> and meson.build should be updated to detect 'default_library' and add it
>> as needed. Don't know
On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote:
> On 9/23/19 6:13 PM, Bruce Richardson wrote:
> [...]
> > However, testing on my system with the meson build, I'm getting lots of
> > link errors [See below]. Any suggestions?
> >
> > /Bruce
> >
> > /usr/bin/ld: /tmp/dpdk-testpmd.
On 9/23/19 6:13 PM, Bruce Richardson wrote:
[...]
> However, testing on my system with the meson build, I'm getting lots of
> link errors [See below]. Any suggestions?
>
> /Bruce
>
> /usr/bin/ld: /tmp/dpdk-testpmd.hncbtE.ltrans93.ltrans.o: in function
> `ena_stop':
> :(.text+0x9ed6): undefined r
On Mon, Sep 23, 2019 at 03:02:25PM +0200, Andrzej Ostruszka wrote:
> On 9/23/19 2:06 PM, Bruce Richardson wrote:
> > On Mon, Sep 23, 2019 at 02:03:35PM +0200, Andrzej Ostruszka wrote:
> [...]
> >> So it is similar ~5x increase as Mattias has reported. Have not
> >> measured it, but the lion share
On 9/23/19 2:06 PM, Bruce Richardson wrote:
> On Mon, Sep 23, 2019 at 02:03:35PM +0200, Andrzej Ostruszka wrote:
[...]
>> So it is similar ~5x increase as Mattias has reported. Have not
>> measured it, but the lion share of that increase is due to linking of
>> 'test' apps.
>>
>
> Interesting. Do
> If "in or out" means "either accept the patches with LTO on and no
> config option or reject them" then I disagree. Even if run time
> improvements are questionable I find the additional link time warnings
> beneficial and would like to have an easy way to turn them on when doing
> final touch
On Mon, Sep 23, 2019 at 02:03:35PM +0200, Andrzej Ostruszka wrote:
> On 9/23/19 9:23 AM, Thomas Monjalon wrote:
> [...]
> > Please can we get some numbers to understand how longer it is?
>
> Below numbers are for make based (make -j8) clean build on my system:
>
> non-LTO
> real: 144.56s, user:45
On 9/23/19 9:23 AM, Thomas Monjalon wrote:
[...]
> Please can we get some numbers to understand how longer it is?
Below numbers are for make based (make -j8) clean build on my system:
non-LTO
real: 144.56s, user:451.81s, sys:48.46s, CPU:346%
LTO
real: 607.20s, user:2141.71s, sys:88.36s, CPU:367%
On 2019-09-23 11:36, Ray Kinsella wrote:
On 23/09/2019 08:23, Thomas Monjalon wrote:
20/09/2019 09:38, Ray Kinsella:
On 19/09/2019 16:16, Bruce Richardson wrote:
On Thu, Sep 19, 2019 at 02:28:04PM +0100, Ray Kinsella wrote:
On 19/09/2019 13:35, Andrzej Ostruszka wrote:
On 9/18/19 3:32 P
On 23/09/2019 08:23, Thomas Monjalon wrote:
> 20/09/2019 09:38, Ray Kinsella:
>>
>> On 19/09/2019 16:16, Bruce Richardson wrote:
>>> On Thu, Sep 19, 2019 at 02:28:04PM +0100, Ray Kinsella wrote:
On 19/09/2019 13:35, Andrzej Ostruszka wrote:
> On 9/18/19 3:32 PM, Ray Kinsella w
20/09/2019 09:38, Ray Kinsella:
>
> On 19/09/2019 16:16, Bruce Richardson wrote:
> > On Thu, Sep 19, 2019 at 02:28:04PM +0100, Ray Kinsella wrote:
> >>
> >>
> >> On 19/09/2019 13:35, Andrzej Ostruszka wrote:
> >>> On 9/18/19 3:32 PM, Ray Kinsella wrote:
> >> ...>
> >>> Compilation time is much lon
On 19/09/2019 16:16, Bruce Richardson wrote:
> On Thu, Sep 19, 2019 at 02:28:04PM +0100, Ray Kinsella wrote:
>>
>>
>> On 19/09/2019 13:35, Andrzej Ostruszka wrote:
>>> On 9/18/19 3:32 PM, Ray Kinsella wrote:
>> ...>
>>> Compilation time is much longer. In a normal hack|fix/compile/repeat
>>> cy
On Thu, Sep 19, 2019 at 02:28:04PM +0100, Ray Kinsella wrote:
>
>
> On 19/09/2019 13:35, Andrzej Ostruszka wrote:
> > On 9/18/19 3:32 PM, Ray Kinsella wrote:
> ...>
> > Compilation time is much longer. In a normal hack|fix/compile/repeat
> > cycle with "compile" part being simple "make" the link
On 19/09/2019 13:35, Andrzej Ostruszka wrote:
> On 9/18/19 3:32 PM, Ray Kinsella wrote:
...>
> Compilation time is much longer. In a normal hack|fix/compile/repeat
> cycle with "compile" part being simple "make" the link time might be a
> bit annoying. So I imagine keeping LTO off for the most
On 9/18/19 3:32 PM, Ray Kinsella wrote:
> this is cool, good work.
> comments below.
[...]>> +CONFIG_RTE_ENABLE_LTO=n
>> +
>> #
>> # Compile to share library
>> #
>
> Why would we make this optional in this way and expand the matrix of
> different ways to build DPDK. To ask another way, why woul
this is cool, good work.
comments below.
On 17/09/2019 08:57, Andrzej Ostruszka wrote:
> This patch adds an option to enable link time optimization. In addition
> to LTO option itself (-flto) fat-lto-objects are being used. This is
> because during the build pmdinfogen scans the generated ELF ob
On Tue, Sep 17, 2019 at 09:57:45AM +0200, Andrzej Ostruszka wrote:
> This patch adds an option to enable link time optimization. In addition
> to LTO option itself (-flto) fat-lto-objects are being used. This is
> because during the build pmdinfogen scans the generated ELF objects to
> find this_
This patch adds an option to enable link time optimization. In addition
to LTO option itself (-flto) fat-lto-objects are being used. This is
because during the build pmdinfogen scans the generated ELF objects to
find this_pmd_name* symbol in symbol table. Without fat-lto-objects gcc
produces ELF
28 matches
Mail list logo
