From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by dpdk.org (Postfix) with ESMTP id 05A688D97 for ; Tue, 17 Apr 2018 09:19:55 +0200 (CEST) Received: by mail-wr0-f170.google.com with SMTP id v24so15374725wra.8 for ; Tue, 17 Apr 2018 00:19:55 -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=FOagxlDH3GFtltEAx40bnhlJUjYLblE9OrG5WVcVeqA=; b=WQ8b3uHVPYRW1/TbQDQv/1f/abU71ukEmicAuJX0NvmR+uj+Qtwri6mK2kkq0X6mfX UWUFtpSJeRaqq9iMr6yz3SjN6g4oc1rDnvwOPG/2G1XOi25zUvnrRExMDImNOVflqnc3 J1AcjJXYOIA55IxdzmBYPEGqJG0TQNLGpCQUzyLOSGpGlyjNafBuMeyShLvi/JJPX7Bs B6mhFaiR8b5So0dQdLHBq5Y35GuVvnHIsUj1P9JDT3P7FUVzk8FjnOOvo1vzJBd3uNxV nT+ICW4JVBvszV6EDBh5n5F+tqK6+ZxedtMtKVujTtpLV4EB1UwU3hyoYmg8SwKWkGvp M4wA== 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=FOagxlDH3GFtltEAx40bnhlJUjYLblE9OrG5WVcVeqA=; b=PW/x7tCRXAqM1L5WoCnHCo0/tbB+qFoduj3RzAhjrEjDWI0DPnH2WuYTKM9QiR1hKp GyBoeHUOipRV8JowMdoEZvDys6h2XmjyXk1NRZs9nUSTuvTGrr4/2EVkOvRPLE9WQD5P 5XHlG9BbtWgHWN77Ftw0xfMVboUej9eeCFVMBMNKoV1r/Q0m8NnlMfc8GIcQ5eATshum xjIHoNdah7aX5BPtIG9LvFEc91BJkeyLvdKG58SyBv7oBVwvBIEF7/M9sbArT638Z2SV 7QyVzv7rl/UDXHXlApoiLlNnZJHbAjIJDvD++ngqKETiTLArraE+FFUtnugWJNk99GQU 3GIw== X-Gm-Message-State: ALQs6tC/zk0fNU21T1A6DRFVWDwap7CajgpHvMpRTx0d923+fuX3Cdt7 G1RCX/EMYY603TASloxzMuMU X-Google-Smtp-Source: AIpwx4/7Tlxhn2QnUtyCLcrIMAE9rX15rqOnYLbfsr/tbC7rzx7GTL2KXfb82iFMEm03HH20kBpYuw== X-Received: by 10.28.110.27 with SMTP id j27mr65973wmc.144.1523949595698; Tue, 17 Apr 2018 00:19:55 -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 103sm6632418wrc.57.2018.04.17.00.19.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 17 Apr 2018 00:19:55 -0700 (PDT) Date: Tue, 17 Apr 2018 09:20:27 +0200 From: =?iso-8859-1?Q?N=E9lio?= Laranjeiro To: "Xueming(Steven) Li" Cc: Adrien Mazarguil , Shahaf Shuler , "dev@dpdk.org" , Olivier Matz Message-ID: <20180417072027.fwg2cgpehfnq56tv@laranjeiro-vm.dev.6wind.com> References: <20180413130237.kb4dkx7o6lamrjoq@laranjeiro-vm.dev.6wind.com> <20180416072857.gyfcvfqoxu3gfepf@laranjeiro-vm.dev.6wind.com> <20180416092825.GW4957@6wind.com> <20180416134737.GZ4957@6wind.com> <20180416160243.GC4957@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: Tue, 17 Apr 2018 07:19:56 -0000 On Tue, Apr 17, 2018 at 04:53:15AM +0000, Xueming(Steven) Li wrote: > > > > -----Original Message----- > > From: Adrien Mazarguil > > Sent: Tuesday, April 17, 2018 12:03 AM > > 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 03:27:37PM +0000, Xueming(Steven) Li wrote: > > > > > > > > > > -----Original Message----- > > > > From: Adrien Mazarguil > > > > Sent: Monday, April 16, 2018 9:48 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 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? > > > > > > Currently, no inner L2 ptype, so for packet with only L2, it will be recognized as non-tunnel packet. > > > > Applications can live with it. Don't bother with a ptype API change at this point, it raises more > > issues than it solves. > > > > Given the size of the series, let's deal with that later through a separate task and according to user > > feedback. > > Nelio, so I'll leave it as it is, are you okay with it? I agree with Adrien, if you are not able to say which kind of tunnel it is, don't set it in the mbuf. Regards, -- Nélio Laranjeiro 6WIND