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