From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3B9CCA00C3 for ; Mon, 3 Oct 2022 14:52:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2E90640DFB; Mon, 3 Oct 2022 14:52:12 +0200 (CEST) Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by mails.dpdk.org (Postfix) with ESMTP id 92E3440695; Mon, 3 Oct 2022 14:52:09 +0200 (CEST) Received: from [192.168.0.101] (unknown [114.241.48.130]) by localhost.localdomain (Coremail) with SMTP id AQAAf8Bxnmsg2Tpjv2klAA--.58518S3; Mon, 03 Oct 2022 20:44:16 +0800 (CST) Message-ID: <53b50799-cb29-7ee6-be89-4fe21566e127@loongson.cn> Date: Mon, 3 Oct 2022 20:44:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH v7 0/7] Introduce support for LoongArch architecture To: Ali Alnubani , David Marchand Cc: "NBU-Contact-Thomas Monjalon (EXTERNAL)" , "bruce.richardson@intel.com" , "anatoly.burakov@intel.com" , "qiming.yang@intel.com" , "Yuying.Zhang@intel.com" , "jgrajcia@cisco.com" , "konstantin.v.ananyev@yandex.ru" , "dev@dpdk.org" , "maobibo@loongson.cn" , Aaron Conole , dpdklab , "ci@dpdk.org" References: <20220930080228.864681-1-zhoumin@loongson.cn> <3219c10e-79fa-39df-30f5-c2287fd1872b@loongson.cn> From: zhoumin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: AQAAf8Bxnmsg2Tpjv2klAA--.58518S3 X-Coremail-Antispam: 1UD129KBjvJXoW3XF15Ar4DuryUXFy3AF1fWFg_yoWxtF1UpF Wruan0yrZ5Jry3Ar42va109Fyj9ryrG34UXr1rtryvk34qqF13Kr4ftw4Y9F9rZr10gryq qr10q3s7X3Z8ZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBj14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr 1j6F4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv 7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r 1j6r4UM4x0Y48IcVAKI48JM4x0x7Aq67IIx4CEVc8vx2IErcIFxwACI402YVCY1x02628v n2kIc2xKxwCYjI0SjxkI62AI1cAE67vIY487MxkIecxEwVAFwVW5JwCF04k20xvY0x0EwI xGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480 Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7 IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k2 6cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxV AFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0xZFpf9x0JUDWrXUUUUU= X-CM-SenderInfo: 52kr3ztlq6z05rqj20fqof0/ X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org Hi, Ali, Thanks for your kind reply. On Mon, Oct 3, 2022 at 16:14, Ali Alnubani wrote: >> -----Original Message----- >> From: David Marchand >> Sent: Friday, September 30, 2022 5:21 PM >> To: zhoumin >> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) ; >> bruce.richardson@intel.com; anatoly.burakov@intel.com; >> qiming.yang@intel.com; Yuying.Zhang@intel.com; jgrajcia@cisco.com; >> konstantin.v.ananyev@yandex.ru; dev@dpdk.org; maobibo@loongson.cn; >> Aaron Conole ; Ali Alnubani ; >> dpdklab ; ci@dpdk.org >> Subject: Re: [PATCH v7 0/7] Introduce support for LoongArch architecture >> >> On Fri, Sep 30, 2022 at 12:05 PM zhoumin wrote: >>> On Fri, Sep 30, 2022 at 16:13, David Marchand wrote: >>>> On Fri, Sep 30, 2022 at 10:02 AM Min Zhou >> wrote: >>>>> The online documents of LoongArch architecture are here: >>>>> https://loongson.github.io/LoongArch-Documentation/README- >> EN.html >>>>> The latest build tools for LoongArch (binary) can be downloaded from: >>>>> https://github.com/loongson/build-tools >>>> Could you confirm which sources have been used to generate it? and >>>> instructions to compile it? >>> Only the cross compiler [1] is required. The instructions can be found in >>> the new added file cross_build_dpdk_for_loongarch.rst. I had added the >>> CI job for cross compiling DPDK for LoongArch in patch v7 7/7. The CI job >>> can run successfully if without the GCC warning caused by vhost. >> - Sorry, but those instructions are not useful. >> >> Is this architecture support in upstream gcc not functional? >> >> Maybe I missed the information.. I spent some time at the different >> links in the docs and in github, but I always end up with a set of >> headers, or binaries, and no reference to the exact sources that were >> used. >> I have limited trust in binaries uploaded somewhere in github. >> I don't want to spend more time on this. >> >> What I ask for, is clear instructions how to get the toolchain >> sources, and how to generate this toolchain. >> >> >> - About the vhost compilation issue, a fix in the same area of the >> code is in progress. >> It will take some time to get the fix. >> I will postpone merging the last patch until the vhost fix is ready. >> (I am rather confident all of this will be resolved by the time 22.11 >> is released). >> >> >>>>> v7: >>>>> - rebase the patchset on the main repository >>>>> - add errno.h to rte_power_intrinsics.c according with >>>>> commit 72b452c5f259 >>>> Thanks, I will look at this last revision. >>>> >>>> >>>> There is still one aspect that is unclear to me. >>>> How will the DPDK community make sure changes won't break this >>>> architecture? (I mean, runtime checks, not only compilation) >>>> IOW, what do you plan to hook to our CI to test patches submitted to >>>> the mailing list? >>> We can send our machine to UNH lab, but it may take a long time. >>> >>> GHA seems to be a good choice. However, I found that the codes of CI >>> runner of GHA [2] are arch-specific. So the CI runner currently cannot >>> run on >>> LoongArch machine. >> I see. >> >> The better solution is probably to go with "your" own CI so that that >> LoongArch has runtime non regression (functional and performance) >> tests. >> See below. >> >> >>> Are there other CI clients which are not arch-specific and can be used >>> for DPDK? >>> We can provide machines accessible by the public network. These >> machines run >>> Loongnix-server system which was built based on the source rpms of >> CentOS 8. >>> We can deploy DPDK CI client on these machines. >> There is no "DPDK CI client" per se. >> >> The DPDK project has a distributed CI made of at least 3 CI entities. >> >> Those CI test patches and post reports via mail: the ovsrobot, Intel >> CI and UNH lab. >> A CI retrieves patches from patchwork, a set of scripts is available >> in https://git.dpdk.org/tools/dpdk-ci/ (especially the poll-pw >> script). >> >> Then the way the patches are tested is something each CI handles on its side: >> - the ovsrobot creates a branch per series under the ovsrobot/dpdk >> github repository, and let GitHub action run (this is how your current >> series has been tested in GHA), >> - Intel CI have their own tool for which I have little detail, >> - UNH lab have their infrastructure too, using some Jenkins iirc. They >> provide a dashboard for reports >> https://lab.dpdk.org/results/dashboard/ and to get all details and >> logs. >> >> The common point is that, at the end of testing a series, a test >> report is sent to the (sender-restricted) test-report@ mailing list. >> >> Those reports could be done per patch, but given the amount of patches >> on the dev@ mailing list, the consensus is to test the whole series >> and report back against the last patch of a series. >> >> All of this is gathered by patchwork (the details of how it is done >> are not 100% clear to me, maybe Ali can confirm later if a >> modification is required). > A few more things to add: > Labs can either use "dpdk-ci:tools/poll-pw" to pull the patches/patchsets from the Events API endpoint (https://patches.dpdk.org/api/events), or they can use their own scripts. Events API objects should be filtered by the categories "patch-completed" or "series-completed". Yes! The scripts in the "dpdk-ci:tools/" are very useful, especially "poll-pw". We are building an internal CI system for LoongArch based on the dpdk-ci scripts and the Events API. > The script "dpdk-ci:tools/send-patch-report.sh" can be used to send reports to the mailing list in the expected report format. OK! It seems that the administer of mailing list should add the mail sender of LoongArch CI system to the whitelist. After that, the test reports from LoongArch CI system will not be blocked. > The dpdk.org servers take care of adding the report results to Patchwork once they are in the test-report archives. Thanks a lot. That is also my concerns. The dpdk.org servers are responsible for adding the report results to Patchwork. >> If you look at your v7 series, you will see: >> https://patchwork.dpdk.org/project/dpdk/list/?series=24929&state=%2A&a >> rchive=both >> - ovsrobot: ci/github-robot link >> http://mails.dpdk.org/archives/test-report/2022-September/310836.html >> - Intel CI: ci/Intel-* links, for example on the compilation test >> http://mails.dpdk.org/archives/test-report/2022-September/310822.html >> - UNH lab: all ci/iol-* links, for example on the compilation test >> http://mails.dpdk.org/archives/test-report/2022-September/310834.html >> >> So what LoongSoon could do is setup some Loongnix systems with a >> similar infrastructure and provide (native?) compilation and runtime >> test reports. >> >> I Cc'd a few people involved in all this. >> And there is the ci@ mailing list where all CI people can discuss. >> >> >> -- >> David Marchand