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 2927045E0A; Mon, 2 Dec 2024 20:35:31 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AC9C740270; Mon, 2 Dec 2024 20:35:30 +0100 (CET) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id 603A14025D for ; Mon, 2 Dec 2024 20:35:29 +0100 (CET) Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2155157c31fso22651245ad.1 for ; Mon, 02 Dec 2024 11:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1733168128; x=1733772928; 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=GUcoFd+5kiRp8Agg3oIZgV2PbPRiJLZRMUfEM/vM474=; b=W2Lo0gJqZs7Lt943K+r23nBAE+9kATN9frV6+1AUmRfvYIEfQfCjZirvTdoL3osQMR F16d97rNIQ9J3r2lHW+s/CPBo3kpT4jPAfgB7By47dvt/vC8s3vwZbtrHkbVoy8yBvo6 8NcLAQBK0079OdYo6rhrRBhWs9xk70hJIO55s/zx2cAMAJrzewmRb9R8n/4HZd8PDuE7 1rkl2L2C/m6Ui27UJKcTT6py9n7Rqr8cUZOHu5BAKKU1MPHMaXg1AI8qxjtMwKQua31y G/sDc2wOIoVy1tQTSB/HHZlFKeKCntVlrDyO8I8MDmyKYSzWHPawNLkMiT5Ge+6DJa4b LUbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733168128; x=1733772928; 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=GUcoFd+5kiRp8Agg3oIZgV2PbPRiJLZRMUfEM/vM474=; b=qsYWrnH4EAXn7qa4TuIlUUr6WPM/In3bAFpSEib8hlIgXaEJsVi0UkJeC8IL1t4+hE GTZiH40GH9E8V0MjfhBBRuzRydT+VlxcLRlT48g3Z3EywRQJNic7O83f5SgI7XiPdY6v +TXk6vufuMkFmE6fMddJqKaikOO7wbCX+vYdmi9JSebSEhA4m21kzN0tw0tGpscyG9U6 rfyd4Rwn0YSClgOz3F6RK9tPZvtE8UbTESCn3uNkdD5L1kmssakc1zlGxv+2eX9S/65u JkOzdC477oiQelTvZZ+EvCx9tAs8h4J8k7y0zJgL287hEiISJTAWPr0dN8luqO46KIJO kACw== X-Gm-Message-State: AOJu0YxXqSSdSt6amINwYRcZ4W8N8+6RS02lQ4csFHmQ5MFDu9PcqjZY 3krleJSu0VPgoFqcQw25e3GZ0sf9YM0f70N+IHc/OHHZWWIBjzUHfP3SyzMFZbc= X-Gm-Gg: ASbGncsfzr1Ac+k/RZp8r6hr4B0wmMccrNaac8PFxmR66Lj37LiYqn5+iKF10ikV80P 7MWo0k7MKpsNmqhEbWpF/0vvMMEh3eUxFUO3G/1OxjRbEfbmgGmFXzIZR1CWrmT4I/05afR20xj FxeIvlbnqK/sPKjP1pGUEmIak4O7fQ6tYWDByQubABSqTS1fliNCFcGtN6IcpKCcYqBuxX0UVqr yh/aiVxGmqnGYPtU1D3MwyyUZOiKjJsVbMZbvM5VApIrr3b6RcwGO4GzenugRaoZGKxpQ8czGWt NQYRLmpApiDwD0G7Gi1rmDwrsfQ= X-Google-Smtp-Source: AGHT+IFDXXvz+m5Ldj13j2ee3Yn7nFlFxsC3ZO4WwcLOwR2Hw/w+fJ+s6zAfjYHikjxJ6HfJ5a9+8A== X-Received: by 2002:a17:902:c7d5:b0:215:3205:58a6 with SMTP id d9443c01a7336-21532055bdamr185270465ad.12.1733168128162; Mon, 02 Dec 2024 11:35:28 -0800 (PST) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72541762411sm9213944b3a.20.2024.12.02.11.35.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Dec 2024 11:35:27 -0800 (PST) Date: Mon, 2 Dec 2024 11:35:25 -0800 From: Stephen Hemminger To: Jie Hai Cc: , , , Wathsala Vithanage , "Min Hu (Connor)" , "Wei Hu (Xavier)" , , , Subject: Re: [PATCH v4] net/hns3: fix Rx packet without CRC data Message-ID: <20241202113525.4d42d726@hermes.local> In-Reply-To: <20241127100807.683461-1-haijie1@huawei.com> References: <20240206011030.2007689-1-haijie1@huawei.com> <20241127100807.683461-1-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 Wed, 27 Nov 2024 18:08:07 +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 > Acked-by: Jie Hai > --- There is another issue around CRC in this driver. If keep crc is enabled and the packet is received into a multisegment mbuf and the CRC bytes are the only data left in the last segment then the driver will free the segment and adjust the lengths. That would make it impossible for an application that was looking for the CRC. See: static inline void recalculate_data_len(struct rte_mbuf *first_seg, struct rte_mbuf *last_seg, struct rte_mbuf *rxm, struct hns3_rx_queue *rxq, uint16_t data_len) { uint8_t crc_len = rxq->crc_len; if (data_len <= crc_len) { rte_pktmbuf_free_seg(rxm); first_seg->nb_segs--; last_seg->data_len = (uint16_t)(last_seg->data_len - (crc_len - data_len)); last_seg->next = NULL; } else rxm->data_len = (uint16_t)(data_len - crc_len); }