From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 53EF8A04BA; Wed, 7 Oct 2020 18:25:22 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A99171B5E1; Wed, 7 Oct 2020 18:25:20 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 21C3A1B3E7 for ; Wed, 7 Oct 2020 18:25:17 +0200 (CEST) IronPort-SDR: 0RN5Llicz0CY9TAJgI/+GUYA25I1tdALswkBF3KoUMg/xYan/tkF9wUNAjavtJpnesKIEsMdP8 O5YJlw0xayxg== X-IronPort-AV: E=McAfee;i="6000,8403,9767"; a="162391063" X-IronPort-AV: E=Sophos;i="5.77,347,1596524400"; d="scan'208";a="162391063" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2020 09:25:17 -0700 IronPort-SDR: e8nZLeHlt6pnddaK6NTfx7Vw0nR+1l05yRBjUDh25TeUk1fgZaGIUt4k455nsk0kGfMMYTGAsq +ToscTToHJwg== X-IronPort-AV: E=Sophos;i="5.77,347,1596524400"; d="scan'208";a="316283039" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.226.27]) ([10.213.226.27]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Oct 2020 09:25:14 -0700 To: Ophir Munk , "dev@dpdk.org" , Wenzhuo Lu , Beilei Xing , Bernard Iremonger , Olivier Matz Cc: Ophir Munk References: <20200915131717.18252-2-ophirmu@nvidia.com> <20200918141735.18488-1-ophirmu@nvidia.com> <20200918141735.18488-2-ophirmu@nvidia.com> From: Ferruh Yigit Message-ID: <24b36e2f-e601-d8b6-9a9e-b626d1ee9fd4@intel.com> Date: Wed, 7 Oct 2020 17:25:11 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v5 1/3] app/testpmd: add GENEVE parsing 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/7/2020 3:52 PM, Ophir Munk wrote: > Hi Ferruh, > Please find comments inline. > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Tuesday, October 6, 2020 5:31 PM >> To: Ophir Munk ; dev@dpdk.org; Wenzhuo Lu > <...> >>> >>> uint16_t vxlan_gpe_udp_port = 4790; >>> +uint16_t geneve_udp_port = RTE_GENEVE_DEFAULT_PORT; >>> >> >> There is a testpmd command to configure the NIC for GENEVE port, "port >> config (port_id) udp_tunnel_port add|rm vxlan|geneve|vxlan-gpe >> (udp_port)" >> >> You are adding support to testpmd to parse the GENEVE packets, but I think >> these two commads should be consistent. >> >> What do you think "port config N add geneve X" update the >> 'geneve_udp_port=X"? >> >> <...> >> > > It is not as simple as suggested. > The command "port config N add geneve X" can be repeated several times - adding another geneve port to the NIC Hardware/Firmware to recognize. As a result the NIC is configured with multiple geneve ports. On the other hand geneve_udp_port is a single variable - so whenever a new "port config" command is executed - we will override the last geneve port and forget all the precedent ones. > The port config command also has a "rm" option in addition to "add". So if we removed the last port - what will we assigned to geneve_udp_port? We need to have a small data base for managing geneve ports. > testpmd also has an option " --geneve-port=N". It should be synched with the "port config" command. > > Another issue to consider is if there is a need for the suggested feature. I think the "port config" is mainly targeted for offloading. So the NIC will probably encap/decap a packet with geneve - leaving testpmd paring unneeded. > > My point is that your suggestion requires an RFC before implementation. > I am not sure about adding database for geneve ports, I think no need to make it more complex. Only when user set via "--geneve-port=N", it is the port for testpmd to parse (same for 'geneve_udp_port' global variable), but when user give command "port config N add geneve X" it is to configure the NIC to offload the parsing. This is too confusing, user can't know (or remember) this without checking the source code. Can we rename the command and variable to highlight that it is for testpmd to parse, I think that will be enough, instead of trying to merge them, which is hard as you described above. What do you think for "--testpmd-geneve-port=N" parameter and 'testpmd_geneve_udp_port' variable name? We can also update the documentation to say this is only the port testpmd uses for parsing, HW may be configured to use another port. >> >>> @@ -865,9 +925,17 @@ pkt_burst_checksum_forward(struct fwd_stream >> *fs) >>> } >>> parse_vxlan(udp_hdr, &info, >>> m->packet_type); >>> - if (info.is_tunnel) >>> + if (info.is_tunnel) { >>> tx_ol_flags |= >>> PKT_TX_TUNNEL_VXLAN; >>> + goto tunnel_update; >>> + } >>> + parse_geneve(udp_hdr, &info); >>> + if (info.is_tunnel) { >>> + tx_ol_flags |= >>> + PKT_TX_TUNNEL_GENEVE; >>> + goto tunnel_update; >>> + } >> >> Can you please update the "csum parse-tunnel" documentation to mention >> "geneve" >> protocol? > > Done in v6. I added other missing tunnel protocols (in alphabetical order) such as "gtp". Since it is more than geneve I added it to the 3rd (cleanup) commit. > Would you mind adding the 'geneve' with the patch adding 'geneve' support (1/3), and add the other missing ones in the patch 3/3 ?