From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 47E0C728A for ; Thu, 11 Jan 2018 13:40:10 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2018 04:40:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,344,1511856000"; d="scan'208";a="194142394" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by fmsmga006.fm.intel.com with ESMTP; 11 Jan 2018 04:40:08 -0800 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX108.ger.corp.intel.com (163.33.3.3) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 11 Jan 2018 12:40:07 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.236]) by irsmsx155.ger.corp.intel.com ([169.254.14.169]) with mapi id 14.03.0319.002; Thu, 11 Jan 2018 12:40:06 +0000 From: "Ananyev, Konstantin" To: Matan Azrad , Thomas Monjalon , Gaetan Rivet , "Wu, Jingjing" CC: "dev@dpdk.org" , Neil Horman , "Richardson, Bruce" Thread-Topic: [PATCH v2 2/6] ethdev: add port ownership Thread-Index: AQHTh5xreoY7ZC2VXUKPLFrmK4AmzKNtEwCwgABGVwCAATRvEA== Date: Thu, 11 Jan 2018 12:40:06 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772588627B12A@irsmsx105.ger.corp.intel.com> References: <1511870281-15282-1-git-send-email-matan@mellanox.com> <1515318351-4756-1-git-send-email-matan@mellanox.com> <1515318351-4756-3-git-send-email-matan@mellanox.com> <2601191342CEEE43887BDE71AB97725880E3B9D6@irsmsx105.ger.corp.intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjhkZGU5OTItOWU2Yi00MTg1LThmZmQtMzM3NGJjMzk0YjUyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IllMaG1wbVRKY1MrMkZNYlFIT3BaODcyaHB6RXZMbnlKUUdINGJCUW5HbmM9In0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 11 Jan 2018 12:40:12 -0000 Hi Matan, >=20 > Hi Konstantin >=20 > From: Ananyev, Konstantin, Wednesday, January 10, 2018 3:36 PM > > Hi Matan, > > > > Few comments from me below. > > BTW, do you plan to add ownership mandatory check in control path > > functions that change port configuration? >=20 > No. So it still totally voluntary usage and application nneds to be changed to exploit it? Apart from RTE_FOR_EACH_DEV() change proposed by Gaetan? >=20 >=20 > > Konstantin > > > > > -----Original Message----- > > > From: Matan Azrad [mailto:matan@mellanox.com] > > > Sent: Sunday, January 7, 2018 9:46 AM > > > To: Thomas Monjalon ; Gaetan Rivet > > > ; Wu, Jingjing > > > Cc: dev@dpdk.org; Neil Horman ; Richardson, > > > Bruce ; Ananyev, Konstantin > > > > > > Subject: [PATCH v2 2/6] ethdev: add port ownership > > > > > > The ownership of a port is implicit in DPDK. > > > Making it explicit is better from the next reasons: > > > 1. It will define well who is in charge of the port usage synchroniza= tion. > > > 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 application is not trying to use a port > > > which is already managed by fail-safe. > > > > > > A port owner is built from owner id(number) and owner name(string) > > > while the owner id must be unique to distinguish between two identica= l > > > 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 mechanism is synchronized for both the primary process threads an= d > > > the secondary processes threads to allow secondary process entity to > > > be a port owner. > > > > > > Add a sinchronized ownership mechanism to DPDK Ethernet devices to > > > avoid multiple management of a device by different DPDK entities. > > > > > > The current ethdev internal port management is not affected by this > > > feature. > > > > > > Signed-off-by: Matan Azrad > > > --- > > > doc/guides/prog_guide/poll_mode_drv.rst | 14 ++- > > > lib/librte_ether/rte_ethdev.c | 206 > > ++++++++++++++++++++++++++++++-- > > > lib/librte_ether/rte_ethdev.h | 89 ++++++++++++++ > > > lib/librte_ether/rte_ethdev_version.map | 12 ++ > > > 4 files changed, 311 insertions(+), 10 deletions(-) > > > > > > > > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c > > > b/lib/librte_ether/rte_ethdev.c index 684e3e8..0e12452 100644 > > > --- a/lib/librte_ether/rte_ethdev.c > > > +++ b/lib/librte_ether/rte_ethdev.c > > > @@ -70,7 +70,10 @@ > > > > > > static const char *MZ_RTE_ETH_DEV_DATA =3D "rte_eth_dev_data"; stru= ct > > > rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS]; > > > +/* ports data array stored in shared memory */ > > > static struct rte_eth_dev_data *rte_eth_dev_data; > > > +/* next owner identifier stored in shared memory */ static uint16_t > > > +*rte_eth_next_owner_id; > > > static uint8_t eth_dev_last_created_port; > > > > > > /* spinlock for eth device callbacks */ @@ -82,6 +85,9 @@ > > > /* spinlock for add/remove tx callbacks */ static rte_spinlock_t > > > rte_eth_tx_cb_lock =3D RTE_SPINLOCK_INITIALIZER; > > > > > > +/* spinlock for eth device ownership management stored in shared > > > +memory */ static rte_spinlock_t *rte_eth_dev_ownership_lock; > > > + > > > /* store statistics names and its offset in stats structure */ > > > struct rte_eth_xstats_name_off { > > > char name[RTE_ETH_XSTATS_NAME_SIZE]; @@ -153,14 +159,18 @@ > > enum { } > > > > > > static void > > > -rte_eth_dev_data_alloc(void) > > > +rte_eth_dev_share_data_alloc(void) > > > { > > > const unsigned flags =3D 0; > > > const struct rte_memzone *mz; > > > + const unsigned int data_size =3D RTE_MAX_ETHPORTS * > > > + sizeof(*rte_eth_dev_data); > > > > > > if (rte_eal_process_type() =3D=3D RTE_PROC_PRIMARY) { > > > + /* Allocate shared memory for port data and ownership */ > > > mz =3D rte_memzone_reserve(MZ_RTE_ETH_DEV_DATA, > > > - RTE_MAX_ETHPORTS * > > sizeof(*rte_eth_dev_data), > > > + data_size + sizeof(*rte_eth_next_owner_id) > > + > > > + sizeof(*rte_eth_dev_ownership_lock), > > > rte_socket_id(), flags); > > > } else > > > mz =3D rte_memzone_lookup(MZ_RTE_ETH_DEV_DATA); > > > @@ -168,9 +178,17 @@ enum { > > > rte_panic("Cannot allocate memzone for ethernet port > > data\n"); > > > > > > rte_eth_dev_data =3D mz->addr; > > > - if (rte_eal_process_type() =3D=3D RTE_PROC_PRIMARY) > > > - memset(rte_eth_dev_data, 0, > > > - RTE_MAX_ETHPORTS * > > sizeof(*rte_eth_dev_data)); > > > + rte_eth_next_owner_id =3D (uint16_t *)((uintptr_t)mz->addr + > > > + data_size); > > > + rte_eth_dev_ownership_lock =3D (rte_spinlock_t *) > > > + ((uintptr_t)rte_eth_next_owner_id + > > > + sizeof(*rte_eth_next_owner_id)); > > > > > > I think that might make rte_eth_dev_ownership_lock location not 4B > > aligned... >=20 > Where can I find the documentation about it? That's in your code above - data_size and mz_->addr are both at least 4B al= igned - rte_eth_dev_ownership_lock =3D mz->addr + data_size + 2; You can align it manually, but as discussed below it is probably easier to = group related fields into the same struct.=20 >=20 > > Why just not to put all data that you are trying to allocate as one chu= nck into > > the same struct: > > static struct { > > uint16_t next_owner_id; > > /* spinlock for eth device ownership management stored in share= d > > memory */ > > rte_spinlock_t dev_ownership_lock; > > rte_eth_dev_data *data; > > } rte_eth_dev_data; > > and allocate/use it everywhere? > > That would simplify allocation/management stuff. > > > I don't understand what exactly do you mean. ? > If you mean to group all in one struct like: >=20 > static struct { > uint16_t next_owner_id; > rte_spinlock_t dev_ownership_lock; > rte_eth_dev_data data[]; > } rte_eth_dev_share_data; >=20 > Just to simplify the addresses calculation above, Yep, that's exactly what I meant. As you said it would help with bulk allocation/alignment stuff, plus IMO it is better and easier to group several related global together - Improve code quality, will make it easier to read & maintain in future.=20 > It will change more code in ethdev relative to the old rte_eth_dev_data g= lobal array and will be more intrusive. > Stay it as is, focuses the change only here. Yes it would require few more changes, though I think it worth it. >=20 > I can just move the spinlock memory allocation to be at the beginning of = the memzone(to be sure about the alignment). >=20 > > It is good to see that now scanning/updating rte_eth_dev_data[] is lock > > protected, but it might be not very plausible to protect both data[] an= d > > next_owner_id using the same lock. >=20 > I guess you mean to the owner structure in rte_eth_dev_data[port_id]. > The next_owner_id is read by ownership APIs(for owner validation), so it = makes sense to use the same lock. > Actually, why not? Well to me next_owner_id and rte_eth_dev_data[] are not directly related. You may create new owner_id but it doesn't mean you would update rte_eth_de= v_data[] immediately. And visa-versa - you might just want to update rte_eth_dev_data[].name or .= owner_id. It is not very good coding practice to use same lock for non-related data s= tructures. >=20 > > In fact, for next_owner_id, you don't need a lock - just rte_atomic_t s= hould > > be enough. >=20 > I don't think so, it is problematic in next_owner_id wraparound and may c= omplicate the code in other places which read it. IMO it is not that complicated, something like that should work I think. /* init to 0 at startup*/ rte_atomic32_t *owner_id; int new_owner_id(void) { int32_t x; x =3D rte_atomic32_add_return(&owner_id, 1); if (x > UINT16_MAX) { rte_atomic32_dec(&owner_id); return -EOVERWLOW; } else=20 return x; =20 }=20 > Why not just to keep it simple and using the same lock? Lock is also fine, I just think it better be a separate one - that would pr= otext just next_owner_id. Though if you are going to use uuid here - all that probably not relevant a= ny more. >=20 > > Another alternative would be to use 2 locks - one for next_owner_id sec= ond > > for actual data[] protection. > > > > Another thing - you'll probably need to grab/release a lock inside > > rte_eth_dev_allocated() too. > > It is a public function used by drivers, so need to be protected too. > > >=20 > Yes, I thought about it, but decided not to use lock in next: > rte_eth_dev_allocated > rte_eth_dev_count > rte_eth_dev_get_name_by_port > rte_eth_dev_get_port_by_name > maybe more... As I can see in patch #3 you protect by lock access to rte_eth_dev_data[].= name (which seems like a good thing). So I think any other public function that access rte_eth_dev_data[].name sh= ould be protected by the same lock. >=20 > Don't you think it is just timing depended?(ask in the next moment and yo= u may get another answer) I don't see optional crash. >=20 > > > + > > > + if (rte_eal_process_type() =3D=3D RTE_PROC_PRIMARY) { > > > + memset(rte_eth_dev_data, 0, data_size); > > > + *rte_eth_next_owner_id =3D RTE_ETH_DEV_NO_OWNER + 1; > > > + rte_spinlock_init(rte_eth_dev_ownership_lock); > > > + } > > > } > > > > > > struct rte_eth_dev * > > > @@ -225,7 +243,7 @@ struct rte_eth_dev * > > > } > > > > > > if (rte_eth_dev_data =3D=3D NULL) > > > - rte_eth_dev_data_alloc(); > > > + rte_eth_dev_share_data_alloc(); > > > > > > if (rte_eth_dev_allocated(name) !=3D NULL) { > > > RTE_PMD_DEBUG_TRACE("Ethernet Device with name %s > > already > > > allocated!\n", @@ -253,7 +271,7 @@ struct rte_eth_dev * > > > struct rte_eth_dev *eth_dev; > > > > > > if (rte_eth_dev_data =3D=3D NULL) > > > - rte_eth_dev_data_alloc(); > > > + rte_eth_dev_share_data_alloc(); > > > > > > for (i =3D 0; i < RTE_MAX_ETHPORTS; i++) { > > > if (strcmp(rte_eth_dev_data[i].name, name) =3D=3D 0) @@ - > > 278,8 +296,12 > > > @@ struct rte_eth_dev * > > > if (eth_dev =3D=3D NULL) > > > return -EINVAL; > > > > > > - memset(eth_dev->data, 0, sizeof(struct rte_eth_dev_data)); > > > + rte_spinlock_lock(rte_eth_dev_ownership_lock); > > > + > > > eth_dev->state =3D RTE_ETH_DEV_UNUSED; > > > + memset(eth_dev->data, 0, sizeof(struct rte_eth_dev_data)); > > > + > > > + rte_spinlock_unlock(rte_eth_dev_ownership_lock); > > > return 0; > > > } > > > > > > @@ -294,6 +316,174 @@ struct rte_eth_dev * > > > return 1; > > > } > > > > > > +static int > > > +rte_eth_is_valid_owner_id(uint16_t owner_id) { > > > + if (owner_id =3D=3D RTE_ETH_DEV_NO_OWNER || > > > + (*rte_eth_next_owner_id > RTE_ETH_DEV_NO_OWNER && > > > + *rte_eth_next_owner_id <=3D owner_id)) { > > > + RTE_LOG(ERR, EAL, "Invalid owner_id=3D%d.\n", owner_id); > > > + return 0; > > > + } > > > + return 1; > > > +} > > > + > > > +uint16_t > > > +rte_eth_find_next_owned_by(uint16_t port_id, const uint16_t > > owner_id) > > > +{ > > > + while (port_id < RTE_MAX_ETHPORTS && > > > + (rte_eth_devices[port_id].state !=3D RTE_ETH_DEV_ATTACHED || > > > + rte_eth_devices[port_id].data->owner.id !=3D owner_id)) > > > + port_id++; > > > + > > > + if (port_id >=3D RTE_MAX_ETHPORTS) > > > + return RTE_MAX_ETHPORTS; > > > + > > > + return port_id; > > > +} > > > + > > > +int > > > +rte_eth_dev_owner_new(uint16_t *owner_id) { > > > + int ret =3D 0; > > > + > > > + rte_spinlock_lock(rte_eth_dev_ownership_lock); > > > + > > > + if (*rte_eth_next_owner_id =3D=3D RTE_ETH_DEV_NO_OWNER) { > > > + /* Counter wrap around. */ > > > + RTE_PMD_DEBUG_TRACE("Reached maximum number of > > Ethernet port owners.\n"); > > > + ret =3D -EUSERS; > > > + } else { > > > + *owner_id =3D (*rte_eth_next_owner_id)++; > > > + } > > > + > > > + rte_spinlock_unlock(rte_eth_dev_ownership_lock); > > > + return ret; > > > +} > > > + > > > +int > > > +rte_eth_dev_owner_set(const uint16_t port_id, > > > + const struct rte_eth_dev_owner *owner) > > > > As a nit - if you'll have rte_eth_dev_owner_set(port_id, old_owner, > > new_owner) > > - that might be more plausible for user, and would greatly simplify uns= et() > > part: > > just set(port_id, cur_owner, zero_owner); > > >=20 > How the user should know the old owner? By dev_owner_get() or it might have it stored somewhere already (or constructed on the fly in case of NO_OWNER). >=20 > > > +{ > > > + struct rte_eth_dev_owner *port_owner; > > > + int ret =3D 0; > > > + int sret; > > > + > > > + rte_spinlock_lock(rte_eth_dev_ownership_lock); > > > + > > > + if (!rte_eth_dev_is_valid_port(port_id)) { > > > + RTE_PMD_DEBUG_TRACE("Invalid port_id=3D%d\n", port_id); > > > + ret =3D -ENODEV; > > > + goto unlock; > > > + } > > > + > > > + if (!rte_eth_is_valid_owner_id(owner->id)) { > > > + ret =3D -EINVAL; > > > + goto unlock; > > > + } > > > + > > > + port_owner =3D &rte_eth_devices[port_id].data->owner; > > > + if (port_owner->id !=3D RTE_ETH_DEV_NO_OWNER && > > > + port_owner->id !=3D owner->id) { > > > + RTE_LOG(ERR, EAL, > > > + "Cannot set owner to port %d already owned by > > %s_%05d.\n", > > > + port_id, port_owner->name, port_owner->id); > > > + ret =3D -EPERM; > > > + goto unlock; > > > + } > > > + > > > + sret =3D snprintf(port_owner->name, > > RTE_ETH_MAX_OWNER_NAME_LEN, "%s", > > > + owner->name); > > > + if (sret < 0 || sret >=3D RTE_ETH_MAX_OWNER_NAME_LEN) { > > > > Personally, I don't see any reason to fail if description was truncated= ... > > Another alternative - just use rte_malloc() here to allocate big enough= buffer > > to hold the description. > > >=20 > But it is static allocation like in the device name, why to allocate it d= ifferently? Static allocation is fine by me - I just said there is probably no need to = fail if description provide by use will be truncated in that case. Though if used description is *that* important - rte_malloc() can help here= .=20 >=20 > > > + memset(port_owner->name, 0, > > RTE_ETH_MAX_OWNER_NAME_LEN); > > > + RTE_LOG(ERR, EAL, "Invalid owner name.\n"); > > > + ret =3D -EINVAL; > > > + goto unlock; > > > + } > > > + > > > + port_owner->id =3D owner->id; > > > + RTE_PMD_DEBUG_TRACE("Port %d owner is %s_%05d.\n", port_id, > > > + owner->name, owner->id); > > > + > > > > As another nit - you can avoid all these gotos by restructuring code a = bit: > > > > rte_eth_dev_owner_set(const uint16_t port_id, const struct > > rte_eth_dev_owner *owner) { > > rte_spinlock_lock(...); > > ret =3D _eth_dev_owner_set_unlocked(port_id, owner); > > rte_spinlock_unlock(...); > > return ret; > > } > > > Don't you like gotos? :) Not really :) > I personally use it only in error\performance scenarios. Same here - prefer to avoid them if possible. > Do you think it worth the effort? IMO - yes, well structured code is much easier to understand and maintain. Konstantin