Re: [PATCH v3 03/14] net/mlx5: support L3 VXLAN flow

["Xueming(Steven) Li" <xuemingl@mellanox.com>]

> -----Original Message-----
> From: Nélio Laranjeiro <nelio.laranjeiro@6wind.com>
> Sent: Friday, April 13, 2018 8:14 PM
> To: Xueming(Steven) Li <xuemingl@mellanox.com>
> Cc: Shahaf Shuler <shahafs@mellanox.com>; dev@dpdk.org
> Subject: Re: [PATCH v3 03/14] net/mlx5: support L3 VXLAN flow
> 
> On Fri, Apr 13, 2018 at 07:20:12PM +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>
> 
> This fully deserves to update MLX5 guide with such information, users are
> already not reading it, don't expect them to read commit logs.

Okay, I'll add them into document update commit

> 
> > 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 2aae988f2..644f26a95 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, /* L3 VXLAN. */
> > +			       RTE_FLOW_ITEM_TYPE_IPV6), /* L3 VXLAN. */
> 
> s/L3/For L3/
> 
> >  		.actions = valid_actions,
> >  		.mask = &(const struct rte_flow_item_vxlan){
> >  			.vni = "\xff\xff\xff",
> > --
> > 2.13.3
> 
> There is an important question about this support as the firmware needs to
> be configured for it.
> 
> 1. Is such rule accepted by the kernel modules if the support is not
> enabled in the firmware?

Yes.

> 
> 2. Is it possible from the PMD to query such information?

Unfortunately.

> 
> If both answers are no, such features should be enabled through a device
> parameter to let the PMD refuse such un-supported flow request.
> 
> Thanks,
> 
> --
> Nélio Laranjeiro
> 6WIND