eal/loongarch: support LoongArch architecture

This patch adds the support for LoongArch architecture. Meanwhile, backports bugfixes for ixgbe driver needed by LoongArch, and removes linking to i40e driver for LoongArch because it was not supported in this version. Signed-off-by: Min Zhou <zhoumin@loongson.cn> (cherry picked from commit 53eeb4c6d07277ff13cd526606d63b08e02b8d38)
2023-07-06 17:16:31 +08:00 · 2023-07-06 17:16:31 +08:00 · 3a63a918ed
commit 3a63a918ed
parent deb33fc7a5
3 changed files with 1783 additions and 3 deletions
--- a/0022-eal-loongarch-support-LoongArch-architecture.patch
+++ b/0022-eal-loongarch-support-LoongArch-architecture.patch
--- a/0314-net-ixgbe-add-proper-memory-barriers-in-Rx.patch
+++ b/0314-net-ixgbe-add-proper-memory-barriers-in-Rx.patch
@ -0,0 +1,136 @@
+From 2b198866b2753d5c8a1241a32023137a91103392 Mon Sep 17 00:00:00 2001
+From: Min Zhou <zhoumin@loongson.cn>
+Date: Tue, 13 Jun 2023 17:44:25 +0800
+Subject: [PATCH 2/2] net/ixgbe: add proper memory barriers in Rx
+
+Segmentation fault has been observed while running the
+ixgbe_recv_pkts_lro() function to receive packets on the Loongson 3C5000
+processor which has 64 cores and 4 NUMA nodes.
+
+From the ixgbe_recv_pkts_lro() function, we found that as long as the first
+packet has the EOP bit set, and the length of this packet is less than or
+equal to rxq->crc_len, the segmentation fault will definitely happen even
+though on the other platforms. For example, if we made the first packet
+which had the EOP bit set had a zero length by force, the segmentation
+fault would happen on X86.
+
+Because when processd the first packet the first_seg->next will be NULL, if
+at the same time this packet has the EOP bit set and its length is less
+than or equal to rxq->crc_len, the following loop will be executed:
+
+    for (lp = first_seg; lp->next != rxm; lp = lp->next)
+        ;
+
+We know that the first_seg->next will be NULL under this condition. So the
+expression of lp->next->next will cause the segmentation fault.
+
+Normally, the length of the first packet with EOP bit set will be greater
+than rxq->crc_len. However, the out-of-order execution of CPU may make the
+read ordering of the status and the rest of the descriptor fields in this
+function not be correct. The related codes are as following:
+
+        rxdp = &rx_ring[rx_id];
+ #1     staterr = rte_le_to_cpu_32(rxdp->wb.upper.status_error);
+
+        if (!(staterr & IXGBE_RXDADV_STAT_DD))
+            break;
+
+ #2     rxd = *rxdp;
+
+The sentence #2 may be executed before sentence #1. This action is likely
+to make the ready packet zero length. If the packet is the first packet and
+has the EOP bit set, the above segmentation fault will happen.
+
+So, we should add a proper memory barrier to ensure the read ordering be
+correct. We also did the same thing in the ixgbe_recv_pkts() function to
+make the rxd data be valid even though we did not find segmentation fault
+in this function.
+
+Fixes: 8eecb3295aed ("ixgbe: add LRO support")
+Cc: stable@dpdk.org
+
+Signed-off-by: Min Zhou <zhoumin@loongson.cn>
+Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
+---
+ drivers/net/ixgbe/ixgbe_rxtx.c | 47 +++++++++++++++-------------------
+ 1 file changed, 21 insertions(+), 26 deletions(-)
+
+diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
+index e19e832..c0491bf 100644
+--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
+@@ -1818,11 +1818,22 @@ ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
+		 * of accesses cannot be reordered by the compiler. If they were
+		 * not volatile, they could be reordered which could lead to
+		 * using invalid descriptor fields when read from rxd.
+		 *
+		 * Meanwhile, to prevent the CPU from executing out of order, we
+		 * need to use a proper memory barrier to ensure the memory
+		 * ordering below.
+		 */
+		rxdp = &rx_ring[rx_id];
+		staterr = rxdp->wb.upper.status_error;
+		if (!(staterr & rte_cpu_to_le_32(IXGBE_RXDADV_STAT_DD)))
+			break;
+
+		/*
+		 * Use acquire fence to ensure that status_error which includes
+		 * DD bit is loaded before loading of other descriptor words.
+		 */
+		rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+		rxd = *rxdp;
+
+		/*
+@@ -2089,32 +2100,10 @@ ixgbe_recv_pkts_lro(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts,
+
+ next_desc:
+		/*
+-		 * The code in this whole file uses the volatile pointer to
+-		 * ensure the read ordering of the status and the rest of the
+-		 * descriptor fields (on the compiler level only!!!). This is so
+-		 * UGLY - why not to just use the compiler barrier instead? DPDK
+-		 * even has the rte_compiler_barrier() for that.
+-		 *
+-		 * But most importantly this is just wrong because this doesn't
+-		 * ensure memory ordering in a general case at all. For
+-		 * instance, DPDK is supposed to work on Power CPUs where
+-		 * compiler barrier may just not be enough!
+-		 *
+-		 * I tried to write only this function properly to have a
+-		 * starting point (as a part of an LRO/RSC series) but the
+-		 * compiler cursed at me when I tried to cast away the
+-		 * "volatile" from rx_ring (yes, it's volatile too!!!). So, I'm
+-		 * keeping it the way it is for now.
+-		 *
+-		 * The code in this file is broken in so many other places and
+-		 * will just not work on a big endian CPU anyway therefore the
+-		 * lines below will have to be revisited together with the rest
+-		 * of the ixgbe PMD.
+-		 *
+-		 * TODO:
+-		 *    - Get rid of "volatile" and let the compiler do its job.
+-		 *    - Use the proper memory barrier (rte_rmb()) to ensure the
+-		 *      memory ordering below.
+		 * "Volatile" only prevents caching of the variable marked
+		 * volatile. Most important, "volatile" cannot prevent the CPU
+		 * from executing out of order. So, it is necessary to use a
+		 * proper memory barrier to ensure the memory ordering below.
+		 */
+		rxdp = &rx_ring[rx_id];
+		staterr = rte_le_to_cpu_32(rxdp->wb.upper.status_error);
+@@ -2122,6 +2111,12 @@ ixgbe_recv_pkts_lro(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts,
+		if (!(staterr & IXGBE_RXDADV_STAT_DD))
+			break;
+
+		/*
+		 * Use acquire fence to ensure that status_error which includes
+		 * DD bit is loaded before loading of other descriptor words.
+		 */
+		rte_atomic_thread_fence(__ATOMIC_ACQUIRE);
+
+		rxd = *rxdp;
+
+		PMD_RX_LOG(DEBUG, "port_id=%u queue_id=%u rx_id=%u "
+--
+2.33.0
--- a/dpdk.spec
+++ b/dpdk.spec
@ -1,6 +1,6 @@
 Name: dpdk
 Version: 21.11
-Release: 51
+Release: 52
 Packager: packaging@6wind.com
 URL: http://dpdk.org
 %global source_version  21.11
@ -334,15 +334,17 @@ Patch6310:    0310-net-hns3-fix-redundant-line-break-in-log.patch
 Patch6311:    0311-ethdev-add-API-to-check-if-queue-is-valid.patch
 Patch6312:    0312-app-testpmd-fix-segment-fault-with-invalid-queue-ID.patch
 Patch6313:    0313-net-hns3-fix-IMP-reset-trigger.patch
+Patch6314:    0314-net-ixgbe-add-proper-memory-barriers-in-Rx.patch

 Patch9020:    0020-pdump-fix-pcap_dump-coredump-caused-by-incorrect-pkt_len.patch
 Patch9021:    0021-gro-fix-gro-with-tcp-push-flag.patch
+Patch9022:    0022-eal-loongarch-support-LoongArch-architecture.patch

 Summary: Data Plane Development Kit core
 Group: System Environment/Libraries
 License: BSD and LGPLv2 and GPLv2

-ExclusiveArch: i686 x86_64 aarch64
+ExclusiveArch: i686 x86_64 aarch64 loongarch64

 BuildRequires: meson ninja-build gcc diffutils python3-pyelftools
 BuildRequires: kernel-devel numactl-devel
@ -353,6 +355,7 @@ BuildRequires: chrpath
 BuildRequires: groff-base

 %define kern_devel_ver %(uname -r)
+%define arch_type %(uname -m)

 %description
 DPDK core includes kernel modules, core libraries and tools.
@ -392,7 +395,12 @@ ninja -C build -v
 #build gazelle-pdump
 cd build/app/dpdk-pdump.p
 export GAZELLE_FLAGS="-lm -lpthread -lrt -lnuma"
+# Remove linking to i40e driver for LoongArch because it was not supported in this version
+%if "%{arch_type}" == "loongarch64"
+export GAZELLE_LIBS="-lrte_pci -lrte_bus_pci -lrte_cmdline -lrte_hash -lrte_mempool -lrte_mempool_ring -lrte_timer -lrte_eal -lrte_gro -lrte_ring -lrte_mbuf -lrte_telemetry -lrte_kni -lrte_net_ixgbe -lrte_kvargs -lrte_net_hinic -lrte_net_virtio -lrte_bus_vdev -lrte_net -lrte_rcu -lrte_ethdev -lrte_pdump -lrte_bpf -lrte_security -lrte_cryptodev -lrte_net_pcap -lrte_metrics"
+%else
 export GAZELLE_LIBS="-lrte_pci -lrte_bus_pci -lrte_cmdline -lrte_hash -lrte_mempool -lrte_mempool_ring -lrte_timer -lrte_eal -lrte_gro -lrte_ring -lrte_mbuf -lrte_telemetry -lrte_kni -lrte_net_ixgbe -lrte_kvargs -lrte_net_hinic -lrte_net_i40e -lrte_net_virtio -lrte_bus_vdev -lrte_net -lrte_rcu -lrte_ethdev -lrte_pdump -lrte_bpf -lrte_security -lrte_cryptodev -lrte_net_pcap -lrte_metrics"
+%endif
 export SECURE_OPTIONS="-fstack-protector-strong -D_FORTIFY_SOURCE=2 -O2 -Wall -Wl,-z,relro,-z,now,-z,noexecstack -Wtrampolines -fPIE -pie -fPIC -g"
 gcc -o gazelle-pdump ${GAZELLE_FLAGS} ${SOCURE_OPTIONS} -L../../drivers -L../../lib ${GAZELLE_LIBS} pdump_main.c.o
 cd -
@ -476,6 +484,12 @@ strip -g $RPM_BUILD_ROOT/lib/modules/%{kern_devel_ver}/extra/dpdk/igb_uio.ko
 /usr/sbin/depmod

 %changelog
+* Tue Jul 4 2023 zhoumin <zhoumin@loongson.cn> - 21.11-52
+- EAL: support LoongArch architecture
+- Backport bugfixes for ixgbe driver needed by LoongArch
+- Remove linking to i40e driver for LoongArch because it was
+  not supported in this version
+
 * Fri Jun 30 2023 jiangheng <jiangheng14@huawei.com> - 21.11-51
 - remove gazelle-proc-info, it function the same as gazellectl -x

@ -485,7 +499,7 @@ strip -g $RPM_BUILD_ROOT/lib/modules/%{kern_devel_ver}/extra/dpdk/igb_uio.ko
 * Tue Jun 13 2023 jiangheng <jiangheng14@huawei.com> - 21.11-49
 - pdump: fix pcap_dump coredump caused by incorrect pkt_len

-* Fir Jun 09 2023 jiangheng <jiangheng14@huawei.com> - 21.11-48
+* Fri Jun 09 2023 jiangheng <jiangheng14@huawei.com> - 21.11-48
 - distinguish self and upstream patches number

 * Wed Jun 07 2023 chenjiji <chenjiji09@163.com> - 21.11-47