From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9CA73A0567; Tue, 10 Mar 2020 13:52:32 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id F1BCF1BF7F; Tue, 10 Mar 2020 13:52:31 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 5B83423D for ; Tue, 10 Mar 2020 13:52:30 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Mar 2020 05:52:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,537,1574150400"; d="scan'208";a="289028948" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by FMSMGA003.fm.intel.com with ESMTP; 10 Mar 2020 05:52:28 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 10 Mar 2020 05:52:28 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 10 Mar 2020 05:52:27 -0700 Received: from FMSEDG002.ED.cps.intel.com (10.1.192.134) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 10 Mar 2020 05:52:27 -0700 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (104.47.55.105) by edgegateway.intel.com (192.55.55.69) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 10 Mar 2020 05:52:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WNmRh8IkFwcRMom+Ok5fFFbm76OudOP+pOFuvXwMbob/rNWS4bqniVkQp3q3ao1D5rjaMhh1tPbHqLK+lUpAVdB6LjZc2NRFrCFVaROjm7Z6XzRoCIZIaxEwen+EE3wPixrMaaSzgGVZxTF5wiZrOTm5piegCXUFfYkeyoF60VhkxA6A8+RJwx00q3T//OKYfvPDQqyY9Azod2GWHjPUed+8U0lMf3XIXh1/vhh+xnnul7cTROM8LPrw3Ffv8cy4IjvEjLsDo4caUnj3WutHrIaNKuPvipqfn9zpWDPTAiq8REsQLbBiJs66JfIdGXmObvqIGUv43SBONH7aA74dcA== 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-SenderADCheck; bh=7SsfN1SxsK+zyDMurm2V38ac9V2bW/Do8xHxx1pvkoY=; b=H5CGQLthv0plB8IN1XYd17aXJoGDDlApYu2w1ldYAvFQ7EudkZ1xcp1gHiI7ilVskxXdfSTKAyyoBQPR3EN2Tvg0y+TbU5dJnU2+T9h8nhI1u/RNretTBk/z3uolHHI4WwDdWXweNpJrHABKNJ9uD3AaIwUaaxaTl98/ev/E610aYNQxkHcYJKDSzlhfd5idFrhsT0ecY9IVarZBK+dJmNkD5847iOgtKf8By6GN6O5T0/0HYov09n3L1xTjM7EXx7E11oTDkIaYe4mplNvs8GIstbObYqQnuJ1noqcEMeIfd722fYu2v6gAUzs5FO/cm2CVe5T+uGR6s45ZHz+v3A== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7SsfN1SxsK+zyDMurm2V38ac9V2bW/Do8xHxx1pvkoY=; b=djCk55TAJMKFM9YlIKHf3/sZvW1rplRcEMkxiWpDZEjQPj6nB+xtjo6LfpOaeK3+K9SGKInpZ1eV7dz88BrYB1WZ792CjkeOvIIjeK2r4M6Y1WfSe8ja1yKtoh1n1cvXhxftI2wlrpCeDbqnl9yOSoMzER9T42kwOHsa397thK8= Received: from MWHPR1101MB2157.namprd11.prod.outlook.com (2603:10b6:301:51::10) by MWHPR1101MB2192.namprd11.prod.outlook.com (2603:10b6:301:59::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Tue, 10 Mar 2020 12:52:26 +0000 Received: from MWHPR1101MB2157.namprd11.prod.outlook.com ([fe80::7d16:3f1d:52c9:3116]) by MWHPR1101MB2157.namprd11.prod.outlook.com ([fe80::7d16:3f1d:52c9:3116%5]) with mapi id 15.20.2793.013; Tue, 10 Mar 2020 12:52:26 +0000 From: "Van Haaren, Harry" To: Honnappa Nagarahalli CC: "dev@dpdk.org" , Phil Yang , Gavin Hu , nd , nd Thread-Topic: Questions on service core feature implementation Thread-Index: AdX0FYNEgdKQmrv+TaKE0Ss7kzbiUwCxCW4A Date: Tue, 10 Mar 2020 12:52:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.2.0.6 authentication-results: spf=none (sender IP is ) smtp.mailfrom=harry.van.haaren@intel.com; x-originating-ip: [192.198.151.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c90bfbfc-8216-43ef-7c0f-08d7c4f1e26c x-ms-traffictypediagnostic: MWHPR1101MB2192: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2582; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39860400002)(396003)(366004)(346002)(199004)(189003)(76116006)(478600001)(66446008)(66556008)(66476007)(64756008)(71200400001)(9686003)(2906002)(81156014)(8676002)(81166006)(86362001)(55016002)(66946007)(4326008)(8936002)(316002)(6916009)(54906003)(52536014)(5660300002)(26005)(33656002)(6506007)(186003)(7696005)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR1101MB2192; H:MWHPR1101MB2157.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IOeO2vbWtvWKzrGgsQm2YLzpPJ+OVhHgQOpVj6LhG8Y5H1diQmCcIijBLo5ecvFezuRi1801VMxl/aSbfMojNcKFD2QtHTZyiT4NuM54THM2FhbuqDzwwElz24hOOMBCYGYL7eTh3ENlWO8SQWNx3uNuNSYtmRBpIFR2dWvjeKx4NCdtmXPm2hQcivJ3VTYTtRTT6jx5qemnMLVw5FebcjPA4FJt1OgxM7VN7svSiympHr6kgpQEYCCxzwKZbG5yCI2HVnBKWCfzaweAfOPTxuXw1uQ+Hfp4/t9XComRq9MPWjOGJuen/rvqM2PY7crzQjbXW9uFtP6dcfCzTkLpXm9zJHt8sPabNwhDbtgVL4kXbAfTlTUZO9w1BbyacrkIPVzGETDEy4DVdbuA1CqsHAmNkWLhPl6/WwYV2uZdmwOETgJJ3x4Mn0lsQpZjsDkc x-ms-exchange-antispam-messagedata: FgJaVazTOzBXdJAM2vrFTTlpGdLzFAmXI2lm0NxtIH+nVz08cCsP7O0amDajtuG+0shwR2ixgbmKGpru2hDFIyQ22oFoqkc0VBF9C4TGsInlDFRl9Z+Wy+XRxrNqrzh1Ms5uSpeWiRx21jz9rO231g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c90bfbfc-8216-43ef-7c0f-08d7c4f1e26c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2020 12:52:25.8868 (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: gwoRiQrSrFjebfZz53roGgQCVLRXfxIrV7dpbNYVV64oC2KsO2RRNgTzYH1i1cykPyQXVay51Ixt/kMydUhKedis0oEQt8YyzV93f1ni2IU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2192 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] Questions on service core feature implementation 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > -----Original Message----- > From: Honnappa Nagarahalli > Sent: Saturday, March 7, 2020 1:15 AM > To: Van Haaren, Harry > Cc: dev@dpdk.org; Phil Yang ; Gavin Hu > ; nd ; nd > Subject: Questions on service core feature implementation >=20 > Hi Harry, Hey Honnappa, > I have few observations on service core feature implementation. >=20 > I believe it is allowed to map/unmap a lcore to service while the service= is > running (i.e. not just during initialization stage). Please clarify > otherwise. Service-cores wasn't designed for this use case, but this "popped up" as the implementation was being finalized. Service cores' solves the proble= m of HW vs SW PMDs lcore requirements being different - and service cores is = the abstraction to hide that lcore requirement difference. So I don't think we made a very conscious decision on if this is allowed or= not. > Assuming yes - >=20 > In the 'service_run' function, the code to detect use of atomics seems to > result in allowing the mt-unsafe service to run on multiple cores. Lookin= g > at the following code: >=20 > 1 const int use_atomics =3D (service_mt_safe(s) =3D=3D 0) && > 2 (rte_atomic32_read(&s->num_mapped_cores) > 1); > 3 if (use_atomics) { > 4 if (!rte_atomic32_cmpset((uint32_t *)&s->execute_lock, 0= , > 1)) > 5 return -EBUSY; > 6 > 7 rte_service_runner_do_callback(s, cs, i); > 8 rte_atomic32_clear(&s->execute_lock); > 9 } else > 10 rte_service_runner_do_callback(s, cs, i); >=20 > Let us say, on core1, after line 4, 'use_atomics' is set to 0. core1 is > running the service function. > On the control plane let us say 'rte_service_map_lcore_set' is called to = map > the service to an additional core, core2. > Now, on core2, after line 4, 'use_atomics' is set to 1. But since core1 d= id > not take execute_lock, core2 will take the lock and starts running the > service function. This should not be allowed since the service is a mt- > unsafe service. > > Please let me know if my assessment is correct. > A possible solution is to take the execute_lock all the time. Yes agreed that your scenario seems to show an inconsistency. As per above, I'm not sure this use case was really the target of the service-cores design - but we as a community should identify if we want to support this use case. We could either update docs explicitly dis-allowing the above situation - this puts the burden on applications to understand what services could be running, and if they're being scheduled already. The other solution being to change the implementation to allow this use-case, which will likely have a performance impact for those already using service cores for its original function, by (as you suggested) taking execute_lock all the time (and paying the atomic cost for that..) > Thank you, > Honnappa Regards, -HvH