[dpdk-dev] EAL lcore config

[dpdk-dev] EAL lcore config

[Stephen Hemminger]

Currently the DPDK Environment Abstraction Layer has its guts on the floor ;-)
The data structure for lcore config is a holey mess and changing it would
break the ABI.

I propose that for 19.05 we introduce accessor functions and change all
internal (out side of eal directory) to use those. And add a deprecation notice.

For 19.08, we can mark the data structure as deprecated but keep it
the same.  Any thing built from source that hits the global variable
will get a warning. Binaries will still run unmodified.

For 19.11, lcore_config can be moved to eal_private.h where it belongs,
and some simple rearrangements will shrink it and get almost all data
on the same cache line. This breaks ABI but API stays the same as 19.05

After that some of the debris can be cleaned out without affecting
API or ABI in future.

[dpdk-dev] EAL lcore config

[Stephen Hemminger]

Currently the DPDK Environment Abstraction Layer has its guts on the floor ;-)
The data structure for lcore config is a holey mess and changing it would
break the ABI.

I propose that for 19.05 we introduce accessor functions and change all
internal (out side of eal directory) to use those. And add a deprecation notice.

For 19.08, we can mark the data structure as deprecated but keep it
the same.  Any thing built from source that hits the global variable
will get a warning. Binaries will still run unmodified.

For 19.11, lcore_config can be moved to eal_private.h where it belongs,
and some simple rearrangements will shrink it and get almost all data
on the same cache line. This breaks ABI but API stays the same as 19.05

After that some of the debris can be cleaned out without affecting
API or ABI in future.

Re: [dpdk-dev] EAL lcore config

[Burakov, Anatoly]

On 03-Apr-19 4:04 AM, Stephen Hemminger wrote:
> Currently the DPDK Environment Abstraction Layer has its guts on the floor ;-)
> The data structure for lcore config is a holey mess and changing it would
> break the ABI.
> 
> I propose that for 19.05 we introduce accessor functions and change all
> internal (out side of eal directory) to use those. And add a deprecation notice.
> 
> For 19.08, we can mark the data structure as deprecated but keep it
> the same.  Any thing built from source that hits the global variable
> will get a warning. Binaries will still run unmodified.
> 
> For 19.11, lcore_config can be moved to eal_private.h where it belongs,
> and some simple rearrangements will shrink it and get almost all data
> on the same cache line. This breaks ABI but API stays the same as 19.05
> 
> After that some of the debris can be cleaned out without affecting
> API or ABI in future.
> 

To be fair, the entire EAL API should receive the same treatment :) 
There are a lot of cases where the "reasonable" way to access something 
is to use a shared internal structure. I've attempted to fix some of 
that on the memory side by introducing a mountain of new API's, but more 
work is needed.

-- 
Thanks,
Anatoly

Re: [dpdk-dev] EAL lcore config

[Burakov, Anatoly]

On 03-Apr-19 4:04 AM, Stephen Hemminger wrote:
> Currently the DPDK Environment Abstraction Layer has its guts on the floor ;-)
> The data structure for lcore config is a holey mess and changing it would
> break the ABI.
> 
> I propose that for 19.05 we introduce accessor functions and change all
> internal (out side of eal directory) to use those. And add a deprecation notice.
> 
> For 19.08, we can mark the data structure as deprecated but keep it
> the same.  Any thing built from source that hits the global variable
> will get a warning. Binaries will still run unmodified.
> 
> For 19.11, lcore_config can be moved to eal_private.h where it belongs,
> and some simple rearrangements will shrink it and get almost all data
> on the same cache line. This breaks ABI but API stays the same as 19.05
> 
> After that some of the debris can be cleaned out without affecting
> API or ABI in future.
> 

To be fair, the entire EAL API should receive the same treatment :) 
There are a lot of cases where the "reasonable" way to access something 
is to use a shared internal structure. I've attempted to fix some of 
that on the memory side by introducing a mountain of new API's, but more 
work is needed.

-- 
Thanks,
Anatoly