On 27.11.2019 8:49, Lance Yang (Arm Technology China) wrote:
> 
> 
>> -----Original Message-----
>> From: Ilya Maximets <i.maxim...@ovn.org>
>> Sent: Tuesday, November 26, 2019 8:48 PM
>> To: Ilya Maximets <i.maxim...@ovn.org>; Lance Yang (Arm Technology China)
>> <lance.y...@arm.com>; ovs-dev@openvswitch.org
>> Cc: Jieqiang Wang (Arm Technology China) <jieqiang.w...@arm.com>; Gavin Hu 
>> (Arm
>> Technology China) <gavin...@arm.com>; Jingzhao Ni (Arm Technology China)
>> <jingzhao...@arm.com>; dwil...@us.ibm.com; nd <n...@arm.com>; Ruifeng Wang 
>> (Arm
>> Technology China) <ruifeng.w...@arm.com>; Yanqin Wei (Arm Technology China)
>> <yanqin....@arm.com>; Ben Pfaff <b...@ovn.org>
>> Subject: Re: [ovs-dev] [PATCH v1 4/4] travis: Enable OVS Travis CI for arm
>>
>> 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.maxim...@ovn.org>
>>>>> Sent: Friday, November 22, 2019 6:36 PM
>>>>> To: Lance Yang (Arm Technology China) <lance.y...@arm.com>; Ilya
>>>>> Maximets <i.maxim...@ovn.org>; ovs-dev@openvswitch.org
>>>>> Cc: Jieqiang Wang (Arm Technology China) <jieqiang.w...@arm.com>;
>>>>> Gavin Hu (Arm Technology China) <gavin...@arm.com>; Jingzhao Ni (Arm
>>>>> Technology China) <jingzhao...@arm.com>; dwil...@us.ibm.com; nd
>>>>> <n...@arm.com>; Ruifeng Wang (Arm Technology China)
>>>>> <ruifeng.w...@arm.com>; Yanqin Wei (Arm Technology China)
>>>>> <yanqin....@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.maxim...@ovn.org>
>>>>>>> Sent: Friday, November 22, 2019 3:47 AM
>>>>>>> To: Lance Yang (Arm Technology China) <lance.y...@arm.com>; ovs-
>>>>>>> d...@openvswitch.org
>>>>>>> Cc: Jieqiang Wang (Arm Technology China) <jieqiang.w...@arm.com>;
>>>>>>> Gavin Hu (Arm Technology China) <gavin...@arm.com>; Jingzhao Ni
>>>>>>> (Arm Technology China) <jingzhao...@arm.com>; dwil...@us.ibm.com;
>>>>>>> nd <n...@arm.com>; Ruifeng Wang (Arm Technology China)
>>>>>>> <ruifeng.w...@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.
> [Lance]
> 
> Hi Ilya,
> 
> Thanks for the options you provided.
> 
> We will enable clang jobs on aarch64 in the next step. As a short-term 
> solution, we prefer the third option to temporarily disable sparse running 
> arm jobs. Meanwhile, we can wait for the sparse supports on neon.
I don't think that sparse will support neon in a near future.
So, the option #3 should be our choice.

Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to