On 12/15/21 17:33, Van Haaren, Harry wrote:
>> -----Original Message-----
>> From: David Marchand <[email protected]>
>> Sent: Wednesday, December 15, 2021 3:55 PM
>> To: Ilya Maximets <[email protected]>
>> Cc: Van Haaren, Harry <[email protected]>; [email protected];
>> Stokes, Ian <[email protected]>; Amber, Kumar <[email protected]>
>> Subject: Re: [PATCH v3] dpif-netdev: Call cpuid for x86 isa availability.
>>
>> On Tue, Dec 7, 2021 at 12:30 AM Ilya Maximets <[email protected]> wrote:
>>>> 3) Lack of constructor functions eases portability (DPDK & Windows has
>>>> issues
>> with constructors IIUC)
>>> OVS uses constructors for coverage counters, logs, and for
>>> some sockets. The last one is actually exclusively on
>>> Windows. And that never was a problem, AFAIK.
>>
>> +1
>>
>>
>> I'll keep the current implementation, but respin with an ovs_assert()
>> where needed as agreed previously.
>> More high level logs might be added in dpif in the future.
>
> Hi Ilya & David,
>
> Sorry, I'm not following what we are trying to achieve here. My understanding
> as follows;
> - David sends patch to change the CPU detection to be in OVS, using CPUID
> impl (~ like DPDK)
> - I raised concerns, suggesting an alternative implementation still using
> CPUID but better logging
> - Ilya raises concerns around using CPUID "as a whole", and notes that
> constructors on Windows are OK
I don't think I raised any concerns about the current approach
in this patch. My goal was to defend it instead.
My key points was:
1. 'I don't understand the point of debugging the CPUID itself.'
This means, I don't think we need logs, as there are other ways
to get this information.
2. There is no clear relation between CPU capabilities and
optimized implementations, so user may not understand how
these are connected. Again, having logs is a low value thing.
3. /proc/cpuinfo wasn't about checking from the code, but about
checking by user's hands to verify what capabilities are there.
That will be identical to checking the logs in most cases, hence
logs are not needed again.
4. OVS uses constructors everywhere without any problems.
And constructors are used on Windows even more than on Linux.
So, that should not be a problem.
6. regarding your solution I had pointed out a few downsides of it,
e.g.. slower work if the check will ever be needed on a hot path
in the future.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
