From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) by dpdk.org (Postfix) with ESMTP id 926B9532E for ; Wed, 20 Jul 2016 19:10:38 +0200 (CEST) Received: by mail-wm0-f41.google.com with SMTP id q128so64423654wma.1 for ; Wed, 20 Jul 2016 10:10:38 -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:content-transfer-encoding :in-reply-to; bh=9drYgs0kFZfa5hZmaB3iygaILZIU/sCVJux4GRz0rOo=; b=L/mw8Gvd7zjfsdotjA3fgIFuAh4ZLJ7xPLr0ik7uLrtr8wEranHfjQ9ld03rxhaEXS L0l76X2+4TAzyhe4YEdfpE8O6RdKTZLM7GZcvPMRoSFMZBoaL8wMO84iyaX8m/Eo5SGs MJNPppFFrFNZyQU7suni8JWEMPZXFovg17GMjoILrBpbjZEcMOqAmiH02+5X0LPiQ8yX U1yq9OS64f7jDZ/bW1i3TRBnszBId0rVlGuWMOYBmAr6K5inTYzn8+RZJDcAWcu60pFd TszzCT8t2nu0CxpBW08fqsQyS77sDIpusEDenLEl4rvjW7YKhWta9dWiQ+h3a1+iOhke ATWw== 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 :content-transfer-encoding:in-reply-to; bh=9drYgs0kFZfa5hZmaB3iygaILZIU/sCVJux4GRz0rOo=; b=KlRvZ3rkNXaBxZ02cJQSCNeHOtY4Mg4geFZNEsNjBKsOpDIKVKxpy23jR/AfHVLpSC WXORGe+6BZFY+jxMONWVq5YFoLMzfAhVro51oT2Spv6hjgrqTFSi+HeOSup4ByjfFjli DVAWOyZilEXylWES+/QkuILClGIU6Ld42aZe6wupO2qSBFx2sR6MK2NDTwXZPsL8nIWX 0RCCRovCvnKiO35NZ0/ImG8WIl7lGMl7vvjsSJ3K4cyZFAuoXVVPqOaKcA/GRBG//kvb HULEYzBInLsT/LSHbPmQqxelwPC2F6XWsnuOIdkHFyTfR2cuqZXQssi0/o5wMigW+tms c7kQ== X-Gm-Message-State: ALyK8tL/l4MLm6QE6VvaFtv72Nbz1ahBVabZweyCLLF2lmAz41PdsEWCo6cvlPsocbuzYFs5 X-Received: by 10.28.31.147 with SMTP id f141mr11938464wmf.69.1469034638351; Wed, 20 Jul 2016 10:10:38 -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 m127sm30453737wmm.21.2016.07.20.10.10.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jul 2016 10:10:37 -0700 (PDT) Date: Wed, 20 Jul 2016 19:10:33 +0200 From: Adrien Mazarguil To: "Chandran, Sugesh" Cc: "dev@dpdk.org" , Thomas Monjalon , "Zhang, Helin" , "Wu, Jingjing" , Rasesh Mody , Ajit Khaparde , Rahul Lakkireddy , "Lu, Wenzhuo" , Jan Medala , John Daley , "Chen, Jing D" , "Ananyev, Konstantin" , Matej Vido , Alejandro Lucero , Sony Chacko , Jerin Jacob , "De Lara Guarch, Pablo" , Olga Shern , "Chilikin, Andrey" Message-ID: <20160720171033.GQ7621@6wind.com> Mail-Followup-To: "Chandran, Sugesh" , "dev@dpdk.org" , Thomas Monjalon , "Zhang, Helin" , "Wu, Jingjing" , Rasesh Mody , Ajit Khaparde , Rahul Lakkireddy , "Lu, Wenzhuo" , Jan Medala , John Daley , "Chen, Jing D" , "Ananyev, Konstantin" , Matej Vido , Alejandro Lucero , Sony Chacko , Jerin Jacob , "De Lara Guarch, Pablo" , Olga Shern , "Chilikin, Andrey" References: <20160705181646.GO7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13DEA331@IRSMSX102.ger.corp.intel.com> <20160708130310.GD7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13DEB236@IRSMSX102.ger.corp.intel.com> <20160713200327.GC7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13DEE55F@IRSMSX102.ger.corp.intel.com> <20160715150402.GE7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13E02938@IRSMSX102.ger.corp.intel.com> <20160718150029.GJ7621@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13E05C5C@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2EF2F5C0CC56984AA024D0B180335FCB13E05C5C@IRSMSX102.ger.corp.intel.com> Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification 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: Wed, 20 Jul 2016 17:10:38 -0000 Hi Sugesh, Please see below. On Wed, Jul 20, 2016 at 04:32:50PM +0000, Chandran, Sugesh wrote: [...] > > > How about a hardware flow flag in packet descriptor that set when the > > > packets hits any hardware rule. This way software doesn’t worry > > > /blocked by a hardware rule . Even though there is an additional > > > overhead of validating this flag, software datapath can identify the > > hardware processed packets easily. > > > This way the packets traverses the software fallback path until the > > > rule configuration is complete. This flag avoids setting ID action for every > > hardware flow that are configuring. > > > > That makes sense. I see it as a sort of single bit ID but it could be > > implemented through a different action for less capable devices. PMDs that > > support 32 bit IDs could reuse the same code for both features. > > > > I understand you'd prefer having this feature always present, however we > > already know that not all PMDs/devices support it, and like everything else > > this is a kind of offload that needs to be explicitly requested by the > > application as it may not be needed. > > > > If we go with the separate action, then perhaps it would make sense to > > rename "ID" to "MARK" to make things clearer: > > > > RTE_FLOW_ACTION_TYPE_FLAG /* Flag packets processed by flow rule. */ > > > > RTE_FLOW_ACTION_TYPE_MARK /* Attach a 32 bit value to a packet. */ > > > > I guess the result of the FLAG action would be something in ol_flag. > > > [Sugesh] This looks fine for me. Great, I will update the specification accordingly. > > Thoughts? > > > [Sugesh] Two more queries that I missed out in the earlier comments are, > Support for PTYPE :- Intel NICs can report packet type in mbuf. > This can be used by software for the packet processing. Is generic API > capable of handling that as well? Yes, however no PTYPE action has been defined for this (yet). It is only a matter of adding one. Currently packet type recognition is enabled per port using a separate API, so correct me if I'm wrong but I am not aware of any adapter with the ability to enable it per flow rule, so I do not think such an action needs to be defined from the start. We may add it later. > RSS hashing support :- Just to confirm, the RSS flow action allows application > to decide the header fields to produce the hash. This gives > programmability on load sharing across different queues. The > application can program the NIC to calculate the RSS hash only using mac or mac+ ip or > ip only using this. I'd say yes but from your summary, I'm not sure we share the same idea of what the RSS action is supposed to do, so here is mine. Like all flow rules, the pattern part of the RSS action only filters the packets on which the action will be performed. The rss_conf parameter (struct rte_eth_rss_conf) only provides a key and a RSS hash function to use (ETH_RSS_IPV4, ETH_RSS_NONFRAG_IPV6_UDP, etc). Nothing prevents the RSS hash function from being applied to protocol headers which are not necessarily present in the flow rule pattern. These are two independent things, e.g. you could have a pattern matching IPv4 packets yet perform RSS hashing only on UDP headers. Finally, the RSS action configuration only affects packets coming from this flow rule. It is not performed on the device globally so packets which are not matched are not affected by RSS processing. As a result it might not be possible to configure two flow rules specifying incompatible RSS actions simultaneously if the underlying device supports only a single global RSS context. Are we on the same page? -- Adrien Mazarguil 6WIND