On 2/20/2024 3:58 AM, Jie Hai wrote:
> Hi, Ferruh,
>
> Thanks for your review.
>
> On 2024/2/7 22:15, Ferruh Yigit wrote:
>> On 2/6/2024 1:10 AM, Jie Hai wrote:
>>> From: Dengdui Huang <huangdeng...@huawei.com>
>>>
>>> When KEEP_CRC offload is enabled, some packets will be truncated and
>>> the CRC is still be stripped in following cases:
>>> 1. For HIP08 hardware, the packet type is TCP and the length
>>> is less than or equal to 60B.
>>> 2. For other hardwares, the packet type is IP and the length
>>> is less than or equal to 60B.
>>>
>>
>> If a device doesn't support the offload by some packets, it can be
>> option to disable offload for that device, instead of calculating it in
>> software and append it.
>
> The KEEP CRC feature of hns3 is faulty only in the specific packet
> type and small packet(<60B) case.
> What's more, the small ethernet packet is not common.
>
>> Unless you have a specific usecase, or requirement to support the
>> offload.
>
> Yes, some users of hns3 are already using this feature.
> So we cannot drop this offload
>
>> <...>
>>
>>> @@ -2492,10 +2544,16 @@ hns3_recv_pkts_simple(void *rx_queue,
>>> goto pkt_err;
>>> rxm->packet_type = hns3_rx_calc_ptype(rxq, l234_info,
>>> ol_info);
>>> -
>>> if (rxm->packet_type == RTE_PTYPE_L2_ETHER_TIMESYNC)
>>> rxm->ol_flags |= RTE_MBUF_F_RX_IEEE1588_PTP;
>>> + if (unlikely(rxq->crc_len > 0)) {
>>> + if (hns3_need_recalculate_crc(rxq, rxm))
>>> + hns3_recalculate_crc(rxq, rxm);
>>> + rxm->pkt_len -= rxq->crc_len;
>>> + rxm->data_len -= rxq->crc_len;
>>>
>>
>> Removing 'crc_len' from 'mbuf->pkt_len' & 'mbuf->data_len' is
>> practically same as stripping CRC.
>>
>> We don't count CRC length in the statistics, but it should be accessible
>> in the payload by the user.
> Our drivers are behaving exactly as you say.
>
If so I missed why mbuf 'pkt_len' and 'data_len' reduced by
'rxq->crc_len', can you please explain what above lines does?
