From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id C39349A8B for ; Tue, 3 Feb 2015 04:25:21 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 02 Feb 2015 19:21:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,510,1418112000"; d="scan'208";a="660648536" Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88]) by fmsmga001.fm.intel.com with ESMTP; 02 Feb 2015 19:25:18 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 3 Feb 2015 11:25:17 +0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.161]) by shsmsx102.ccr.corp.intel.com ([169.254.2.124]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 11:25:16 +0800 From: "Zhang, Helin" To: "Ananyev, Konstantin" , Olivier MATZ , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 00/17] unified packet type Thread-Index: AQHQPJEKPA3enZdlxUCzQrgE37GgSZzcqDeAgAARzICAAF+/AIABLjmQ Date: Tue, 3 Feb 2015 03:25:15 +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> <54CF617B.5010009@6wind.com> <2601191342CEEE43887BDE71AB977258213E28EC@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB977258213E28EC@irsmsx105.ger.corp.intel.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: Tue, 03 Feb 2015 03:25:22 -0000 > -----Original Message----- > From: Ananyev, Konstantin > Sent: Tuesday, February 3, 2015 1:20 AM > To: Olivier MATZ; Zhang, Helin; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 00/17] unified packet type >=20 > Hi Olivier, >=20 > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier MATZ > > Sent: Monday, February 02, 2015 11:38 AM > > To: Zhang, Helin; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 00/17] unified packet type > > > > Hi Helin, > > > > On 02/02/2015 03:44 AM, Zhang, Helin wrote: > > >>>> 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 compar= ed 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 desc= ribed. > > > Hmm, I think the packet_type may need to be renamed to else, like > offload_packet_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 same in mbuf among different hardware for the same packet. > > > With your question, I think the hardware capability flags may be > > > needed. Applications can query the packet type capabilities on each > > > port, then it knows what type of packet type information can be repor= ted by > the corresponding hardware. > > > What do you think? And are they any better ideas from you? > > > > I'm not sure renaming the field would change something here. > > > > The high-level question is: how a software can take advantage of this > > information given by the hardware? If the same packet_type does not > > have the same meaning depending on the hardware, it's not worth having > > this info. > > > > I think the API should describe for each packet type what can be > > expected by the application. Here is an example. When a driver sets > > the > > RTE_PTYPE_L3_IPV4 type, it means that: > > > > - the layer 3 is identified as IP by underlying layer (ex: ethertype=3D= IP > > if layer 2 is ethernet) > > - the IP version field is 4 > > - there is no IP options (i.e the size of header is 20) >=20 > Yes, I suppose that's what supported HW can guarantee when > RTE_PTYPE_L3_IPV4 is set. >=20 > > - the checksum field has been verified by hw, and if wrong, the > > flag PKT_RX_IP_CKSUM_BAD is set >=20 > Hmm, why is that? > As I remember on many devices it is configurable by SW should HW do RX > checksum offload or not. > From DPDK point of view there is hw_ip_checksum field in rte_eth_rxmode. > So it is a possible situation, when at RX HW does packet type determinati= on, > but doesn't make L3/L4 checksum calculation. >=20 > I suppose for checksum(s) it should be a separate flags (in ol_flags) wit= h 3 > possible values: > CKSUM_UNKNOWN, CKSUM_BAD, CKSUM_OK. >=20 > Konstantin I think packet type and checksum are totally different things in DPDK, thou= gh they might have dependencies in hardware. Checksum good/bad is still indicated in ol_flags. Packet type is nothing ab= out checksum. Regards, Helin >=20 > > > > If the hardware is not able to give all this information, there are > > 2 solutions: > > - do the remaining tests in the driver > > - or set l3 pkt_type to unknown > > > > All other conditions that are not described in the API should be > > checked by the applition if it needs the information (ex: check that > > IP dest address is legal, that ip->len is >=3D 20, ...). > > > > > > If we are able to describe this for all packet types, it would really > > help application to take advantage of these packet types. > > > > Regards, > > Olivier