From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr60067.outbound.protection.outlook.com [40.107.6.67]) by dpdk.org (Postfix) with ESMTP id BCA031B32B for ; Thu, 18 Jan 2018 15:52:22 +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=kEWkTm7S7HPaBryFAQC+UT6+m4CKGuDFIaaSmN7Lzhw=; b=UuKEpIj7oBFGpZHBnE9X0hUTnk44WaQMygv0tz93WPSLzyx6rT9lfwf0XxoineVffKH8iQnjp0u7BYDtd8s2fasf7KHGdfcEQ7BQL7V9m/ET/VL1v9rroaVUPBwurJMF2CLRUyzWtNm3Me6/HReBrWU3C41YTqsgmGf7IjOkUXQ= Received: from AM6PR0502MB3797.eurprd05.prod.outlook.com (52.133.21.26) by AM6PR0502MB3880.eurprd05.prod.outlook.com (52.133.21.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Thu, 18 Jan 2018 14:52:20 +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; Thu, 18 Jan 2018 14:52:20 +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+CABQwJgIAAEk3ggABinoCAANUIAIAAxQGAgAAGCnCAAQnKAIAAAmNwgAApSwCAAC0cwIABWjcAgAALDRA= Date: Thu, 18 Jan 2018 14:52:20 +0000 Message-ID: References: <2601191342CEEE43887BDE71AB9772588627DC25@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772588627DE30@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772588627E954@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772588627EE60@irsmsx105.ger.corp.intel.com> <20180117140020.GA5432@hmswarspite.think-freely.org> <20180118132056.GB1622@hmswarspite.think-freely.org> In-Reply-To: <20180118132056.GB1622@hmswarspite.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: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR0502MB3880; 7:6aD88GeXfOHmAXShOhPTZ2rGWAqqzzQ5xHVtqgePNQ11fevbrGIDVzHcZ1wpW4XZyXc6MWH0XKU3I/6fKa6+QEDr5Lp+BFBIuDEgNSFCPamkkH7AvF+svfqm3S2uozyW7oSXf+O5LwK5W+nxUz1YQ1Vu+c7r/DpjYMRBC/GwRgw+qHbWmyAK8xa1arIxjQKLVzeW66ZFnPDaEw6yBWuObOzmstPrrRkjirMO0iRYr05BtoVcBhYikfvvBtusGGYv x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 93ac1da5-10a0-4d5e-9e2d-08d55e8313bd 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:AM6PR0502MB3880; x-ms-traffictypediagnostic: AM6PR0502MB3880: 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)(3231023)(944501161)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041268)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM6PR0502MB3880; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM6PR0502MB3880; x-forefront-prvs: 05568D1FF7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(346002)(39380400002)(376002)(189003)(199004)(74316002)(4326008)(7736002)(305945005)(3846002)(106356001)(33656002)(25786009)(2900100001)(6116002)(99286004)(97736004)(7696005)(93886005)(5660300001)(26005)(66066001)(2950100002)(76176011)(102836004)(54906003)(59450400001)(6506007)(316002)(6916009)(478600001)(8936002)(81166006)(68736007)(55016002)(9686003)(6436002)(53936002)(229853002)(81156014)(86362001)(8676002)(5250100002)(6246003)(14454004)(3280700002)(3660700001)(105586002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR0502MB3880; 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: +pDWj5vuQ0Xg66aZpOatha/un3Xh3kpsKRmslFfPI/mZIKL6mN2E4/xJK5X/KvtCgepHmV7GZ9XaktbY4KJLtA== 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: 93ac1da5-10a0-4d5e-9e2d-08d55e8313bd X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2018 14:52:20.6463 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0502MB3880 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: Thu, 18 Jan 2018 14:52:23 -0000 Hi Neil From: Neil Horman, Thursday, January 18, 2018 3:21 PM > On Wed, Jan 17, 2018 at 05:58:07PM +0000, Matan Azrad wrote: > > > > Hi Neil > > > > From: Neil Horman, Wednesday, January 17, 2018 4:00 PM > > > On Wed, Jan 17, 2018 at 12:05:42PM +0000, Matan Azrad wrote: > > > Matan is correct here, there is no way to preform parallel set > > > operations using just and atomic variable here, because multiple > > > reads of next_owner_id need to be preformed while it is stable. > > > That is to say rte_eth_next_owner_id must be compared to > > > RTE_ETH_DEV_NO_OWNER and owner_id in rte_eth_is_valid_owner_id. > If > > > you were to only use an atomic_read on such a variable, it could be > > > incremented by the owner_new function between the checks and an > > > invalid owner value could become valid because a third thread > > > incremented the next value. The state of next_owner_id must be kept > > > stable during any validity checks > > > > > > That said, I really have to wonder why ownership ids are really > > > needed here at all. It seems this design could be much simpler with > > > the addition of a per- port lock (and optional ownership record). > > > The API could consist of three > > > operations: > > > > > > ownership_set > > > ownership_tryset > > > ownership_release > > > ownership_get > > > > > > > > > The first call simply tries to take the per-port lock (blocking if > > > its already > > > locked) > > > > > > > Per port lock is not good because the ownership mechanism must to be > synchronized with the port creation\release. > > So the port creation and port ownership should use the same lock. > > > In what way do you need to synchronize with port creation? The port release zeroes the data field of the port owner, so it should be s= ynchronized with the ownership APIs. The port creation should be synchronized with the port release. > If a port has not > yet been created, then by definition the owner must be the thread calling > the create function. No, the owner can be any dpdk entity. (an application - multi\single thread= s\proccesses, a PMD, a library). So the port allocation(usually done from the port PMD by one thread from on= e process) just should to allocate a port. > If you are concerned about the mechanics of the port > data structure (i.e. the fact that rte_eth_devices is statically allocate= d, you > can add a lock structure to the rte_eth_dev struct and initialize it stat= ically > with > RTE_SPINLOCK_INITAIZER() >=20 The lock should be in shared memory to allow secondary processes entities t= o take owner safely. =20 > > I didn't find precedence for blocking function in ethdev. > > > Then perhaps we don't need that api call. Perhaps ownership_tryset is > enough. > As I already did :) =20 > > > The second call is a non-blocking version of the first > > > > > > The third unlocks the port, allowing others to take ownership > > > > > > The fourth returns whatever ownership record you want to encode with > > > the lock. > > > > > > The addition of all this id checking seems a bit overcomplicated > > > > You miss the identification of the owner - we want to allow info of the > owner for printing and easy debug. > > And it is makes sense to manage the owner uniqueness by unique ID. > > > I specifically pointed that out above. There is no reason an owernship r= ecord > couldn't be added to the rte_eth_dev structure. >=20 Sorry, don't understand why. > > The API already discussed a lot in the previous version, Do you really = want, > now, to open it again? > > > What I want is the most useful and elegant ownership API available. If y= ou > think what you have is that, so be it. I only bring this up because the = amount > of debate you and Konstantin have had over lock safety causes me to > wonder if this isn't an overly complex design. I think the complex design is in secondary\primary processes, not in the cu= rrent port ownership. I think there is some work to do there regardless port ownership. I think also there is some work in progress for it. Thanks, a lot. >=20 > Neil >=20 >=20 > > > Neil > > > >