From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f68.google.com (mail-wm0-f68.google.com [74.125.82.68]) by dpdk.org (Postfix) with ESMTP id D62191B826 for ; Mon, 9 Apr 2018 16:49:57 +0200 (CEST) Received: by mail-wm0-f68.google.com with SMTP id r191so19632869wmg.4 for ; Mon, 09 Apr 2018 07:49:57 -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:references:mime-version :content-disposition:in-reply-to; bh=uGg4XEgSfYTb8vulJ6aAUKdtAgjAhJRWhdIkS8Rx5LQ=; b=FmElbqyw9pmDNZqqwp3aP2zkHgeN0q9rmvnIjSk8VEcFLj+WoUGsahoYkOlIGn2Dzs 1YXlW7d+0SbWw7Ythd8r9Z7ATVtmnwD5Oh+HoGCPouR+4evhJi3TS2N0Dqd/7frlYbBV shcbti2DUIOgMuqcBwZbcumw3JhPBiDsN0jKHeDr4ASVqBjGsK8hVStSkmCwUxb3P4Lo HikOtsAk388IstSgomiScrYIR+AdXeqbbwf9UFhxs0TKJNLbzxd/TTaDYJypX0bMqDFj pJVnuCXKMnYimTOmnzflGp/qq1TBFAheJnwjlk9NisbAe6HMxirsZbvegcPOWXwp7Qow FscA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=uGg4XEgSfYTb8vulJ6aAUKdtAgjAhJRWhdIkS8Rx5LQ=; b=X+OHCt0zMTPZNkQzscIQKmbVObPYEkIsFhyQiTkocqNybya+b4/gWKwAnODEOU8wHG LVZVcsXJkDHb9o44eQcBruRXKUHuhvY5qAqa9zX660PvnHw8r3itkzgOPnhgrsP/oUlP EDQtTRf635C4GJfSfQWXVJ5pp3bwUeykundE4IR2e91/HHp1ftsTPeXAmUnSDzHC5SZz yLZGp/I6jFJoc0Z593t0USHUxw3KbjEbBF4m8uHPTnXFlpV3Fufl7je4g+iIuO1cS9Xm aHA7psog9ctnF0zIScvnSMvjNle9mIu2svRZE0Zx89ZYzfL2g9sbukqxaXj9QrLapHii uybQ== X-Gm-Message-State: ALQs6tD7vFpk23E4sr5MN9RHiynLQQUchaikl216s+PYQUYb+hwxyuj8 WkxVTVqlpXlua6fBOSAPO+TQHg== X-Google-Smtp-Source: AIpwx49okhgmx2rS8VOWE3mURXx5bs+cz9dlbtkJmv+8pbFzBhR+HmSALA0iI30ExoL0JRbO0ZeBiw== X-Received: by 10.28.132.211 with SMTP id g202mr206086wmd.17.1523285397634; Mon, 09 Apr 2018 07:49:57 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id p4sm1157213wma.5.2018.04.09.07.49.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Apr 2018 07:49:56 -0700 (PDT) Date: Mon, 9 Apr 2018 16:49:43 +0200 From: Adrien Mazarguil To: Andrew Rybchenko Cc: Thomas Monjalon , Ferruh Yigit , dev@dpdk.org, Ajit Khaparde , Somnath Kotur , Beilei Xing , Qi Zhang Message-ID: <20180409144943.GA4957@6wind.com> References: <20180404150312.12304-1-adrien.mazarguil@6wind.com> <20180406131736.19145-1-adrien.mazarguil@6wind.com> <20180406131736.19145-13-adrien.mazarguil@6wind.com> <664d5436-bd31-6f29-d309-a444db6d5a3e@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <664d5436-bd31-6f29-d309-a444db6d5a3e@solarflare.com> Subject: Re: [dpdk-dev] [PATCH v2 12/15] ethdev: update behavior of VF/PF in 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, 09 Apr 2018 14:49:58 -0000 On Sat, Apr 07, 2018 at 12:41:17PM +0300, Andrew Rybchenko wrote: > On 04/06/2018 04:25 PM, Adrien Mazarguil wrote: > > Contrary to all other pattern items, these are inconsistently documented as > > affecting traffic instead of simply matching its origin, without provision > > for the latter. > > > > This commit clarifies documentation and updates PMDs since the original > > behavior now has to be explicitly requested using the new transfer > > attribute. > > > > It breaks ABI compatibility for the following public functions: > > > > - rte_flow_create() > > - rte_flow_validate() > > > > Impacted PMDs are bnxt and i40e, for which the VF pattern item is now only > > supported when a transfer attribute is also present. > > > > Signed-off-by: Adrien Mazarguil > > Cc: Ajit Khaparde > > Cc: Somnath Kotur > > Cc: Beilei Xing > > Cc: Qi Zhang > > --- > > app/test-pmd/cmdline_flow.c | 12 +++--- > > doc/guides/prog_guide/rte_flow.rst | 36 +++++++++--------- > > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 12 +++--- > > drivers/net/bnxt/bnxt_filter.c | 22 ++++++----- > > drivers/net/i40e/i40e_flow.c | 23 +++++++----- > > lib/librte_ether/rte_flow.h | 47 ++++++++++-------------- > > 6 files changed, 77 insertions(+), 75 deletions(-) > > <...> > > > diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst > > index 735ce6323..beedc713b 100644 > > --- a/doc/guides/prog_guide/rte_flow.rst > > +++ b/doc/guides/prog_guide/rte_flow.rst > > @@ -518,15 +518,12 @@ Usage example, matching non-TCPv4 packets only: > > Item: ``PF`` > > ^^^^^^^^^^^^ > > -Matches packets addressed to the physical function of the device. > > +Matches traffic originating from (ingress) or going to (egress) the physical > > +function of the current device. > > Not sure that I understand above. It looks like ingress and egress are > misplaced. > There many similar cases below. In this API, "ingress" and "egress" are always defined as relative to the application creating the flow rule. In that sense they are respectively synonyms for "from" and "to". I agree they are not properly defined in this document, in fact ingress and egress were clarified (with diagrams and all) in the RFC submitted prior to this patch [1]. I will update the "Attribute: Traffic direction" section in my next update. [1] See "Traffic direction" in http://dpdk.org/ml/archives/dev/2018-March/092513.html -- Adrien Mazarguil 6WIND