From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id D155E160 for ; Mon, 8 Oct 2018 11:04:55 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 71AB921D23; Mon, 8 Oct 2018 05:04:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 08 Oct 2018 05:04:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=F9g1chfHiMwDiqLxAPItUC/CcabNqcI9/OmlyQGPiEg=; b=TEitspqAsdAW Vjvc0tdYF9riJrNp5WmO3uhkBnqHVvc9kWLCh0v7Wz9WROuqgghknGL2A2VsOg+r HfDanKnIb3XsK0GmGPwWkudCWNkJIzeSJkbZGNawuUDvhOgXhIZqfL4fC6qqVWR/ NlCwpjDqG5ct2lfXwSGTC1SXdlXyAxM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=F9g1chfHiMwDiqLxAPItUC/CcabNqcI9/OmlyQGPi Eg=; b=k6/0WKrEtRbtJL3t3MmMEgYzfnK5u4kNdiPnxkrq6zDMgFq56cTKQaPxB kNnSXzzVI6+dS8oT6OM2h1Yo5FWtJ14g2lXN1cHUXx5M7M8Sbn5Y3aABRCfBtIVo CqJJcAElIRS0Av9CqD2Mb9n3LQIj9IicWDsfrx5G2iKz+q1eoUFpBuqqWLzEPKOO 2WkJ39l1/Vble0qsNYT7BoEufTPuEv+guSAehBJSqweFtCFF2sMJV7eUs9G6w+Rs 6k05sX66d59Rad7jOSlLJhCnNg3WWrgVDl2BTof4oPp+q96Owm/VJx87iG/AesNn 2ePV+ew/jX7jZwdcl7LJmLbfGnrWg== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C4ED3102D3; Mon, 8 Oct 2018 05:04:52 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob , Ferruh Yigit , "Ananyev, Konstantin" Cc: Andrew Rybchenko , "Lu, Wenzhuo" , "Wu, Jingjing" , "Iremonger, Bernard" , "Mcnamara, John" , "Kovacevic, Marko" , Olivier Matz , "dev@dpdk.org" , "shahafs@mellanox.com" , "didier.pallard@6wind.com" Date: Mon, 08 Oct 2018 11:04:51 +0200 Message-ID: <2218090.RkeNvosNi6@xps> In-Reply-To: <20181008082421.GA3554@jerin> References: <20180913134707.23698-1-jerin.jacob@caviumnetworks.com> <601d2413-e148-73c4-e7a5-59f09bd02451@intel.com> <20181008082421.GA3554@jerin> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add Rx offload outer UDP checksum definition X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2018 09:04:56 -0000 08/10/2018 10:24, Jerin Jacob: > From: Ferruh Yigit > > On 10/6/2018 1:18 PM, Ananyev, Konstantin wrote: > > > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com] > > >> From: Thomas Monjalon > > >>> However, we should re-visit the flag PKT_RX_EIP_CKSUM_BAD. > > >> > > >> Do we need to block this patch due to the exiting PKT_RX_EIP_CKSUM_BAD > > >> definition? > > >> > > >> I already added the author of the PKT_RX_EIP_CKSUM_BAD flag and ethdev and mbuf > > >> maintainers in this list. So what else I need make forward progress > > >> on this patch? > > >> > > >> I think, the definition of PKT_RX_EIP_CKSUM_BAD based on HW capability. It > > >> is safe to assume that ALL HW can support CKSUM BAD if the feature is > > >> available and hence it is more portable. > > > > > > Yes, as I remember PKT_RX_EIP_CKSUM_BAD is based on DEV_RX_OFFLOAD_OUTER_IPV4_CKSUM. > > > > Switching to two bit won't reduce the portability, HW supports only reporting > > CKSUM_BAD can set BAD || UNKNOWN. > > UNKNOWN is not a bit. It is represented as 0. It spec has 2 bit, then > driver need to report GOOD as well. > > Same applies for PKT_RX_EL4_CKSUM as well. > > > > > And I think patch is not blocked by PKT_RX_EIP_CKSUM_BAD, it can be changed > > separately, for this patch question is can we represent PKT_RX_EL4_CKSUM_* with > > two bits, to have BAD/GOOD/UNKNOWN? Yes, exact. PKT_RX_EIP_CKSUM_BAD must be left aside. We should just avoid taking it as a reference. And we can reconsider its definition later.