From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr60054.outbound.protection.outlook.com [40.107.6.54]) by dpdk.org (Postfix) with ESMTP id CA4962BF4 for ; Fri, 19 Jan 2018 08:14:19 +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=0/5s88Y1xyohHMIqS751/SWvlG/E6aQkXKJC2TcKx3I=; b=Gy4bbdF4q+xZGldndEB63ykH0fHU3BSZgbcvKkODZ7uXUNYjHqyKHMMgDwVW7L4EhsvDxO8qjlZcxaAFbIxeG6rQPOdztGEQZ4y/UVkgRsBNpfsLcWEK7TD1FEINE7hsTVFkm+WGI0IIuXD5/EQXTXLGPRaqlEpvSMYiefLgx8Y= Received: from AM6PR0502MB3797.eurprd05.prod.outlook.com (52.133.21.26) by AM6PR0502MB3894.eurprd05.prod.outlook.com (52.133.21.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Fri, 19 Jan 2018 07:14:17 +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 07:14:17 +0000 From: Matan Azrad To: Neil Horman CC: "Ananyev, Konstantin" , Thomas Monjalon , Gaetan Rivet , "Wu, Jingjing" , "dev@dpdk.org" , "Richardson, Bruce" Thread-Topic: [PATCH v2 2/6] ethdev: add port ownership Thread-Index: AQHTihf/M9xg8LYorUSRFqZtTc27hqNtNdVQgAFomACAAAOCwIAAuwQAgABvY+CABQwJgIAAEk3ggABinoCAANUIAIAAxQGAgAAGCnCAAQnKAIAAAmNwgAApSwCAADKGAIABUdOAgAAMD/CAADKfgIAAAbBAgAAcRwCAABk1cIAAXAAAgABVCKA= Date: Fri, 19 Jan 2018 07:14:17 +0000 Message-ID: References: <2601191342CEEE43887BDE71AB9772588627EE60@irsmsx105.ger.corp.intel.com> <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> In-Reply-To: <20180119014122.GA3516@neilslaptop.think-freely.org> 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; AM6PR0502MB3894; 7:559F09QAS83FaygimMdd81HiHW3LEZwKgTGAJRrmLh3eC5kbMjDz7V+gz/Z2aDkhfliZshM0yAZ/uToDi6fvkEcMLUYJTCZdAdzMggoFOjksIED7zWIFJZHcooKI0aeuZ3jBUNvhTX+yMTWeM1kEU5Vr/ixHsdouOLjeidJCH9GpiVIJbUo6hQJz5SGFqaZbuTSfiptvCOAJcuY+P9rpHw3mmUydPbG0uyCaL/PoBFSWuMks1r7ItjEYf+2+yUQx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d57da560-2797-4db3-a709-08d55f0c4105 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:AM6PR0502MB3894; x-ms-traffictypediagnostic: AM6PR0502MB3894: 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)(8121501046)(5005006)(3002001)(3231023)(2400073)(944501161)(93006095)(93001095)(10201501046)(6055026)(6041268)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:AM6PR0502MB3894; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM6PR0502MB3894; x-forefront-prvs: 0557CBAD84 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(39380400002)(366004)(199004)(189003)(6506007)(14454004)(86362001)(33656002)(99286004)(54906003)(68736007)(6916009)(2950100002)(26005)(74316002)(316002)(105586002)(3280700002)(3660700001)(5660300001)(2906002)(3846002)(25786009)(6116002)(59450400001)(102836004)(478600001)(305945005)(53936002)(7736002)(55016002)(9686003)(76176011)(6436002)(106356001)(8936002)(4326008)(66066001)(7696005)(97736004)(229853002)(5250100002)(6246003)(2900100001)(93886005)(81156014)(8676002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR0502MB3894; H:AM6PR0502MB3797.eurprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: z23aZAegcNy/ozGXefyPegMa9VsF+6lxcgvPHawXU/TNlbQ/NaESY9Air5bK5HzTTKp11dzVzfZDFlUzrO9nNA== 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: d57da560-2797-4db3-a709-08d55f0c4105 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2018 07:14:17.6210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0502MB3894 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 07:14:20 -0000 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 i= f you > want) which should be fixed? > > > > > > sorry for that, I think it is not relevant continue discussion i= f we are > not fully understand each other. So let's start from the beginning "with = good > order :)" by answering the above questions. >=20 >=20 > Sure, this seems like a reasonable way to level set. >=20 > 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 resou= rce > 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 w= ith > a success or error indicator to let the caller know if access is granted. >=20 > If I were to codify this port ownership api in pseudo code it would look > something like this: >=20 > struct rte_eth_dev { >=20 > < eth dev bits > > rte_spinlock_t owner_lock; > bool locked; > pid_t owner_pid; > } >=20 >=20 > bool rte_port_claim_ownership(struct rte_eth_dev *dev) { > bool ret =3D false; >=20 > 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; > } >=20 >=20 > bool rte_port_release_ownership(rte_eth_dev *dev) { >=20 > 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; > } >=20 > bool rte_port_is_owned_by(struct rte_eth_dev *dev, pid_t pid) { > bool ret =3D false; >=20 > 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; > } >=20 > 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 po= rt) > despite its ownership object. >=20 > 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 exclusi= ve > 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 an= y > port unless it calls owner_new again. >=20 > Does that help clarify my position? Now I fully understand you, thanks for your patience. So, you are missing here one of the main ideas of my port ownership intenti= on. There are options for X>1 different uncoordinated owners running in the sam= e thread. For example: 1. Think about Testpmd control commands that call to failsafe port devop wh= ich call to its sub-devices devops, while tespmd is different owner(control= ling failsafe-port) and failsafe is a different owner(controlling all its s= ub-devices ports), There are both run control commands in the same thread a= nd there are uncoordinated! 2. Interrupt callbacks that anyone can register to them and all will run b= y the DPDK host thread.=20 So, no any optional owner becomes an owner, it depends in the specific imp= lementation. So if some "part of code" wants to manage a port exclusively and wants to t= ake 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 yes, i= t should synchronize its port management.=20 3. Release ownership in the end. Remember that may be different "part of code"s running in the same thread\t= hreads\process\processes. Thanks, Matan. >=20 > Regards > Neil >=20 > }