From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f171.google.com (mail-wr0-f171.google.com [209.85.128.171]) by dpdk.org (Postfix) with ESMTP id AE4E91B1D6 for ; Mon, 16 Apr 2018 09:28:27 +0200 (CEST) Received: by mail-wr0-f171.google.com with SMTP id q6so10846874wrd.6 for ; Mon, 16 Apr 2018 00:28:27 -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=j8kARgeV7yGgfjnvnw1qsFKm6TpT1QyefzzYtQmt2TI=; b=iH6VVf8K1YZaktaA+faavHLj9j8VkXyzeDQ/cyi8Skl0GnCru5gGnVWrXLM/SlKQiM J0EWyCT1j/ln6WxXZQxe6D4Coe+4v0A+k0N9kszKRgNlAVzjiyn6eZqKzlOt8S+Kt6i4 110wZwzBaYzP5QOZ9a/8ZnP846ngCrW7eTT3ejFM7/F+YobKHuUl4chIIOtfr3D4c16w 1FZp7XNhcrKwFysTWcHctbRVHE5EPlqqhKkAUyNhiNegdMQaweSwPWYbbyNVh82OYCFW c83Kc/QSRttTNzmqkJh/3QhTl8Q3t0xLUBblxfPKpkVuE/LmJu6CIa1Rbemwtkdl50L9 lzBg== 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=j8kARgeV7yGgfjnvnw1qsFKm6TpT1QyefzzYtQmt2TI=; b=gj9lvRhJW/YkcjEdeMPfGBsDCVZ/u2WqNX0FTcm5YxhgfsMlrEQReb1uy74g2tpnuX jXCabUNO83dYXDGEpYqLZBqm1l+DiKnPW3Hp4ZJdLqYZ8v84aBTLalsfkFqXc6PsGCdF lxdCbxmDg2BB68KGDs70BGrDHWzkic66aYVkoLEnKIJDY38xMwdK1mKougRZKyE/73Qj d4666uSGo5987I0gki5ZH1T9J4fsAv/u9MZ+3d2TV1lPxuXSC6AU+ay1ffXXMjh4SRB5 m65c27usfBEle4+X78AHw3Rt6jG+Mb/V9OOSCPicCckaI1y7tDtu+wLx6/3K/IFC78gd 3Uwg== X-Gm-Message-State: ALQs6tA1WABZOpbAtk1Y9OrcVOa3I1JbkvHPqubYEWaFmzdli1sQE4oY scRveBE5+jUdG79MIj4/1sOs X-Google-Smtp-Source: AIpwx4/2IYOadvaOedBaXQg60qPVFm7QWPh+CxS8GRMRhPTgf1g7+xwlTZyJPUSMdOiGw1QHKN3cOg== X-Received: by 10.223.165.146 with SMTP id g18mr1450604wrc.171.1523863707465; Mon, 16 Apr 2018 00:28:27 -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 19sm7265146wmv.18.2018.04.16.00.28.26 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 16 Apr 2018 00:28:27 -0700 (PDT) Date: Mon, 16 Apr 2018 09:28:57 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: "Xueming(Steven) Li" Cc: Shahaf Shuler , "dev@dpdk.org" , Olivier Matz , Adrien Mazarguil Message-ID: <20180416072857.gyfcvfqoxu3gfepf@laranjeiro-vm.dev.6wind.com> References: <20180410133415.189905-1-xuemingl%40mellanox.com> <20180413112023.106420-5-xuemingl@mellanox.com> <20180413130237.kb4dkx7o6lamrjoq@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 v3 04/14] net/mlx5: support Rx tunnel type identification 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: Mon, 16 Apr 2018 07:28:27 -0000 On Sat, Apr 14, 2018 at 12:57:58PM +0000, Xueming(Steven) Li wrote: > +Adrien > > > -----Original Message----- > > From: Nélio Laranjeiro > > Sent: Friday, April 13, 2018 9:03 PM > > To: Xueming(Steven) Li > > Cc: Shahaf Shuler ; dev@dpdk.org; Olivier Matz > > > > Subject: Re: [PATCH v3 04/14] net/mlx5: support Rx tunnel type > > identification > > > > +Olivier, > > > > On Fri, Apr 13, 2018 at 07:20:13PM +0800, Xueming Li wrote: > > > This patch introduced tunnel type identification based on flow rules. > > > If flows of multiple tunnel types built on same queue, > > > RTE_PTYPE_TUNNEL_MASK will be returned, user application could use > > > bits in flow mark as tunnel type identifier. > > > > For an application it will mean the packet embed all tunnel types defined > > in DPDK, to make such thing you need a RTE_PTYPE_TUNNEL_UNKNOWN which does > > not exists currently. > > There was a RTE_PTYPE_TUNNEL_UNKNOWN definition, but removed due to discussion. > So I think it good to add it in the patchset of reviewed by Adrien. Agreed, > > > Even with it, the application still needs to parse the packet to discover > > which tunnel the packet embed, is there any benefit having such bit? Not > > so sure. > > With a tunnel flag, checksum status represent inner checksum. Not sure this is generic enough, MLX5 behaves as this, but how behaves other NICs? It should have specific bits for inner checksum if all NIC don't have the same behavior. > Setting flow mark for different flow type could save time of parsing tunnel. Thanks, -- Nélio Laranjeiro 6WIND