From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f175.google.com (mail-wr0-f175.google.com [209.85.128.175]) by dpdk.org (Postfix) with ESMTP id 784656C9B for ; Thu, 19 Apr 2018 15:40:18 +0200 (CEST) Received: by mail-wr0-f175.google.com with SMTP id d1-v6so14164760wrj.13 for ; Thu, 19 Apr 2018 06:40:18 -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=cDbI64L2LdccZkqVK7wq15X0/11n1fUw9UzFGwxemUo=; b=nDaJYOZM9HHnqMWX2r6VFmr2RXFjKxF/qklnt1RR8rMTFoaU2KlsgXwAX0K7Ty0v5Q iv539mUtQzIuFTMRZsPSgoRtcMEqyfGsPUKHQt/KWF/OYItXoc1rQSczxe7edtab5uQu nO2pk3kcAYbK7cH3wkWrpPHtYR1LEcNrZzYx+WGKpDDbEpFv/B/dkPINduuvKz961pPi 1SWXdhA0wWYaKqFZJuUZ+8Iz01mtBnV60hNgeLpyePuOkYKO7A/VLA73GFVtPcJIPoCH 8crZFpRfbppna7yFkyxH3Y8kpCg1n+yJYBW9afZgcRIaXBSsuhjK9ra/Tt3765As7TYL t45Q== 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=cDbI64L2LdccZkqVK7wq15X0/11n1fUw9UzFGwxemUo=; b=khzrFwCXLAqW3KZS4vt2EuvB/m2/SEsc3ChoCVgMT3A+lz4f2e9r13sJOQoAYgPoZX CEfCeYjxdkuPmoacLofkT9BFiXcfwZAe7zZ4YE87GKK3V4OLM9ECf52DioF7cqHnVrP3 jRbbSv/YoxcBbNjT6jDrN7agqKb4g5Gdr4eOO1pNnzuOziN4MFdNwThd1ZfFk2N+Hnk5 1sPutS7w/0UDPDHzdSvbCevauYYr4bVvG7ZxqYRr5uiUYNM2rrKYeVWu/y43nOWxYhMW GljfOz6d1PUQqfXpUaUkBOhw//XDPPekFoTBBIAY0DEkzJMWX1nsFVEGMBkI1326i7mf izrg== X-Gm-Message-State: ALQs6tA/LqJpGyARkuiX05MBsVza7eSAtraz8Kju0hLI3RfRDFZFag9Z 3rrpBLSWOmSGqlnMXUsr6VhTOFtXcw== X-Google-Smtp-Source: AIpwx4+Cj93kH8xr9tc8x2/0j6IRuZlNmYmt18CJTc1TRAp2w1a4hn8+vdELnVzMgv6UTkAvSq6mCw== X-Received: by 10.28.127.146 with SMTP id a140mr4722945wmd.48.1524145218126; Thu, 19 Apr 2018 06:40:18 -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 y9-v6sm4778243wrg.46.2018.04.19.06.40.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 19 Apr 2018 06:40:17 -0700 (PDT) Date: Thu, 19 Apr 2018 15:40:54 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: "Xueming(Steven) Li" Cc: Shahaf Shuler , "dev@dpdk.org" Message-ID: <20180419134054.wbijysht32l5runc@laranjeiro-vm.dev.6wind.com> References: <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> <20180419121841.gj2wjxcwfrtkcbl7@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 13:40:18 -0000 On Thu, Apr 19, 2018 at 12:49:41PM +0000, Xueming(Steven) Li wrote: > > > > -----Original Message----- > > From: Nélio Laranjeiro > > Sent: Thursday, April 19, 2018 8:19 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 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? > > 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