From: Stephen Hemminger <stephen@networkplumber.org>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: David Marchand <david.marchand@redhat.com>, <dev@dpdk.org>,
<stable@dpdk.org>, Chengwen Feng <fengchengwen@huawei.com>,
Shaowei Sun <1819846787@qq.com>
Subject: Re: [PATCH] telemetry: lower log level on socket error
Date: Mon, 17 Jun 2024 08:13:45 -0700 [thread overview]
Message-ID: <20240617081345.7e5abe4f@hermes.local> (raw)
In-Reply-To: <ZnBNmSFzhIva9hdC@bricha3-mobl1.ger.corp.intel.com>
On Mon, 17 Jun 2024 15:52:09 +0100
Bruce Richardson <bruce.richardson@intel.com> wrote:
> > >
> > > Would it be also worthwhile having the probing process wait a small amount
> > > of time or check for an input string before closing the socket? That should
> > > avoid the error message being necessary at all for the case described.
> >
> > If telemetry used abstract socket path instead this would not be a problem.
> > Using regular paths leads to races and problems with restart.
> > And all the stat and runtime check logic could go away.
>
> Are abstract paths not linux-specific? Also, would using abstract paths not
> mean that we need to implement some form of authentication on the
> connections? Right now, using real paths in the DPDK runtime directory, a
> regular user cannot connect to the telemetry of a process running as
> another user or as root.
Yes. But existing restart logic is brittle.
next prev parent reply other threads:[~2024-06-17 15:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 12:26 [PATCH] telemetry: lower log level on socket error David Marchand
2024-06-06 13:26 ` Christian Ehrhardt
2024-06-19 14:37 ` Thomas Monjalon
2024-06-17 14:28 ` Bruce Richardson
2024-06-17 14:39 ` Stephen Hemminger
2024-06-17 14:52 ` Bruce Richardson
2024-06-17 15:13 ` Stephen Hemminger [this message]
2024-06-19 15:44 ` Thomas Monjalon
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=20240617081345.7e5abe4f@hermes.local \
--to=stephen@networkplumber.org \
--cc=1819846787@qq.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=fengchengwen@huawei.com \
--cc=stable@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.