From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <helin.zhang@intel.com>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id B42272A61
 for <dev@dpdk.org>; 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" <helin.zhang@intel.com>
To: Olivier MATZ <olivier.matz@6wind.com>, "dev@dpdk.org" <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: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7F8013@SHSMSX103.ccr.corp.intel.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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