[ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm

[Ilya Maximets]

On 25.11.2019 7:28, Lance Yang (Arm Technology China) wrote:
> 
> 
>> -----Original Message-----
>> From: Ilya Maximets <i.maximets at ovn.org>
>> Sent: Friday, November 22, 2019 6:36 PM
>> To: Lance Yang (Arm Technology China) <Lance.Yang at arm.com>; Ilya Maximets
>> <i.maximets at ovn.org>; ovs-dev at openvswitch.org
>> Cc: Jieqiang Wang (Arm Technology China) <Jieqiang.Wang at arm.com>; Gavin Hu (Arm
>> Technology China) <Gavin.Hu at arm.com>; Jingzhao Ni (Arm Technology China)
>> <Jingzhao.Ni at arm.com>; dwilder at us.ibm.com; nd <nd at arm.com>; Ruifeng Wang (Arm
>> Technology China) <Ruifeng.Wang at arm.com>; Yanqin Wei (Arm Technology China)
>> <Yanqin.Wei at arm.com>
>> Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm
>>
>> On 22.11.2019 10:35, Lance Yang (Arm Technology China) wrote:
>>> Hi Ilya,
>>>
>>> Thanks for your reply. Please see the inline reply.
>>>
>>> Best regards,
>>> Lance Yang
>>>
>>>> -----Original Message-----
>>>> From: Ilya Maximets <i.maximets at ovn.org>
>>>> Sent: Friday, November 22, 2019 3:47 AM
>>>> To: Lance Yang (Arm Technology China) <Lance.Yang at arm.com>; ovs-
>>>> dev at openvswitch.org
>>>> Cc: Jieqiang Wang (Arm Technology China) <Jieqiang.Wang at arm.com>;
>>>> Gavin Hu (Arm Technology China) <Gavin.Hu at arm.com>; Jingzhao Ni (Arm
>>>> Technology China) <Jingzhao.Ni at arm.com>; dwilder at us.ibm.com; nd
>>>> <nd at arm.com>; Ruifeng Wang (Arm Technology China)
>>>> <Ruifeng.Wang at arm.com>
>>>> Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI
>>>> for arm
>>>>
>>>> On 20.11.2019 9:15, Lance Yang wrote:
>>>>> Enable part of travis jobs with gcc compiler for arm64 architecture
>>>>>
>>>>> 1. Add arm jobs into the matrix in .travis.yml and define dpdk cache
>>>>> directory for arm64 architecture.
>>>>> 2. Temporarily disable sparse checker because of static code
>>>>> checking failure on arm64
>>>>
>>>> Could you provide the sparse error messages?
>>>> Maybe we could fix them instead of disabling.
>>>>
>>>>>
>>>>> Successful travis build jobs report:
>>>>> https://travis-ci.org/yzyuestc/ovs/builds/614299933
>>>>
>>>> There are some issues in Travis in above build.  It seems that Travis
>>>> fails to upload the resulted cache directory due to missing md5deep:
>>>>
>>>> ""
>>> [Lance]
>>> The issue occurred because sparse checker does not recognize some arm neon intrinsics:
>>>
>>> 1. Some components in Open vSwitch source code directly includes the header file
>> <arm_neon.h>.
>>>
>>> 2. When compiling OvS with DPDK, OvS includes some DPDK headers, which
>>> sometimes includes <arm_neon.h>. You can see the details of the error
>>> in the report at: https://travis-ci.org/yzyuestc/ovs/jobs/615414391
>>> after line 2693
>>>
>>> For the first issue where OvS directly imported the arm_neon.h,  I can fix it in my patch set
>> v2. However, for the second issue that DPDK project has imported the arm neon intrinsics, it
>> seems that I am unable to fix this issue until DPDK solved it.
>>
>> Hi.
>>
>> Thanks for the information.
>> Could, you, please, check if the following patch fixes the issue:
>>     https://patchwork.ozlabs.org/patch/1199398/
>> ?
> [Lance]
> Thanks for your reply.
> 
> I downloaded and applied the patch from patchwork. However, it seems that the patch does not work as expected. I attached the original travis report link: https://travis-ci.org/yzyuestc/ovs/jobs/616442657#L2692. You can check the error after line 2692.


Thanks for checking.  I found the root cause.
The issue is that GCC has NEON vector types as compiler built-in types.
x86 vector types (e.g. __m128i) are typedefs of a normal types with
a special 'vector_size' attribute that sparse understands.  But it
can not understand special built-in types.  Note that clang defines
NEON vector types with 'vector_size' attribute inside arm_neon.h, so
it's unclear why GCC doesn't do the same.

So, there are 3 options on how we can fix that:

1. Create special include/sparse/arm_neon.h  header and mock all the
   GCC built-ins for NEON support.  This doesn't look very hard, but
   could take some time.  I tried to re-define all the base types this
   way, but it requires something else and I need to look at exact
   arm_neon.h that is in use to understand what is missing. We, probably,
   will have to mock a bunch of NEON-specific built-in functions too.
   Not sure if it worth the efforts.

2. Add NEON support to sparse itself, i.e. allow it to understand GCC
   specific vector types and built-in functions.  That is the most
   clean solution, but requires development in a different project and
   it's unclear when this support will be integrated to upstream sparse.

3. Just disable sparse for ARM in our Travis for now.  The easiest
   solution that you've already implemented.  So, we, probably, should
   start from this.  One thing that I'm asking is to add more information
   why it was disabled in commit message and in a comment in the travis
   file.  You may use some parts of my investigation above.

Best regards, Ilya Maximets.