From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id 55CDE5A90 for ; Mon, 30 May 2016 18:07:07 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id n129so93164132wmn.1 for ; Mon, 30 May 2016 09:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=DK0y7tWyXk7l5vE/A/wBHJea4gHTN3UeVTWwJ00+g2Q=; b=glr2MJh0EOzxQRXnY39vBsumuqP5JSdio0Fl+mlu0ciYLbs8uhBxXVCOpJdQDLWFrX oadd0x36T7Pr/cBjRPLaMmbGk//qWBvNKy03cqPJNOPEt4jnyJjpW2W8KZm39hArYHbb S2OTbkFqjMiVk5JGKE94pZsX4BcPcQdz0tfd6yKVlHn2+5JEMDgnzf6Hv04n2JpRMhTr yXgTHk9hQhCORit9SU1/UMEU3tKj/7wTiAK7OcQ75Za3sGP/6RCrEdNKfdmkZBxSNHiS 6jGU2fsDqEJJvwR3V1/qKKoMlPQGLiuHKv++gZoyBujv2Nm9rFe/m7FH4qmxwm+OR3v1 h8IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=DK0y7tWyXk7l5vE/A/wBHJea4gHTN3UeVTWwJ00+g2Q=; b=hIg/WELJkFW2GJm65kieiQxmUnwANA0Jv81Y0UPvII3Oh6zA0aL3SOLzH3xQcu2f3J Jf7tYd77ZOCHaw8BooXXxwR0E73tKoZG10VSGBtCi7OUNCknYPAIC/x72WYYVdZzBeg/ 5kK4ADdYKMxu/WTqo2UDE8yYaKtbwQTNZ5uptNG+0HoiFbcCAjzg/kPGXEDZFIRKM3/d XnrYER8cpHgQ0vmdJiGy6VkT9CLtVvF8xy67GewfNVi8puK2EYjCHxGKRPrRyjMw9qlp 10+/PrCflSJoZsliFA06wTvwBKKrFlk9X54NSwB946tYXKZGgkITLOGDxRiftQOqIvao gsrA== X-Gm-Message-State: ALyK8tK64dYWkd2qaZVvOTHyNoNUneLEbsDmaIYKFxYtDEF51wc67jPOBPFQ9V8ci1fbWswc X-Received: by 10.28.173.66 with SMTP id w63mr12485372wme.14.1464624427032; Mon, 30 May 2016 09:07:07 -0700 (PDT) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id c185sm24667161wme.9.2016.05.30.09.07.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 09:07:06 -0700 (PDT) Date: Mon, 30 May 2016 18:07:03 +0200 From: Adrien Mazarguil To: Olivier Matz Cc: "dev@dpdk.org" , "Ananyev, Konstantin" , Yuanhan Liu , "Richardson, Bruce" Message-ID: <20160530160703.GH1428@6wind.com> Mail-Followup-To: Olivier Matz , "dev@dpdk.org" , "Ananyev, Konstantin" , Yuanhan Liu , "Richardson, Bruce" References: <574C5B9D.4080006@6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <574C5B9D.4080006@6wind.com> Subject: Re: [dpdk-dev] about rx checksum flags 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: Mon, 30 May 2016 16:07:07 -0000 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