From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 221247F25 for ; Thu, 6 Nov 2014 15:17:54 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 06 Nov 2014 06:21:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,326,1413270000"; d="scan'208";a="618226151" Received: from pgsmsx101.gar.corp.intel.com ([10.221.44.78]) by fmsmga001.fm.intel.com with ESMTP; 06 Nov 2014 06:27:18 -0800 Received: from pgsmsx107.gar.corp.intel.com (10.221.44.105) by PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 6 Nov 2014 22:27:17 +0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 6 Nov 2014 22:27:16 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.202]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.13]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 22:27:15 +0800 From: "Liu, Jijiang" To: Olivier MATZ Thread-Topic: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload Thread-Index: AQHP8Yux0VUY397yik2xjVM3DjesSpxPpsiAgAGaY5CAABv8AIACIm/A//+c1oCAAJI8MA== Date: Thu, 6 Nov 2014 14:27:16 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D85962@SHSMSX101.ccr.corp.intel.com> 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> <545B72E5.9090002@6wind.com> In-Reply-To: <545B72E5.9090002@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 14:17:56 -0000 Hi Olivier, > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Thursday, November 6, 2014 9:09 PM > To: Liu, Jijiang > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checks= um > offload >=20 > Hello Jijiang, >=20 > 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 packe= t > >> 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 w= ith 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. >=20 > Where is it written that when the PKT_RX_TUNNEL_IPV4_HDR flag is set, the > packet_type is also set? >=20 > To which header packet_type refers to? Inner or Outer? Depends? >=20 > What are the possible values for packet_type? >=20 > 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) >=20 > 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 conc= erns > the first one, else it would break many applications relying on the these= flags. >=20 > As you can see, today, an application cannot use PKT_RX_TUNNEL_IPV4_HDR o= r > m->packet_type because it is not documented. >=20 >=20 > > In terms of VXLAN packet format (MAC,IPv4,UDP,VXLAN,MAC,IP,TCP,PAY4), i= f > 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. >=20 > 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 c= heck in > software. And there are several reasons why the flag may not be present: > - the packet is not a VxLAN packet As long as it is tunneling packet with IPv4/6 header, the flag should be se= t by driver. > - 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?)=20 > - the hw or driver does not support it (all drivers except i40e) E1000/ixgbe don't support VXLAN packet and another tunneling packet, so dri= ver don't need to set this flag. As to other NICs that support tunneling packet , I don't why HW or driver c= an't recognize it. > So the application has to provide the software equivalent code to process= PAY4. >=20 > The "csum" testpmd forwarding engine is now a bad example because it is n= ot > 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, proc= ess the > checksum in the NIC, else in SW". > Now, it's "huh... it depends on the flag." Currently, If the packet is non-tunneling packet, I believe the "csum" tes= tpmd forwarding engine also works well as before. we changed the engine as follows, which is compatible with previous impleme= ntation. - if (pkt_ol_flags & PKT_RX_IPV4_HDR) { + if (pkt_ol_flags & (PKT_RX_IPV4_HDR | PKT_RX_TUNNEL_IPV4_HDR)) { ... - else if (pkt_ol_flags & PKT_RX_IPV6_HDR) { + } else if (pkt_ol_flags & (PKT_RX_IPV6_HDR | PKT_RX_TUNNEL_IPV6_HDR)) { > I will submit a rework of the csum fowarding engine to clarify its behavi= or. OK. good. > Regards, > Olivier