From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 4E3F33978 for ; Fri, 26 Feb 2016 14:14:06 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 26 Feb 2016 05:14:05 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,498,1449561600"; d="scan'208";a="659715529" Received: from irsmsx154.ger.corp.intel.com ([163.33.192.96]) by FMSMGA003.fm.intel.com with ESMTP; 26 Feb 2016 05:14:04 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.237]) by IRSMSX154.ger.corp.intel.com ([169.254.12.174]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 13:14:03 +0000 From: "Ananyev, Konstantin" To: "Tan, Jianfeng" , "dev@dpdk.org" Thread-Topic: [PATCH v4 12/12] examples/l3fwd: add option to parse ptype Thread-Index: AQHRcGTtIifTLhAFr0u9onp+cs1LHJ8+MTyg Date: Fri, 26 Feb 2016 13:14:02 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B0BB05@irsmsx105.ger.corp.intel.com> References: <1451544799-70776-1-git-send-email-jianfeng.tan@intel.com> <1456445371-147264-1-git-send-email-jianfeng.tan@intel.com> <1456445371-147264-13-git-send-email-jianfeng.tan@intel.com> In-Reply-To: <1456445371-147264-13-git-send-email-jianfeng.tan@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZmQ2Y2NkOTItNDFjMC00ZGYwLTlhYmMtMTg2ODc0ZTM0MTZhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlNtUGlhc0R4dVFOMHVWWGtGaWVcL2hWc0FKXC80ZVA5VU84YU9zYWhMOE5MTT0ifQ== x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v4 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: Fri, 26 Feb 2016 13:14:06 -0000 Hi Jianfeng, >=20 > +static int > +check_packet_type_ok(int portid) > +{ > + int i, ret; > + int ptype_l3_ipv4 =3D 0, ptype_l3_ipv6 =3D 0; > + > + ret =3D rte_eth_dev_get_ptype_info(portid, RTE_PTYPE_L3_MASK, NULL, 0); > + if (ret <=3D 0) > + return 0; > + > + uint32_t ptypes[ret]; > + > + ret =3D rte_eth_dev_get_ptype_info(portid, RTE_PTYPE_L3_MASK, > + ptypes, ret); > + /* It is not a perfect pre-check, i.e., IP packets with extension and > + * IP packets which are not TCP/UDP, can pass this check, but cannot > + * work well at the mode of EXACT_MATCH. > + */ > + for (i =3D 0; i < ret; ++i) { > + if (ptypes[i] & RTE_PTYPE_L3_IPV4) > + ptype_l3_ipv4 =3D 1; > + if (ptypes[i] & RTE_PTYPE_L3_IPV6) > + ptype_l3_ipv6 =3D 1; > + } > + > + if (ptype_l3_ipv4 =3D=3D 0) > + printf("port %d cannot parse RTE_PTYPE_L3_IPV4\n", portid); > + > + if (ptype_l3_ipv6 =3D=3D 0) > + printf("port %d cannot parse RTE_PTYPE_L3_IPV6\n", portid); > + > + if (ptype_l3_ipv4 && ptype_l3_ipv6) > + return 1; > + > + return 0; > +} > +static inline void > +parse_packet_type(struct rte_mbuf *m) > +{ > + struct ether_hdr *eth_hdr; > + uint32_t packet_type =3D 0; > + uint16_t ethertype; > + > + eth_hdr =3D rte_pktmbuf_mtod(m, struct ether_hdr *); > + ethertype =3D rte_be_to_cpu_16(eth_hdr->ether_type); > + switch (ethertype) { > + case ETHER_TYPE_IPv4: > +#if (APP_LOOKUP_METHOD =3D=3D APP_LOOKUP_EXACT_MATCH) > + { > + int hdr_len; > + struct ipv4_hdr *hdr; > + > + hdr =3D (struct ipv4_hdr *)((uint8_t *)eth_hdr + > + sizeof(struct ether_hdr)); > + hdr_len =3D (hdr->version_ihl & IPV4_HDR_IHL_MASK) > + * IPV4_IHL_MULTIPLIER; > + /* Exact match uses 5 tuples to calculate hash, so > + * adequate packets should not only have no ip header > + * extension but also be TCP/UDP packet > + */ > + if (hdr_len =3D=3D sizeof(struct ipv4_hdr) && > + (hdr->next_proto_id =3D=3D 6 || > + hdr->next_proto_id =3D=3D 17)) Use IPPORTO_UDP, IPPORTO_TCP instead of hardcoded values. > + packet_type |=3D RTE_PTYPE_L3_IPV4; > + } Actually it is a good point: for EM case should l3fwd process only TCP/UDP packets? If yes, then it needs to check not only L3, but also L4 type too Which means that for EM and LPM check_packet_type_ok() should also be diffe= rent. Or we can leave it as it is - in that case EM even for non UDP/TCP packet w= ould still do route lookup using first 4B of L3 payload. If you choose first approach, then there is another thing to consider - there are 2 patches in flight for l3fwd: http://dpdk.org/dev/patchwork/patch/10800/ http://dpdk.org/dev/patchwork/patch/10782/ Which makes LPM/EM choice for l3fwd a runtime decision. So APP_LOOKUP_METHOD macro would not be available after it. Probably need to take that into account for your changes. Might be exclude l3fwd from this patch series, then rebase it on these patches and submit as a separate one? > +#elif (APP_LOOKUP_METHOD =3D=3D APP_LOOKUP_LPM) > + packet_type |=3D RTE_PTYPE_L3_IPV4_EXT_UNKNOWN; > +#endif > + break; > + case ETHER_TYPE_IPv6: > +#if (APP_LOOKUP_METHOD =3D=3D APP_LOOKUP_EXACT_MATCH) > + { > + struct ipv6_hdr *hdr; > + > + hdr =3D (struct ipv6_hdr *)((uint8_t *)eth_hdr + > + sizeof(struct ether_hdr)); > + if (hdr->proto =3D=3D 6 || hdr->proto =3D=3D 17) > + packet_type |=3D RTE_PTYPE_L3_IPV4; s/ RTE_PTYPE_L3_IPV4/RTE_PTYPE_L3_IPV6/ ? Apart from that the series looks good to me. Konstantin