[dpdk-dev] [PATCH] drivers: cleanup unnecessary global variables
Olivier Matz
olivier.matz at 6wind.com
Thu Apr 26 10:29:07 CEST 2018
Le 25 avril 2018 17:52:00 GMT+02:00, Pavan Nikhilesh <pbhagavatula at caviumnetworks.com> a écrit :
>On Mon, Apr 23, 2018 at 11:00:09AM +0200, Olivier Matz wrote:
>> On Fri, Apr 20, 2018 at 12:21:59AM +0530, Pavan Nikhilesh wrote:
>> > Signed-off-by: Pavan Nikhilesh <pbhagavatula at caviumnetworks.com>
>> > ---
>> > drivers/bus/dpaa/base/fman/netcfg_layer.c | 5 -----
>> > drivers/bus/dpaa/base/qbman/bman_driver.c | 4 ++--
>> > drivers/bus/dpaa/base/qbman/qman.c | 2 +-
>> > drivers/bus/dpaa/base/qbman/qman_driver.c | 4 ++--
>> > drivers/bus/dpaa/base/qbman/qman_priv.h | 1 -
>> > drivers/bus/dpaa/dpaa_bus.c | 2 +-
>> > drivers/bus/fslmc/qbman/qbman_portal.c | 3 +--
>> > drivers/bus/fslmc/qbman/qbman_portal.h | 1 -
>> > drivers/net/i40e/i40e_flow.c | 2 +-
>> > drivers/net/qede/base/bcm_osal.c | 2 +-
>> > drivers/raw/skeleton_rawdev/skeleton_rawdev.c | 2 +-
>> > lib/librte_net/net_crc_neon.h | 4 ++--
>> > 12 files changed, 12 insertions(+), 20 deletions(-)
>>
>> [...]
>>
>> > diff --git a/lib/librte_net/net_crc_neon.h
>b/lib/librte_net/net_crc_neon.h
>> > index 63fa1d4a1..cb3da72ed 100644
>> > --- a/lib/librte_net/net_crc_neon.h
>> > +++ b/lib/librte_net/net_crc_neon.h
>> > @@ -21,8 +21,8 @@ struct crc_pmull_ctx {
>> > uint64x2_t rk7_rk8;
>> > };
>> >
>> > -struct crc_pmull_ctx crc32_eth_pmull __rte_aligned(16);
>> > -struct crc_pmull_ctx crc16_ccitt_pmull __rte_aligned(16);
>> > +static struct crc_pmull_ctx crc32_eth_pmull __rte_aligned(16);
>> > +static struct crc_pmull_ctx crc16_ccitt_pmull __rte_aligned(16);
>> >
>> > /**
>>
>> Not sure it will still work after that.
>>
>> From what I see, these global variables are initialized once in
>> rte_net_crc_neon_init, and used as a const parameter in
>> crc32_eth_calc_pmull().
>>
>> Changing them to static will create an instance of these variables
>for
>> each included file, which is not what we want.
>>
>> I think that the proper way to solve it would be to add the
>definition
>> in a new .c file, and only have a declaration in the .h.
>>
>>
>Hi Olivier,
>
>Thanks for the heads up, the second solution seems more viable and
>while
>implementing it I faced few Issues. GCC doesnt suport const vector
>instructions
>i.e. the following assignment throw as compiler error.
>
> static const struct crc_pmull_ctx crc32_eth_pmull = {
> .rk1_rk2 = vld1q_u64((uint64_t[2]){0xccaa009eLLU, 0x1751997d0LLU}),
> .rk5_rk6 = vld1q_u64((uint64_t[2]){0xccaa009eLLU, 0x163cd6124LLU}),
> .rk7_rk8 = vld1q_u64((uint64_t[2]){0x1f7011640LLU, 0x1db710641LLU}),
> } __rte_aligned(16);
>
>I have gotten path the error by modifying struct crc_pmull_ctx as
>follows:
>
> struct crc_pmull_ctx {
> union {
> uint64_t rk12[2];
> uint64x2_t rk1_rk2;
> };
> union {
> uint64_t rk56[2];
> uint64x2_t rk5_rk6;
> };
> union {
> uint64_t rk78[2];
> uint64x2_t rk7_rk8;
> };
> };
>
> static const struct crc_pmull_ctx crc32_eth_pmull __rte_aligned(16) =
>{
> .rk12 = {0xccaa009eLLU, 0x1751997d0LLU},
> .rk56 = {0xccaa009eLLU, 0x163cd6124LLU},
> .rk78 = {0x1f7011640LLU, 0x1db710641LLU},
> };
>
> static const struct crc_pmull_ctx crc16_ccitt_pmull __rte_aligned(16)
>= {
> .rk12 = {0x189aeLLU, 0x8e10LLU},
> .rk56 = {0x189aeLLU, 0x114aaLLU},
> .rk78 = {0x11c581910LLU, 0x10811LLU},
> };
>
>I have checked the hex dump of the assignment with the current code and
>the
>above piece of code and they are similar.
>
>Let me know if my solution seems viable I will send the v2.
>
Looks good, just wondering about possible endianness issues. Is arm architecture supported with both little and big endian in dpdk ?
>> An even better way would be to make variable const and initialize it
>> with its content. It could even enhance performance. Something like:
>>
>> net_crc_neon.h:
>>
>> static const struct crc_pmull_ctx crc32_eth_pmull = {
>> <values...>
>> } __rte_aligned(16);
>>
>> static const struct crc_pmull_ctx crc16_ccitt_pmull = {
>> <values...>
>> } __rte_aligned(16);
>>
>
>Thanks,
>Pavan.
More information about the dev
mailing list