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 78CDB9AA6 for ; Tue, 1 Mar 2016 15:31:43 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 01 Mar 2016 06:30:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,523,1449561600"; d="scan'208";a="756004152" Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga003.jf.intel.com with ESMTP; 01 Mar 2016 06:30:20 -0800 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.237]) by IRSMSX104.ger.corp.intel.com ([169.254.5.87]) with mapi id 14.03.0248.002; Tue, 1 Mar 2016 14:30:18 +0000 From: "Ananyev, Konstantin" To: "Tan, Jianfeng" , "dev@dpdk.org" Thread-Topic: [PATCH] examples/l3fwd: fix using packet type blindly Thread-Index: AQHRc5PH5XOiXCU2xkqlshX+tOUuFp9ElSlggAAN2ACAAAJ/4A== Date: Tue, 1 Mar 2016 14:30:17 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836B0C9EF@irsmsx105.ger.corp.intel.com> References: <1451544799-70776-1-git-send-email-jianfeng.tan@intel.com> <1456795416-118189-1-git-send-email-jianfeng.tan@intel.com> <2601191342CEEE43887BDE71AB97725836B0C99C@irsmsx105.ger.corp.intel.com> <56D5A476.6070500@intel.com> In-Reply-To: <56D5A476.6070500@intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYThiMDg2MWYtMmE3Zi00OTBlLTk1MjYtNjQ1OTI3NDQzMmJkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkV0NFR1VkkycE5LQWJrM3BkMkFwNERlZUlVWHlPUU8zZjB5U1M5RzFXems9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: fix using packet type blindly 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: Tue, 01 Mar 2016 14:31:43 -0000 > >> + > >> +void > >> +lpm_parse_ptype(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: > >> + packet_type |=3D RTE_PTYPE_L3_IPV4_EXT_UNKNOWN; > >> + break; > >> + case ETHER_TYPE_IPv6: > >> + packet_type |=3D RTE_PTYPE_L3_IPV6_EXT_UNKNOWN; > >> + break; > >> + default: > >> + break; > >> + } > >> + > >> + m->packet_type |=3D packet_type; > > Might be safer: > > m->packet_type =3D packet_type; >=20 > Your previous comment on this says that the assignment will write off > some ptype info PMDs have filled. But for l3fwd, I think it does not > care other ptype info. Ah, yes - missed that you setup it to 0 at the start of that function. Probably better than to use PTYPE_UNKNOW macro=20 >=20 > [...] > > +static uint16_t > > +cb_parse_packet_type(uint8_t port __rte_unused, > > + uint16_t queue __rte_unused, > > + struct rte_mbuf *pkts[], > > + uint16_t nb_pkts, > > + uint16_t max_pkts __rte_unused, > > + void *user_param __rte_unused) > > +{ > > + unsigned i; > > + > > + for (i =3D 0; i < nb_pkts; ++i) > > + l3fwd_lkp.parse_ptype(pkts[i]); > > > > No need to create callback chains. > > That way you have extra call per packet. > > Just 2 callbaclks: cb_lpm_parse_ptype & cb_em_parse_ptype, > > and then register one depending on which mode are we in. > > Would be simpler and faster, I believe. >=20 > Yes, I was considering it too. In addition, shall I use vector > instruction here to accelerate it? If you like you can have 2 versions one scalar one, another vector one. Same as we have for the rest of EM/LPM processing. Just scalar one would do too, at least for now. Konstantin