From: Stephen Hemminger <stephen@networkplumber.org>
To: "Ciprian Pascu (Nokia)" <ciprian.pascu@nokia.com>
Cc: "users@dpdk.org" <users@dpdk.org>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>
Subject: Re: DPDK issue with reading the eth interface status?
Date: Mon, 12 Dec 2022 08:26:51 -0800 [thread overview]
Message-ID: <20221212082651.36a5d902@hermes.local> (raw)
In-Reply-To: <HE1PR07MB346505BDEB295E1751BF627DE31A9@HE1PR07MB3465.eurprd07.prod.outlook.com>
On Wed, 7 Dec 2022 14:12:36 +0000
"Ciprian Pascu (Nokia)" <ciprian.pascu@nokia.com> wrote:
> It seems that in the Linux kernel some locking has been added with this commit: https://github.com/torvalds/linux/commit/83d0feffc5695d7dc24c6b8dac9ab265533beb78:
>
> spin_lock_irqsave(&adapter->cmd_lock, flags);
>
> VMXNET3_WRITE_BAR1_REG(adapter, VMXNET3_REG_CMD, VMXNET3_CMD_GET_LINK);
>
> ret = VMXNET3_READ_BAR1_REG(adapter, VMXNET3_REG_CMD);
> spin_unlock_irqrestore(&adapter->cmd_lock, flags);
>
>
> Ciprian.
>
>
> ________________________________
> Lähettäjä: Ciprian Pascu (Nokia)
> Lähetetty: keskiviikko 7. joulukuuta 2022 15.57
> Vastaanottaja: users@dpdk.org <users@dpdk.org>; bruce.richardson@intel.com <bruce.richardson@intel.com>
> Aihe: DPDK issue with reading the eth interface status?
>
>
> Hi,
>
> I encountered an issue while using dpdk-20.05 in our VMware based VMs: at times, when sysstat data is collected, dpdk signals that some eth interface is down; this happens occasionally; after sysstat data has been collected, eth interface is signaled as up; I was wondering about these lines in '__vmxnet3_dev_link_update' function:
>
>
>
> 1251 »·······VMXNET3_WRITE_BAR1_REG(hw, VMXNET3_REG_CMD, VMXNET3_CMD_GET_LINK);
>
> 1252 »·······ret = VMXNET3_READ_BAR1_REG(hw, VMXNET3_REG_CMD);
>
>
>
> Is this atomic? Could this lead to problems if some other module tries to read something else at about the same time and overwrites the command?
>
The kernel allows any thread to do control operations at any time.
The DPDK assumes only one thread at a time will do control operations. Coordination is up to the application.
You didn't send the full call stack, but I assume this is from thread
calling rte_eth_link_get(). There is no documentation about thread safety for that function.
Several drivers do things that are not thread safe there.
prev parent reply other threads:[~2022-12-12 16:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-07 13:57 Ciprian Pascu (Nokia)
2022-12-07 14:12 ` VS: " Ciprian Pascu (Nokia)
2022-12-12 16:26 ` Stephen Hemminger [this message]
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=20221212082651.36a5d902@hermes.local \
--to=stephen@networkplumber.org \
--cc=bruce.richardson@intel.com \
--cc=ciprian.pascu@nokia.com \
--cc=users@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).