From: Stephen Hemminger <stephen@networkplumber.org>
To: Andrew Rybchenko <arybchenko@solarflare.com>
Cc: <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 02/15] ethdev: add linkstatus get/set helper functions
Date: Sat, 6 Jan 2018 06:24:56 -0800 [thread overview]
Message-ID: <20180106062456.1d1eba50@xeon-e3> (raw)
In-Reply-To: <cef9e4d6-f2b2-f2e4-3426-7f7cdc78be4a@solarflare.com>
On Sat, 6 Jan 2018 13:49:50 +0300
Andrew Rybchenko <arybchenko@solarflare.com> wrote:
> On 01/06/2018 04:06 AM, Stephen Hemminger wrote:
> > Many drivers are all doing copy/paste of the same code to atomically
> > update the link status. Reduce duplication, and allow for future
> > changes by having common function for this.
> >
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > lib/librte_ether/rte_ethdev.c | 35 +++++++++++++++++++++++++++++++++++
> > lib/librte_ether/rte_ethdev.h | 28 ++++++++++++++++++++++++++++
> > 2 files changed, 63 insertions(+)
> >
> > diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> > index 27b52131ef01..4897e1dcda14 100644
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -1495,6 +1495,41 @@ rte_eth_link_get_nowait(uint16_t port_id, struct rte_eth_link *eth_link)
> > }
> > }
> >
> > +int
> > +_rte_eth_linkstatus_set(struct rte_eth_dev *dev,
> > + const struct rte_eth_link *new_link)
> > +{
> > + volatile uint64_t *dev_link
> > + = (volatile uint64_t *)&(dev->data->dev_link);
> > + union {
> > + uint64_t val64;
> > + struct rte_eth_link link;
> > + } orig;
> > +
> > + RTE_BUILD_BUG_ON(sizeof(*new_link) != sizeof(uint64_t));
> > +
> > + orig.val64 = rte_atomic64_exchange(dev_link,
> > + *(const uint64_t *)new_link);
> > +
> > + return (orig.link.link_status == new_link->link_status) ? -1 : 0;
>
> It looks like it contradicts to the function description saying that 0 is
> returned if link status is the same.
Looks like a mismatch in original code. Will fix that.
> > +}
> > +
> > +void
> > +_rte_eth_linkstatus_get(const 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);
>
> As I understand nobody says that *link (i.e. *dst) is initialized, so it
> could be
> reading uninitialized value. Not fatal, but not good as well.
> May be it is better to use something like rte_atomic64_read().
>
link is a pointer passed in by the caller.
If it is uninitialized, that is still ok since it will have some value.
The different question is that since is almost backwards use of cmpset,
not sure if processor really guarantees atomic read of source pointer.
But this code is cloned from original in Intel driver so it is bug
for bug compatiable!
next prev parent reply other threads:[~2018-01-06 14:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-06 1:06 [dpdk-dev] [PATCH v2 00/15] common ethdev linkstatus functions Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 01/15] eal: introduce atomic exchange operation Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 02/15] ethdev: add linkstatus get/set helper functions Stephen Hemminger
2018-01-06 10:49 ` Andrew Rybchenko
2018-01-06 14:24 ` Stephen Hemminger [this message]
2018-01-06 14:35 ` Andrew Rybchenko
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 03/15] virtio: use eth_linkstatus_set Stephen Hemminger
2018-01-06 3:10 ` Tiwei Bie
2018-01-08 17:03 ` Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 04/15] vmxnet3: use rte_eth_linkstatus_set Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 05/15] dpaa2: " Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 06/15] nfp: use rte_eth_linkstatus functions Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 07/15] e1000: use rte_eth_linkstatus helpers Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 08/15] ixgbe: use rte_eth_linkstatus functions Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 09/15] sfc: use new " Stephen Hemminger
2018-01-06 11:10 ` Andrew Rybchenko
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 10/15] i40e: use " Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 11/15] liquidio: use _rte_eth_linkstatus_set Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 12/15] thunderx: " Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 13/15] szedata: " Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 14/15] octeontx: use rte_eth_linkstatus_set Stephen Hemminger
2018-01-06 1:06 ` [dpdk-dev] [PATCH v2 15/15] enic: use _rte_eth_linkstatus_set Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180106062456.1d1eba50@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).