From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f68.google.com (mail-pl0-f68.google.com [209.85.160.68]) by dpdk.org (Postfix) with ESMTP id 482ED2904 for ; Fri, 5 Jan 2018 21:15:10 +0100 (CET) Received: by mail-pl0-f68.google.com with SMTP id d21so3672074pll.1 for ; Fri, 05 Jan 2018 12:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=3mRtOvlx2T34dXqmnROzBZoNqUPFl8VsL+pJK4t4Okc=; b=yhv/KBSo0VrH3fe50brcM9+MmWgNb1oKPHXmZX9qxBNlybQ7i5+OkWVxudIBYt3OJt jKufsQ9YuhFR25XCL0JmpfwwKuIW9F4IZrOdKSGQ8aXMEJoxX/U9kKBDuNPGx/5ycNnx L/3qD1a8OX+NbCqbn+QfnBZ3yIrLXuFmrMWaSQTFSFG6cjQ3KiGl84h03Ju5VvWKzUNz iBbYgyjo5hWnFSmvO/vUSydwZaYiZHw41z8OXpgqj838BHBMnFf3OlMC6kGdzrnGJx9e SeE04vafbF0Sm8NAQ/q+TjW8kS48x2tjVoJMawZxlWEwYV71UZIdBtmPnCQN9rlxLgIt ygmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3mRtOvlx2T34dXqmnROzBZoNqUPFl8VsL+pJK4t4Okc=; b=ZMM8sf2hhjwTaSYaaW+vZAx4jhg6csbwRsTQ6WI6yqTpab69U2DF2IkB9HtPHuYPBw Hd3DMMTcQkWmhZ/yoejcphG7kcvCyOXsp/5hsAXCqtruEgvQk6yKjkxwMvTwpPMRrOnd o5zEJG58G/qHmaLWR8zH23GcP+u89/J6uQkxdMe61AhAuOJeIDBe1s1iUkKuB8lGq+tE hrH1frCj86WpwNq9f7aX8vei1xC0jW6pj2xRDe3Tw1s3ReZiDXKz3pmTTVMGBdJE927z ycQU0aTba/lL+I/KwS5W7BP7AhjcqN200CFv0vKhlsAawGg2yZdYTu70/Z02sahLd54E 9OPQ== X-Gm-Message-State: AKGB3mLNKdVgVJ5jioVLLpHir5P1n0hMqwCFIlVZ0C7cUlxeNkzuRTnP pHU0n2HRpkqJ7LJ/9RNO8rBc/g== X-Google-Smtp-Source: ACJfBov8a8PLIdHQJjVhlj4tw7GVuZGPMaPSYu3LIdaCa+PrsZZl9R0AnEdkCAMZ6M6Uulp5BvtDZg== X-Received: by 10.84.218.4 with SMTP id q4mr4304534pli.123.1515183309284; Fri, 05 Jan 2018 12:15:09 -0800 (PST) Received: from xeon-e3 (204-195-18-133.wavecable.com. [204.195.18.133]) by smtp.gmail.com with ESMTPSA id o10sm11897753pgn.70.2018.01.05.12.15.08 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 05 Jan 2018 12:15:08 -0800 (PST) Date: Fri, 5 Jan 2018 12:15:03 -0800 From: Stephen Hemminger To: Thomas Monjalon Cc: dev@dpdk.org, "Yang, Qiming" , Stephen Hemminger Message-ID: <20180105121503.6fb6dff4@xeon-e3> In-Reply-To: <2251657.F6TyrEKx4p@xps> References: <20170714183027.16021-1-stephen@networkplumber.org> <20171013081215.6dbcab50@xeon-e3> <2251657.F6TyrEKx4p@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 20:15:10 -0000 On Fri, 05 Jan 2018 15:24:48 +0100 Thomas Monjalon wrote: > 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. I would just change the name to linkstatsus update. Also since writes of unsigned long are guaranteed atomic, the code could be optimized on 64bit platforms.