> -----Original Message-----
> From: Nélio Laranjeiro <nelio.laranje...@6wind.com>
> Sent: Friday, April 13, 2018 8:14 PM
> To: Xueming(Steven) Li <xuemi...@mellanox.com>
> Cc: Shahaf Shuler <shah...@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 <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 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
