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 3BC65DE0 for ; Thu, 10 Jan 2019 17:50:20 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2019 08:50:19 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,462,1539673200"; d="scan'208";a="125032145" Received: from silpixa00399779.ir.intel.com (HELO silpixa00399779.ger.corp.intel.com) ([10.237.222.118]) by orsmga002.jf.intel.com with ESMTP; 10 Jan 2019 08:50:17 -0800 From: Harry van Haaren To: dev@dpdk.org Cc: Harry van Haaren , reshma.pattan@intel.com, cristian.dumitrescu@intel.com, thomas@monjalon.net Date: Thu, 10 Jan 2019 16:50:51 +0000 Message-Id: <20190110165051.4859-1-harry.van.haaren@intel.com> X-Mailer: git-send-email 2.17.1 Subject: [dpdk-dev] [PATCH] mbuf: fix compile by making sched struct visible 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: Thu, 10 Jan 2019 16:50:20 -0000 Although C compilation works with the struct rte_mbuf_sched declared inside the struct rte_mbuf namespace, C++ fails to compile. This fix moves the rte_mbuf_sched struct up to the global namespace, instead of declaring it inside the struct mbuf namespace. The struct rte_mbuf_sched is being used on the stack in rte_mbuf_sched_get() and as a cast in _set(). For this reason, it must be exposed as an available type. Fixes: 5d3f72100904 ("mbuf: implement generic format for sched field") Signed-off-by: Harry van Haaren --- Cc: reshma.pattan@intel.com Cc: cristian.dumitrescu@intel.com Cc: thomas@monjalon.net Hey folks, Currently the mbuf header will fail to compile with a C++ compiler, this patch is one possible solution. I'm not particularly happy with this as a fix as it reduces mbuf struct readability, however it does resolve the issue. Regards, -Harry --- lib/librte_mbuf/rte_mbuf.h | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h index bc562dc8a..a9df0cd00 100644 --- a/lib/librte_mbuf/rte_mbuf.h +++ b/lib/librte_mbuf/rte_mbuf.h @@ -468,6 +468,17 @@ __extension__ typedef uint64_t MARKER64[0]; /**< marker that allows us to overwrite 8 bytes * with a single assignment */ +struct rte_mbuf_sched { + uint32_t queue_id; /**< Queue ID. */ + uint8_t traffic_class; + /**< Traffic class ID. Traffic class 0 + * is the highest priority traffic class. + */ + uint8_t color; + /**< Color. @see enum rte_color.*/ + uint16_t reserved; /**< Reserved. */ +}; /**< Hierarchical scheduler */ + /** * The generic rte_mbuf, containing a packet mbuf. */ @@ -574,16 +585,7 @@ struct rte_mbuf { * on PKT_RX_FDIR_* flag in ol_flags. */ } fdir; /**< Filter identifier if FDIR enabled */ - struct rte_mbuf_sched { - uint32_t queue_id; /**< Queue ID. */ - uint8_t traffic_class; - /**< Traffic class ID. Traffic class 0 - * is the highest priority traffic class. - */ - uint8_t color; - /**< Color. @see enum rte_color.*/ - uint16_t reserved; /**< Reserved. */ - } sched; /**< Hierarchical scheduler */ + struct rte_mbuf_sched sched; /**< Hierarchical scheduler */ struct { uint32_t reserved1; uint16_t reserved2; -- 2.17.1