| Message ID | 20220930080228.864681-1-zhoumin@loongson.cn (mailing list archive) |
|---|---|
| Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@inbox.dpdk.org Delivered-To: patchwork@inbox.dpdk.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8CBFEA00C4; Fri, 30 Sep 2022 10:02:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9EA9D4280C; Fri, 30 Sep 2022 10:02:47 +0200 (CEST) Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by mails.dpdk.org (Postfix) with ESMTP id DDA0341109 for <dev@dpdk.org>; Fri, 30 Sep 2022 10:02:44 +0200 (CEST) Received: from localhost.localdomain (unknown [10.2.5.185]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxnmuUojZjOhskAA--.54564S2; Fri, 30 Sep 2022 16:02:31 +0800 (CST) From: Min Zhou <zhoumin@loongson.cn> To: thomas@monjalon.net, david.marchand@redhat.com, bruce.richardson@intel.com, anatoly.burakov@intel.com, qiming.yang@intel.com, Yuying.Zhang@intel.com, jgrajcia@cisco.com, konstantin.v.ananyev@yandex.ru, zhoumin@loongson.cn Cc: dev@dpdk.org, maobibo@loongson.cn Subject: [PATCH v7 0/7] Introduce support for LoongArch architecture Date: Fri, 30 Sep 2022 16:02:21 +0800 Message-Id: <20220930080228.864681-1-zhoumin@loongson.cn> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID: AQAAf8BxnmuUojZjOhskAA--.54564S2 X-Coremail-Antispam: 1UD129KBjvJXoW3XF48GrWUKr1fWryDWw1kGrg_yoW7Zryxpr WDCF9xKa1xGrWxZr9Iva4jgFn5A3Z7Gw12gFyagryrCryIqw1DZr4xKr9xZFy7A34Utr10 qr4fWw1UWF1UWaUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnUUvcSsGvfC2KfnxnUUI43ZEXa7xR_UUUUUUUUU== X-CM-SenderInfo: 52kr3ztlq6z05rqj20fqof0/ X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org |
| Series |
Introduce support for LoongArch architecture
|
|
Message
zhoumin
Sept. 30, 2022, 8:02 a.m. UTC
Dear team,
The following patch set is intended to support DPDK running on LoongArch
architecture.
LoongArch is the general processor architecture of Loongson Corporation
and is a new RISC ISA, which is a bit like MIPS or RISC-V.
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
v7:
- rebase the patchset on the main repository
- add errno.h to rte_power_intrinsics.c according with
commit 72b452c5f259
v6:
- place some blocks for LoongArch in a pseudo alphabetical order
- remove some macros not used
- update release notes in the correct format
- remove some headers for LoongArch, including msclock, pflock and
ticketlock, which are now non-arch specific
- rename some helpers to make them more readable
- remove some copied comments
- force-set RTE_FORCE_INTRINSICS in config and remove non-arch
specific implementations
- fix format errors in meson file reported by check-meson.py
- rebase the patchset on the main repository
v5:
- merge all patches for supporting LoongArch EAL into one patch
- add LoongArch cross compilation document and update some documents
related to architecture
- remove vector stubs added for LoongArch in net/i40e and net/ixgbe
- add LOONGARCH64 cross compilation job in github ci
v4:
- rebase the patchset on the main repository of version 22.07.0
v3:
- add URL for cross compile tool chain
- remove rte_lpm_lsx.h which was a dummy vector implementation
because there is already a scalar implementation, thanks to
Michal Mazurek
- modify the name of compiler for cross compiling
- remove useless variable in meson.build
v2:
- use standard atomics of toolchain to implement
atomic operations
- implement spinlock based on standard atomics
Min Zhou (7):
eal/loongarch: support LoongArch architecture
net/ixgbe: add vector stubs for LoongArch
net/memif: set memfd syscall ID on LoongArch
net/tap: set BPF syscall ID for LoongArch
examples/l3fwd: enable LoongArch operation
test/cpuflags: add test for LoongArch cpu flag
ci: add LOONGARCH64 cross compilation job
.ci/linux-build.sh | 10 ++
.github/workflows/build.yml | 10 +-
MAINTAINERS | 6 ++
app/test/test_cpuflags.c | 41 ++++++++
app/test/test_xmmt_ops.h | 12 +++
.../loongarch/loongarch_loongarch64_linux_gcc | 16 ++++
config/loongarch/meson.build | 43 +++++++++
doc/guides/contributing/design.rst | 2 +-
.../cross_build_dpdk_for_loongarch.rst | 87 +++++++++++++++++
doc/guides/linux_gsg/index.rst | 1 +
doc/guides/nics/features.rst | 8 ++
doc/guides/nics/features/default.ini | 1 +
doc/guides/nics/features/ixgbe.ini | 1 +
doc/guides/rel_notes/release_22_11.rst | 7 ++
drivers/net/i40e/meson.build | 6 ++
drivers/net/ixgbe/ixgbe_rxtx.c | 7 +-
drivers/net/memif/rte_eth_memif.h | 2 +
drivers/net/tap/tap_bpf.h | 2 +
examples/l3fwd/l3fwd_em.c | 8 ++
lib/eal/linux/eal_memory.c | 4 +
lib/eal/loongarch/include/meson.build | 18 ++++
lib/eal/loongarch/include/rte_atomic.h | 47 ++++++++++
lib/eal/loongarch/include/rte_byteorder.h | 40 ++++++++
lib/eal/loongarch/include/rte_cpuflags.h | 39 ++++++++
lib/eal/loongarch/include/rte_cycles.h | 47 ++++++++++
lib/eal/loongarch/include/rte_io.h | 18 ++++
lib/eal/loongarch/include/rte_memcpy.h | 61 ++++++++++++
lib/eal/loongarch/include/rte_pause.h | 24 +++++
.../loongarch/include/rte_power_intrinsics.h | 20 ++++
lib/eal/loongarch/include/rte_prefetch.h | 47 ++++++++++
lib/eal/loongarch/include/rte_rwlock.h | 42 +++++++++
lib/eal/loongarch/include/rte_spinlock.h | 64 +++++++++++++
lib/eal/loongarch/include/rte_vect.h | 65 +++++++++++++
lib/eal/loongarch/meson.build | 11 +++
lib/eal/loongarch/rte_cpuflags.c | 93 +++++++++++++++++++
lib/eal/loongarch/rte_cycles.c | 45 +++++++++
lib/eal/loongarch/rte_hypervisor.c | 11 +++
lib/eal/loongarch/rte_power_intrinsics.c | 53 +++++++++++
meson.build | 2 +
39 files changed, 1017 insertions(+), 4 deletions(-)
create mode 100644 config/loongarch/loongarch_loongarch64_linux_gcc
create mode 100644 config/loongarch/meson.build
create mode 100644 doc/guides/linux_gsg/cross_build_dpdk_for_loongarch.rst
create mode 100644 lib/eal/loongarch/include/meson.build
create mode 100644 lib/eal/loongarch/include/rte_atomic.h
create mode 100644 lib/eal/loongarch/include/rte_byteorder.h
create mode 100644 lib/eal/loongarch/include/rte_cpuflags.h
create mode 100644 lib/eal/loongarch/include/rte_cycles.h
create mode 100644 lib/eal/loongarch/include/rte_io.h
create mode 100644 lib/eal/loongarch/include/rte_memcpy.h
create mode 100644 lib/eal/loongarch/include/rte_pause.h
create mode 100644 lib/eal/loongarch/include/rte_power_intrinsics.h
create mode 100644 lib/eal/loongarch/include/rte_prefetch.h
create mode 100644 lib/eal/loongarch/include/rte_rwlock.h
create mode 100644 lib/eal/loongarch/include/rte_spinlock.h
create mode 100644 lib/eal/loongarch/include/rte_vect.h
create mode 100644 lib/eal/loongarch/meson.build
create mode 100644 lib/eal/loongarch/rte_cpuflags.c
create mode 100644 lib/eal/loongarch/rte_cycles.c
create mode 100644 lib/eal/loongarch/rte_hypervisor.c
create mode 100644 lib/eal/loongarch/rte_power_intrinsics.c
Comments
Hello, On Fri, Sep 30, 2022 at 10:02 AM Min Zhou <zhoumin@loongson.cn> wrote: > > Dear team, > > The following patch set is intended to support DPDK running on LoongArch > architecture. > > LoongArch is the general processor architecture of Loongson Corporation > and is a new RISC ISA, which is a bit like MIPS or RISC-V. > > 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? > > 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?
Hi, David, Thanks a lot for your kind reply. On Fri, Sep 30, 2022 at 16:13, David Marchand wrote: > Hello, > > On Fri, Sep 30, 2022 at 10:02 AM Min Zhou <zhoumin@loongson.cn> wrote: >> Dear team, >> >> The following patch set is intended to support DPDK running on LoongArch >> architecture. >> >> LoongArch is the general processor architecture of Loongson Corporation >> and is a new RISC ISA, which is a bit like MIPS or RISC-V. >> >> 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. >> 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. 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. [1] https://github.com/loongson/build-tools/releases/download/2022.08.11/loongarch64-clfs-5.1-cross-tools-gcc-glibc.tar.xz [2] https://github.com/actions/runner -- Thanks, Min Zhou
On Fri, Sep 30, 2022 at 12:05 PM zhoumin <zhoumin@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 <zhoumin@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.
Hi, David, Thanks a lot for your helpful reply. On Fri, Sep 30, 2022 at 22:20, David Marchand wrote: > On Fri, Sep 30, 2022 at 12:05 PM zhoumin<zhoumin@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<zhoumin@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. I'm Sorry, I misunderstood the 'instructions' you said. The process of making the toolchain is a little complicated. So I made a script used to generate the toolchain from source codes. The content of the script is as follows: #!/bin/bash # Prepare the working directories export SYSDIR=/tmp/la_cross_tools mkdir -pv ${SYSDIR} mkdir -pv ${SYSDIR}/downloads mkdir -pv ${SYSDIR}/build install -dv ${SYSDIR}/cross-tools install -dv ${SYSDIR}/sysroot set +h umask 022 # Set the environment variables to be used next export BUILDDIR="${SYSDIR}/build" export DOWNLOADDIR="${SYSDIR}/downloads" export LC_ALL=POSIX export CROSS_HOST="$(echo $MACHTYPE | sed "s/$(echo $MACHTYPE | cut -d- -f2)/cross/")" export CROSS_TARGET="loongarch64-unknown-linux-gnu" export MABI="lp64d" export BUILD64="-mabi=lp64d" export PATH=${SYSDIR}/cross-tools/bin:/bin:/usr/bin export JOBS=-j8 unset CFLAGS unset CXXFLAGS # Download the source code archives pushd $DOWNLOADDIR wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.19.tar.gz wget https://ftp.gnu.org/gnu/gmp/gmp-6.2.1.tar.xz wget https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0.tar.xz wget https://ftp.gnu.org/gnu/mpc/mpc-1.2.1.tar.gz wget https://ftp.gnu.org/gnu/libc/glibc-2.36.tar.xz popd # Make and install the linux header files tar xvf ${DOWNLOADDIR}/linux-5.19.tar.gz -C ${BUILDDIR} pushd ${BUILDDIR}/linux-5.19 make mrproper make ARCH=loongarch INSTALL_HDR_PATH=dest headers_install find dest/include -name '.*' -delete mkdir -pv ${SYSDIR}/sysroot/usr/include cp -rv dest/include/* ${SYSDIR}/sysroot/usr/include popd # Prepare the binutils source code git clone git://sourceware.org/git/binutils-gdb.git --depth 1 pushd binutils-gdb git archive --format=tar.gz --prefix=binutils-2.38/ --output ../binutils-2.38.tar.gz "master" popd mv binutils-2.38.tar.gz ${DOWNLOADDIR} # Make and install the binutils files tar xvf ${DOWNLOADDIR}/binutils-2.38.tar.gz -C ${BUILDDIR} pushd ${BUILDDIR}/binutils-2.38 rm -rf gdb* libdecnumber readline sim mkdir tools-build pushd tools-build CC=gcc AR=ar AS=as \ ../configure --prefix=${SYSDIR}/cross-tools --build=${CROSS_HOST} --host=${CROSS_HOST} \ --target=${CROSS_TARGET} --with-sysroot=${SYSDIR}/sysroot --disable-nls \ --disable-static --disable-werror --enable-64-bit-bfd make configure-host ${JOBS} make ${JOBS} make install-strip cp -v ../include/libiberty.h ${SYSDIR}/sysroot/usr/include popd popd # Make and install the gmp files used by GCC tar xvf ${DOWNLOADDIR}/gmp-6.2.1.tar.xz -C ${BUILDDIR} pushd ${BUILDDIR}/gmp-6.2.1 ./configure --prefix=${SYSDIR}/cross-tools --enable-cxx --disable-static make ${JOBS} make install popd # Make and install the mpfr files used by GCC tar xvf ${DOWNLOADDIR}/mpfr-4.1.0.tar.xz -C ${BUILDDIR} pushd ${BUILDDIR}/mpfr-4.1.0 ./configure --prefix=${SYSDIR}/cross-tools --disable-static --with-gmp=${SYSDIR}/cross-tools make ${JOBS} make install popd # Make and install the mpc files used by GCC tar xvf ${DOWNLOADDIR}/mpc-1.2.1.tar.gz -C ${BUILDDIR} pushd ${BUILDDIR}/mpc-1.2.1 ./configure --prefix=${SYSDIR}/cross-tools --disable-static --with-gmp=${SYSDIR}/cross-tools make ${JOBS} make install popd # Prepare the gcc source code git clone git://sourceware.org/git/gcc.git --depth 1 pushd gcc git archive --format=tar.gz --prefix=gcc-13.0.0/ --output ../gcc-13.0.0.tar.gz "master" popd mv gcc-13.0.0.tar.gz ${DOWNLOADDIR} # Make and install the simplified GCC files tar xvf ${DOWNLOADDIR}/gcc-13.0.0.tar.gz -C ${BUILDDIR} pushd ${BUILDDIR}/gcc-13.0.0 mkdir tools-build pushd tools-build AR=ar LDFLAGS="-Wl,-rpath,${SYSDIR}/cross-tools/lib" \ ../configure --prefix=${SYSDIR}/cross-tools --build=${CROSS_HOST} --host=${CROSS_HOST} \ --target=${CROSS_TARGET} --disable-nls \ --with-mpfr=${SYSDIR}/cross-tools --with-gmp=${SYSDIR}/cross-tools \ --with-mpc=${SYSDIR}/cross-tools \ --with-newlib --disable-shared --with-sysroot=${SYSDIR}/sysroot \ --disable-decimal-float --disable-libgomp --disable-libitm \ --disable-libsanitizer --disable-libquadmath --disable-threads \ --disable-target-zlib --with-system-zlib --enable-checking=release \ --enable-default-pie \ --enable-languages=c make all-gcc all-target-libgcc ${JOBS} make install-strip-gcc install-strip-target-libgcc popd popd # Make and install the glibc files tar xvf ${DOWNLOADDIR}/glibc-2.36.tar.xz -C ${BUILDDIR} pushd ${BUILDDIR}/glibc-2.36 sed -i "s@5.15.0@4.15.0@g" sysdeps/unix/sysv/linux/loongarch/configure{,.ac} mkdir -v build-64 pushd build-64 BUILD_CC="gcc" CC="${CROSS_TARGET}-gcc ${BUILD64}" \ CXX="${CROSS_TARGET}-gcc ${BUILD64}" \ AR="${CROSS_TARGET}-ar" RANLIB="${CROSS_TARGET}-ranlib" \ ../configure --prefix=/usr --host=${CROSS_TARGET} --build=${CROSS_HOST} \ --libdir=/usr/lib64 --libexecdir=/usr/lib64/glibc \ --with-binutils=${SYSDIR}/cross-tools/bin \ --with-headers=${SYSDIR}/sysroot/usr/include \ --enable-stack-protector=strong --enable-add-ons \ --disable-werror libc_cv_slibdir=/usr/lib64 \ --enable-kernel=4.15 make ${JOBS} make DESTDIR=${SYSDIR}/sysroot install cp -v ../nscd/nscd.conf ${SYSDIR}/sysroot/etc/nscd.conf mkdir -pv ${SYSDIR}/sysroot/var/cache/nscd install -v -Dm644 ../nscd/nscd.tmpfiles \ ${SYSDIR}/sysroot/usr/lib/tmpfiles.d/nscd.conf install -v -Dm644 ../nscd/nscd.service \ ${SYSDIR}/sysroot/usr/lib/systemd/system/nscd.service popd mkdir -v build-locale pushd build-locale ../configure --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/lib64/glibc \ --enable-stack-protector=strong --enable-add-ons \ --disable-werror libc_cv_slibdir=/usr/lib64 make ${JOBS} make DESTDIR=${SYSDIR}/sysroot localedata/install-locales popd popd # Make and install the complete GCC files tar xvf ${DOWNLOADDIR}/gcc-13.0.0.tar.gz -C ${BUILDDIR} pushd ${BUILDDIR}/gcc-13.0.0 mkdir tools-build-all pushd tools-build-all AR=ar LDFLAGS="-Wl,-rpath,${SYSDIR}/cross-tools/lib" \ ../configure --prefix=${SYSDIR}/cross-tools --build=${CROSS_HOST} \ --host=${CROSS_HOST} --target=${CROSS_TARGET} \ --with-sysroot=${SYSDIR}/sysroot --with-mpfr=${SYSDIR}/cross-tools \ --with-gmp=${SYSDIR}/cross-tools --with-mpc=${SYSDIR}/cross-tools \ --enable-__cxa_atexit --enable-threads=posix --with-system-zlib \ --enable-libstdcxx-time --enable-checking=release \ --enable-default-pie \ --enable-languages=c,c++,fortran,objc,obj-c++,lto make ${JOBS} make install-strip popd popd I have tested the script on an x86 machine running CentOS 8 system. I successfully used the toolchain generated by this script to cross compiling DPDK for LoongArch. This script may take one hour to complete, which depends on the speed of network and the performance of machine used. This script requires at least 15G of disk space when running. > - 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). Thank you for your concern and efforts on this issue. >>>> 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. Yes, we had spent some time building our own CI system and made the CI system working internally. Our CI system based on Jenkins and DTS. Every time we submit patch to our internal DPDK repository, the Jenkins will be triggered to call DTS for testing the patch. But we have only run less than 100 unit tests currently. More test cases will be added later. >> 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 > inhttps://git.dpdk.org/tools/dpdk-ci/ (especially the poll-pw > script). This information is really very useful. Please forgive me for not taking the time to study dpdk-ci. It sounds that dpdk-ci can help us to test patches submitted to the mailing list for LoongArch. > 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. This process doesn't seem very complicated. We can build a CI system to retrieve patches from patchwork by dpdk-ci and compile, test them on Loongnix system. After completing those jobs, we will generate the test report and send it to the test-report@ mailing list. But my concern is which set of test cases we need to run. Besides, can patchwork gather the test reports we sent and show them on the patch details web page? > 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). Thank you for your consideration. > 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. Yes, we will build the CI system talked above on Loongnix systems to provide compilation and runtime test reports for DPDK on LoongArch machine. But It will take some time to set up this system and make it run stably. We will get this done as soon as possible. > I Cc'd a few people involved in all this. > And there is the ci@ mailing list where all CI people can discuss. Thanks a lot for all your help. -- Thanks, Min Zhou
> -----Original Message----- > From: David Marchand <david.marchand@redhat.com> > Sent: Friday, September 30, 2022 5:21 PM > To: zhoumin <zhoumin@loongson.cn> > Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; > 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 <aconole@redhat.com>; Ali Alnubani <alialnu@nvidia.com>; > dpdklab <dpdklab@iol.unh.edu>; ci@dpdk.org > Subject: Re: [PATCH v7 0/7] Introduce support for LoongArch architecture > > On Fri, Sep 30, 2022 at 12:05 PM zhoumin <zhoumin@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 <zhoumin@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). 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". The script "dpdk-ci:tools/send-patch-report.sh" can be used to send reports to the mailing list in the expected report format. The dpdk.org servers take care of adding the report results to Patchwork once they are in the test-report archives. > > 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
Hi, Ali, Thanks for your kind reply. On Mon, Oct 3, 2022 at 16:14, Ali Alnubani wrote: >> -----Original Message----- >> From: David Marchand <david.marchand@redhat.com> >> Sent: Friday, September 30, 2022 5:21 PM >> To: zhoumin <zhoumin@loongson.cn> >> Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; >> 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 <aconole@redhat.com>; Ali Alnubani <alialnu@nvidia.com>; >> dpdklab <dpdklab@iol.unh.edu>; ci@dpdk.org >> Subject: Re: [PATCH v7 0/7] Introduce support for LoongArch architecture >> >> On Fri, Sep 30, 2022 at 12:05 PM zhoumin <zhoumin@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 <zhoumin@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). > 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
Hello Min, On Sat, Oct 1, 2022 at 4:26 PM zhoumin <zhoumin@loongson.cn> wrote: > I'm Sorry, I misunderstood the 'instructions' you said. The process of > making the toolchain is a little complicated. So I made a script used to > generate the toolchain from source codes. The content of the script is > as follows: > I successfully generated a cross compilation toolchain with this script. I ran this script in a UBI8 image (iow RHEL8), with the codeready-builder-for-rhel-8-x86_64-rpms repo enabled and the following packages installed: # subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms # dnf install bison diffutils file flex gcc gcc-c++ git gmp-devel libtool make python3 rsync texinfo wget xz zlib-devel The script below works, but it is really better to run it with -e. # bash -e $script > #!/bin/bash > > # Prepare the working directories > export SYSDIR=/tmp/la_cross_tools > mkdir -pv ${SYSDIR} > mkdir -pv ${SYSDIR}/downloads > mkdir -pv ${SYSDIR}/build > install -dv ${SYSDIR}/cross-tools > install -dv ${SYSDIR}/sysroot > > set +h > umask 022 > # Set the environment variables to be used next > export BUILDDIR="${SYSDIR}/build" > export DOWNLOADDIR="${SYSDIR}/downloads" > export LC_ALL=POSIX > export CROSS_HOST="$(echo $MACHTYPE | sed "s/$(echo $MACHTYPE | cut -d- -f2)/cross/")" > export CROSS_TARGET="loongarch64-unknown-linux-gnu" > export MABI="lp64d" > export BUILD64="-mabi=lp64d" > export PATH=${SYSDIR}/cross-tools/bin:/bin:/usr/bin > export JOBS=-j8 > unset CFLAGS > unset CXXFLAGS > > # Download the source code archives > pushd $DOWNLOADDIR > wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.19.tar.gz > wget https://ftp.gnu.org/gnu/gmp/gmp-6.2.1.tar.xz > wget https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0.tar.xz > wget https://ftp.gnu.org/gnu/mpc/mpc-1.2.1.tar.gz > wget https://ftp.gnu.org/gnu/libc/glibc-2.36.tar.xz > popd > > # Make and install the linux header files > tar xvf ${DOWNLOADDIR}/linux-5.19.tar.gz -C ${BUILDDIR} > pushd ${BUILDDIR}/linux-5.19 > make mrproper > make ARCH=loongarch INSTALL_HDR_PATH=dest headers_install > find dest/include -name '.*' -delete > mkdir -pv ${SYSDIR}/sysroot/usr/include > cp -rv dest/include/* ${SYSDIR}/sysroot/usr/include > popd > > # Prepare the binutils source code > git clone git://sourceware.org/git/binutils-gdb.git --depth 1 > pushd binutils-gdb > git archive --format=tar.gz --prefix=binutils-2.38/ --output ../binutils-2.38.tar.gz "master" > popd > mv binutils-2.38.tar.gz ${DOWNLOADDIR} > > # Make and install the binutils files > tar xvf ${DOWNLOADDIR}/binutils-2.38.tar.gz -C ${BUILDDIR} > pushd ${BUILDDIR}/binutils-2.38 > rm -rf gdb* libdecnumber readline sim > mkdir tools-build > pushd tools-build > CC=gcc AR=ar AS=as \ > ../configure --prefix=${SYSDIR}/cross-tools --build=${CROSS_HOST} --host=${CROSS_HOST} \ > --target=${CROSS_TARGET} --with-sysroot=${SYSDIR}/sysroot --disable-nls \ > --disable-static --disable-werror --enable-64-bit-bfd > make configure-host ${JOBS} > make ${JOBS} > make install-strip > cp -v ../include/libiberty.h ${SYSDIR}/sysroot/usr/include > popd > popd > > # Make and install the gmp files used by GCC > tar xvf ${DOWNLOADDIR}/gmp-6.2.1.tar.xz -C ${BUILDDIR} > pushd ${BUILDDIR}/gmp-6.2.1 > ./configure --prefix=${SYSDIR}/cross-tools --enable-cxx --disable-static > make ${JOBS} > make install > popd > > # Make and install the mpfr files used by GCC > tar xvf ${DOWNLOADDIR}/mpfr-4.1.0.tar.xz -C ${BUILDDIR} > pushd ${BUILDDIR}/mpfr-4.1.0 > ./configure --prefix=${SYSDIR}/cross-tools --disable-static --with-gmp=${SYSDIR}/cross-tools > make ${JOBS} > make install > popd > > # Make and install the mpc files used by GCC > tar xvf ${DOWNLOADDIR}/mpc-1.2.1.tar.gz -C ${BUILDDIR} > pushd ${BUILDDIR}/mpc-1.2.1 > ./configure --prefix=${SYSDIR}/cross-tools --disable-static --with-gmp=${SYSDIR}/cross-tools > make ${JOBS} > make install > popd > > # Prepare the gcc source code > git clone git://sourceware.org/git/gcc.git --depth 1 > pushd gcc > git archive --format=tar.gz --prefix=gcc-13.0.0/ --output ../gcc-13.0.0.tar.gz "master" > popd > mv gcc-13.0.0.tar.gz ${DOWNLOADDIR} > > # Make and install the simplified GCC files > tar xvf ${DOWNLOADDIR}/gcc-13.0.0.tar.gz -C ${BUILDDIR} > pushd ${BUILDDIR}/gcc-13.0.0 > mkdir tools-build > pushd tools-build > AR=ar LDFLAGS="-Wl,-rpath,${SYSDIR}/cross-tools/lib" \ > ../configure --prefix=${SYSDIR}/cross-tools --build=${CROSS_HOST} --host=${CROSS_HOST} \ > --target=${CROSS_TARGET} --disable-nls \ > --with-mpfr=${SYSDIR}/cross-tools --with-gmp=${SYSDIR}/cross-tools \ > --with-mpc=${SYSDIR}/cross-tools \ > --with-newlib --disable-shared --with-sysroot=${SYSDIR}/sysroot \ > --disable-decimal-float --disable-libgomp --disable-libitm \ > --disable-libsanitizer --disable-libquadmath --disable-threads \ > --disable-target-zlib --with-system-zlib --enable-checking=release \ > --enable-default-pie \ > --enable-languages=c > make all-gcc all-target-libgcc ${JOBS} > make install-strip-gcc install-strip-target-libgcc > popd > popd > > # Make and install the glibc files > tar xvf ${DOWNLOADDIR}/glibc-2.36.tar.xz -C ${BUILDDIR} > pushd ${BUILDDIR}/glibc-2.36 > sed -i "s@5.15.0@4.15.0@g" sysdeps/unix/sysv/linux/loongarch/configure{,.ac} > mkdir -v build-64 > pushd build-64 > BUILD_CC="gcc" CC="${CROSS_TARGET}-gcc ${BUILD64}" \ > CXX="${CROSS_TARGET}-gcc ${BUILD64}" \ > AR="${CROSS_TARGET}-ar" RANLIB="${CROSS_TARGET}-ranlib" \ > ../configure --prefix=/usr --host=${CROSS_TARGET} --build=${CROSS_HOST} \ > --libdir=/usr/lib64 --libexecdir=/usr/lib64/glibc \ > --with-binutils=${SYSDIR}/cross-tools/bin \ > --with-headers=${SYSDIR}/sysroot/usr/include \ > --enable-stack-protector=strong --enable-add-ons \ > --disable-werror libc_cv_slibdir=/usr/lib64 \ > --enable-kernel=4.15 > make ${JOBS} > make DESTDIR=${SYSDIR}/sysroot install > cp -v ../nscd/nscd.conf ${SYSDIR}/sysroot/etc/nscd.conf > mkdir -pv ${SYSDIR}/sysroot/var/cache/nscd > install -v -Dm644 ../nscd/nscd.tmpfiles \ > ${SYSDIR}/sysroot/usr/lib/tmpfiles.d/nscd.conf > install -v -Dm644 ../nscd/nscd.service \ > ${SYSDIR}/sysroot/usr/lib/systemd/system/nscd.service > popd > mkdir -v build-locale > pushd build-locale > ../configure --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/lib64/glibc \ > --enable-stack-protector=strong --enable-add-ons \ > --disable-werror libc_cv_slibdir=/usr/lib64 > make ${JOBS} > make DESTDIR=${SYSDIR}/sysroot localedata/install-locales > popd > popd > > # Make and install the complete GCC files > tar xvf ${DOWNLOADDIR}/gcc-13.0.0.tar.gz -C ${BUILDDIR} > pushd ${BUILDDIR}/gcc-13.0.0 > mkdir tools-build-all > pushd tools-build-all > AR=ar LDFLAGS="-Wl,-rpath,${SYSDIR}/cross-tools/lib" \ > ../configure --prefix=${SYSDIR}/cross-tools --build=${CROSS_HOST} \ > --host=${CROSS_HOST} --target=${CROSS_TARGET} \ > --with-sysroot=${SYSDIR}/sysroot --with-mpfr=${SYSDIR}/cross-tools \ > --with-gmp=${SYSDIR}/cross-tools --with-mpc=${SYSDIR}/cross-tools \ > --enable-__cxa_atexit --enable-threads=posix --with-system-zlib \ > --enable-libstdcxx-time --enable-checking=release \ > --enable-default-pie \ > --enable-languages=c,c++,fortran,objc,obj-c++,lto > make ${JOBS} > make install-strip > popd > popd >
On Fri, Sep 30, 2022 at 10:02 AM Min Zhou <zhoumin@loongson.cn> wrote: > > Dear team, > > The following patch set is intended to support DPDK running on LoongArch > architecture. > > LoongArch is the general processor architecture of Loongson Corporation > and is a new RISC ISA, which is a bit like MIPS or RISC-V. > > 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 > > v7: > - rebase the patchset on the main repository > - add errno.h to rte_power_intrinsics.c according with > commit 72b452c5f259 I did some comments on patch 1. I am still considering the patch 7 (hooking into GHA) but the rest looks good enough to me. Could you respin the series? Thanks!
Hi, David, Thanks for your kind reply. On Tue, Oct 4, 2022 at 00:30, David Marchand wrote: > Hello Min, > > On Sat, Oct 1, 2022 at 4:26 PM zhoumin <zhoumin@loongson.cn> wrote: >> I'm Sorry, I misunderstood the 'instructions' you said. The process of >> making the toolchain is a little complicated. So I made a script used to >> generate the toolchain from source codes. The content of the script is >> as follows: >> > I successfully generated a cross compilation toolchain with this script. > > I ran this script in a UBI8 image (iow RHEL8), with the > codeready-builder-for-rhel-8-x86_64-rpms repo enabled and the > following packages installed: > # subscription-manager repos --enable codeready-builder-for-rhel-8-x86_64-rpms > # dnf install bison diffutils file flex gcc gcc-c++ git gmp-devel > libtool make python3 rsync texinfo wget xz zlib-devel I'm sorry. I forgot to give the dependencies for build the cross compilation toolchain. These dependencies can be added into the documentation for LoongArch. Thanks a lot. > The script below works, but it is really better to run it with -e. > > # bash -e $script Yes, thanks. The script will run for a long time. It is better to run it with -e in order to exit quickly when an error has occured. > >> #!/bin/bash >> >> # Prepare the working directories >> export SYSDIR=/tmp/la_cross_tools >> mkdir -pv ${SYSDIR} >> mkdir -pv ${SYSDIR}/downloads >> mkdir -pv ${SYSDIR}/build >> install -dv ${SYSDIR}/cross-tools >> install -dv ${SYSDIR}/sysroot >> >> set +h >> umask 022 >> # Set the environment variables to be used next >> export BUILDDIR="${SYSDIR}/build" >> export DOWNLOADDIR="${SYSDIR}/downloads" >> export LC_ALL=POSIX >> export CROSS_HOST="$(echo $MACHTYPE | sed "s/$(echo $MACHTYPE | cut -d- -f2)/cross/")" >> export CROSS_TARGET="loongarch64-unknown-linux-gnu" >> export MABI="lp64d" >> export BUILD64="-mabi=lp64d" >> export PATH=${SYSDIR}/cross-tools/bin:/bin:/usr/bin >> export JOBS=-j8 >> unset CFLAGS >> unset CXXFLAGS >> >> # Download the source code archives >> pushd $DOWNLOADDIR >> wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.19.tar.gz >> wget https://ftp.gnu.org/gnu/gmp/gmp-6.2.1.tar.xz >> wget https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0.tar.xz >> wget https://ftp.gnu.org/gnu/mpc/mpc-1.2.1.tar.gz >> wget https://ftp.gnu.org/gnu/libc/glibc-2.36.tar.xz >> popd >> >> # Make and install the linux header files >> tar xvf ${DOWNLOADDIR}/linux-5.19.tar.gz -C ${BUILDDIR} >> pushd ${BUILDDIR}/linux-5.19 >> make mrproper >> make ARCH=loongarch INSTALL_HDR_PATH=dest headers_install >> find dest/include -name '.*' -delete >> mkdir -pv ${SYSDIR}/sysroot/usr/include >> cp -rv dest/include/* ${SYSDIR}/sysroot/usr/include >> popd >> >> # Prepare the binutils source code >> git clone git://sourceware.org/git/binutils-gdb.git --depth 1 >> pushd binutils-gdb >> git archive --format=tar.gz --prefix=binutils-2.38/ --output ../binutils-2.38.tar.gz "master" >> popd >> mv binutils-2.38.tar.gz ${DOWNLOADDIR} >> >> # Make and install the binutils files >> tar xvf ${DOWNLOADDIR}/binutils-2.38.tar.gz -C ${BUILDDIR} >> pushd ${BUILDDIR}/binutils-2.38 >> rm -rf gdb* libdecnumber readline sim >> mkdir tools-build >> pushd tools-build >> CC=gcc AR=ar AS=as \ >> ../configure --prefix=${SYSDIR}/cross-tools --build=${CROSS_HOST} --host=${CROSS_HOST} \ >> --target=${CROSS_TARGET} --with-sysroot=${SYSDIR}/sysroot --disable-nls \ >> --disable-static --disable-werror --enable-64-bit-bfd >> make configure-host ${JOBS} >> make ${JOBS} >> make install-strip >> cp -v ../include/libiberty.h ${SYSDIR}/sysroot/usr/include >> popd >> popd >> >> # Make and install the gmp files used by GCC >> tar xvf ${DOWNLOADDIR}/gmp-6.2.1.tar.xz -C ${BUILDDIR} >> pushd ${BUILDDIR}/gmp-6.2.1 >> ./configure --prefix=${SYSDIR}/cross-tools --enable-cxx --disable-static >> make ${JOBS} >> make install >> popd >> >> # Make and install the mpfr files used by GCC >> tar xvf ${DOWNLOADDIR}/mpfr-4.1.0.tar.xz -C ${BUILDDIR} >> pushd ${BUILDDIR}/mpfr-4.1.0 >> ./configure --prefix=${SYSDIR}/cross-tools --disable-static --with-gmp=${SYSDIR}/cross-tools >> make ${JOBS} >> make install >> popd >> >> # Make and install the mpc files used by GCC >> tar xvf ${DOWNLOADDIR}/mpc-1.2.1.tar.gz -C ${BUILDDIR} >> pushd ${BUILDDIR}/mpc-1.2.1 >> ./configure --prefix=${SYSDIR}/cross-tools --disable-static --with-gmp=${SYSDIR}/cross-tools >> make ${JOBS} >> make install >> popd >> >> # Prepare the gcc source code >> git clone git://sourceware.org/git/gcc.git --depth 1 >> pushd gcc >> git archive --format=tar.gz --prefix=gcc-13.0.0/ --output ../gcc-13.0.0.tar.gz "master" >> popd >> mv gcc-13.0.0.tar.gz ${DOWNLOADDIR} >> >> # Make and install the simplified GCC files >> tar xvf ${DOWNLOADDIR}/gcc-13.0.0.tar.gz -C ${BUILDDIR} >> pushd ${BUILDDIR}/gcc-13.0.0 >> mkdir tools-build >> pushd tools-build >> AR=ar LDFLAGS="-Wl,-rpath,${SYSDIR}/cross-tools/lib" \ >> ../configure --prefix=${SYSDIR}/cross-tools --build=${CROSS_HOST} --host=${CROSS_HOST} \ >> --target=${CROSS_TARGET} --disable-nls \ >> --with-mpfr=${SYSDIR}/cross-tools --with-gmp=${SYSDIR}/cross-tools \ >> --with-mpc=${SYSDIR}/cross-tools \ >> --with-newlib --disable-shared --with-sysroot=${SYSDIR}/sysroot \ >> --disable-decimal-float --disable-libgomp --disable-libitm \ >> --disable-libsanitizer --disable-libquadmath --disable-threads \ >> --disable-target-zlib --with-system-zlib --enable-checking=release \ >> --enable-default-pie \ >> --enable-languages=c >> make all-gcc all-target-libgcc ${JOBS} >> make install-strip-gcc install-strip-target-libgcc >> popd >> popd >> >> # Make and install the glibc files >> tar xvf ${DOWNLOADDIR}/glibc-2.36.tar.xz -C ${BUILDDIR} >> pushd ${BUILDDIR}/glibc-2.36 >> sed -i "s@5.15.0@4.15.0@g" sysdeps/unix/sysv/linux/loongarch/configure{,.ac} >> mkdir -v build-64 >> pushd build-64 >> BUILD_CC="gcc" CC="${CROSS_TARGET}-gcc ${BUILD64}" \ >> CXX="${CROSS_TARGET}-gcc ${BUILD64}" \ >> AR="${CROSS_TARGET}-ar" RANLIB="${CROSS_TARGET}-ranlib" \ >> ../configure --prefix=/usr --host=${CROSS_TARGET} --build=${CROSS_HOST} \ >> --libdir=/usr/lib64 --libexecdir=/usr/lib64/glibc \ >> --with-binutils=${SYSDIR}/cross-tools/bin \ >> --with-headers=${SYSDIR}/sysroot/usr/include \ >> --enable-stack-protector=strong --enable-add-ons \ >> --disable-werror libc_cv_slibdir=/usr/lib64 \ >> --enable-kernel=4.15 >> make ${JOBS} >> make DESTDIR=${SYSDIR}/sysroot install >> cp -v ../nscd/nscd.conf ${SYSDIR}/sysroot/etc/nscd.conf >> mkdir -pv ${SYSDIR}/sysroot/var/cache/nscd >> install -v -Dm644 ../nscd/nscd.tmpfiles \ >> ${SYSDIR}/sysroot/usr/lib/tmpfiles.d/nscd.conf >> install -v -Dm644 ../nscd/nscd.service \ >> ${SYSDIR}/sysroot/usr/lib/systemd/system/nscd.service >> popd >> mkdir -v build-locale >> pushd build-locale >> ../configure --prefix=/usr --libdir=/usr/lib64 --libexecdir=/usr/lib64/glibc \ >> --enable-stack-protector=strong --enable-add-ons \ >> --disable-werror libc_cv_slibdir=/usr/lib64 >> make ${JOBS} >> make DESTDIR=${SYSDIR}/sysroot localedata/install-locales >> popd >> popd >> >> # Make and install the complete GCC files >> tar xvf ${DOWNLOADDIR}/gcc-13.0.0.tar.gz -C ${BUILDDIR} >> pushd ${BUILDDIR}/gcc-13.0.0 >> mkdir tools-build-all >> pushd tools-build-all >> AR=ar LDFLAGS="-Wl,-rpath,${SYSDIR}/cross-tools/lib" \ >> ../configure --prefix=${SYSDIR}/cross-tools --build=${CROSS_HOST} \ >> --host=${CROSS_HOST} --target=${CROSS_TARGET} \ >> --with-sysroot=${SYSDIR}/sysroot --with-mpfr=${SYSDIR}/cross-tools \ >> --with-gmp=${SYSDIR}/cross-tools --with-mpc=${SYSDIR}/cross-tools \ >> --enable-__cxa_atexit --enable-threads=posix --with-system-zlib \ >> --enable-libstdcxx-time --enable-checking=release \ >> --enable-default-pie \ >> --enable-languages=c,c++,fortran,objc,obj-c++,lto >> make ${JOBS} >> make install-strip >> popd >> popd >> Thanks, -- Min Zhou >
On Tue, Oct 4, 2022 at 14:59, David Marchand wrote: > On Fri, Sep 30, 2022 at 10:02 AM Min Zhou <zhoumin@loongson.cn> wrote: >> Dear team, >> >> The following patch set is intended to support DPDK running on LoongArch >> architecture. >> >> LoongArch is the general processor architecture of Loongson Corporation >> and is a new RISC ISA, which is a bit like MIPS or RISC-V. >> >> 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 >> >> v7: >> - rebase the patchset on the main repository >> - add errno.h to rte_power_intrinsics.c according with >> commit 72b452c5f259 > I did some comments on patch 1. Yes, thanks. I have read them carefully and prepare to send the v8 patchset. > I am still considering the patch 7 (hooking into GHA) but the rest > looks good enough to me. Yes, thanks. The changes in the patch 7 is indeed not good for adding CI for LoongArch. As we discussed last weekend, it is better to set up a CI system for LoongArch and integrate the test results of new patch to Patchwork. We are building the CI system, but it will take some time. > Could you respin the series? OK, thank. I will send the v8 patchset to fix them. > > Thanks! Thanks, -- Min Zhou