On Fri, Sep 30, 2022 at 12:05 PM zhoumin <zhou...@loongson.cn> wrote: > On Fri, Sep 30, 2022 at 16:13, David Marchand wrote: > > On Fri, Sep 30, 2022 at 10:02 AM Min Zhou <zhou...@loongson.cn> 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). If you look at your v7 series, you will see: https://patchwork.dpdk.org/project/dpdk/list/?series=24929&state=%2A&archive=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
