From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-f177.google.com (mail-wj0-f177.google.com [209.85.210.177]) by dpdk.org (Postfix) with ESMTP id 929B9106A for ; Mon, 12 Dec 2016 12:17:19 +0100 (CET) Received: by mail-wj0-f177.google.com with SMTP id tk12so68742059wjb.3 for ; Mon, 12 Dec 2016 03:17:19 -0800 (PST) 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:references:mime-version :content-disposition:in-reply-to; bh=bF93zpu5UbbzFmFKuAum9xhRe92giraCoP05dwKyMUQ=; b=laCOElvPLQyEuKUu1i6bertooRpirGYZzXefzXlAgrBEpL5qHDs/QePJsrg80AKcl2 US7ttM3B8U9PeOJepYa2o4vxdTeY/yymLl3g5aEEHb9kKbsLNbqkJ/DAPclrjYMVrDaC tEvTErMmwXxs3UPNTb2VTFm0JzL8o4A61dCDwa3PKiznQBEXZh6q0kjP0nOR0xz8K11B e3GefSI7ZS6nFsUp+Bt8Goen+8yovtJpFXtb7mBhW7nv29iDibbTk0JcGOyTdsieaYBc GtFsY10rh06uCTwWeyFvY6HCogk1zTHc4tHTugpKpKgJSpBnc8ueAqYlYIuUuq5tYKPx U6MA== 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:references :mime-version:content-disposition:in-reply-to; bh=bF93zpu5UbbzFmFKuAum9xhRe92giraCoP05dwKyMUQ=; b=FbFqGFNuYq0Py2ozpGFcGHHDIR5Bw3xhu9g6k8VVys/3tKINU+vLn9yJfB6b4/ABMi k/fC38b0EVrroaqP1Fzcx8y51PVp/LSmBKchzCoAk5iDP34e3gwpyJljJWrlk8XPiCQN 1jTpH6eMzJBIs0U1hahejrdsOJXk2HdKH+OpIPfdFvDmVk51EMgv/xuB3b566qREOeYe iUYS+CSj764F7AMDskOJz10tkDtreErWSjMM0zztfA+fGzp1oVgOCxFqoyMSvBNrfALM 3Tb1+NN516XvXue7xqTIioDFB/D9LJ9scQUunHAQTBNQM5zpLYZz4vcjAJdZ0CjK3kvQ QTBg== X-Gm-Message-State: AKaTC01JMqcd2Mnpg9saqfr/YbrmodywXA1rdN87PwVs6D5SwA9tuipaGnhVtUX2SfW2jGLm X-Received: by 10.194.162.8 with SMTP id xw8mr25363899wjb.125.1481541439308; Mon, 12 Dec 2016 03:17:19 -0800 (PST) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id kq7sm56630810wjb.30.2016.12.12.03.17.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Dec 2016 03:17:18 -0800 (PST) Date: Mon, 12 Dec 2016 12:17:11 +0100 From: Adrien Mazarguil To: "Chandran, Sugesh" Cc: Kevin Traynor , "dev@dpdk.org" , Thomas Monjalon , "De Lara Guarch, Pablo" , Olivier Matz Message-ID: <20161212111711.GS10340@6wind.com> References: <1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com> <59393e58-6c85-d2e5-1aab-a721fe9c933e@redhat.com> <20161201083652.GI10340@6wind.com> <7f65ba09-e6fe-d97a-6ab5-97e84a828a81@redhat.com> <2EF2F5C0CC56984AA024D0B180335FCB13EC330D@IRSMSX102.ger.corp.intel.com> <20161208150908.GJ10340@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13EC4696@IRSMSX102.ger.corp.intel.com> <20161209163846.GN10340@6wind.com> <2EF2F5C0CC56984AA024D0B180335FCB13EC4F76@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2EF2F5C0CC56984AA024D0B180335FCB13EC4F76@IRSMSX102.ger.corp.intel.com> Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API 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, 12 Dec 2016 11:17:19 -0000 Hi Sugesh, On Mon, Dec 12, 2016 at 10:20:18AM +0000, Chandran, Sugesh wrote: > Hi Adrien, > > Regards > _Sugesh > > > -----Original Message----- > > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com] > > Sent: Friday, December 9, 2016 4:39 PM > > To: Chandran, Sugesh > > Cc: Kevin Traynor ; dev@dpdk.org; Thomas > > Monjalon ; De Lara Guarch, Pablo > > ; Olivier Matz ; > > sugesh.chandran@intel.comn > > Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API > > > > Hi Sugesh, > > > > On Fri, Dec 09, 2016 at 12:18:03PM +0000, Chandran, Sugesh wrote: > > [...] > > > > > Are you going to provide any control over the initialization of > > > > > NIC to define the capability matrices For eg; To operate in a L3 > > > > > router mode, > > > > software wanted to initialize the NIC port only to consider the L2 > > > > and L3 fields. > > > > > I assume the initialization is done based on the first rules that > > > > > are > > > > programmed into the NIC.? > > > > > > > > Precisely, PMDs are supposed to determine the most appropriate > > > > device mode to use in order to handle the requested rules. They may > > > > even switch to another mode if necessary assuming this does not > > > > break existing constraints. > > > > > > > > I think we've discussed an atomic (commit-based) mode of operation > > > > through separate functions as well, where the application would > > > > attempt to create a bunch of rules at once, possibly making it > > > > easier for PMDs to determine the most appropriate mode of operation > > for the device. > > > > > > > > All of these may be added later according to users feedback once the > > > > basic API has settled. > > > [Sugesh] Yes , we discussed about this before. However I feel that, it > > > make sense to provide some flexibility to the user/application to define a > > profile/mode of the device. > > > This way the complexity of determining the mode by itself will be taken > > away from PMD. > > > Looking at the P4 enablement patches in OVS, the mode definition APIs > > > can be used in conjunction > > > P4 behavioral model. > > > For eg: A P4 model for a L2 switch operate OVS as a L2 switch. Using > > > the mode definition APIs Its possible to impose the same behavioral model > > in the hardware too. > > > This way its simple, clean and very predictive though it needs to define an > > additional profile_define APIs. > > > I am sorry to provide the comment at this stage, However looking at > > > the adoption of ebpf, P4 make me to think this way. > > > What do you think? > > > > What you suggest (device profile configuration) would be done by a separate > > function in any case, so as long as everyone agrees on a generic method to > > do so, no problem with extending rte_flow. By default in the meantime we'll > > have to rely on PMDs to make the right decision. > [Sugesh] I am fine with PMD is making the decision on profile/mode selection in > Default case. However we must provide an option for the application to define a mode > and PMD must honor with it to avoid making an invalid mode change. > > > > Do you think it has to be defined from the beginning? > [Sugesh] I feel it's going to be another big topic to decide how proposed mode implementation will be looks like, > What should be available modes and etc. So I am OK to consider as its not part of this flow API definition for now. > However its good to mention that in the API comments section to be aware. Do you agree that? Will do, I'll mention it in the "future evolutions" section. -- Adrien Mazarguil 6WIND