From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id BE0B61B00B for ; Fri, 5 Jan 2018 15:25:09 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5706220ABC; Fri, 5 Jan 2018 09:25:09 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 05 Jan 2018 09:25:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=lJozDyjvKq5+92ltlDgpkINRwi FNuHfkJvusKsj8vWQ=; b=fPAUndguW/yB1SYXPB3c2HgTUwmSWga48zFBuSH5bM 2DK+l68vXlPTdmyh2WGqOvETz3EnDb615Wsj6Q0Sx9+xPtgmubK2Hw9hFTiUw32g wgVhdLASL6uUhB9Dh+eo1JXuivymj/WVh7L6C+mol6I+Fqw8jfrFK/OlnkbFr335 0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=lJozDy jvKq5+92ltlDgpkINRwiFNuHfkJvusKsj8vWQ=; b=eq2/I0wutdA1kEbXfWqMpB hF134CXt1XPpx4Dzile3Xy0GXJYqXdYWcoKNcoSP7yEi/6DO4AJzmKg/agupe5v/ KvmTkqCSicYy1yMix+MlGrN8l4sWxgAT6OWF0wMwK/SJ8Ae/xDUC2Q3gNkpO1xlN +1YK5ykVga9c87JQ+YV4srE4kNa41hGr3rCvCjjWcuxB2QUj67QNGsxQqyUsgqK1 n0OCQhARTPHAkQU6IWTLhKCifGlvdnRZxROizqsc0+P+7gYDahPfjRy26MnyVqbl BYng5JsJ+JsbHcAQHcAr+RnSyjFDpMsp1EgJoxlVniYxITQfG0aoKOccT5FuGVsg == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 0381224600; Fri, 5 Jan 2018 09:25:09 -0500 (EST) From: Thomas Monjalon To: Stephen Hemminger Cc: dev@dpdk.org, "Yang, Qiming" , Stephen Hemminger Date: Fri, 05 Jan 2018 15:24:48 +0100 Message-ID: <2251657.F6TyrEKx4p@xps> In-Reply-To: <20171013081215.6dbcab50@xeon-e3> References: <20170714183027.16021-1-stephen@networkplumber.org> <20171013081215.6dbcab50@xeon-e3> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC 01/14] ethdev: add link status read/write functions 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, 05 Jan 2018 14:25:10 -0000 Stephen, Qiming was suggesting a name change for the functions. What do you think? 13/10/2017 17:12, Stephen Hemminger: > On Wed, 11 Oct 2017 08:32:12 +0000 > "Yang, Qiming" wrote: > > > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger > > > Sent: Saturday, July 15, 2017 2:30 AM > > > To: dev@dpdk.org > > > Cc: Stephen Hemminger ; Stephen Hemminger > > > > > > Subject: [dpdk-dev] [RFC 01/14] ethdev: add link status read/write functions > > > > > > Many drivers are all doing copy/paste of the same code to atomicly update the > > > link status. Reduce duplication, and allow for future changes by having common > > > function for this. > > > > > > Signed-off-by: Stephen Hemminger > > > --- > > > lib/librte_ether/rte_ethdev.c | 36 ++++++++++++++++++++++++++++++++++++ > > > lib/librte_ether/rte_ethdev.h | 28 ++++++++++++++++++++++++++++ > > > 2 files changed, 64 insertions(+) > > > > > > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c index > > > a1b744704f3a..7532fc6b65f0 100644 > > > --- a/lib/librte_ether/rte_ethdev.c > > > +++ b/lib/librte_ether/rte_ethdev.c > > > @@ -1332,6 +1332,42 @@ rte_eth_link_get_nowait(uint8_t port_id, struct > > > rte_eth_link *eth_link) } > > > > > > int > > > +_rte_eth_link_update(struct rte_eth_dev *dev, > > > + const struct rte_eth_link *link) > > > +{ > > > + volatile struct rte_eth_link *dev_link = &(dev->data->dev_link); > > > + struct rte_eth_link old; > > > + > > > + RTE_BUILD_BUG_ON(sizeof(*link) != sizeof(uint64_t)); > > > + > > > + old = *dev_link; > > > + > > > + /* Only reason we use cmpset rather than set is > > > + * that on some architecture may use sign bit as a flag value. > > > + */ > > > + while (rte_atomic64_cmpset((volatile uint64_t *)dev_link, > > > + *(volatile uint64_t *)dev_link, > > > + *(const uint64_t *)link) == 0) > > > + continue; > > > + > > > + return (old.link_status == link->link_status) ? -1 : 0; } > > > + > > > +void _rte_eth_link_read(struct rte_eth_dev *dev, > > > + struct rte_eth_link *link) > > > +{ > > > + const uint64_t *src = (const uint64_t *)&(dev->data->dev_link); > > > + volatile uint64_t *dst = (uint64_t *)link; > > > + > > > + RTE_BUILD_BUG_ON(sizeof(*link) != sizeof(uint64_t)); > > > + > > > + /* Note: this should never fail since both destination and expected > > > + * values are the same and are a pointer from caller. > > > + */ > > > + rte_atomic64_cmpset(dst, *dst, *src); > > > +} > > > + > > > +int > > > rte_eth_stats_get(uint8_t port_id, struct rte_eth_stats *stats) { > > > struct rte_eth_dev *dev; > > > diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h index > > > f6837278521c..974657933f23 100644 > > > --- a/lib/librte_ether/rte_ethdev.h > > > +++ b/lib/librte_ether/rte_ethdev.h > > > @@ -2219,6 +2219,34 @@ void rte_eth_link_get(uint8_t port_id, struct > > > rte_eth_link *link); > > > */ > > > void rte_eth_link_get_nowait(uint8_t port_id, struct rte_eth_link *link); > > > > > > + > > > +/** > > > + * @internal > > > + * Atomically write the link status for the specific device. > > > + * It is for use by DPDK device driver use only. > > > + * User applications should not call it > > > + * > > > + * @param dev > > > + * Pointer to struct rte_eth_dev. > > > + * @param link > > > + * New link status value. > > > + * @return > > > + * -1 if link state has changed, 0 if the same. > > > + */ > > > +int _rte_eth_link_update(struct rte_eth_dev *dev, > > > + const struct rte_eth_link *link); > > > + > > This function is only do the atomically write, what do you think to change the function name to _rte_eth_atomic_write_link_status, > > Use name link_update makes me confused, and mix up it with dev_ops link_update. > > > +/** > > > + * @internal > > > + * Atomically read the link speed and status. > > > + * @param dev > > > + * Pointer to struct rte_eth_dev. > > > + * @param link > > > + * link status value. > > > + */ > > > +void _rte_eth_link_read(struct rte_eth_dev *dev, > > > + struct rte_eth_link *link); > > > + > > This name is also not very clear. I think change to _rte_eth_atomic_read_link_status will better. > > > /** > > > * Retrieve the general I/O statistics of an Ethernet device. > > > * > > > -- > > > 2.11.0 > > > > The first set of patches was just trying to combine multiple copies of same code. > Every place was doing same thing for atomic update.