On Thu, Apr 19, 2018 at 06:20:50AM +0000, Xueming(Steven) Li wrote:
>
>
> > -----Original Message-----
> > From: Nélio Laranjeiro <nelio.laranje...@6wind.com>
> > Sent: Wednesday, April 18, 2018 11:09 PM
> > To: Xueming(Steven) Li <xuemi...@mellanox.com>
> > Cc: Shahaf Shuler <shah...@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.laranje...@6wind.com>
> > > > Sent: Wednesday, April 18, 2018 2:49 PM
> > > > To: Xueming(Steven) Li <xuemi...@mellanox.com>
> > > > Cc: Shahaf Shuler <shah...@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 <xuemi...@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.
> 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.
Regards,
--
Nélio Laranjeiro
6WIND
