From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Mattias Rönnblom" <hofors@lysator.liu.se>,
"Stephen Hemminger" <stephen@networkplumber.org>
Cc: "Ferruh Yigit" <ferruh.yigit@amd.com>,
"Thomas Monjalon" <thomas@monjalon.net>,
"Andrew Rybchenko" <andrew.rybchenko@oktetlabs.ru>,
dev@dpdk.org, stable@dpdk.org,
"Mattias Rönnblom" <mattias.ronnblom@ericsson.com>
Subject: RE: [PATCH] ethdev: document that stats reset APIs are not thread-safe
Date: Mon, 29 Apr 2024 08:20:13 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9F3FF@smartserver.smartshare.dk> (raw)
In-Reply-To: <1a65e90a-a54b-4584-bc00-a568d7c11f78@lysator.liu.se>
> From: Mattias Rönnblom [mailto:hofors@lysator.liu.se]
> Sent: Sunday, 28 April 2024 17.53
>
> On 2024-04-26 17:17, Morten Brørup wrote:
> >> From: Stephen Hemminger [mailto:stephen@networkplumber.org]
> >> Sent: Friday, 26 April 2024 17.14
> >>
> >> On Fri, 26 Apr 2024 14:20:01 +0200
> >> Morten Brørup <mb@smartsharesystems.com> wrote:
> >>
> >>>> From: Ferruh Yigit [mailto:ferruh.yigit@amd.com]
> >>>> Sent: Thursday, 25 April 2024 18.53
> >>>>
> >>>> Making 'rte_eth_stats_reset()' and 'rte_eth_xstats_reset()' APIs thread
> >>>> safe has performance impact on datapath.
> >>>>
> >>>> Instead document APIs as not thread safe and add condition for reliable
> >>>> stats reset functionality, forwarding should be stopped.
> >>>
> >>> I'm not sure stopping forwarding suffices.
> >>> NIC hardware counters will keep progressing unless RX and TX is stopped at
> >> NIC level.
> >>>
> >>> I don't have any suggestions for a better wording, though. :-(
> >>>
> >>> Anyway, better with the patch than without...
> >>> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> >>>
> >>
> >> The safest option would be:
> >> rte_eth_dev_stop
> >> rte_eth_stats_reset
> >> rte_eth_dev_start
> >
> > Yes, but this will cause packet loss.
> > Network admins should be able to clear the counters without causing packet
> loss.
> >
>
> For sure, and they would do it via some O&M interface, which would in
> turn talk the control plane, which in turn would talk to the data plane
> (including <rte_ethdev.h>).
>
> Either the control plane or the O&M layer could keep track of a reset
> offset. Doesn't have to be on the PMD level.
Exactly.
Snapshotting the "reset" offset in the control plane has many advantages.
Let's promote that design pattern, rather than trying to work around different quirks required by different drivers.
next prev parent reply other threads:[~2024-04-29 6:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 16:53 Ferruh Yigit
2024-04-26 12:20 ` Morten Brørup
2024-04-26 15:13 ` Stephen Hemminger
2024-04-26 15:17 ` Morten Brørup
2024-04-26 22:57 ` Stephen Hemminger
2024-04-28 15:52 ` Mattias Rönnblom
2024-04-29 6:20 ` Morten Brørup [this message]
2024-04-29 15:33 ` Stephen Hemminger
2024-04-28 15:48 ` Mattias Rönnblom
2024-04-29 7:57 ` Morten Brørup
2024-04-29 9:30 ` Mattias Rönnblom
2024-04-26 21:33 ` Patrick Robb
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=98CBD80474FA8B44BF855DF32C47DC35E9F3FF@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=hofors@lysator.liu.se \
--cc=mattias.ronnblom@ericsson.com \
--cc=stable@dpdk.org \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/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).