Re: [RFC 00/16] enhance checksum offload API

[Olivier MATZ <olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>]

Hi Stephen,

On 01/22/2015 02:01 AM, Stephen Hemminger wrote:
> On Thu, 22 Jan 2015 00:36:19 +0100
> Olivier Matz <olivier.matz-pdR9zngts4EAvxtiuMwx3w@public.gmane.org> wrote:
> 
>> The goal of this series is to clarify and simplify the mbuf offload API.
>> Several issues are solved:
> 
> If you are doing this could you invert the meaning of the checksum
> flags? Right now the flags are fine for Intel hardware but are useless
> for devices that have less checksum support.
> 
> It would work better if instead of two states:
>   * Checksum known bad    =>  PKT_RX_L4_CKSUM_BAD == 1
>   * Checksum (maybe) good =>  PKT_RX_L4_CKSUM_BAD == 0
> The bit was changed to only flag good checksum:
>   * Checksum known good	    => PKT_RX_L4_CKSUM_GOOD == 1
>   * Checksum status unknown => PKT_RX_L4_CKSUM_GOOD == 0
> 
> That way code code fallback to software checksum if hardware was incapable
> of handling the packet. It does mean packets with bad checksums get checked
> twice, but thats ok.

I agree that current rx checksum flags in dpdk could be enhanced.
Your proposition is indeed already much better that what we currently
have. I'm ok to submit a patch for this before the 2.0 release.

However, I think we could do even better with 2 flags. The first
idea is to have one bit saying "the hw verified the checksum" and
a second one saying "it is good or bad".

The second idea is to use flags like PKT_RX_L4_TCP or PKT_RX_L4_UDP
to replace the first bit of the first idea, like it's done for IPv4.
Therefore, the value of the flag PKT_RX_L4_CKSUM_GOOD should only
be checked if the L4 protocol is recognized.

Another thing that could be also useful for virtual driver is a
way to say: "the packet integrity is correct but the checksum field
in the packet may be wrong". This can happen for instance in this
case:
- a guest transmits on a vdev without calculating the checksums
  (gaining cpu time)
- the host receives it, it does not check the rx checksums (because
  it knows the packet integrity is correct, the packet comes from
  memory not from a network)
- then if the host wants to forward it, it has to schedule a tx
  checksum on a real hw.

Let me know if you have any comment.

However, I think this will conflicts with the packet_type feature that
is proposed by Helin:
http://dpdk.org/ml/archives/dev/2015-January/011156.html


Regards,
Olivier