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 1355A2C31 for ; Fri, 30 Dec 2016 08:30:23 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 29 Dec 2016 23:30:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,428,1477983600"; d="scan'208";a="803519714" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by FMSMGA003.fm.intel.com with ESMTP; 29 Dec 2016 23:30:22 -0800 Received: from fmsmsx112.amr.corp.intel.com (10.18.116.6) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 29 Dec 2016 23:30:22 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX112.amr.corp.intel.com (10.18.116.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 29 Dec 2016 23:30:22 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.20]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.177]) with mapi id 14.03.0248.002; Fri, 30 Dec 2016 15:30:20 +0800 From: "Tan, Jianfeng" To: Yuanhan Liu CC: "dev@dpdk.org" , "stephen@networkplumber.org" Thread-Topic: [PATCH v2 8/9] examples/l3fwd: add parse-ptype option Thread-Index: AQHSYaVsqb0C7S/EIkGKxLJvUuQDQ6EfhaaAgACLCPA= Date: Fri, 30 Dec 2016 07:30:19 +0000 Message-ID: References: <1482996643-113253-1-git-send-email-jianfeng.tan@intel.com> <1482996643-113253-9-git-send-email-jianfeng.tan@intel.com> <20161230063953.GK21789@yliu-dev.sh.intel.com> In-Reply-To: <20161230063953.GK21789@yliu-dev.sh.intel.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 v2 8/9] examples/l3fwd: add parse-ptype option X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 07:30:24 -0000 Hi, > -----Original Message----- > From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com] > Sent: Friday, December 30, 2016 2:40 PM > To: Tan, Jianfeng > Cc: dev@dpdk.org; stephen@networkplumber.org > Subject: Re: [PATCH v2 8/9] examples/l3fwd: add parse-ptype option >=20 > On Thu, Dec 29, 2016 at 07:30:42AM +0000, Jianfeng Tan wrote: > > To support those devices that do not provide packet type info when > > receiving packets, add a new option, --parse-ptype, to analyze > > packet type in the Rx callback. >=20 > I think this would be needed for all PMD drivers don't have the PTYPE > support. For these, --parse-ptype looks like a mandatory option in > the l3fwd example. I didn't find such option given in your test guide > though, which is weird. Mistake? Oops, my fault, it should be used with this option. As I just cared about i= f packets are received, instead of what types of packets are received, so I= missed that. I'll fix it. >=20 > Besides that, is there a way to query whether a PMD supports PTYPE > or not?=20 Yes, we have API rte_eth_dev_get_supported_ptypes() to do that. This patch = is to emulate the commit 71a7e2424e07 ("examples/l3fwd: fix using packet ty= pe blindly"). As we talked offline, I'll leverage this API to query if device support nee= ded ptypes, if not, register callback to analysis ptypes. This avoids to us= e another option. But for record, this also leads to un-consistent behavior= with l3fwd. Thanks, Jianfeng > If not, we should add a software one by our own. This could > be done without introducing yet another option. >=20 > > > > Signed-off-by: Jianfeng Tan > > --- > > examples/l3fwd-power/main.c | 60 > ++++++++++++++++++++++++++++++++++++++++++++- > > 1 file changed, 59 insertions(+), 1 deletion(-) > > > > diff --git a/examples/l3fwd-power/main.c b/examples/l3fwd- > power/main.c > > index b65d683..44843ec 100644 > > --- a/examples/l3fwd-power/main.c > > +++ b/examples/l3fwd-power/main.c > > @@ -164,6 +164,8 @@ static uint32_t enabled_port_mask =3D 0; > > static int promiscuous_on =3D 0; > > /* NUMA is enabled by default. */ > > static int numa_on =3D 1; > > +static int parse_ptype; /**< Parse packet type using rx callback, and = */ > > + /**< disabled by default */ > > > > enum freq_scale_hint_t > > { > > @@ -607,6 +609,48 @@ get_ipv4_dst_port(struct ipv4_hdr *ipv4_hdr, > uint8_t portid, > > #endif > > > > static inline void > > +parse_ptype_one(struct rte_mbuf *m) > > +{ > > + struct ether_hdr *eth_hdr; > > + uint32_t packet_type =3D RTE_PTYPE_UNKNOWN; > > + uint16_t ether_type; > > + > > + eth_hdr =3D rte_pktmbuf_mtod(m, struct ether_hdr *); > > + ether_type =3D eth_hdr->ether_type; > > + if (ether_type =3D=3D rte_cpu_to_be_16(ETHER_TYPE_IPv4)) > > + packet_type |=3D RTE_PTYPE_L3_IPV4_EXT_UNKNOWN; > > + else if (ether_type =3D=3D rte_cpu_to_be_16(ETHER_TYPE_IPv6)) > > + packet_type |=3D RTE_PTYPE_L3_IPV6_EXT_UNKNOWN; >=20 > BTW, we have rte_net_get_ptype(). Looks like a better option? >=20 > --yliu