From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0044.outbound.protection.outlook.com [104.47.1.44]) by dpdk.org (Postfix) with ESMTP id 788451B298 for ; Fri, 19 Jan 2018 11:44:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CmPKvyEk1PSItDNUZtKHmq/qPmAfQ6LP+gfr7QuWzRM=; b=GBXusyD6jUV3tblgvRhY4xewkA9tPaQvUECgVQqHgbOpu1c32x0ZeVhtstOPopOZJuzF1er+Yhx1m7NK+4EFij62aPh/9nv06nyUnG1fU8zmwi/i6dRWDb8X+7Mawgv17ZNnwR1V+CArKBh/ctmBJKpEcKTp0JevEki5xpEh+vU= Received: from AM6PR0502MB3797.eurprd05.prod.outlook.com (52.133.21.26) by AM6PR0502MB4006.eurprd05.prod.outlook.com (52.133.30.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Fri, 19 Jan 2018 10:44:32 +0000 Received: from AM6PR0502MB3797.eurprd05.prod.outlook.com ([fe80::6c28:c6b3:de94:a733]) by AM6PR0502MB3797.eurprd05.prod.outlook.com ([fe80::6c28:c6b3:de94:a733%13]) with mapi id 15.20.0428.014; Fri, 19 Jan 2018 10:44:32 +0000 From: Matan Azrad To: Bruce Richardson CC: Neil Horman , "Ananyev, Konstantin" , Thomas Monjalon , "Gaetan Rivet" , "Wu, Jingjing" , "dev@dpdk.org" Thread-Topic: [PATCH v2 2/6] ethdev: add port ownership Thread-Index: AQHTihf/M9xg8LYorUSRFqZtTc27hqNtNdVQgAFomACAAAOCwIAAuwQAgABvY+CABQwJgIAAEk3ggABinoCAANUIAIAAxQGAgAAGCnCAAQnKAIAAAmNwgAApSwCAADKGAIABUdOAgAAMD/CAADKfgIAAAbBAgAAcRwCAABk1cIAAXAAAgABVCKCAAC37gIAAEAZg Date: Fri, 19 Jan 2018 10:44:32 +0000 Message-ID: References: <20180117140020.GA5432@hmswarspite.think-freely.org> <2601191342CEEE43887BDE71AB9772588627F0E9@irsmsx105.ger.corp.intel.com> <20180118131017.GA1622@hmswarspite.think-freely.org> <20180118165436.GD1622@hmswarspite.think-freely.org> <20180118184152.GA22115@neilslaptop.think-freely.org> <20180119014122.GA3516@neilslaptop.think-freely.org> <20180119093017.GB14048@bricha3-MOBL3.ger.corp.intel.com> In-Reply-To: <20180119093017.GB14048@bricha3-MOBL3.ger.corp.intel.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; x-originating-ip: [85.64.136.190] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR0502MB4006; 7:tjxt7T7da1suziQvtKoc+zWyq7/HilyeUn601nQg1WffAgB6GC6nziU5cRUiR0YFciNsL0H4KXkJ7syQ6CpAljC3qc8pu4yA8G1/vX1oB0olAlD7PM3oErXVWvkTzjn4aUulLPemyXpvBanzkBME0oumUadKo2jxwLfnGF/HScC0w/8Ci+fGV3/JXKGdFJcOdQPXW5l0Tc2qFR/Bz85LkYGpyyLopfTyCyt8Zlxbuq0SynHBo56UX4OtPNQC3Uif x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e36b2ab7-a305-41ba-83f5-08d55f29a038 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(48565401081)(2017052603307)(7153060)(7193020); SRVR:AM6PR0502MB4006; x-ms-traffictypediagnostic: AM6PR0502MB4006: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(2400076)(944501161)(93006095)(93001095)(10201501046)(6055026)(6041268)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:AM6PR0502MB4006; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM6PR0502MB4006; x-forefront-prvs: 0557CBAD84 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(39380400002)(39860400002)(346002)(189003)(199004)(76176011)(3660700001)(81156014)(53936002)(6116002)(3846002)(229853002)(81166006)(25786009)(97736004)(9686003)(55016002)(561944003)(86362001)(3280700002)(6436002)(105586002)(7696005)(478600001)(5660300001)(8676002)(14454004)(2906002)(8936002)(2950100002)(6916009)(7736002)(305945005)(74316002)(5250100002)(6246003)(4326008)(33656002)(54906003)(6506007)(102836004)(26005)(316002)(68736007)(59450400001)(99286004)(66066001)(2900100001)(93886005)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR0502MB4006; H:AM6PR0502MB3797.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DPDBrSb0ejAJqbBbdgMoWkA2nVcz51urf8M4NknbPOzucdJCZduEBkiMvaP5NchMXvY4MoLuH0vzNnMNXIn5iQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: e36b2ab7-a305-41ba-83f5-08d55f29a038 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2018 10:44:32.7899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0502MB4006 Subject: Re: [dpdk-dev] [PATCH v2 2/6] ethdev: add port ownership 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, 19 Jan 2018 10:44:34 -0000 Hi Bruce From: Bruce Richardson, Friday, January 19, 2018 11:30 AM > On Fri, Jan 19, 2018 at 07:14:17AM +0000, Matan Azrad wrote: > > > > Hi Neil > > From: Neil Horman, Friday, January 19, 2018 3:41 AM > > > On Thu, Jan 18, 2018 at 08:21:34PM +0000, Matan Azrad wrote: > > > > Hi Neil. > > > > > > > > From: Neil Horman, Thursday, January 18, 2018 8:42 PM > > > > > > > > 1. What exactly do you want to improve?(in details) 2. Which API > > > > specifically do you want to change(\ part of code)? > > > > 3. What is the missing in current code(you can answer it in V3 I > > > > sent if you > > > want) which should be fixed? > > > > > > > > > > > > sorry for that, I think it is not relevant continue > > > > discussion if we are > > > not fully understand each other. So let's start from the beginning > > > "with good order :)" by answering the above questions. > > > > > > > > > Sure, this seems like a reasonable way to level set. > > > > > > I mentioned in another thread that perhaps some of my issue here is > > > perception regarding what is meant by ownership. When I think of an > > > ownership api I think primarily of mutual exclusion (that is to say, > > > enforcement of a single execution context having access to a > > > resource at any given time. In my mind the simplest form of > > > ownership is a spinlock or a mutex. A single execution context > > > either does or does not hold the resource at any one time. Those > > > contexts that attempt to gain excusive access to the resource call > > > an api that (depending on > > > implementation) either block continued execution of that thread > > > until exclusive access to the resource can be granted, or returns > > > immediately with a success or error indicator to let the caller know = if > access is granted. > > > > > > If I were to codify this port ownership api in pseudo code it would > > > look something like this: > > > > > > struct rte_eth_dev { > > > > > > < eth dev bits > > > > rte_spinlock_t owner_lock; > > > bool locked; > > > pid_t owner_pid; > > > } > > > > As an aside, if you ensure that both locked (or "owned", I think in this > context) and owner_pid are integer values, you can do away with the lock > and use a compare-and-set to take ownership, by setting both atomically i= f > unmodified from the originally read values. >=20 > > > > > > bool rte_port_claim_ownership(struct rte_eth_dev *dev) { > > > bool ret =3D false; > > > > > > spin_lock(dev->owner_lock); > > > if (dev->locked) > > > goto out; > > > dev->locked =3D true; > > > dev->owner_pid =3D getpid(); > > > ret =3D true; > > > out: > > > spin_unlock(dev->lock) > > > return ret; > > > } > > > > > > > > > bool rte_port_release_ownership(rte_eth_dev *dev) { > > > > > > boot ret =3D false; > > > spin_lock(dev->owner_lock); > > > if (!dev->locked) > > > goto out; > > > if (dev->owner_pid !=3D getpid()) > > > goto out; > > > dev->locked =3D false; > > > dev_owner_pid =3D 0; > > > ret =3D true; > > > out: > > > spin_unlock(dev->owner_lock) > > > return ret; > > > } > > > > > > bool rte_port_is_owned_by(struct rte_eth_dev *dev, pid_t pid) { > > > bool ret =3D false; > > > > > > spin_lock(dev->owner_lock); > > > if (pid) > > > ret =3D (dev->locked && (pid =3D=3D dev->owner_pid)); > > > else > > > ret =3D dev->locked; > > > spin_unlock(dev->owner_lock); > > > return ret; > > > } > > > > > > The idea here is that lock state is isolated from ownership > > > information. Any context has the opportunity to lock the resource > > > (in this case the eth port) despite its ownership object. > > > > > > In comparison, your api, which is in may ways simmilar, separates > > > the creation of ownership objects to a separate api call, and that > > > ownership information embodies state that is integral to the ability > > > to get exclusive access to the resource. I.E. if thread A calls > > > your owner_new call, and then thread B calls owner_new, thread A > > > will never be able to get access to any port unless it calls owner_ne= w > again. > > > > > > Does that help clarify my position? > This would have been my understanding of what was being looked for too, > from my minimal understanding of the problem. Thanks for putting that > forward on behalf of many of us! >=20 > > > > Now I fully understand you, thanks for your patience. > > > > So, you are missing here one of the main ideas of my port ownership > intention. > > There are options for X>1 different uncoordinated owners running in the > same thread. >=20 > Thanks Matan for taking time to try and explain how your idea differs, bu= t I > for one am still a little confused. Sorry for the late questions. >=20 > Sure, Neil's example above takes the pid or thread id as the owner id > parameter, but there is no reason we can't use the same scheme with > arbitrarily assigned owner ids, so long as they are unique. We can even h= ave > a simple mapping table mapping ids to names of components. > > Sorry, don't understand your point here. My approach asked to allocate unique ID for "any part of code want to manag= e\use a port". What is the problem here and how do you suggest to fix it? Neil approach (with process iD\ thread id ) is wrong because 2 different ow= ners can run in same thread (as I explained a lot below). > > For example: > > 1. Think about Testpmd control commands that call to failsafe port devo= p > which call to its sub-devices devops, while tespmd is different > owner(controlling failsafe-port) and failsafe is a different owner(contro= lling > all its sub-devices ports), There are both run control commands in the sa= me > thread and there are uncoordinated! > > 2. Interrupt callbacks that anyone can register to them and all will r= un by > the DPDK host thread. >=20 > Can you provide a little more details here: what is the specific issue or= conflict > in each of these examples and how does your ownership proposal fix it, > when Neil's simpler approach doesn't? >=20 For the first example: My approach: Testpmd want to manage the fail-safe port, therefore it should allocate uni= que ID(only one time) and use owner set(by its ID) to take ownership of thi= s port. If it succeed to take ownership it can manage the port. Failsafe PMD wants to manage its sub-devices ports and does the same proces= s as Testpmd. Everything is ok. Neil approach: Testpmd want to manage the fail-safe port, therefore it just need to claim = ownership(set) and its pid will take as the owner identifier. Failsafe PMD wants to manage its sub-devices ports and does the same proces= s as Testpmd. But look these 2 entities run in same threads and there both can set the sa= me pid. -> problem! The second one just describe more scenario about more than one DPDK entitie= s which run from the same thread. > > > > So, no any optional owner becomes an owner, it depends in the specific > implementation. > > > > So if some "part of code" wants to manage a port exclusively and wants = to > take ownership of it to prevent other "part of code" to use this port : > > 1. Take ownership. > > 2. It should ask itself: Am I run in different threads\processes? If ye= s, it > should synchronize its port management. > > 3. Release ownership in the end. > > > > Remember that may be different "part of code"s running in the same > thread\threads\process\processes. > > > > Thanks, Matan. > > > > > > Regards > > > Neil > > > > > > }