From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 0F69D7E75 for ; Thu, 6 Nov 2014 13:59:38 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XmMr3-0007Sk-Oh; Thu, 06 Nov 2014 14:12:05 +0100 Message-ID: <545B72E5.9090002@6wind.com> Date: Thu, 06 Nov 2014 14:08:53 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Liu, Jijiang" References: <1414376006-31402-1-git-send-email-jijiang.liu@intel.com> <1414376006-31402-11-git-send-email-jijiang.liu@intel.com> <54588BF7.309@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D8510E@SHSMSX101.ccr.corp.intel.com> <5459FBB2.1040408@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D858A1@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D858A1@SHSMSX101.ccr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 12:59:38 -0000 Hello Jijiang, On 11/06/2014 12:24 PM, Liu, Jijiang wrote: >> Is it possible to have a more formal definition? For instance, is the following >> definition below correct? >> >> "the PKT_RX_TUNNEL_IPV4_HDR flag CAN be set by a driver if the packet >> contains a tunneling protocol inside an IPv4 header". > > Yes, correct. > >> If the definition above is correct, I don't see how this flag can help an application >> to run faster. There is already a flag telling if there is a valid IPv4 header >> (PKT_RX_IPV4_HDR). As the PKT_RX_TUNNEL_IPV4_HDR flag does not tell what >> is ip->proto, the work done by an application to dissect a packet would be exactly >> the same with or without this flag. > > If the PKT_RX_TUNNEL_IPV4_HDR flag is set, which means driver tell application that incoming packet is encapsulated packet, and application will process / analyse the packet according to tunneling format indicated by packet_type. Where is it written that when the PKT_RX_TUNNEL_IPV4_HDR flag is set, the packet_type is also set? To which header packet_type refers to? Inner or Outer? Depends? What are the possible values for packet_type? Is the PKT_RX_TUNNEL_IPV4_HDR flag set in mbuf related to the commands rx_vxlan_port add|del? If yes, it should be written in the API! (assuming this is the right API design) When the PKT_RX_TUNNEL_IPV4_HDR flag is set, does PKT_RX_IPV4_HDR or PKT_RX_VLAN_PKT concerns the inner or outer headers? I hope it still concerns the first one, else it would break many applications relying on the these flags. As you can see, today, an application cannot use PKT_RX_TUNNEL_IPV4_HDR or m->packet_type because it is not documented. > In terms of VXLAN packet format (MAC,IPv4,UDP,VXLAN,MAC,IP,TCP,PAY4), if only the PKT_RX_IPV4_HDR flag is set, and application regard its payload as "from VXLAN to PAY4", but actually, the real payload is PAY4. > >> Please, can you give an example showing in which conditions this flag can help an >> application? > > http://dpdk.org/ml/archives/dev/2014-October/007151.html > http://dpdk.org/ml/archives/dev/2014-October/007156.html > > We used the PKT_RX_TUNNEL_IPV4_HDR in the two patches to help application identify incoming packet is tunneling packet. As you agreed on "the PKT_RX_TUNNEL_IPV4_HDR flag CAN be set by a driver", it means that if the flag is not present, the application should do the check in software. And there are several reasons why the flag may not be present: - the packet is not a VxLAN packet - the hw or driver was not able to recognize it (I don't know, maybe if there are IP options the hw will not recognize it?) - the hw or driver does not support it (all drivers except i40e) So the application has to provide the software equivalent code to process PAY4. The "csum" testpmd forwarding engine is now a bad example because it is not able to do the same processing in software or hardware. It now only works with an i40e driver, which was not the case before. Also, the semantic of the command line arguments changed. Before, the meaning was "if the flag is set, process the checksum in the NIC, else in SW". Now, it's "huh... it depends on the flag." I will submit a rework of the csum fowarding engine to clarify its behavior. Regards, Olivier