From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro <nelio.laranjeiro@6wind.com>
Subject: Re: [PATCH v4 03/11] net/mlx5: support L3 VXLAN flow
Date: Thu, 19 Apr 2018 13:15:26 +0200
Message-ID: <20180419111526.kh4rdujzomrb4isz@laranjeiro-vm.dev.6wind.com>
References: <20180413112023.106420-1-xuemingl@mellanox.com>
 <20180417151436.161374-4-xuemingl@mellanox.com>
 <20180418064856.hk5bst2wuzxxwv6r@laranjeiro-vm.dev.6wind.com>
 <VI1PR05MB16784858EE0A851113E1EA77ACB60@VI1PR05MB1678.eurprd05.prod.outlook.com>
 <20180418150858.tlfmca2y3fhv2xcp@laranjeiro-vm.dev.6wind.com>
 <VI1PR05MB16781F1D6FC177480DBC1A46ACB50@VI1PR05MB1678.eurprd05.prod.outlook.com>
 <20180419065541.s4iy36c6amaavvm7@laranjeiro-vm.dev.6wind.com>
 <DB5PR05MB167165A899132F58DB2402CFACB50@DB5PR05MB1671.eurprd05.prod.outlook.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Cc: Shahaf Shuler <shahafs@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>
To: "Xueming(Steven) Li" <xuemingl@mellanox.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mail-wr0-f180.google.com (mail-wr0-f180.google.com
 [209.85.128.180]) by dpdk.org (Postfix) with ESMTP id 013222C01
 for <dev@dpdk.org>; Thu, 19 Apr 2018 13:14:50 +0200 (CEST)
Received: by mail-wr0-f180.google.com with SMTP id q13-v6so12979127wre.3
 for <dev@dpdk.org>; Thu, 19 Apr 2018 04:14:50 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <DB5PR05MB167165A899132F58DB2402CFACB50@DB5PR05MB1671.eurprd05.prod.outlook.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 Thu, Apr 19, 2018 at 10:21:26AM +0000, Xueming(Steven) Li wrote:
> 
> 
> > -----Original Message-----
> > From: Nélio Laranjeiro <nelio.laranjeiro@6wind.com>
> > Sent: Thursday, April 19, 2018 2:56 PM
> > To: Xueming(Steven) Li <xuemingl@mellanox.com>
> > Cc: Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org
> > Subject: Re: [PATCH v4 03/11] net/mlx5: support L3 VXLAN flow
> > 
> > On Thu, Apr 19, 2018 at 06:20:50AM +0000, Xueming(Steven) Li wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Nélio Laranjeiro <nelio.laranjeiro@6wind.com>
> > > > Sent: Wednesday, April 18, 2018 11:09 PM
> > > > To: Xueming(Steven) Li <xuemingl@mellanox.com>
> > > > Cc: Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org
> > > > Subject: Re: [PATCH v4 03/11] net/mlx5: support L3 VXLAN flow
> > > >
> > > > On Wed, Apr 18, 2018 at 02:43:30PM +0000, Xueming(Steven) Li wrote:
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Nélio Laranjeiro <nelio.laranjeiro@6wind.com>
> > > > > > Sent: Wednesday, April 18, 2018 2:49 PM
> > > > > > To: Xueming(Steven) Li <xuemingl@mellanox.com>
> > > > > > Cc: Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org
> > > > > > Subject: Re: [PATCH v4 03/11] net/mlx5: support L3 VXLAN flow
> > > > > >
> > > > > > On Tue, Apr 17, 2018 at 11:14:28PM +0800, Xueming Li wrote:
> > > > > > > This patch support L3 VXLAN, no inner L2 header comparing to
> > > > > > > standard VXLAN protocol. L3 VXLAN using specific overlay UDP
> > > > > > > destination port to discriminate against standard VXLAN, FW
> > > > > > > has to be configured to support
> > > > > > > it:
> > > > > > >   sudo mlxconfig -d <device> -y s IP_OVER_VXLAN_EN=1
> > > > > > >   sudo mlxconfig -d <device> -y s IP_OVER_VXLAN_PORT=<port>
> > > > > > >
> > > > > > > Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> > > > > > > ---
> > > > > > >  drivers/net/mlx5/mlx5_flow.c | 4 +++-
> > > > > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/drivers/net/mlx5/mlx5_flow.c
> > > > > > > b/drivers/net/mlx5/mlx5_flow.c index 771d5f14d..d7a921dff
> > > > > > > 100644
> > > > > > > --- a/drivers/net/mlx5/mlx5_flow.c
> > > > > > > +++ b/drivers/net/mlx5/mlx5_flow.c
> > > > > > > @@ -413,7 +413,9 @@ static const struct mlx5_flow_items mlx5_flow_items[] = {
> > > > > > >  		.dst_sz = sizeof(struct ibv_flow_spec_tunnel),
> > > > > > >  	},
> > > > > > >  	[RTE_FLOW_ITEM_TYPE_VXLAN] = {
> > > > > > > -		.items = ITEMS(RTE_FLOW_ITEM_TYPE_ETH),
> > > > > > > +		.items = ITEMS(RTE_FLOW_ITEM_TYPE_ETH,
> > > > > > > +			       RTE_FLOW_ITEM_TYPE_IPV4, /* For L3 VXLAN. */
> > > > > > > +			       RTE_FLOW_ITEM_TYPE_IPV6), /* For L3 VXLAN. */
> > > > > > >  		.actions = valid_actions,
> > > > > > >  		.mask = &(const struct rte_flow_item_vxlan){
> > > > > > >  			.vni = "\xff\xff\xff",
> > > > > > > --
> > > > > > > 2.13.3
> > > > > >
> > > > > > Such support must be under device parameter has it depends on
> > > > > > the configuration of the firmware.  If the firmware is not
> > > > > > correctly configured the PMD must refuse
> > > > such rule.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > --
> > > > > > Nélio Laranjeiro
> > > > > > 6WIND
> > > > >
> > > > > Are you suggesting Verbs parameter? I'm afraid we can't have it in
> > > > > short time, need new patch in later release when Verbs ready.
> > > >
> > > > Take a look at [1], this is what I mean.
> > >
> > > Enabling a new device parameter can't make L3 VXLAN packet get
> > > received if fw configuration not set.
> > 
> > So you expect than the user will enable a feature without reading the PMD documentation?
> > If it is the case, the answer it pretty simple, it is the same as above, read the PMD documentation.
> > 
> > > On the other hand, if fw continuation enabled and device parameter not
> > > set, packet could be received but failed to create rule.
> > 
> > Again a user using a NIC should read the documentation.
> 
> If a user read the document, fw should be configured correctly to enable this feature.

And a user which does not read this document must not be able to create
rules the NIC cannot handle because the firmware is not configured.

> > > I'm afraid that a device parameter will introduce complexity of using
> > > this feature w/o real benefits.
> > 
> > Add this missing device parameter and update accordingly the documentation, or wait for Verbs to add
> > the missing query feature.
> > 
> > If the firmware it not configured this rule must be refused, as there is no way in the PMD to know if
> > the firmware is configured, it must rely on a device parameter.
> 
> Let's keep the design simple, users know exactly what they are doing and should not expecting 
> such flow working by reading document.

This is exactly the opposite, users never read documentation even
today I've already spotted a new user to such documentation [1].

For this same reason a functionality not enabled by default in the
firmware must not be used by the PMD.  No device parameter no feature.

Add the device parameter and the according documentation.

Regards,

[1] https://dpdk.org/ml/archives/users/2018-April/003020.html

-- 
Nélio Laranjeiro
6WIND