From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by dpdk.org (Postfix) with ESMTP id EF0F9682E for ; Wed, 19 Nov 2014 11:28:34 +0100 (CET) Received: by mail-wi0-f174.google.com with SMTP id h11so4860316wiw.7 for ; Wed, 19 Nov 2014 02:39:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QzjOtpLeZ8NOV1mGfwctOiQ1WGtF4gRsCZGz8TyX62I=; b=J2KKTk+m3NFPW1i9XWDVh4iUjptcZ4WIESPZus/s/eXzbriCFpZSTeZgTRz+9rXoLg Xmuhj5aJRDgGjyPWjXPWOaM76qhZnbb6hFq1HWNwXikXR4+EdnoosN9fqwKQ7mwmqIoN vPSrVyIvIYAGcAsA72QAJnGrhUtc4tFxHvtBtkhMz8HnypGsCYXqwNN6o6rxClBKNQlw AgKdA4CY1Wjuen0tsmFT0nxVsYnIcOKRVEMDFtAO+JsAkqSt8OX6rn24Ri4mqk18Cl1M U3LL/omHmeHQgIyCBYkEkGe4YaLaiHrByQKeYy1/CLYfMAsTgVAgS8YQmyl9gLMHeLWW Dzew== X-Gm-Message-State: ALoCoQkCX5RS9WX2reY74vGzuwYVwr+qk9KgumlBcPJjm5puvO8ZrZNODpXOTxMSqGps4Ugo0tet X-Received: by 10.180.78.73 with SMTP id z9mr4269524wiw.52.1416393540005; Wed, 19 Nov 2014 02:39:00 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id e7sm1695153wjx.31.2014.11.19.02.38.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Nov 2014 02:38:59 -0800 (PST) Message-ID: <546C733C.1020404@6wind.com> Date: Wed, 19 Nov 2014 11:38:52 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Jijiang Liu , dev@dpdk.org References: <1416296251-7534-1-git-send-email-jijiang.liu@intel.com> <1416296251-7534-2-git-send-email-jijiang.liu@intel.com> In-Reply-To: <1416296251-7534-2-git-send-email-jijiang.liu@intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 19 Nov 2014 10:28:35 -0000 Hi Jijiang, 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 = 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 */ > [...] 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 does 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? This question applies to all types of course. 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 do I need to check in the packet if I want to set the RTE_PTYPE_IPv4_IPv4 type? 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 do exactly the same checks than i40e. It is crucial that what having a packet type set means... else it will stay an i40e-only mbuf field, which is probably not what we want. So, I think if we really want packet types to be integrated in mbuf, we need to: - start with a small list (maybe ipv4, ipv6, vxlan tunnels, ...) - each type must be well defined: what does having this type means? We *need* to know what was checked by the hw. - remove similar things in ol_flags to avoid having a redundant API. Regards, Olivier