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 BBE6A1B026 for ; Mon, 16 Apr 2018 11:28:39 +0200 (CEST) Received: by mail-wr0-f175.google.com with SMTP id w3so7316316wrg.2 for ; Mon, 16 Apr 2018 02:28:39 -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; bh=DFt+lFyfoG1bB66jQwLBcdhKioOroob5zZdyjOAVv/8=; b=d65TdekAtMJsQevWrmHyI3T3P65FnyLRNG4TY18LTlzYl98xVbLd4agPoC/zwbKANA FgnAVrzy3FOA6o/dbLr530psweT9YvdmRsubITcYge+gG/oVX/hm9buVUTddvPpQtQ7r 5vihTJ6Gy0yjhMx1nRoc2WJP6xuP7V3vW9jyu6pA6UOQWVYhbmH9aTejlpJgG1ZL28pU 78gpjBjQ9gdaq8YqmXouwYx44cKTpWZexFt85plNgl7w+m7HdFbm1XD95eqwYFgUUT7J HC0wYUyOQMWTsAqgYPLqUfpdCsv8NsnGptvPU+BlRP3wMgCUehBui6HkQoku+FgiVJOq MOOg== 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; bh=DFt+lFyfoG1bB66jQwLBcdhKioOroob5zZdyjOAVv/8=; b=h604SrFvyhCPJ2RvWHKliWc0uYsgfSziY4knoTGg3dOHfBrQgN2POy0Ad7O1lHsXP6 /j9d4v+aQcWlvixm1DmLglvAkV52IlJsr0jaUvslq0A8LJdoS+mfHZ8UZWImJkJucX4D QLL3/CwAXcR6+zVcdTkCLB8NhWJFmVlV7+UebfrWI6ZAjhTB/a+VOXaa9H2vq2xlNeFd JyaCTA0gE9o0dnO7E0tl0aiMXqRfLh6s1oX5/kk1xDxC1CWSnyaBh23LLowTKYY5vlI2 wlEteekpDln13FumIMu4RIm3ICMBs7OjJ8mWJTHutUhHkgf5Krmt96FRRJj69CkP8khf t0Cg== X-Gm-Message-State: ALQs6tDXYAWJPhEY6g1o4ZP1efogdmLNbEj23DsbDIo+FdBhs6cXsre5 vXyqtOb34TeSw/AIUscswk+aQQ== X-Google-Smtp-Source: AIpwx48OFRjZH7k1OwtQ3F72it0nNB5OytGYqFivWI3GmDarPrc+TBxIq/gj0az8j1/Vg9SvWzZxzg== X-Received: by 10.28.129.86 with SMTP id c83mr9797800wmd.37.1523870919536; Mon, 16 Apr 2018 02:28:39 -0700 (PDT) Received: from 6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id c27sm18803486wrg.75.2018.04.16.02.28.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 02:28:38 -0700 (PDT) Date: Mon, 16 Apr 2018 11:28:25 +0200 From: Adrien Mazarguil To: "Xueming(Steven) Li" Cc: =?utf-8?B?TsOpbGlv?= Laranjeiro , Shahaf Shuler , "dev@dpdk.org" , Olivier Matz Message-ID: <20180416092825.GW4957@6wind.com> References: <20180410133415.189905-1-xuemingl%40mellanox.com> <20180413112023.106420-5-xuemingl@mellanox.com> <20180413130237.kb4dkx7o6lamrjoq@laranjeiro-vm.dev.6wind.com> <20180416072857.gyfcvfqoxu3gfepf@laranjeiro-vm.dev.6wind.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 09:28:39 -0000 On Mon, Apr 16, 2018 at 08:05:13AM +0000, Xueming(Steven) Li wrote: > > > > -----Original Message----- > > From: Nélio Laranjeiro > > Sent: Monday, April 16, 2018 3:29 PM > > To: Xueming(Steven) Li > > Cc: Shahaf Shuler ; dev@dpdk.org; Olivier Matz > > ; Adrien Mazarguil > > Subject: Re: [PATCH v3 04/14] net/mlx5: support Rx tunnel type > > identification > > > > 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. > > From my understanding, if outer checksum invalid, the packet can't be received > as a tunneled packet, but a normal packet, thus checksum flags always result > of inner for a valid tunneled packet. Yes, since checksum validation information covers all layers at once (outermost to the innermost recognized), the presence of an "unknown tunnel" bit implicitly means outer headers are OK. Now regarding the addition of RTE_PTYPE_TUNNEL_UNKNOWN, the main issue I see is that it's implicit, as in getting 0 after and'ing packet types with RTE_PTYPE_TUNNEL_MASK means either not present or unknown type. How about not setting any tunnel bit and let applications rely on the presence of RTE_PTYPE_INNER_* to determine that there is a tunnel of unknown type? The rationale being that a tunneled packet without an inner payload is kind of pointless anyway. > > > Setting flow mark for different flow type could save time of parsing > > tunnel. > > > > Thanks, > > > > -- > > Nélio Laranjeiro > > 6WIND -- Adrien Mazarguil 6WIND