On 2024/11/30 1:12, Stephen Hemminger wrote:
> On Fri, 29 Nov 2024 09:36:43 +0800
> Jie Hai <haij...@huawei.com> wrote:
>
>>> +
>>> +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);
>>> +
>>> + /*
>>> + * 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.
>>> + */
>>> + append_data = rte_pktmbuf_append(m, RTE_ETHER_CRC_LEN);
>>> +
>>> + /* CRC data is binary data and does not care about the byte order. */
>>> + memcpy(append_data, &crc, RTE_ETHER_CRC_LEN);
>>> +}
>
> As mentioned previously.
> Including CRC in the packet length (pkt_len and data_len) is not the
> current behavior of most drivers. Therefore hns3 should follow the precedent
> of other drivers and put it past the data.
Yes. This patch does not change the original behavior.
In subsequent processing, crc_len is deducted from pkt_len and data_len.
>
> In the future the KEEP_CRC flag needs more work to be useable. It needs
> documentation and flag in mbuf (similar to hash and checksum) so that
> application
> can no that it is present and valid.
>
> Please resend the patch as a bugfix that puts crc after the data.
