From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 30F475A8E for ; Fri, 23 Jan 2015 10:52:16 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YEaxz-0000Mq-Hn; Fri, 23 Jan 2015 10:55:55 +0100 Message-ID: <54C219C6.8080304@6wind.com> Date: Fri, 23 Jan 2015 10:52:06 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0 MIME-Version: 1.0 To: Stephen Hemminger References: <1421883395-27235-1-git-send-email-olivier.matz@6wind.com> <20150121170149.157da6ed@urahara> In-Reply-To: <20150121170149.157da6ed@urahara> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [RFC 00/16] enhance checksum offload API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 09:52:16 -0000 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