From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by dpdk.org (Postfix) with ESMTP id B3FF78DA7 for ; Mon, 16 Apr 2018 15:47:51 +0200 (CEST) Received: by mail-wr0-f174.google.com with SMTP id u11so26213503wri.12 for ; Mon, 16 Apr 2018 06:47:51 -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=SjqC8aVYNcd+hIfH5eaVkn9gKMUZtZL2PDJP5N/pn7Q=; b=pRuNkdbdUMuXiBWFsW1D8MTi153r8a6fN1u5vq71PwFoLFCPodPPfpPvVJM9OCot1V YfD/mMMfYaK1PywVZylt/creEilQr3z+ZxMPFCjZrJdYTsIG2gugDUk5LmGzJNAaEguz rQi/U0BZxGp4Lt0XX60eBjnoRFn7rbqMmnnoJ3fyo7CjwW1MLJ9JEeTj4ZSByh41Dysc XwbsU4xdrksq0DL2q9APUleU4ghgrn4H/b8hdBFYTBd9rkCfS/0UAp5hP806uZdMlKuV H+nCkc5hNhPTsFH+M4/qEjzDZupeARWP81qcv9slg5nAe/GCGRdw+QUOt4amY4NlLz+7 2CSA== 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=SjqC8aVYNcd+hIfH5eaVkn9gKMUZtZL2PDJP5N/pn7Q=; b=rFgW0t3lTa7fRI/4D3ijOSv2zgujlpCo4hP47NbB0Pyr1OLcKw3sjtpVDbbVByFzIb QjtODkopX7HZV8CTxTFM0dJMSbuZm3pvQLkkw3Et2s+7NZWfbeoYEhnG6zqpAhFEH1+a U7vRBMHxJVQqIpx7cJvQd8NT7tWUXb0UxeYP0450XSfMO5dCZ4srrMVAvAt0ZwAUdHBK tPF14zUbrqDvzmxvDoU3udZ2gLxn0KMcHHFzIIW6FDgP2AQ8ZAPPTJnuV+qGsFewUxeG nll9fD0Pqa7YzHmDRla8hL8mF3E7YWv2c43n6PEbB6CdjPAFPgC3C3ssbY17eqk4fY+e x2iw== X-Gm-Message-State: ALQs6tCdVWnhhmHXnVPOdvs4zdoNo49MVfGBMiHKvSGWFGJ1gpSHJ5RR RAaaVSXJe0J5z3dERmfh5qxM8A== X-Google-Smtp-Source: AIpwx4+bjIpGu3lvdv62PjRwG2We147iieMvVn2y1S+tZR2qCcDwrjcwHS7SuWhxpa57x9MTVt5EfA== X-Received: by 10.28.148.82 with SMTP id w79mr6436602wmd.64.1523886471486; Mon, 16 Apr 2018 06:47:51 -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 p4sm13510160wrh.3.2018.04.16.06.47.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Apr 2018 06:47:50 -0700 (PDT) Date: Mon, 16 Apr 2018 15:47:37 +0200 From: Adrien Mazarguil To: "Xueming(Steven) Li" Cc: =?utf-8?B?TsOpbGlv?= Laranjeiro , Shahaf Shuler , "dev@dpdk.org" , Olivier Matz Message-ID: <20180416134737.GZ4957@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> <20180416092825.GW4957@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 13:47:51 -0000 On Mon, Apr 16, 2018 at 01:32:49PM +0000, Xueming(Steven) Li wrote: > > > -----Original Message----- > > From: Adrien Mazarguil > > Sent: Monday, April 16, 2018 5:28 PM > > To: Xueming(Steven) Li > > Cc: Nélio Laranjeiro ; Shahaf Shuler ; dev@dpdk.org; > > Olivier Matz > > Subject: Re: [PATCH v3 04/14] net/mlx5: support Rx tunnel type identification > > > > 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 define RTE_PTYPE_TUNNEL_UNKNOWN same ask RTE_PTYPE_TUNNEL_MASK? And'ding packet types always > return a non-zero value. I mean the value already exists, it's implicitly 0. Adding one with the same value as RTE_PTYPE_TUNNEL_MASK could be seen as a waste of a value otherwise usable for an actual tunnel type (there are only 4 bits). > > 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. > > An unknown type doesn't break anything, neither enum bits, straightforward IMHO. Keep in mind that mbuf packet types report what is identified. All the definitions in this file name a specific protocol. For instance there is no such definition as "L3 present" or "L4 present". "Tunnel present" doesn't make a lot of sense on its own either. Don't you agree that reporting at least one inner ptype while leaving tunnel ptype to 0 automatically addresses this issue? > > > > > Setting flow mark for different flow type could save time of > > > > > parsing > > > > tunnel. > > > > > > > > Thanks, > > > > > > > > -- > > > > Nélio Laranjeiro > > > > 6WIND > > > > -- > > Adrien Mazarguil > > 6WIND -- Adrien Mazarguil 6WIND