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 6A72345D9C; Sun, 24 Nov 2024 20:42:56 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 567284028A; Sun, 24 Nov 2024 20:42:54 +0100 (CET) Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by mails.dpdk.org (Postfix) with ESMTP id 3841240274 for ; Sun, 24 Nov 2024 20:42:52 +0100 (CET) Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-2127d4140bbso33959005ad.1 for ; Sun, 24 Nov 2024 11:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1732477371; x=1733082171; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=H5yA79Tb61H4oH5GpfgJccmdZQ+hclNqVRNljDu+kao=; b=BZf+WhN6J4suhzKmyVtalQjzYUNMUmPGmMcAIC2B6oRz3oVOUEsbKIAQAp8Ii1XL8v +GnWE9pk+p7luKuc9XldOBAVHRRNwcNkbhZQxXgtFLwnNFCKq6kfA+0NNbw0YQo6/ivV qfheSQkzeZrkvU0Q+fJm1fwCZLbRLK5H9UwZ40850ApGIpI7E5EuX0BUlGLZ9gPSPdZt 0NlHoQVUxbXvNnJQKOk1MRimk22JPtz49xiMdGkuLeEAGQ7JSq63qIR3VlvxZzGxMy68 q3FEQucoU3Fhd2WhSyFzwhken5LSHFgF7AHtemuGRk4gfFTsI6KWFxvLr0d4RtrAVue6 P8YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732477371; x=1733082171; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H5yA79Tb61H4oH5GpfgJccmdZQ+hclNqVRNljDu+kao=; b=B5if56QawsMmDCMPYfm6IQfNAhNeR/qAfYdUqPh44m9DO4QZwV3S5iPVCA6N84pRjd JY4zeN7UBHCsxtgfzGyumQM1bxFgmpFfgQ5meLym58ljmH7jeXb1UVlarnM8asDbJoSB YG7ytNkg1yhSFFlkvgvZNBnZokboRZk04yXwdJigx65JjVs3gGT3gActhfYQiI+a3ub9 ID5VZ0imJcSRmXhx/rT/283qN3y71JOmUlRiPKXf8uqMMP5CRwnTq+k9w9+o5GmNfAB7 fhT0T9fTautAAaHRnm8LS9LV+deYf9krYKxAHExHoUzMn0rwACSaun/LlX+VRBplFZPJ FMLw== X-Gm-Message-State: AOJu0YxYBKYR9ENd5Q90xR/IuDHAHkmYBqBUvBzQpa0+qLRJi2k27Qqo S6i9WJPyUPWn0LDAUnzH1sG0c922WdT4BH4BnvjWFj83WrSdwSLct+yeEDEaonc= X-Gm-Gg: ASbGnctLRRuYiIEcP0MtV1sw+GqF/4hsN+mrXEIItcsv1cJRP6axeYb5op2A5ZTA4Gt ZR5gbGv+kBCSEQc7gRBckXVd4/VGmxaOsRs8H3KNUhxH2z9ubez2xZw7zx9Jjsk6SOpdg0xH0hl +rWWhbU1uNzBR5UPEenfPjEHEcVevmn1lMIQ+6UbIcobARW+TXGTpi6wtEPyyaaX7Mz2hMc74Km WGZWkTK5dHqY/I25474UgintTmmlpP5LnFsdrYfR5tUYlMMNARg5RsnNHvbpAIlIMjvV5gaDHw5 cJ3aJQafdATjPAenLKLd1NxA2qA= X-Google-Smtp-Source: AGHT+IGKBl+pftUtVp0wi5DY+jBhZJ5Ltl4C9N6gbKlLIxwVHBpHRlCn2uL8bxM4h1SDYLwuzG0lHQ== X-Received: by 2002:a17:902:da81:b0:212:45b8:4667 with SMTP id d9443c01a7336-2129f28892cmr160256625ad.39.1732477367374; Sun, 24 Nov 2024 11:42:47 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2129dba5920sm50212585ad.107.2024.11.24.11.42.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 24 Nov 2024 11:42:46 -0800 (PST) Date: Sun, 24 Nov 2024 11:42:43 -0800 From: Stephen Hemminger To: Jie Hai Cc: , , , , Yisen Zhuang , "Wei Hu (Xavier)" , "Min Hu (Connor)" , , , Subject: Re: [PATCH v3 3/3] net/hns3: fix Rx packet without CRC data Message-ID: <20241124114110.312d7f1d@hermes.local> In-Reply-To: <20240719090415.1513301-4-haijie1@huawei.com> References: <20240206011030.2007689-1-haijie1@huawei.com> <20240719090415.1513301-1-haijie1@huawei.com> <20240719090415.1513301-4-haijie1@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Fri, 19 Jul 2024 17:04:15 +0800 Jie Hai wrote: > From: Dengdui Huang > > When KEEP_CRC offload is enabled, the CRC data is still stripped > in following cases: > 1. For HIP08 network engine, the packet type is TCP and the length > is less than or equal to 60B. > 2. For HIP09 network engine, the packet type is IP and the length > is less than or equal to 60B. > > So driver has to recaculate packet CRC for this rare scenarios. > > In addition, to avoid impacting performance, KEEP_CRC is not > supported when NEON or SVE algorithm is used. > > Fixes: 8973d7c4ca12 ("net/hns3: support keeping CRC") > Cc: stable@dpdk.org > > Signed-off-by: Dengdui Huang > Acked-by: Huisong Li > +static inline void > +hns3_recalculate_crc(struct rte_mbuf *m) > +{ > + char *append_data; > + uint32_t crc; > + > + crc = rte_net_crc_calc(rte_pktmbuf_mtod(m, void *), > + m->data_len, RTE_NET_CRC32_ETH); > + > + /* > + * The hns3 driver requires that mbuf size must be at least 512B. > + * When CRC is stripped by hardware, the pkt_len must be less than > + * or equal to 60B. Therefore, the space of the mbuf is enough > + * to insert the CRC. > + * > + * In addition, after CRC is stripped by hardware, pkt_len and data_len > + * do not contain the CRC length. Therefore, after CRC data is appended > + * by PMD again, both pkt_len and data_len add the CRC length. > + */ > + append_data = rte_pktmbuf_append(m, RTE_NET_CRC32_ETH); > + /* The CRC data is binary data and does not care about the byte order. */ > + rte_memcpy(append_data, (void *)&crc, RTE_NET_CRC32_ETH); > +} Ok, but minor nits for future. Trying to phase out use of rte_memcpy(), rte_memcpy() has no advantage except in certain cases of unaligned variable length copies mostly on older non x86 distros. And regular memcpy() enables compiler to do more checking. And you don't need a void * cast there, in C there is implicit cast to void * there. Applied to next-net