On Wed, 7 Dec 2022 14:12:36 +0000 "Ciprian Pascu (Nokia)" <[email protected]> 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: [email protected] <[email protected]>; [email protected] > <[email protected]> > 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.
