From mboxrd@z Thu Jan  1 00:00:00 1970
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Subject: Re: [PATCH v2 14/15] ethdev: add physical port action to
 flow API
Date: Mon, 9 Apr 2018 17:00:33 +0200
Message-ID: <20180409150033.GB4957@6wind.com>
References: <20180404150312.12304-1-adrien.mazarguil@6wind.com>
 <20180406131736.19145-1-adrien.mazarguil@6wind.com>
 <20180406131736.19145-15-adrien.mazarguil@6wind.com>
 <07a42ecb-3a82-edc7-6763-1fd850ce580b@solarflare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Thomas Monjalon <thomas@monjalon.net>,
 Ferruh Yigit <ferruh.yigit@intel.com>, dev@dpdk.org,
 "Zhang, Qi Z" <qi.z.zhang@intel.com>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wr0-f169.google.com (mail-wr0-f169.google.com
 [209.85.128.169]) by dpdk.org (Postfix) with ESMTP id D24387EBF
 for <dev@dpdk.org>; Mon,  9 Apr 2018 17:00:47 +0200 (CEST)
Received: by mail-wr0-f169.google.com with SMTP id l49so9930356wrl.4
 for <dev@dpdk.org>; Mon, 09 Apr 2018 08:00:47 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <07a42ecb-3a82-edc7-6763-1fd850ce580b@solarflare.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://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: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On Sat, Apr 07, 2018 at 12:51:40PM +0300, Andrew Rybchenko wrote:
> On 04/06/2018 04:25 PM, Adrien Mazarguil wrote:
> > This patch adds the missing action counterpart to the PHY_PORT pattern
> > item, that is, the ability to directly inject matching traffic into a
> > physical port of the underlying device.
> 
> Does it mean that if it is applied on ingress (incoming packet from network)
> it will simply send packets back to network (specified physical port)?

Precisely.

> And if it is applied on egress (outgoing from device to network) it will
> be directed to possibly different physical port and sent to network.

Right, note it gives applications the ability to express that wish, the fact
PMDs support it is another matter :)

In any case, this action is added for API completeness but should be rarely
necessary since we chose to go with port representors.

Port representors will expose valid DPDK port IDs, therefore applications
will simply have to create ingress/egress flow rules on the right DPDK port
targeting different port IDs through the PORT_ID action.

> > It breaks ABI compatibility for the following public functions:
> > 
> > - rte_flow_copy()
> > - rte_flow_create()
> > - rte_flow_query()
> > - rte_flow_validate()
> > 
> > Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > Cc: "Zhang, Qi Z" <qi.z.zhang@intel.com>
> > ---
> >   app/test-pmd/cmdline_flow.c                 | 35 ++++++++++++++++++++++++
> >   app/test-pmd/config.c                       |  1 +
> >   doc/guides/prog_guide/rte_flow.rst          | 20 ++++++++++++++
> >   doc/guides/testpmd_app_ug/testpmd_funcs.rst |  5 ++++
> >   lib/librte_ether/rte_flow.c                 |  1 +
> >   lib/librte_ether/rte_flow.h                 | 22 +++++++++++++++
> >   6 files changed, 84 insertions(+)
> 
> <...>

-- 
Adrien Mazarguil
6WIND