[dpdk-dev] [PATCH v4 03/11] net/mlx5: support L3 VXLAN flow

[Xueming(Steven) Li]

> -----Original Message-----
> From: Nélio Laranjeiro <nelio.laranjeiro at 6wind.com>
> Sent: Thursday, April 19, 2018 7:15 PM
> To: Xueming(Steven) Li <xuemingl at mellanox.com>
> Cc: Shahaf Shuler <shahafs at mellanox.com>; dev at dpdk.org
> Subject: Re: [PATCH v4 03/11] net/mlx5: support L3 VXLAN flow
> 
> On Thu, Apr 19, 2018 at 10:21:26AM +0000, Xueming(Steven) Li wrote:
> >
> >
> > > -----Original Message-----
> > > From: Nélio Laranjeiro <nelio.laranjeiro at 6wind.com>
> > > Sent: Thursday, April 19, 2018 2:56 PM
> > > To: Xueming(Steven) Li <xuemingl at mellanox.com>
> > > Cc: Shahaf Shuler <shahafs at mellanox.com>; dev at 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 at 6wind.com>
> > > > > Sent: Wednesday, April 18, 2018 11:09 PM
> > > > > To: Xueming(Steven) Li <xuemingl at mellanox.com>
> > > > > Cc: Shahaf Shuler <shahafs at mellanox.com>; dev at 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 at 6wind.com>
> > > > > > > Sent: Wednesday, April 18, 2018 2:49 PM
> > > > > > > To: Xueming(Steven) Li <xuemingl at mellanox.com>
> > > > > > > Cc: Shahaf Shuler <shahafs at mellanox.com>; dev at 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 at 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].

  "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.
   Again a user using a NIC should read the documentation."

> 
> 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.

Unlike other functionality, this feature related to supporting a new tunnel type, w/o fw configuration, 
L3 VXLAN packet certainly be treated as normal packet, it doesn't hurt. How do you think?

> 
> Add the device parameter and the according documentation.
> 
> Regards,
> 
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdpdk.org%2Fml%2Farchives%2Fusers%2F
> 2018-
> April%2F003020.html&data=02%7C01%7Cxuemingl%40mellanox.com%7C7b417f2ace1044d6858a08d5a5e6c502%7Ca65297
> 1c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636597332927305548&sdata=7sUJ8okKx2yKTQz9nXfi%2B2cDwYVUbMa41glmez
> SYQyQ%3D&reserved=0
> 
> --
> Nélio Laranjeiro
> 6WIND