From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f182.google.com (mail-wr0-f182.google.com [209.85.128.182]) by dpdk.org (Postfix) with ESMTP id B45198E6E for ; Thu, 19 Apr 2018 14:18:04 +0200 (CEST) Received: by mail-wr0-f182.google.com with SMTP id q3-v6so3426352wrj.6 for ; Thu, 19 Apr 2018 05:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=hcLSbw77GHEP0r84Tgq5XgYz869r56KAtnTQOdDvMJs=; b=qKoIdDjSRn8frWm1vWFgHhhpHe07bnkNvdP1sMAMzqIwshAUFUUjsf8O1LJM2bVRq3 ImeU5RU0+nx7VXOHvjsLw5SHjrIkTNMGNPa9XKGtf/DmQs3axxDCtAv4swKWjDYrdL5f T2cd6dojiaVTejF8nfW6eBMnCTvLCxdZoHuEjNLQwdzvdPFQhYt+YH2VgAj29s8gzZr1 0/S302dwo9pBG4zCae2z95uGocFQG8WhGXQvkoqHV5R5MHhISZtruZsrOakfvPzVfqd4 0xt79wa8piaElMwGTMNGywygLIDiz2yBNr/2xc5bITvyNUB61ophs5/MCbCReL1qpfVR 6ghQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=hcLSbw77GHEP0r84Tgq5XgYz869r56KAtnTQOdDvMJs=; b=m0vGA53vcG5Ypn8LJHk0iTMlzobntsuPlLrm/Mzk34HfagOGy98o7dG5yBzMojJUbn vsRSX8D+DhS4udVCn/pFNH+7m6Llc2W7qKU8RdtFHpI+fbag2+xMcMGgVai2x/yBfdDQ p97cM2tDwX6oii6SrDTmBwrpQ6QS0gS43RIuakMVzAqqnZ8S/Ogtn7C9DolCH5NmR6ID uU+WYVdjBsZSHUTI2GdRPPxR3UHtLswUNJVbMAQptfpCpBnYEbIHu/jVqtSpAY8i99/c YW1CcjHhUxLtFDrmBeevWe2NXvR56jUW8Y/9RGWTfkihXDymc+H3KoY03GamApyWFDJF LIFA== X-Gm-Message-State: ALQs6tDapMT13/JdehlGozxW/Oq4rtq/LKs9GkdVLKJuaFMdpEE0rFBE YeM0ik4Y/s1uPbzn6qbvF9/10Kl+wQ== X-Google-Smtp-Source: AIpwx4+Aj2hWsd3iv/ist5abUZKn2UJdrOYchhrBli8A8yZC6NTqBfoHg4A4xsElMpkR7tSP7XvAug== X-Received: by 10.28.28.148 with SMTP id c142mr869340wmc.30.1524140284422; Thu, 19 Apr 2018 05:18:04 -0700 (PDT) Received: from laranjeiro-vm.dev.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id n8-v6sm3400824wrh.51.2018.04.19.05.18.03 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 19 Apr 2018 05:18:03 -0700 (PDT) Date: Thu, 19 Apr 2018 14:18:41 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: "Xueming(Steven) Li" Cc: Shahaf Shuler , "dev@dpdk.org" Message-ID: <20180419121841.gj2wjxcwfrtkcbl7@laranjeiro-vm.dev.6wind.com> References: <20180413112023.106420-1-xuemingl@mellanox.com> <20180417151436.161374-4-xuemingl@mellanox.com> <20180418064856.hk5bst2wuzxxwv6r@laranjeiro-vm.dev.6wind.com> <20180418150858.tlfmca2y3fhv2xcp@laranjeiro-vm.dev.6wind.com> <20180419065541.s4iy36c6amaavvm7@laranjeiro-vm.dev.6wind.com> <20180419111526.kh4rdujzomrb4isz@laranjeiro-vm.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v4 03/11] net/mlx5: support L3 VXLAN flow X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 12:18:04 -0000 On Thu, Apr 19, 2018 at 11:53:05AM +0000, Xueming(Steven) Li wrote: > > > > -----Original Message----- > > From: Nélio Laranjeiro > > Sent: Thursday, April 19, 2018 7:15 PM > > To: Xueming(Steven) Li > > Cc: Shahaf Shuler ; dev@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 > > > > Sent: Thursday, April 19, 2018 2:56 PM > > > > To: Xueming(Steven) Li > > > > Cc: Shahaf Shuler ; dev@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 > > > > > > Sent: Wednesday, April 18, 2018 11:09 PM > > > > > > To: Xueming(Steven) Li > > > > > > Cc: Shahaf Shuler ; 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 > > > > > > > > Sent: Wednesday, April 18, 2018 2:49 PM > > > > > > > > To: Xueming(Steven) Li > > > > > > > > Cc: Shahaf Shuler ; 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 -y s IP_OVER_VXLAN_EN=1 > > > > > > > > > sudo mlxconfig -d -y s > > > > > > > > > IP_OVER_VXLAN_PORT= > > > > > > > > > > > > > > > > > > Signed-off-by: Xueming Li > > > > > > > > > --- > > > > > > > > > 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? Any rule *accepted* by the PMD *must* follow the user request, otherwise it is a bug. Add the device parameter and the according documentation. Regards, -- Nélio Laranjeiro 6WIND