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 B42272A61 for ; Mon, 2 Feb 2015 03:45:31 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga103.fm.intel.com with ESMTP; 01 Feb 2015 18:38:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,503,1418112000"; d="scan'208";a="671252663" Received: from pgsmsx105.gar.corp.intel.com ([10.221.44.96]) by fmsmga002.fm.intel.com with ESMTP; 01 Feb 2015 18:45:26 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by PGSMSX105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 2 Feb 2015 10:44:25 +0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.91]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.129]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 10:44:25 +0800 From: "Zhang, Helin" To: Olivier MATZ , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 00/17] unified packet type Thread-Index: AQHQPJEKPA3enZdlxUCzQrgE37GgSZzcqDeA Date: Mon, 2 Feb 2015 02:44:25 +0000 Message-ID: References: <1421637666-16872-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-1-git-send-email-helin.zhang@intel.com> <54CB879D.2010505@6wind.com> In-Reply-To: <54CB879D.2010505@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 Subject: Re: [dpdk-dev] [PATCH 00/17] unified packet type 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: Mon, 02 Feb 2015 02:45:32 -0000 Hi Olivier > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Friday, January 30, 2015 9:31 PM > To: Zhang, Helin; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 00/17] unified packet type >=20 > Hi Helin, >=20 > On 01/29/2015 04:15 AM, Helin Zhang wrote: > > Currently only 6 bits which are stored in ol_flags are used to > > indicate the packet types. This is not enough, as some NIC hardware > > can recognize quite a lot of packet types, e.g i40e hardware can > > recognize more than 150 packet types. Hiding those packet types hides > > hardware offload capabilities which could be quite useful for improving > performance and for end users. > > So an unified packet types are needed to support all possible PMDs. > > Recently a 16 bits packet_type field has been added in mbuf header > > which can be used for this purpose. In addition, all packet types > > stored in ol_flag field should be deleted at all, and 6 bits of ol_flag= s can be > save as the benifit. > > > > Initially, 16 bits of packet_type can be divided into several sub > > fields to indicate different packet type information of a packet. The > > initial design is to divide those bits into 4 fields for L3 types, > > tunnel types, inner L3 types and L4 types. All PMDs should translate > > the offloaded packet types into this 4 fields of information, for user > applications. >=20 > You haven't answered to my question I asked in your RFC patch [1]. > I copied it below: >=20 >=20 > >> On 01/20/2015 03:28 AM, Zhang, Helin wrote: > >>>> Another question I've asked several times[1][2] : what does having > >>>> RTE_PTYPE_TUNNEL_IP mean? What fields are checked by the hardware > >>>> (or the driver) and what fields should be checked by the application= ? > >>>> Are you sure that all the drivers (ixgbe, i40e, vmxnet3, enic) > >>>> check the same fields? (ethertype, ip version, ip len correct, ip > >>>> checksum correct, flags, ...) > >>> RTE_PTYPE_TUNNEL_IP means hardware recognizes the received packet > as > >>> an IP-in-IP packet. > >>> All the fields are filled by PMD which is recognized by hardware. > >>> The application can just use it which can save some cpu cycles to > >>> recognize the packet type by software. > >>> Drivers is responsible for filling with correct values according to > >>> the packet types recognized by its hardware. Different PMDs may fill > >>> with different values based on different capabilities. > >> > >> Sorry, that does not answer to my question. > >> > >> Let's take a simple example. Imagine a hardware-1 that is able to > >> recognize an IP packet by checking the ethertype and that the IP > >> version is set to 4. > >> Another hardware-2 recognize an IP packet by checking the ethertype, > >> the IP version and that the IP length is correct compared to m_len(m). > >> > >> For the same packet, both hardwares will return RTE_PTYPE_L3_IPV4, > >> but they don't do the same checks on the packet. As I want my > >> application behave exactly the same whatever the hardware, I need to > >> know what checks are done in hardware, so I can decide what checks > >> must be done in my application. > >> > >> Example of definition: RTE_PTYPE_L3_IPV4 means that ethertype is > >> 0x0800 and IP.version is 4. > >> > >> It means that I can skip these 2 tests in my application if I have > >> this packet_type, but all other checks must be done in software (ip > >> length, flags, checksum, ...) > >> > >> For each packet type, we need a definition like above, and we must > >> check that all drivers setting a packet type behave like described. Hmm, I think the packet_type may need to be renamed to else, like offload_p= acket_type. It is just for hardware reported packet type information. It is not for all information of a packet. As different hardware may have different capability, it cannot report the s= ame in mbuf among different hardware for the same packet. With your question, I think the hardware capability flags may be needed. Ap= plications can query the packet type capabilities on each port, then it knows what typ= e of packet type information can be reported by the corresponding hardware. What do you think? And are they any better ideas from you? Thanks you very much! Regards, Helin >=20 > I'm not opposed to have a packet_type field in rx mbuf, but I really thin= k the > question above is an important question to make this feature useful to th= e > applications. >=20 >=20 > Regards, > Olivier >=20 > [1] http://dpdk.org/ml/archives/dev/2015-January/011273.html >=20