From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id EF30EA0542; Mon, 29 Aug 2022 12:41:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B2B9D4069D; Mon, 29 Aug 2022 12:41:30 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by mails.dpdk.org (Postfix) with ESMTP id 8311E4003C for ; Mon, 29 Aug 2022 12:41:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1661769688; x=1693305688; h=date:from:to:cc:subject:message-id:references: content-transfer-encoding:in-reply-to:mime-version; bh=/VvG/bvP//xKPQeNeuEA6Rm9fUA3zGzSALRcGr01N2o=; b=RyBHSBml7er1TFh1oeUifMZdh+Ns6UTn/vtwAI404jfVQHZ7MXxOGYGN RC22VNtcV+NX1Tm8dqSViO0fS+zQTs22zxLpamoeM7pJvQF3XgQtDSUAM P0Gce+k34FlhLNjsgjw0wUPJY0E7T0AJtKS0fxdVbVwNcg/aoJs9v0d/4 SmPwPRaAVEE+NocjO9JcH9ft2DFqOnAcX09Ig8yUXVpC2qxeg0wVZrFu9 k2Xmz384Y+P9ruhuvlLG4Uk/vWKB9O0kpQBt6K3TM4XC4b1AM3EQ4gFn5 5tcd2EPYS+nKa82J9X9a8kNM5Q6FdKXCR5RDYW000nV5XpNsJWcztBA0G w==; X-IronPort-AV: E=McAfee;i="6500,9779,10453"; a="358828006" X-IronPort-AV: E=Sophos;i="5.93,272,1654585200"; d="scan'208";a="358828006" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Aug 2022 03:41:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,272,1654585200"; d="scan'208";a="588123610" Received: from orsmsx602.amr.corp.intel.com ([10.22.229.15]) by orsmga006.jf.intel.com with ESMTP; 29 Aug 2022 03:41:27 -0700 Received: from orsmsx607.amr.corp.intel.com (10.22.229.20) by ORSMSX602.amr.corp.intel.com (10.22.229.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 29 Aug 2022 03:41:27 -0700 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX607.amr.corp.intel.com (10.22.229.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 29 Aug 2022 03:41:26 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx610.amr.corp.intel.com (10.22.229.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31 via Frontend Transport; Mon, 29 Aug 2022 03:41:26 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.175) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Mon, 29 Aug 2022 03:41:26 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RliWO3ZQ5AEn/UYQoPLGezCctAi1a+llksi5oDzivhornorl3+F2A4PCrSkiswNemvyLqjYAeUbnMcAEBhLUkMOAH28ckZyuO1zT217z53NBvE9GMW5RzH6Anwo9SraARInk8YRVFMjESR1eUR8x04bq0fH038vtkii2uhnHPqSTkRm6Icc1HYeHJQzgPo3IYl06rXJVjpt73sMwAMDx8nqJS6oStpPFIXotX04LK0HxdkgOrDhfiC1Gfir6ngY/O5YJD1QG5EEYi4wito39Jz5MOT8m8C97w/a6PskZDoIslDo3NUMTFvZH1jpLe9AETXWiYf8lygqDUCMRaI5IGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=0wG6UapLtOLBz2u/ggm7PxaoQWzRFA8kpaNK2l0Nj8E=; b=nHNX6MBPi7MNq06XLO9qWvtmRcAvIpS+Qna5mSe35B4A+rb8q7OEoDi0r6LRT7Q0fyH32rF8Zmr9hb03C7eXnkqZdlEkiDYykhP3ftWk+R6V7qWMyHAtQrUOz2aA+WWuzZY0E78XSttbjdly0QvPebIjUttGrMxKYhn8+qvsYQn82UCgEX3xiICeW7Uv1I1HWlmG3ML80IVneFyd4zZiFo1qFbWoZ9A1c+fDGkFpiKrIhPUfgjxJgmNjTtfN1i0tGPv+7xpDbIvWv+XVjFVuAtthtQtwA5kxKlRB89ikVrCUVMZe719vRDdMIYSxlAIiKAd7cnHJxQAsYxAO6kI0Sg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; Received: from MWHPR11MB1629.namprd11.prod.outlook.com (2603:10b6:301:d::21) by BL0PR11MB3060.namprd11.prod.outlook.com (2603:10b6:208:72::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5566.14; Mon, 29 Aug 2022 10:41:21 +0000 Received: from MWHPR11MB1629.namprd11.prod.outlook.com ([fe80::13c:8120:d994:16d2]) by MWHPR11MB1629.namprd11.prod.outlook.com ([fe80::13c:8120:d994:16d2%6]) with mapi id 15.20.5566.021; Mon, 29 Aug 2022 10:41:21 +0000 Date: Mon, 29 Aug 2022 11:41:12 +0100 From: Bruce Richardson To: Morten =?iso-8859-1?Q?Br=F8rup?= CC: Kevin Laatz , Jerin Jacob , Anatoly Burakov , dpdk-dev , "Conor Walsh" , David Hunt , "Nicolas Chautru" , Fan Zhang , Ashish Gupta , Akhil Goyal , Chengwen Feng , Ray Kinsella , Thomas Monjalon , Ferruh Yigit , Andrew Rybchenko , Jerin Jacob , Sachin Saxena , Hemant Agrawal , Ori Kam , Honnappa Nagarahalli , Konstantin Ananyev Subject: Re: [PATCH v3 1/3] eal: add lcore poll busyness telemetry Message-ID: References: <24c49429394294cfbf0d9c506b205029bac77c8b.1657890378.git.anatoly.burakov@intel.com> <20220825152852.1231849-1-kevin.laatz@intel.com> <20220825152852.1231849-2-kevin.laatz@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D872B4@smartserver.smartshare.dk> <1fde7c20-256d-2df1-b503-beef1723d8fb@intel.com> <98CBD80474FA8B44BF855DF32C47DC35D872C4@smartserver.smartshare.dk> Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D872C4@smartserver.smartshare.dk> X-ClientProxiedBy: DB7PR02CA0001.eurprd02.prod.outlook.com (2603:10a6:10:52::14) To MWHPR11MB1629.namprd11.prod.outlook.com (2603:10b6:301:d::21) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3619b2b3-e3aa-46d3-43b0-08da89ab0309 X-MS-TrafficTypeDiagnostic: BL0PR11MB3060:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZfaWXOmZ0Z6ktGCIxZD9f/nkD0w6e8Mee4rHXvT2zgcKKAntVjlTiASeYuZ/W/iiPDgpbX4Z7DR1Pjti2hogoKqRBQSQe6f5ognb7WSrbyyFQrDnVDPfMxbfBGRVLedM0ODhnQ7kAcrMp4VrHH6xf/IfpVxhKpdOMTm1jTT5JvPwKntm8GYWqpuo8Lrm/lnlclhjfdLttIhssGmntoJmyg8CYcEYONlogH17IoVibSEt39xY0AlCghPOT/4MgwcGO+jhvkUH3ifGZrnupvlXo4zuwBRd2OmwXdho32x8+LSZaChkwwKfJr1TadNYnzMZQRjuoq+LWTcQ0hAePopz16qH360S+4DECg7ExlbsCymqOSN6o+ooCkF4Hg0hwRWcGptgr9f6PfiX+FGjVZXgAr38Oxc8hCTUX3IiWV3SV6fEbiC3nrAswyrKRYhaR6PeBnnaBZ9beeHUTiu5j29mFa5rl0oDUidUrJDo+Fnm5om2f0p+yqcWDAjGUhHcdnTFYZWgkSBjfPGqzXxthCeDqPSj2qtqGdZBu+I6zN9B4jl68PfcqMxiqVUH/KSFwfkg+cKN1ztuwAZObqWSx+K2KRlvSCTv5iZMbQHUw6+/uU7yya74z2URfPP7M1Og++YsHPZ4VcYNsuSkvdBt/bQ8MyOu4UhIaBfyOVum0VvyywsSINh8niHxfbIeGcNdJJklVpP26OEK7Ba62iXQ1U3B9cmSxGqYyZLkInsonVOoQSHEg6w2v+akUcBI2PF7yDuM X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1629.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(39860400002)(366004)(346002)(396003)(136003)(376002)(6506007)(66574015)(53546011)(2906002)(44832011)(6666004)(83380400001)(6512007)(186003)(26005)(38100700002)(316002)(966005)(8676002)(6486002)(4326008)(86362001)(66476007)(66556008)(66946007)(6916009)(54906003)(82960400001)(7416002)(5660300002)(41300700001)(8936002)(478600001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?zdzjfXdYdIRuHsnz7iHFr77A9Q7fVU/liVgRTjcdy40ybtcLePme+qS6G/?= =?iso-8859-1?Q?yruHB7y9FKXkOyr7FYagXvHxy5CL/hahhlcjzaJFVmCSGDzIM6fw5HHfyo?= =?iso-8859-1?Q?B091Sl9/JXD3Nm9yPaCaLvR+My/XHw4jQQBhRocKOCgeH9go4UQVoMNwOD?= =?iso-8859-1?Q?t8vnbasfbtmnKep5Ix/a6e5jJdoPxRL3Qv0zma6GTFPxMuIjOhIJ3472eq?= =?iso-8859-1?Q?EdlPAYRuZDwJOjZPionduvSEj1ZGHcBlAD8SZMlVa0gdwH3xzlQgPiE3oT?= =?iso-8859-1?Q?LYQT0ptDfSeaPoaFMF0LBRR7b+Am95qmJO9Unrgaj7EAgl38OwQ5e3QrXE?= =?iso-8859-1?Q?mSmBesL/JFzyFRc1rBgpSoQ6U9r0xYjzjwawSKR7iSOCxY8NyroQfOMGzR?= =?iso-8859-1?Q?R93foWNsLealIguUQzlV1mQ2zHujs5CxnjgumtgakUH/j2WMUAA5OtYMv9?= =?iso-8859-1?Q?ZITPnQIGPRNOSo87bOSdSyEs1zcsZ+BJlKokfiNcT08nnSJ3H6zjLEbknm?= =?iso-8859-1?Q?CBRs+BACZBLRbYbgdGfssyAgUr9A0bl0tB2oVJy2os94Wljj5d5kp6qYmm?= =?iso-8859-1?Q?lwOa+bwvePVCmD8LXJhbfmaVrvUZ6tRUltsdT2v3DjmdaXxl6QgVzZVxko?= =?iso-8859-1?Q?eZdKUXhE5liJOBZXwPrXOGLgN+LAKVG5AmlJ/AoKDWP3VO33S4q4x68J30?= =?iso-8859-1?Q?zf7a5pvLfCtg5P8XQbH10X1fTBnTSoyKQS4x0VRm2TzO3fltGhaa3+h/3g?= =?iso-8859-1?Q?xnp14haeCkrBxk5SI/iZD5zcpLDeNYwcaeUQSBTrsakiI2JPQf23Ith3SC?= =?iso-8859-1?Q?4lFsZ78bDq2mMTnO1x8I3CplubDZptCljUflQ+gvOFy9yvbRd2gcKUGj5D?= =?iso-8859-1?Q?4zTmbSfoYZzDWd2uNaAHI9nhFFwRJKIJA/HVb7RYYX2Zaq+MHRl81yl/Wy?= =?iso-8859-1?Q?mpFXls+DRPgBopMNUgh0zrPhBbLALXxgEgYaxa2Z86qe2b/AEssIWzmZva?= =?iso-8859-1?Q?VS8+vWtyiDxaaAC2dT+9B5cUCJo6To6Pi3RIlawjh3B8dm8yUpFSvSrPNR?= =?iso-8859-1?Q?5kzswz4hjWsYsH8niGzNux7XMqUhU3LU/vEh8FwBp7T5jkePMjx97wUDA6?= =?iso-8859-1?Q?oog4xCBASYGaj8+ZCGJ2V9fALWdLqk7726d6DC58LIS4cALu3x/oxeItuZ?= =?iso-8859-1?Q?ZJRidGPKt8JqHvDRNC8U9rQUb/1P/DoPxmCu8vJRdqJnnxbDOCegm9Dyz1?= =?iso-8859-1?Q?5ZIF6SudJZaH03NtnG03GFjOYraLR39GreCqGfLa0acjzI4p68Ip7tYD00?= =?iso-8859-1?Q?vW73v0JtCgevcyepyVYywLDSQqb0IACeeEtLHIMNP+zGW3dpwGUO1IUR0Y?= =?iso-8859-1?Q?eIG6kbO1KfwF0P7xhXcsnYZJFsXPe9yAvWPNW4aoMENnQ6iFRIM+BoWUSD?= =?iso-8859-1?Q?zBfmqyj/drWKh0JWnvtpTwbOSBiifSuwgA6PQaz8Ndd88ZW4nOcoJI2lwq?= =?iso-8859-1?Q?49mdRMJ5uIzTnUsuU62qbv0/Y/mrnBGU2sNtT0J9QsZoZseDI/1oo8Fwjz?= =?iso-8859-1?Q?kJL3MkOXAOckekrvx2gUv+QAsjTX0h9ZXVG3Db0DnX9Vz0HYLCU5gutAdh?= =?iso-8859-1?Q?vbOv5FTIvSLC58vjMP8/YBxPj6+u/GaWvn0vcmcrlucyWe3rU9XHCtEA?= =?iso-8859-1?Q?=3D=3D?= X-MS-Exchange-CrossTenant-Network-Message-Id: 3619b2b3-e3aa-46d3-43b0-08da89ab0309 X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1629.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2022 10:41:21.2979 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EwIxaZsBCs8NY5go72bVh8vvMZb+rc3nD2bIWIa9b+SEDJNtUpK8/VmkuihE2ZBZLEdul4mn0yo3ihuETToBhgbv7eDGwM6CXva0bHcwMdE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3060 X-OriginatorOrg: intel.com X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Aug 26, 2022 at 05:46:48PM +0200, Morten Brørup wrote: > > From: Kevin Laatz [mailto:kevin.laatz@intel.com] > > Sent: Friday, 26 August 2022 17.27 > > > > On 26/08/2022 09:29, Morten Brørup wrote: > > >> From: Jerin Jacob [mailto:jerinjacobk@gmail.com] > > >> Sent: Friday, 26 August 2022 10.16 > > >> > > >> On Fri, Aug 26, 2022 at 1:37 PM Bruce Richardson > > >> wrote: > > >>> On Fri, Aug 26, 2022 at 12:35:16PM +0530, Jerin Jacob wrote: > > >>>> On Thu, Aug 25, 2022 at 8:56 PM Kevin Laatz > > > > >> wrote: > > >>>>> From: Anatoly Burakov > > >>>>> > > >>>>> Currently, there is no way to measure lcore poll busyness in a > > >> passive way, > > >>>>> without any modifications to the application. This patch adds a > > >> new EAL API > > >>>>> that will be able to passively track core polling busyness. > > >>>>> > > >>>>> The poll busyness is calculated by relying on the fact that most > > >> DPDK API's > > >>>>> will poll for packets. Empty polls can be counted as "idle", > > >> while > > >>>>> non-empty polls can be counted as busy. To measure lcore poll > > >> busyness, we > > >>>>> simply call the telemetry timestamping function with the number > > >> of polls a > > >>>>> particular code section has processed, and count the number of > > >> cycles we've > > >>>>> spent processing empty bursts. The more empty bursts we > > >> encounter, the less > > >>>>> cycles we spend in "busy" state, and the less core poll busyness > > >> will be > > >>>>> reported. > > >>>>> > > >>>>> In order for all of the above to work without modifications to > > >> the > > >>>>> application, the library code needs to be instrumented with calls > > >> to the > > >>>>> lcore telemetry busyness timestamping function. The following > > >> parts of DPDK > > >>>>> are instrumented with lcore telemetry calls: > > >>>>> > > >>>>> - All major driver API's: > > >>>>> - ethdev > > >>>>> - cryptodev > > >>>>> - compressdev > > >>>>> - regexdev > > >>>>> - bbdev > > >>>>> - rawdev > > >>>>> - eventdev > > >>>>> - dmadev > > >>>>> - Some additional libraries: > > >>>>> - ring > > >>>>> - distributor > > >>>>> > > >>>>> To avoid performance impact from having lcore telemetry support, > > >> a global > > >>>>> variable is exported by EAL, and a call to timestamping function > > >> is wrapped > > >>>>> into a macro, so that whenever telemetry is disabled, it only > > >> takes one > > >>>>> additional branch and no function calls are performed. It is also > > >> possible > > >>>>> to disable it at compile time by commenting out > > >> RTE_LCORE_BUSYNESS from > > >>>>> build config. > > >>>>> > > >>>>> This patch also adds a telemetry endpoint to report lcore poll > > >> busyness, as > > >>>>> well as telemetry endpoints to enable/disable lcore telemetry. A > > >>>>> documentation entry has been added to the howto guides to explain > > >> the usage > > >>>>> of the new telemetry endpoints and API. > > >>>>> > > >>>>> Signed-off-by: Kevin Laatz > > >>>>> Signed-off-by: Conor Walsh > > >>>>> Signed-off-by: David Hunt > > >>>>> Signed-off-by: Anatoly Burakov > > >>>>> > > >>>>> --- > > >>>>> v3: > > >>>>> * Fix missed renaming to poll busyness > > >>>>> * Fix clang compilation > > >>>>> * Fix arm compilation > > >>>>> > > >>>>> v2: > > >>>>> * Use rte_get_tsc_hz() to adjust the telemetry period > > >>>>> * Rename to reflect polling busyness vs general busyness > > >>>>> * Fix segfault when calling telemetry timestamp from an > > >> unregistered > > >>>>> non-EAL thread. > > >>>>> * Minor cleanup > > >>>>> --- > > >>>>> diff --git a/meson_options.txt b/meson_options.txt > > >>>>> index 7c220ad68d..725b851f69 100644 > > >>>>> --- a/meson_options.txt > > >>>>> +++ b/meson_options.txt > > >>>>> @@ -20,6 +20,8 @@ option('enable_driver_sdk', type: 'boolean', > > >> value: false, description: > > >>>>> 'Install headers to build drivers.') > > >>>>> option('enable_kmods', type: 'boolean', value: false, > > >> description: > > >>>>> 'build kernel modules') > > >>>>> +option('enable_lcore_poll_busyness', type: 'boolean', value: > > >> true, description: > > >>>>> + 'enable collection of lcore poll busyness telemetry') > > >>>> IMO, All fastpath features should be opt-in. i.e default should be > > >> false. > > >>>> For the trace fastpath related changes, We have done the similar > > >> thing > > >>>> even though it cost additional one cycle for disabled trace points > > >>>> > > >>> We do need to consider runtime and build defaults differently, > > >> though. > > >>> Since this has also runtime enabling, I think having build-time > > >> enabling > > >>> true as default is ok, so long as the runtime enabling is false > > >> (assuming > > >>> no noticable overhead when the feature is disabled.) > > >> I was talking about buildtime only. "enable_trace_fp" meson option > > >> selected as > > >> false as default. > > > Agree. "enable_lcore_poll_busyness" is in the fast path, so it should > > follow the design pattern of "enable_trace_fp". > > > > +1 to making this opt-in. However, I'd lean more towards having the > > buildtime option enabled and the runtime option disabled by default. > > There is no measurable impact cause by the extra branch (the check for > > enabled/disabled in the macro) by disabling at runtime, and we gain the > > benefit of avoiding a recompile to enable it later. > > The exact same thing could be said about "enable_trace_fp"; however, the development effort was put into separating it from "enable_trace", so it could be disabled by default. > > Your patch is unlikely to get approved if you don't follow the "enable_trace_fp" design pattern as suggested. > > > > > > > > >> If the concern is enabling on generic distros then distro generic > > >> config can opt in this > > >> > > >>> /Bruce > > > @Kevin, are you considering a roadmap for using > > RTE_LCORE_TELEMETRY_TIMESTAMP() for other purposes? Otherwise, it > > should also be renamed to indicate that it is part of the "poll > > busyness" telemetry. > > > > No further purposes are planned for this macro, I'll rename it in the > > next revision. > > OK. Thank you. > > Also, there's a new discussion about EAL bloat [1]. Perhaps I'm stretching it here, but it would be nice if your library was made a separate library, instead of part of the EAL library. (Since this kind of feature is not new to the EAL, I will categorize this suggestion as "nice to have", not "must have".) > > [1] http://inbox.dpdk.org/dev/2594603.Isy0gbHreE@thomas/T/ > I was actually discussing this with Kevin and Dave H. on Friay, and trying to make this a separate library is indeed a big stretch. :-) >From that discussion, the key point/gap is that we are really missing a clean way of providing undefs or macro fallbacks for when a library is just not present. For example, if this was a separate library we would gain a number of advantages e.g. no need for separate enable/disable flag, but the big disadvantage is that every header include for it, and every reference to the macros used in that header need to be surrounded by big ugly ifdefs. For now, adding this into EAL is the far more practical approach, since it means that even if support for the feature is disabled at build time the header is still available to provide the appropriate no-op macros. /Bruce