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 B2BC97F0C for ; Fri, 21 Nov 2014 13:16:26 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 21 Nov 2014 04:19:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="419777205" Received: from pgsmsx108.gar.corp.intel.com ([10.221.44.103]) by FMSMGA003.fm.intel.com with ESMTP; 21 Nov 2014 04:17:09 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by PGSMSX108.gar.corp.intel.com (10.221.44.103) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 21 Nov 2014 20:26:37 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id 14.03.0195.001; Fri, 21 Nov 2014 20:26:38 +0800 From: "Liu, Jijiang" To: Olivier MATZ , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 1/4] rte_mbuf:add packet types Thread-Index: AQHQAwKQof3+45qLC0+ULmOwCg9cS5xnPeMAgAO4VBA= Date: Fri, 21 Nov 2014 12:26:36 +0000 Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D9D8D6@SHSMSX101.ccr.corp.intel.com> References: <1416296251-7534-1-git-send-email-jijiang.liu@intel.com> <1416296251-7534-2-git-send-email-jijiang.liu@intel.com> <546C733C.1020404@6wind.com> In-Reply-To: <546C733C.1020404@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 1/4] rte_mbuf:add packet types 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: Fri, 21 Nov 2014 12:16:28 -0000 Hi Olivier, > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Wednesday, November 19, 2014 6:39 PM > To: Liu, Jijiang; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 1/4] rte_mbuf:add packet types >=20 > Hi Jijiang, >=20 > On 11/18/2014 08:37 AM, Jijiang Liu wrote: > > This patch abstracts packet types of L2 packet, Non Tunneled IPv4/6, IP= in IP, IP > in GRE, MAC in GRE and MAC in UDP, and add 4 MACROS to check packet IP > header. > > > > Signed-off-by: Jijiang Liu > > --- > > lib/librte_mbuf/rte_mbuf.h | 223 > ++++++++++++++++++++++++++++++++++++++++++++ > > 1 files changed, 223 insertions(+), 0 deletions(-) > > > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > > index f5f8658..678db0d 100644 > > --- a/lib/librte_mbuf/rte_mbuf.h > > +++ b/lib/librte_mbuf/rte_mbuf.h > > @@ -125,6 +125,229 @@ extern "C" { > > */ > > #define PKT_TX_OFFLOAD_MASK (PKT_TX_VLAN_PKT | PKT_TX_IP_CKSUM | > > PKT_TX_L4_MASK) > > > > +/** > > + * Ethernet packet type > > + */ > > +enum rte_eth_packet_type { > > + > > + /* undefined packet type, means HW can't recognise it */ > > + RTE_PTYPE_UNDEF =3D 0, > > + > > + /* L2 Packet types */ > > + RTE_PTYPE_PAY2, > > + RTE_PTYPE_TimeSync_PAY2, /**< IEEE1588 and 802.1AS */ > > + RTE_PTYPE_FIP_PAY2, /**< FCoE Initiation Protocol */ > > + RTE_PTYPE_LLDP_PAY2, /**< Link Layer Discovery Protocol */ > > + RTE_PTYPE_ECP_PAY2, /**< Edge Control Protocol */ > > [...] >=20 > I have one question about the packet_type: it is not clear to me what the > software can expect, for instance when RTE_PTYPE_IPv4_IPv4 is set. What d= oes > that mean exactly? Which fields must be valid in the packet to have this = type? > - L2 ethertype > - Presence of vlan? > - IP version > - IP checksum > - IP header length > - IP length (compared to packet len) > - anything about IP options? The RTE_PTYPE_IPv4_IPv4 means that packet format is MAC, IPV4, IPV4, PAY3. = The following fields are valid, L2 ethertype No VLAN IPv4, The RTE_PTYPE_IPv4_GRENAT_MACVLAN_IPv6_ICMP means that the packet format is= MAC without VLAN, IPv4,GRE or UDP tunneling header, MAC with VLAN, IPv6, I= CMP, PAY4 In all the packet types, I omitted MAC part. >=20 > This question applies to all types of course. >=20 > If I want to use packet type in an IP stack, I need to know which fields = are > checked by hardware (and what "checked" means for some of them), so I can= do > the remaining work in my application. > If I want to write a new PMD (maybe a virtual one, full software), what d= o I need > to check in the packet if I want to set the > RTE_PTYPE_IPv4_IPv4 type? For RTE_PTYPE_IPv4_IPv4, you just need to check PAY3 directly because you h= ave already known the packet format, so you don't need to check if there is= VLAN or IPv6. I admit that the RTE_PTYPE_IPv4_IPv4 is little i40e specific. It is not sta= ndard format. > I also feel it can be redundant with the current flags ("header is IPv4" > for instance). > To me, these types look very "i40e" oriented. If tomorrow (or today ?) we= want to > write a PMD for a hardware that is able to recognize IPv4, but does not d= o exactly > the same checks than i40e. It is crucial that what having a packet type s= et > means...=20 If the packet type can't match these defined packet type, and I think we ca= n add a new packet type in rte_eth_packet_type. >else it will stay an i40e-only mbuf field, which is probably not what we > want. It is open if you don't like which name/definition of the packet types, I = can change it. >=20 > So, I think if we really want packet types to be integrated in mbuf, we n= eed to: > - start with a small list (maybe ipv4, ipv6, vxlan tunnels, ...). Ok, makes sense. But a question is how to map i40e paket type if the packe= t type is not defined. For example, if the following packet type are not defined, how to map i40e = packet type, we will probably omit these for i40e. /* L2 Packet types */ + RTE_PTYPE_PAY2, + RTE_PTYPE_TimeSync_PAY2, /**< IEEE1588 and 802.1AS */ + RTE_PTYPE_FIP_PAY2, /**< FCoE Initiation Protocol */ + RTE_PTYPE_LLDP_PAY2, /**< Link Layer Discovery Protocol */ + RTE_PTYPE_ECP_PAY2, /**< Edge Control Protocol */ + RTE_PTYPE_EAPOL_PAY2, + /**< IEEE 802.1X Extensible Authentication Protocol over LAN */ + RTE_PTYPE_ARP, + RTE_PTYPE_FCOE_PAY3, + RTE_PTYPE_FCOE_FCDATA, + RTE_PTYPE_FCOE_FCRDY, + RTE_PTYPE_FCOE_FCRSP, + RTE_PTYPE_FCOE_FCOTHER, + RTE_PTYPE_FCOE_VFT, + RTE_PTYPE_FCOE_VFT_FCDATA, + RTE_PTYPE_FCOE_VFT_FCRDY, + RTE_PTYPE_FCOE_VFT_FCRSP, + RTE_PTYPE_FCOE_VFT_FCOTHER, + > - each type must be well defined: what does having this type means? We > *need* to know what was checked by the hw. Current packet name have already had clear meaning, I thought. > - remove similar things in ol_flags to avoid having a redundant API. Yes, when all i40e/ixgbe/igb PMDs done, the related IP header offload shoul= d be removed. I just changed for i40e, there still are igb&ixgbe need to be changed in D= PDK2.0, so we can't remove the IP ol_flags now. Actually, I think it will be a good time to integrate all the changes for p= acket type when all the PMDs done in DPDK2.0. Thomas, do you agree on this? >=20 > Regards, > Olivier