From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B2997A00E6 for ; Thu, 8 Aug 2019 13:08:53 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id CC3CA1BDEB; Thu, 8 Aug 2019 13:08:52 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 2F0261B9E7 for ; Thu, 8 Aug 2019 13:08:51 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailnew.nyi.internal (Postfix) with ESMTP id 5FCA124A7; Thu, 8 Aug 2019 07:08:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 08 Aug 2019 07:08:50 -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=le8DKUFijOKha1ks8jebgZ5gBqqnBtuvAYNAa1L0GGQ=; b=ZarEHGTzQ0B8 RTBa2SPop2wws37mRSJsx9LPTVfAhy152WzLJ9CcL80DAazzmgenSry9WA7SIGy6 2nWC8fZFSBeq5FDi3l7ahg5S9gIiR4csa1jwBAaZv+YmLlq9N6ITE6ZJNJQBuW8E oUqTuTa5RuM5TnGa6WjY4yFrgdEWNqA= 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=le8DKUFijOKha1ks8jebgZ5gBqqnBtuvAYNAa1L0G GQ=; b=gqit5thm6O8vK2Zc2CQ9FCa0ibUmsTUlaeWjl5JgEXiNUddQV9iRP9Lbj gPFqxpytv0F1T7901Fzdd87XzLmjX9AMNePYe06E4NmV1gC07Vam3z7uPlHSJOf+ HW6CnUAMx0xPJLYDiMR2d8eP0Zn3IQVjUaguJ5TZiMmMhmFWgj8iRrTs60i+TNQL MZRXwJ8y/DiYbBz0nB3BdBGsYnXEKV57JBNoQcvK2MrcFQmhrptXY4IASOHrPcHk EZhYhAT6Qrl/70zJ4LT4QwcwFgnuS/1C3kp6r2Pf1q6Ir3UlRaZgFczd2htKDyPK A9udkuqc+CRgVENKMIP2YU8/tQXsQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudduhedgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeelfedriedrudegledruddugeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhm rghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (114.149.6.93.rev.sfr.net [93.6.149.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 095E1380087; Thu, 8 Aug 2019 07:08:47 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Kollanukkaran , "Ananyev, Konstantin" Cc: Pavan Nikhilesh Bhagavatula , "stephen@networkplumber.org" , "arybchenko@solarflare.com" , "hemant.agrawal@nxp.com" , "Yigit, Ferruh" , "Richardson, Bruce" , Neil Horman , "Mcnamara, John" , "Kovacevic, Marko" , "dev@dpdk.org" Date: Thu, 08 Aug 2019 13:08:46 +0200 Message-ID: <11191491.azPNE95Zc7@xps> In-Reply-To: References: <20190808081752.516-1-pbhagavatula@marvell.com> <2601191342CEEE43887BDE71AB9772580168A63A1B@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [patch v3] doc: announce API change in ethdev offload flags 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 08/08/2019 12:59, Jerin Jacob Kollanukkaran: > From: Ananyev, Konstantin > > From: Jerin Jacob Kollanukkaran [mailto:jerinj@marvell.com] > > > From: Ananyev, Konstantin > > > > > > > From: Pavan Nikhilesh > > > > > > One question about DEV_RX_OFFLOAD_PTYPE: > > > > > > Does it mean that new ol_flags value (PKT_RX_PTYPE) will be > > > > > > introduced to indicate that mbuf.packet_type value is set? > > > > > > Or PMD will have to set mbuf.packet_type to zero, when > > > > > > DEV_RX_OFFLOAD_PTYPE was not enabled by user? > > > > > > > > > > I was thinking when DEV_RX_OFFLOAD_PTYPE is set > > > > > - mbuf.packet_type will be valid and mbuf.packet_type will have > > > > > parsed > > > > packet type. > > > > > If not set > > > > > - mbuf.packet_type can be anything application should not use > > > > mbuf.packet_type field. > > > > > > > > But in that case, we do need a new value for ol_flags, PKT_RX_PTYPE > > > > or so, right? > > > > > > Since application has two knobs rte_eth_dev_get_supported_ptypes() and > > > DEV_RX_OFFLOAD_PTYPE. We may not need to new ol_flags for this > > change. Right? > > > i.e if application sets the DEV_RX_OFFLOAD_PTYPE, The application will > > > get the parsed ptypes by the driver(= > > rte_eth_dev_get_supported_ptypes()). > > > So there is no scope ambiguity. Right? > > > > I still think there is: > > Imagine user has 2 eth devices, one does support DEV_RX_OFFLOAD_PTYPE, > > second doesn't. Now he has a mix of packets from both devices, that you > > want t process. > > How would he figure out for which of them ptype values are valid, and for > > each are not? > > Trace back from what port he has received them? > > Not very convenient, and not always possible. > > I thought so. But in that case, application can always set DEV_RX_OFFLOAD_PTYPE > Flags for all the ethdev ports. Right? Rather having any complicated ol_flags > or port based parsing. If limit the _contract_ to following, we are good. Right? > # when DEV_RX_OFFLOAD_PTYPE is set, mbuf.packet_type will be valid > and mbuf.packet_type will have parsed packet type > > or the negative offload(This contract is pretty clear, I don't think any ambiguity at all) > # when DEV_RX_OFFLOAD_NO_PTYPE(something similar) is set, > mbuf.packet_type will be invalid. Just a note here: I am clearly against negative flags. We recently cleaned up the flags to all be positive.