From: Stephen Hemminger <stephen@networkplumber.org>
To: Jie Hai <haijie1@huawei.com>
Cc: <dev@dpdk.org>, <ferruh.yigit@amd.com>,
<mb@smartsharesystems.com>, <andrew.rybchenko@oktetlabs.ru>,
Yisen Zhuang <yisen.zhuang@huawei.com>,
"Wei Hu (Xavier)" <xavier.huwei@huawei.com>,
"Min Hu (Connor)" <humin29@huawei.com>, <huangdengdui@huawei.com>,
<fengchengwen@huawei.com>, <lihuisong@huawei.com>
Subject: Re: [PATCH v3 3/3] net/hns3: fix Rx packet without CRC data
Date: Sun, 24 Nov 2024 11:42:43 -0800 [thread overview]
Message-ID: <20241124114110.312d7f1d@hermes.local> (raw)
In-Reply-To: <20240719090415.1513301-4-haijie1@huawei.com>
On Fri, 19 Jul 2024 17:04:15 +0800
Jie Hai <haijie1@huawei.com> wrote:
> From: Dengdui Huang <huangdengdui@huawei.com>
>
> 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 <huangdengdui@huawei.com>
> Acked-by: Huisong Li <lihuisong@huawei.com>
> +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
next prev parent reply other threads:[~2024-11-24 19:42 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 1:10 [PATCH] net/hns3: fix Rx packet truncation when KEEP CRC enabled Jie Hai
2024-02-07 14:15 ` Ferruh Yigit
2024-02-20 3:58 ` Jie Hai
2024-02-23 13:53 ` Ferruh Yigit
2024-02-26 3:16 ` Jie Hai
2024-02-26 16:43 ` Ferruh Yigit
2024-02-28 2:27 ` huangdengdui
2024-02-28 13:07 ` Ferruh Yigit
2024-02-29 3:58 ` huangdengdui
2024-02-29 9:25 ` Ferruh Yigit
2024-03-01 6:55 ` huangdengdui
2024-03-01 11:10 ` Ferruh Yigit
2024-03-08 11:36 ` Jie Hai
2024-03-22 6:28 ` Jie Hai
2024-06-03 1:38 ` Jie Hai
2024-06-03 2:33 ` Stephen Hemminger
2024-06-03 5:24 ` Morten Brørup
2024-06-03 7:07 ` Andrew Rybchenko
2024-07-18 11:48 ` [PATCH v2 0/3] bugfix about KEEP CRC offload Jie Hai
2024-07-18 11:48 ` [PATCH v2 1/3] ethdev: add description for " Jie Hai
2024-07-18 11:57 ` Morten Brørup
2024-07-18 11:48 ` [PATCH v2 2/3] net/hns3: fix packet length do not contain CRC data length Jie Hai
2024-07-18 11:48 ` [PATCH v2 3/3] net/hns3: fix Rx packet without CRC data Jie Hai
2024-11-26 23:17 ` [RFC] net/hns3: clarify handling of crc reinsert Stephen Hemminger
2024-07-18 12:35 ` [PATCH v2 0/3] bugfix about KEEP CRC offload lihuisong (C)
2024-11-26 23:12 ` Stephen Hemminger
2024-07-19 9:04 ` [PATCH v3 " Jie Hai
2024-07-19 9:04 ` [PATCH v3 1/3] ethdev: add description for " Jie Hai
2024-09-05 6:33 ` Andrew Rybchenko
2024-11-22 17:10 ` Stephen Hemminger
2024-11-26 7:47 ` Jie Hai
2024-11-26 23:51 ` Stephen Hemminger
2024-11-22 17:35 ` Stephen Hemminger
2024-07-19 9:04 ` [PATCH v3 2/3] net/hns3: fix packet length do not contain CRC data length Jie Hai
2024-07-19 9:04 ` [PATCH v3 3/3] net/hns3: fix Rx packet without CRC data Jie Hai
2024-11-24 19:42 ` Stephen Hemminger [this message]
2024-11-25 17:45 ` Stephen Hemminger
2024-11-26 2:40 ` huangdengdui
2024-11-26 3:16 ` Stephen Hemminger
2024-11-27 0:16 ` Stephen Hemminger
2024-11-27 2:32 ` Jie Hai
2024-11-27 3:21 ` Stephen Hemminger
2024-07-19 9:49 ` [PATCH v3 0/3] bugfix about KEEP CRC offload fengchengwen
2024-08-09 9:21 ` Jie Hai
2024-09-05 2:53 ` Jie Hai
2024-10-18 1:39 ` Jie Hai
2024-11-06 2:19 ` Jie Hai
2024-11-13 3:14 ` Jie Hai
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=20241124114110.312d7f1d@hermes.local \
--to=stephen@networkplumber.org \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=ferruh.yigit@amd.com \
--cc=haijie1@huawei.com \
--cc=huangdengdui@huawei.com \
--cc=humin29@huawei.com \
--cc=lihuisong@huawei.com \
--cc=mb@smartsharesystems.com \
--cc=xavier.huwei@huawei.com \
--cc=yisen.zhuang@huawei.com \
/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).