From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [RFC 00/16] enhance checksum offload API Date: Fri, 23 Jan 2015 10:52:06 +0100 Message-ID: <54C219C6.8080304@6wind.com> References: <1421883395-27235-1-git-send-email-olivier.matz@6wind.com> <20150121170149.157da6ed@urahara> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Stephen Hemminger Return-path: In-Reply-To: <20150121170149.157da6ed@urahara> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" Hi Stephen, On 01/22/2015 02:01 AM, Stephen Hemminger wrote: > On Thu, 22 Jan 2015 00:36:19 +0100 > Olivier Matz 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