From: zhoumin <zhoumin@loongson.cn>
To: David Marchand <david.marchand@redhat.com>
Cc: 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
Date: Sat, 1 Oct 2022 22:25:55 +0800 [thread overview]
Message-ID: <50bd37d8-1741-eee8-0b1c-fec9b415bc66@loongson.cn> (raw)
In-Reply-To: <CAJFAV8wGOqWjuW1HZfWmtUMt3w3J=94ZZpF3VZRqk9zM9C_O4A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 14977 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 20610 bytes --]
next prev parent reply other threads:[~2022-10-01 14:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20220930080228.864681-1-zhoumin@loongson.cn>
[not found] ` <CAJFAV8y1DzYBTOU4ZXfMnTSeEsHfn=68qexRhgy_+bjaqP1fUQ@mail.gmail.com>
[not found] ` <3219c10e-79fa-39df-30f5-c2287fd1872b@loongson.cn>
2022-09-30 14:20 ` David Marchand
2022-10-01 14:25 ` zhoumin [this message]
2022-10-03 16:30 ` David Marchand
2022-10-04 8:49 ` zhoumin
2022-10-03 8:14 ` Ali Alnubani
2022-10-03 12:44 ` zhoumin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50bd37d8-1741-eee8-0b1c-fec9b415bc66@loongson.cn \
--to=zhoumin@loongson.cn \
--cc=Yuying.Zhang@intel.com \
--cc=aconole@redhat.com \
--cc=alialnu@nvidia.com \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=ci@dpdk.org \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dpdklab@iol.unh.edu \
--cc=jgrajcia@cisco.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=maobibo@loongson.cn \
--cc=qiming.yang@intel.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).