DPDK issue with reading the eth interface status?

DPDK issue with reading the eth interface status?

[Ciprian Pascu (Nokia)]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

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?


Thanks,
Ciprian.


[-- Attachment #2: Type: text/html, Size: 3590 bytes --]

VS: DPDK issue with reading the eth interface status?

[Ciprian Pascu (Nokia)]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

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?





Thanks,

Ciprian.



[-- Attachment #2: Type: text/html, Size: 6841 bytes --]

Re: DPDK issue with reading the eth interface status?

[Stephen Hemminger]

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.