Re: [dpdk-dev] [PATCH v3 19/20] net/sfc: support flow action COUNT in transfer rules

[Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>]

On 7/1/21 4:35 PM, Bruce Richardson wrote:
> On Thu, Jul 01, 2021 at 04:05:56PM +0300, Andrew Rybchenko wrote:
>> @Bruce, see below.
>>
>> On 7/1/21 3:34 PM, David Marchand wrote:
>>> On Thu, Jul 1, 2021 at 11:22 AM Andrew Rybchenko
>>> <andrew.rybchenko@oktetlabs.ru> wrote:
>>>> The build works fine for me on FC34, but it has
>>>> libatomic-11.1.1-3.fc34.x86_64 installed.
>>>
>>> I first produced the issue on my "old" FC32.
>>> Afaics, for FC33 and later, gcc now depends on libatomic and the
>>> problem won't be noticed.
>>> FC32 and before are EOL, but I then reproduced the issue on RHEL 8
>>> (and Intel CI reported it on Centos 8 too).
>>
>> I see. Thanks for the clarification.
>>
>>>>
>>>> I'd like to understand what we're trying to solve here.
>>>> Are we trying to make meson to report the missing library
>>>> correctly?
>>>>
>>>> If so, I think I can do simple check using cc.links()
>>>> which will fail if the library is not found. I'll
>>>> test that it works as expected if the library is not
>>>> completely installed.
>>>>
>>>
>>> I tried below diff, and it works for me.
>>> "works" as in net/sfc gets disabled without libatomic installed:
>>>
>>> diff --git a/drivers/net/sfc/meson.build b/drivers/net/sfc/meson.build
>>> index 32b58e3d76..8d62aad774 100644
>>> --- a/drivers/net/sfc/meson.build
>>> +++ b/drivers/net/sfc/meson.build
>>> @@ -15,6 +15,7 @@ endif
>>>  if (arch_subdir != 'x86' or not dpdk_conf.get('RTE_ARCH_64')) and
>>> (arch_subdir != 'arm' or not
>>> host_machine.cpu_family().startswith('aarch64'))
>>>      build = false
>>>      reason = 'only supported on x86_64 and aarch64'
>>> +    subdir_done()
>>
>> @Bruce  Shouldn't we add subdir_done() after all build = false
>> cases? As I understand it is OK for minimum supported meson
>> version.
>>
> We can add it, no problem. For many files it's just not necessary, since in
> a lot of cases we just do assignments to variables afterward and those vars
> are just ignored and unused on return. That's the only reason it wasn't
> added generally before.

Thanks Bruce, I see the difference now.