[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 8:19 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 11:53:05AM +0000, Xueming(Steven) Li wrote:
> >
> >
> > > -----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?
> 
>  flow create 0 ingress eth / ipv4 / end action queue index 3 end
> 
> but the packet ends in queue 0, will it hurt?

This is the correct example: 

flow create 0 ingress pattern eth / ipv4 / udp dst is 4789 / vxlan / ipv4 / end actions rss queues 1 2  end / end

Users should never create such rule and expect it to work because it doesn't meet and VXLAN RFC.
If users want to match L3 VXLAN, read document and configure fw to get correct result.

> 
> Any rule *accepted* by the PMD *must* follow the user request, otherwise it is a bug.

I'd beg you to consider from user's perspective, the motivation of this design is to sale rte flow
by replacing device parameter, now we are making the flow usage awkward.

> 
> Add the device parameter and the according documentation.
> 
> Regards,
> 
> --
> Nélio Laranjeiro
> 6WIND