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

Nélio Laranjeiro nelio.laranjeiro at 6wind.com
Thu Apr 19 15:40:54 CEST 2018


On Thu, Apr 19, 2018 at 12:49:41PM +0000, Xueming(Steven) Li wrote:
> 
> 
> > -----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.

DPDK application are generic, they can still create specific rules for
some devices, but has it don't have any knowledge on the underlying NIC
it must query them through the flow API and devices not supporting the
flow must answer with an error.

"Users should never" in reality the flow API is present for the exact
opposite.

Coming back to this specific patch, you are only giving more arguments
to refuse it and this, for the "user".

I cannot accept this patch as in some situation the user request cannot
be offloaded by the hardware.

There are only two possibilities for me to accept such feature in the
PMD:

1. the PMD can query the firmware and know if such feature is enabled
   (as it does for the (E)MPS and others) and thus refuse the flow if
   not.
2. a device parameter to enable such feature from the PMD perspective
   (does not mean it will be available from the hardware one).

I would prefer #1, but has you have mentioned there is no possibility
from Verbs team to provide such solution so fast.

Remains the #2 solution.  Add it and I can accept the patch.

Regards,

-- 
Nélio Laranjeiro
6WIND


More information about the dev mailing list