From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 245562A5E for ; Thu, 25 Feb 2016 11:41:03 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP; 25 Feb 2016 02:41:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,498,1449561600"; d="scan'208";a="920847161" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.193]) ([10.239.67.193]) by orsmga002.jf.intel.com with ESMTP; 25 Feb 2016 02:41:01 -0800 To: "Ananyev, Konstantin" , "dev@dpdk.org" References: <1451544799-70776-1-git-send-email-jianfeng.tan@intel.com> <1452836759-63540-1-git-send-email-jianfeng.tan@intel.com> <1452836759-63540-13-git-send-email-jianfeng.tan@intel.com> <2601191342CEEE43887BDE71AB97725836AE6144@irsmsx105.ger.corp.intel.com> From: "Tan, Jianfeng" Message-ID: <56CEDA3C.6010402@intel.com> Date: Thu, 25 Feb 2016 18:41:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <2601191342CEEE43887BDE71AB97725836AE6144@irsmsx105.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 12/12] examples/l3fwd: add option to parse ptype 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: Thu, 25 Feb 2016 10:41:04 -0000 Hi Konstantin, On 1/15/2016 10:47 PM, Ananyev, Konstantin wrote: > Hi Jianfeng, > >> -----Original Message----- >> From: Tan, Jianfeng >> Sent: Friday, January 15, 2016 5:46 AM >> To: dev@dpdk.org >> Cc: Zhang, Helin; Ananyev, Konstantin; Tan, Jianfeng >> Subject: [PATCH v2 12/12] examples/l3fwd: add option to parse ptype >> >> As a example to use ptype info, l3fwd needs firstly to use >> rte_eth_dev_get_ptype_info() API to check if device and/or PMD driver will >> parse and fill the needed packet type. If not, use the newly added option, >> --parse-ptype, to analyze it in the callback softly. >> >> Signed-off-by: Jianfeng Tan >> --- >> examples/l3fwd/main.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 91 insertions(+) >> ... >> +static inline void >> +parse_packet_type(struct rte_mbuf *m) >> +{ >> + struct ether_hdr *eth_hdr; >> + uint32_t packet_type = 0; >> + uint16_t ethertype; >> + >> + eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *); >> + ethertype = rte_be_to_cpu_16(eth_hdr->ether_type); >> + switch (ethertype) { >> + case ETHER_TYPE_IPv4: >> + packet_type |= RTE_PTYPE_L3_IPV4_EXT_UNKNOWN; >> + break; >> + case ETHER_TYPE_IPv6: >> + packet_type |= RTE_PTYPE_L3_IPV6_EXT_UNKNOWN; >> + break; > That's enough for LPM, for EM, don't we need to be sure there are no extensions > in the IP header? > > Konstantin Yes, EM needs to differentiate RTE_PTYPE_L3_IPV4/RTE_PTYPE_L3_IPV4_EXT, RTE_PTYPE_L3_IPV6/RTE_PTYPE_L3_IPV6_EXT: a. for soft ptype parser here, I'll add the code to do it. b. for hardware ptype parser, things become complex: those NICs which can differentiate: e1000 fmf10k ixgbe those NICs which cannot differentiate: cxgbe (ipv4, ipv6) enic (ipv4, ipv6) i40e (ipv4_ext_unknown, ipv6_ext_unknown) mlx4 (ipv4, ipv6) mlx5 (ipv4, ipv6) nfp (ipv4, ipv6, ipv6_ext) vmxnet3 (ipv4, ipv4_ext) As a result, l3fwd can only work perfectly on those NICs which can differentiate. SO if we really do the strict checking? Thanks, Jianfeng