Re: [dpdk-dev] about rx checksum flags

[Adrien Mazarguil <adrien.mazarguil@6wind.com>]

On Mon, May 30, 2016 at 05:26:21PM +0200, Olivier Matz wrote:
> Hi,
> 
> I'm planning to add the support for offloads in virtio-net pmd.
> It appears that the current rx flags in mbuf are not sufficient to
> describe the state of a packet received from a virtual driver.
> I think we need a way to say "the checksum in the packet data is
> not calculated, but the integrity of the data is verified".
> 
> Currently, we have one flag for L4 (same for IP):
> 
>   PKT_RX_L4_CKSUM_BAD: L4 cksum of RX pkt. is not OK.
> 
> This has also another problem that has already been discussed [1]:
> if no flag is set, it is expected that the checksum is verified by
> hw, but there is no way to say "the hw does not know if the cksum
> is correct".
> 
> I would like to extend this flag to a 4-state value (2 bits):
> 
>  PKT_RX_L4_CKSUM_UNKNOWN: no information about the RX L4 checksum
>   -> the application should verify the checksum by sw
> 
>  PKT_RX_L4_CKSUM_BAD: the L4 checksum in the packet is wrong
>   -> the application can drop the packet without additional check
> 
>  PKT_RX_L4_CKSUM_GOOD: the L4 checksum in the packet is valid
>   -> the application can accept the packet without verifying the
>      checksum by sw
> 
>  PKT_RX_L4_CKSUM_NONE: the L4 checksum is not correct in the packet
>  data, but the integrity of the L4 header is verified.
>   -> the application can process the packet but must not verify the
>      checksum by sw. It has to take care to recalculate the cksum
>      if the packet is transmitted (either by sw or using tx offload)

This API makes and lot of sense for both mlx4 and mlx5 PMDs as well, for
which hardware only returns information about "good" headers ("unknown"
should be assumed otherwise). It does not map well with the current API that
only provides info about bad checksums.

For instance, non-IP packets do not have valid L3/L4 checksums and thus are
not returned as "good" by hardware. These PMDs perform the "not good means
bad" conversion for DPDK which is wrong in such cases. Same for unknown
packet types.

> To keep the compatibility with application, the old flag is kept at the
> same value, and a new flag is added. It is assumed that the behavior
> of applications was:
> 
>   PKT_RX_L4_CKSUM_BAD = 0 -> packet is accepted
>   PKT_RX_L4_CKSUM_BAD = 1 -> packet is dropped
> 
> The new checksum states for L4 (same for IP) would be:
> 
>   old flag   new flag   meaning
>   0          0          PKT_RX_L4_CKSUM_UNKNOWN
>   1          0          PKT_RX_L4_CKSUM_BAD
>   0          1          PKT_RX_L4_CKSUM_GOOD
>   1          1          PKT_RX_L4_CKSUM_NONE
> 
> With this, an old application that only checks the old flag, and
> running using a dpdk having this modification would accept GOOD and
> UNKNOWN packets (like today), drop BAD packets (like today) and
> drop NONE packets (this is a new feature that has to be explicitly
> enabled by the application).
> 
> 
> Any comment?

Considering mlx4 and mlx5 can only return "good" or "unknown" checksums, I'm
all for updating the API as suggested.

> Olivier
> 
> 
> [1] http://dpdk.org/ml/archives/dev/2015-January/011550.html

-- 
Adrien Mazarguil
6WIND