From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <adrien.mazarguil@6wind.com>
Received: from mail-wm0-f52.google.com (mail-wm0-f52.google.com [74.125.82.52])
 by dpdk.org (Postfix) with ESMTP id B719E3772
 for <dev@dpdk.org>; Fri,  9 Dec 2016 17:38:55 +0100 (CET)
Received: by mail-wm0-f52.google.com with SMTP id a197so32010711wmd.0
 for <dev@dpdk.org>; Fri, 09 Dec 2016 08:38:55 -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=AGe9WIEi8UbkxlQ+1LIhNJKS3FeeDTaycXnZsPugsIU=;
 b=ZSwajigvB0G4Frnr3YQYDyJLGgg0SHR8tpKLhRjLDdWArOg/umOpxDZTwX6RjfkXVp
 Vv1wWiv/lCsg+rTcIv2JOB7AWRFOyK3wHWxmLzI6+mqfctV1WvKskJKGJCzmRZHb1NXz
 /7eHf1IHYc/967ohPq6UA/PPu2eleUxN3YUqvau1qzetDm2gzA7z3fz7XvpmI03uNA0a
 rVFcp9IPDYUc/rhjGWV5DDjm/g4eCRi08f/URoh6V3oOJw3vxER7nuqqppR944D+zsZS
 xRBHF8Gm8X8LeuvL3xmizXKFp5bMQM8+4Xs42GQGG/ANiU0lNWqpUocKk+hsxt+lPGeX
 uOFA==
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=AGe9WIEi8UbkxlQ+1LIhNJKS3FeeDTaycXnZsPugsIU=;
 b=UuPeEd1Ub2QAbLh+cN7P4OKMT0Fw8ZT+VUoU05EjwPWG03oNwlWgpzXiifjxYVVu70
 77VcJwDp4c6Xvh4tBhBsgmSgTU1Or/nOwGzPyFAhdi0nt//AfLsJe3rUipzJBbWLjox1
 VXyPyImn8OjcryU1AlMgcnCoOZMfFJslDlY2cPwmtjpSFOLrgam+fQiVBUxUAt7a2JYw
 1GYeDbh6kaXbevTT+CJSJr+Ia5mNS8oAe32rsWCwW3yfC07RQgBVHLkAeGFs6rOEeqfG
 jXHGTf9lhdrS7q4vZmk6M7uwIT8F/e/n2V+ZXHx0InBP/unDIu3x9pLec85/KmIsKjVs
 MDkw==
X-Gm-Message-State: AKaTC02aY3zZOYoTvT9FR1CtUcDTMJqVg/+6Mx/thipqU4Hw99qCYpzsvy0WrhrE1owoZskO
X-Received: by 10.28.137.81 with SMTP id l78mr7334891wmd.36.1481301535203;
 Fri, 09 Dec 2016 08:38:55 -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 yj10sm43183043wjb.3.2016.12.09.08.38.53
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Fri, 09 Dec 2016 08:38:53 -0800 (PST)
Date: Fri, 9 Dec 2016 17:38:46 +0100
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: "Chandran, Sugesh" <sugesh.chandran@intel.com>
Cc: Kevin Traynor <ktraynor@redhat.com>, "dev@dpdk.org" <dev@dpdk.org>,
 Thomas Monjalon <thomas.monjalon@6wind.com>,
 "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>,
 Olivier Matz <olivier.matz@6wind.com>,
 "sugesh.chandran@intel.comn" <sugesh.chandran@intel.comn>
Message-ID: <20161209163846.GN10340@6wind.com>
References: <cover.1471632644.git.adrien.mazarguil@6wind.com>
 <cover.1479309719.git.adrien.mazarguil@6wind.com>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2EF2F5C0CC56984AA024D0B180335FCB13EC4696@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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2016 16:38:55 -0000

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.

Do you think it has to be defined from the beginning?

-- 
Adrien Mazarguil
6WIND