From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id F075236E for ; Mon, 6 Mar 2017 15:46:12 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2017 06:46:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,254,1484035200"; d="scan'208";a="232824647" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 06 Mar 2017 06:46:11 -0800 Received: from fmsmsx101.amr.corp.intel.com (10.18.124.199) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 6 Mar 2017 06:46:11 -0800 Received: from fmsmsx113.amr.corp.intel.com ([169.254.13.172]) by fmsmsx101.amr.corp.intel.com ([169.254.1.198]) with mapi id 14.03.0248.002; Mon, 6 Mar 2017 06:46:10 -0800 From: "Wiles, Keith" To: Pascal Mazon CC: "dev@dpdk.org" Thread-Topic: [PATCH 5/6] net/tap: add packet type management Thread-Index: AQHSlAMe5cJ/51kDn0KVSe+iAUMP8aGDxHeAgASgcoCAAAn1gA== Date: Mon, 6 Mar 2017 14:46:10 +0000 Message-ID: <5D908DC5-1F22-4353-8840-E164760E7782@intel.com> References: <5044b7ef7b9e5207fb2202bd5715524bd0d49379.1488534161.git.pascal.mazon@6wind.com> <0FF8ED8E-9F3B-421A-AF51-7F6557095D59@intel.com> <20170306151031.77a73da0@paques.dev.6wind.com> In-Reply-To: <20170306151031.77a73da0@paques.dev.6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.49.209] Content-Type: text/plain; charset="us-ascii" Content-ID: <121743B07CFEB746B9F42CAEC058FBF5@intel.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 5/6] net/tap: add packet type management 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: Mon, 06 Mar 2017 14:46:13 -0000 > On Mar 6, 2017, at 8:10 AM, Pascal Mazon wrote: >=20 > On Fri, 3 Mar 2017 15:31:14 +0000 > "Wiles, Keith" wrote: >=20 >>=20 >>> On Mar 3, 2017, at 3:46 AM, Pascal Mazon >>> wrote: >>>=20 >>> Advertize RTE_PTYPE_UNKNOWN since tap does not report any packet >>> type. >>>=20 >>> Signed-off-by: Pascal Mazon >>> --- >>> doc/guides/nics/features/tap.ini | 1 + >>> drivers/net/tap/rte_eth_tap.c | 15 +++++++++++++++ >>> 2 files changed, 16 insertions(+) >>>=20 >>> diff --git a/doc/guides/nics/features/tap.ini >>> b/doc/guides/nics/features/tap.ini index 6aa11874e2bc..7f3f4d661dd7 >>> 100644 --- a/doc/guides/nics/features/tap.ini >>> +++ b/doc/guides/nics/features/tap.ini >>> @@ -13,6 +13,7 @@ MTU update =3D Y >>> Multicast MAC filter =3D Y >>> Speed capabilities =3D Y >>> Unicast MAC filter =3D Y >>> +Packet type parsing =3D Y >>> Other kdrv =3D Y >>> ARMv7 =3D Y >>> ARMv8 =3D Y >>> diff --git a/drivers/net/tap/rte_eth_tap.c >>> b/drivers/net/tap/rte_eth_tap.c index 64b84cd76321..e4af36a6d142 >>> 100644 --- a/drivers/net/tap/rte_eth_tap.c >>> +++ b/drivers/net/tap/rte_eth_tap.c >>> @@ -36,6 +36,7 @@ >>> #include >>> #include >>> #include >>> +#include >>>=20 >>> #include >>> #include >>> @@ -216,6 +217,8 @@ pmd_rx_burst(void *queue, struct rte_mbuf >>> **bufs, uint16_t nb_pkts) mbuf->data_len =3D len; >>> mbuf->pkt_len =3D len; >>> mbuf->port =3D rxq->in_port; >>> + mbuf->packet_type =3D rte_net_get_ptype(mbuf, NULL, >>> + >>> RTE_PTYPE_ALL_MASK); >>>=20 >>> /* account for the receive frame */ >>> bufs[num_rx++] =3D mbuf; >>> @@ -760,6 +763,17 @@ tap_mtu_set(struct rte_eth_dev *dev, uint16_t >>> mtu) return 0; >>> } >>>=20 >>> +static const uint32_t* >>> +tap_dev_supported_ptypes_get(struct rte_eth_dev *dev __rte_unused) >>> +{ >>> + static const uint32_t ptypes[] =3D { >>> + RTE_PTYPE_UNKNOWN, >>> + >>> + }; >>> + >>> + return ptypes; >>> +} >>=20 >> Can we just add the code to grab the ptype value instead of just >> saying not supported. >>=20 >> The original code would just return an error from ethdev correct, >> what was wrong with that one. I would like to see the tap PMD just >> return the ptype would that not be more useful? >>=20 >=20 > tap PMD depends on the rte_net_get_ptype(), which code may change in the > future to support more packet types. Those changes would then need to be > reflected on the tap PMD, to be consistent. >=20 > I reported only RTE_PTYPE_UNKNOWN to avoid keeping a tight sync with the > rte_net library. As we're allowed to be more precise in the packet types > we actually set, compared to those we declare as supported, I thought it > best. >=20 > Would you indeed rather we copied all currently supported packet types > from rte_net to tap_dev_supported_ptypes_get()? I see your point here, it not reasonable to copy all of the ptypes from rte= _net to here ignore my comment. >=20 > Regards, > Pascal >=20 >>> + >>> static const struct eth_dev_ops ops =3D { >>> .dev_start =3D tap_dev_start, >>> .dev_stop =3D tap_dev_stop, >>> @@ -784,6 +798,7 @@ static const struct eth_dev_ops ops =3D { >>> .mtu_set =3D tap_mtu_set, >>> .stats_get =3D tap_stats_get, >>> .stats_reset =3D tap_stats_reset, >>> + .dev_supported_ptypes_get =3D tap_dev_supported_ptypes_get, >>> }; >>>=20 >>> static int >>> --=20 >>> 2.8.0.rc0 >>>=20 >>=20 >> Regards, >> Keith >>=20 >=20 Regards, Keith