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 258BA45879; Tue, 27 Aug 2024 17:32:44 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1661D40E3A; Tue, 27 Aug 2024 17:32:44 +0200 (CEST) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com [209.85.218.45]) by mails.dpdk.org (Postfix) with ESMTP id 9131340E37 for ; Tue, 27 Aug 2024 17:32:42 +0200 (CEST) Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-a86e5e9ff05so125255066b.1 for ; Tue, 27 Aug 2024 08:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1724772762; x=1725377562; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9LwdLgiTj/cjjvWgpTUTA7aBPsg3ivxYWj+wjdFlKHw=; b=hCsLktmY20LCGrjUIUVxbxAiV6nGpsvpvIhsHgwzjelmBhxWHgBIfn20aFBp66ntHO KhmPpfSM4eJ7KoyVwxmJysz3qW1kea6PWSHNBS9jDiRJAaRqviEVu5/PvdMRH7RAac4i YdDvppDcRGKZ6j9NfQH+fWu8cbRpQit8dtx8wLxfNWtk3g9GOuLRADMyLFUDyiQEDPsT o82WDIS4XcPAUU7TMP0wOCBnHsVR6bJHHKRtMm6ANF6H028B2QN2Hx5Yv7IIm+k/RBfn njvrJDB8nutjSB3OKf96h3IRndnUhzLFemw/sLmJnW2LjOoGwETYWmgyn1uOm2Y2ETtF kl5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724772762; x=1725377562; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9LwdLgiTj/cjjvWgpTUTA7aBPsg3ivxYWj+wjdFlKHw=; b=ZJ1ePX7yxh+xgG/+x/8DafixojFCpazN7Ql1MDu+bN0tUdJvRQLTlXwUbk3dgADJlA ywc2l/pPWEUM4eK7wg96NhtzsZ4wwNiYizuyhvFUd/5a8vnHcND36hIZEHPPaS6r2LuO R1/qTVzd1GNV8XkpXLkVarfj3usFvbkEskuiTXNcZAqBlydyEDAckSEVyTu30PXC36xA /fBWVDFAdzIRBFWmmvSIyTQymFqBoP/8zFD6PkvDZ1d9ekvbqGqGDHlC3fdG2u6O4Tpb 15v/JbLw5vfy6Ujjwt+T+iGGVVYOwakzVrhPD5Qfdj94apzMZZYPZANGXLGQ/OxZT1Dg 4bwQ== X-Gm-Message-State: AOJu0YyyEa30yJkFnYa4xb0V0JmBMWYCgRmJxvwTlAHEoLr6xoGv4NHt qruciQz62alVj3eSlLMOqT7mTYiqHxGdwy/vf8djz1nKFAz00eYNfitCfy59j4Zp9zmeQoQoYrZ E X-Google-Smtp-Source: AGHT+IHJIcUFHrGvtpk46YflatKOF86LkIAfGiWq2eCgLWk4CjAeSk7b6voCcj3v507tLZoUEiV59w== X-Received: by 2002:a17:907:970c:b0:a7a:8da1:eb00 with SMTP id a640c23a62f3a-a86e397db45mr319345866b.7.1724772761931; Tue, 27 Aug 2024 08:32:41 -0700 (PDT) Received: from C02FF2N1MD6T.bytedance.net ([93.115.195.2]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a86e582da41sm122323066b.109.2024.08.27.08.32.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Aug 2024 08:32:41 -0700 (PDT) From: Daniel Gregory To: Stanislaw Kardach Cc: dev@dpdk.org, Punit Agrawal , Liang Ma , Pengcheng Wang , Chunsong Feng , Daniel Gregory Subject: [PATCH v3 0/9] riscv: implement accelerated crc using zbc Date: Tue, 27 Aug 2024 16:32:20 +0100 Message-Id: <20240827153230.52880-1-daniel.gregory@bytedance.com> X-Mailer: git-send-email 2.39.3 (Apple Git-146) In-Reply-To: <20240712154645.80622-1-daniel.gregory@bytedance.com> References: <20240712154645.80622-1-daniel.gregory@bytedance.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org The RISC-V Zbc extension adds instructions for carry-less multiplication we can use to implement CRC in hardware. This patch set contains two new implementations: - one in lib/hash/rte_crc_riscv64.h that uses a Barrett reduction to implement the four rte_hash_crc_* functions - one in lib/net/net_crc_zbc.c that uses repeated single-folds to reduce the buffer until it is small enough for a Barrett reduction to implement rte_crc16_ccitt_zbc_handler and rte_crc32_eth_zbc_handler My approach is largely based on the Intel's "Fast CRC Computation Using PCLMULQDQ Instruction" white paper https://www.researchgate.net/publication/263424619_Fast_CRC_computation and a post about "Optimizing CRC32 for small payload sizes on x86" https://mary.rs/lab/crc32/ Whether these new implementations are enabled is controlled by new build-time and run-time detection of the RISC-V extensions present in the compiler and on the target system. I have carried out some performance comparisons between the generic table implementations and the new hardware implementations. Listed below is the number of cycles it takes to compute the CRC hash for buffers of various sizes (as reported by rte_get_timer_cycles()). These results were collected on a Kendryte K230 and averaged over 20 samples: |Buffer | CRC32-ETH (lib/net) | CRC32C (lib/hash) | |Size (MB) | Table | Hardware | Table | Hardware | |----------|----------|----------|----------|----------| | 1 | 155168 | 11610 | 73026 | 18385 | | 2 | 311203 | 22998 | 145586 | 35886 | | 3 | 466744 | 34370 | 218536 | 53939 | | 4 | 621843 | 45536 | 291574 | 71944 | | 5 | 777908 | 56989 | 364152 | 89706 | | 6 | 932736 | 68023 | 437016 | 107726 | | 7 | 1088756 | 79236 | 510197 | 125426 | | 8 | 1243794 | 90467 | 583231 | 143614 | These results suggest a speed-up of lib/net by thirteen times, and of lib/hash by four times. I have also run the hash_functions_autotest benchmark in dpdk_test, which measures the performance of the lib/hash implementation on small buffers, getting the following times: | Key Length | Time (ticks/op) | | (bytes) | Table | Hardware | |------------|----------|----------| | 1 | 0.47 | 0.85 | | 2 | 0.57 | 0.87 | | 4 | 0.99 | 0.88 | | 8 | 1.35 | 0.88 | | 9 | 1.20 | 1.09 | | 13 | 1.76 | 1.35 | | 16 | 1.87 | 1.02 | | 32 | 2.96 | 0.98 | | 37 | 3.35 | 1.45 | | 40 | 3.49 | 1.12 | | 48 | 4.02 | 1.25 | | 64 | 5.08 | 1.54 | v3: - rebase on 24.07 - replace crc with CRC in commits (check-git-log.sh) v2: - replace compile flag with build-time (riscv extension macros) and run-time detection (linux hwprobe syscall) (Stephen Hemminger) - add qemu target that supports zbc (Stanislaw Kardach) - fix spelling error in commit message - fix a bug in the net/ implementation that would cause segfaults on small unaligned buffers - refactor net/ implementation to move variable declarations to top of functions - enable the optimisation in a couple other places optimised crc is preferred to jhash - l3fwd-power - cuckoo-hash Daniel Gregory (9): config/riscv: detect presence of Zbc extension hash: implement CRC using riscv carryless multiply net: implement CRC using riscv carryless multiply config/riscv: add qemu crossbuild target examples/l3fwd: use accelerated CRC on riscv ipfrag: use accelerated CRC on riscv examples/l3fwd-power: use accelerated CRC on riscv hash/cuckoo: use accelerated CRC on riscv member: use accelerated CRC on riscv MAINTAINERS | 2 + app/test/test_crc.c | 9 + app/test/test_hash.c | 7 + config/riscv/meson.build | 44 +++- config/riscv/riscv64_qemu_linux_gcc | 17 ++ .../linux_gsg/cross_build_dpdk_for_riscv.rst | 5 + examples/l3fwd-power/main.c | 2 +- examples/l3fwd/l3fwd_em.c | 2 +- lib/eal/riscv/include/rte_cpuflags.h | 2 + lib/eal/riscv/rte_cpuflags.c | 112 +++++++--- lib/hash/meson.build | 1 + lib/hash/rte_crc_riscv64.h | 89 ++++++++ lib/hash/rte_cuckoo_hash.c | 3 + lib/hash/rte_hash_crc.c | 13 +- lib/hash/rte_hash_crc.h | 6 +- lib/ip_frag/ip_frag_internal.c | 6 +- lib/member/rte_member.h | 2 +- lib/net/meson.build | 4 + lib/net/net_crc.h | 11 + lib/net/net_crc_zbc.c | 191 ++++++++++++++++++ lib/net/rte_net_crc.c | 40 ++++ lib/net/rte_net_crc.h | 2 + 22 files changed, 529 insertions(+), 41 deletions(-) create mode 100644 config/riscv/riscv64_qemu_linux_gcc create mode 100644 lib/hash/rte_crc_riscv64.h create mode 100644 lib/net/net_crc_zbc.c -- 2.39.2