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

Tue Nov 26 12:47:59 UTC 2019

On 26.11.2019 13:37, Ilya Maximets wrote:
> 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.

There is one more option is to use clang for ARM64 build instead of gcc.
We're not using sparse for clang builds right now.  If we'll be lucky
someday to make sparse work with clang in our Travis environment, there
should be no such big issues with NEON, because clang doesn't use built-in
types.

Is it possible to build OVS with clang on aarch64 in Travis?

Best regards, Ilya Maximets.