From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0084.outbound.protection.outlook.com [104.47.2.84]) by dpdk.org (Postfix) with ESMTP id E156C4C57 for ; Thu, 30 Nov 2017 16:43:01 +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=82XmOh/rXimd0VjiZrQOE4LAI1pPhR1GbK2WjPJE3NU=; b=enEotWnSZZL6m7AraCyfWmkc8hr1f95nOFINwjdDKfJL47SxwXmwT5ZxXBrg+mh7qLDji4SKB6UOMDRVCNmY75u3QOWJC4Y9leusRCxifsqDEctR9tGg12TWf/skQsMq2QvvUtY1i+kRi16JoMSSGcAVVCde75OsYn0wJPF52zE= Received: from HE1PR0502MB3659.eurprd05.prod.outlook.com (10.167.127.17) by HE1PR0502MB3660.eurprd05.prod.outlook.com (10.167.127.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Thu, 30 Nov 2017 15:43:00 +0000 Received: from HE1PR0502MB3659.eurprd05.prod.outlook.com ([fe80::55fd:2b8a:f957:6e53]) by HE1PR0502MB3659.eurprd05.prod.outlook.com ([fe80::55fd:2b8a:f957:6e53%13]) with mapi id 15.20.0260.007; Thu, 30 Nov 2017 15:43:00 +0000 From: Matan Azrad To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= CC: Neil Horman , Thomas Monjalon , Jingjing Wu , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership Thread-Index: AQHTaEBDeXaioloFskiHncvIK1YNTKMs3xqAgAANj4CAAAb0QIAAFmqAgAADMlA= Date: Thu, 30 Nov 2017 15:43:00 +0000 Message-ID: References: <1511870281-15282-1-git-send-email-matan@mellanox.com> <1511870281-15282-3-git-send-email-matan@mellanox.com> <20171130123611.GA20914@hmswarspite.think-freely.org> <20171130132443.4htutb5gpktcshgh@bidouze.vm.6wind.com> <20171130150949.tguod6p6s3amxvyq@bidouze.vm.6wind.com> In-Reply-To: <20171130150949.tguod6p6s3amxvyq@bidouze.vm.6wind.com> Accept-Language: en-US, he-IL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.47.165.251] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0502MB3660; 6:YuJfCjcnKaYvITZFPOGdwXc0ZCYJXH17binBaSdjSO2fGeA8GmXIkrv4pzfL4VnJFntdcwXlXijoRKW8VAQYdfaLZ+U7+FmqCoVWQYCynfnc6vCQpD9YVSEyEYRLzHUc0hxxlOY5jCkS3BqPUjqCXYR5bOD7gm/mLZMGtOKoGt7yfpN1Fdz9e97qv/POlmAoNSJyUV7Ycc4KzJmuWL/nRZ3fFBWTokMls5spJB51Iq4Q+7/azaPxhv2p1Xy8UNYp6xueQef8zs+yC2u9kcAICSDmW/MIVXEJAF9M8dvQg2te4OtXmbf6eblKEQ57sBguY8Jb6GGDwMYKaw6NxHbhIQ+Q43P8c7FZfJAktl2V+HU=; 5:Spm0lVzWepIYRB834Er2dPg0xdS8W4Ezf1irvUYRgbabJVrODBjAAQ80Jux4W9nywcPtX1v8FzF+nrU8eamhNhP/da1oeuSBkXMpTEapQ9jebIOwoy+fgTiQBzDc4PL9GQjq0y1NkVbPs1+h1dfiFeSJLU1y3lidvHuHmTprxP0=; 24:RE8p/NgLQ2MBki3x2xj3c4C13vsAGFbs3Mqe3FYnv9i2l/vbVd4rmWZhErZmE8r0O8IxvdotEwIR2DDvEcZWZQfvY2fmdK7UzQpeCtsqXbI=; 7:sdGZHP53geHevIUotjRznC8okgPg4So0zFmdgKM9mB7TarICvdh8+mofwJR+CRY5IBWEjPaQRjf6VhJulUtqL5JyOXRoA684aG0OCNVEDiTAB7oH4AWgnV2CyLaRQHc2dOVmnF37VGqAkS5TsGOdkqNWq76CQjiSdzFOFeVLvIy4XjU1nngDF+i80Y0kW744HoA0UZh1VOJlwzU0/31MlRjDK3JhmPUhaQ7TWBBudPI8pY5qzQb7qKNuV7ZVgv4q x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b93a38a6-86a8-407d-dd9d-08d53809092c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:HE1PR0502MB3660; x-ms-traffictypediagnostic: HE1PR0502MB3660: authentication-results: spf=none (sender IP is ) smtp.mailfrom=matan@mellanox.com; x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(278428928389397)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:HE1PR0502MB3660; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR0502MB3660; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(39860400002)(346002)(376002)(189002)(13464003)(53754006)(24454002)(199003)(33656002)(189998001)(478600001)(101416001)(53936002)(6246003)(305945005)(7736002)(81166006)(5660300001)(86362001)(3280700002)(2900100001)(6506006)(81156014)(5250100002)(25786009)(76176010)(54356010)(50986010)(68736007)(6436002)(8676002)(2906002)(3660700001)(7696005)(66066001)(8936002)(4326008)(99286004)(102836003)(53546010)(93886005)(3846002)(55016002)(6116002)(229853002)(97736004)(105586002)(6916009)(9686003)(74316002)(54906003)(2950100002)(14454004)(106356001)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0502MB3660; H:HE1PR0502MB3659.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: b93a38a6-86a8-407d-dd9d-08d53809092c X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 15:43:00.1183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0502MB3660 Subject: Re: [dpdk-dev] [PATCH 2/5] 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, 30 Nov 2017 15:43:02 -0000 Hi Gaetan > -----Original Message----- > From: Ga=EBtan Rivet [mailto:gaetan.rivet@6wind.com] > Sent: Thursday, November 30, 2017 5:10 PM > To: Matan Azrad > Cc: Neil Horman ; Thomas Monjalon > ; Jingjing Wu ; > dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership >=20 > On Thu, Nov 30, 2017 at 02:30:20PM +0000, Matan Azrad wrote: > > Hi all > > > > > -----Original Message----- > > > From: Ga=EBtan Rivet [mailto:gaetan.rivet@6wind.com] > > > Sent: Thursday, November 30, 2017 3:25 PM > > > To: Neil Horman > > > Cc: Matan Azrad ; Thomas Monjalon > > > ; Jingjing Wu ; > > > dev@dpdk.org > > > Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership > > > > > > Hello Matan, Neil, > > > > > > I like the port ownership concept. I think it is needed to clarify > > > some operations and should be useful to several subsystems. > > > > > > This patch could certainly be sub-divided however, and your current > > > 1/5 should probably come after this one. > > > > Can you suggest how to divide it? > > >=20 > Adding first the API to add / remove owners, then in a second patch set /= get > / unset. (by the way, remove / delete is pretty confusing, I'd suggest > renaming those.) You can also separate the introduction of the new owner- > wise iterator. > > Ultimately, you are the author, it's your job to help us review your work= . >=20 When you suggest improvement I think you need to propose another method\ide= a. The author probably thought about it and arrived to his conclusions. Exactly as you are doing now in naming. If you have a specific question, I'm here to answer :)=20 I agree with unset name instead of remove, will change it in V2. =20 > > 1/5 could be actually outside of this series, it is just better > > behavior to use the right function to do release port :) > > > > > > > > Some comments inline. > > > > > > On Thu, Nov 30, 2017 at 07:36:11AM -0500, Neil Horman wrote: > > > > On Tue, Nov 28, 2017 at 11:57:58AM +0000, Matan Azrad wrote: > > > > > The ownership of a port is implicit in DPDK. > > > > > Making it explicit is better from the next reasons: > > > > > 1. It may be convenient for multi-process applications to know wh= ich > > > > > process is in charge of a port. > > > > > 2. A library could work on top of a port. > > > > > 3. A port can work on top of another port. > > > > > > > > > > Also in the fail-safe case, an issue has been met in testpmd. > > > > > We need to check that the user is not trying to use a port which > > > > > is already managed by fail-safe. > > > > > > > > > > Add ownership mechanism to DPDK Ethernet devices to avoid > > > > > multiple management of a device by different DPDK entities. > > > > > > > > > > A port owner is built from owner id(number) and owner > > > > > name(string) while the owner id must be unique to distinguish > > > > > between two identical entity instances and the owner name can be > any name. > > > > > The name helps to logically recognize the owner by different > > > > > DPDK entities and allows easy debug. > > > > > Each DPDK entity can allocate an owner unique identifier and can > > > > > use it and its preferred name to owns valid ethdev ports. > > > > > Each DPDK entity can get any port owner status to decide if it > > > > > can manage the port or not. > > > > > > > > > > The current ethdev internal port management is not affected by > > > > > this feature. > > > > > > > > > > > The internal port management is not affected, but the external > > > interface is, however. In order to respect port ownership, > > > applications are forced to modify their port iterator, as shown by yo= ur > testpmd patch. > > > > > > I think it would be better to modify the current RTE_ETH_FOREACH_DEV > > > to call RTE_FOREACH_DEV_OWNED_BY, and introduce a default owner > that > > > would represent the application itself (probably with the ID 0 and > > > an owner string ""). Only with specific additional configuration > > > should this default subset of ethdev be divided. > > > > > > This would make this evolution seamless for applications, at no cost > > > to the complexity of the design. > > > > As you can see in patch code and in testpmd example I added option to > > iterate over all valid ownerless ports which should be more relevant by > owner_id =3D 0. > > So maybe the RTE_ETH_FOREACH_DEV should be changed to run this by > the new iterator. >=20 > That is precisely what I am suggesting. > Ideally, you should not have to change anything in testpmd, beside some b= ug > fixing regarding port iteration to avoid those with a specific owner. >=20 > RTE_ETH_FOREACH_DEV must stay valid, and should iterate over ownerless > ports (read: port owned by the default owner). >=20 > > By this way current applications don't need to build their owners but t= he > ABI will be broken. > > >=20 > ABI is broken anyway as you will add the owner to rte_eth_dev_data. >=20 It is not, rte_eth_dev_data is internal. > > Actually, I think the old iterator RTE_ETH_FOREACH_DEV should be > > unexposed or just removed, >=20 > I don't think so. Using RTE_ETH_FOREACH_DEV should allow keeping the > current behavior of iterating over ownerless ports. Applications that do = not > care for this API should not have to change anything to their code. >=20 If we will break the ABI later users can use RTE_ETH_FOREACH_DEV_OWNED_BY(p= ,0) to do it. RTE_ETH_FOREACH_DEV will be unnecessary anymore but maybe is too = much to applications to change also the API. I can agree with it. > > also the DEFFERED state should be removed, >=20 > Of course. >=20 > > I don't really see any usage to iterate over all valid ports by DPDK en= tities > different from ethdev itself. > > I just don't want to break it now. > > >=20 > [snip] >=20 > -- > Ga=EBtan Rivet > 6WIND