[PATCH v2 38/45] bus/vmbus: use rte stdatomic API
Mattias Rönnblom
hofors at lysator.liu.se
Fri Mar 22 08:04:30 CET 2024
On 2024-03-21 22:34, Long Li wrote:
>
>>> static inline void
>>> vmbus_set_monitor(const struct vmbus_channel *channel, uint32_t
>> monitor_id)
>>> {
>>> - uint32_t *monitor_addr, monitor_mask;
>>> + RTE_ATOMIC(uint32_t) *monitor_addr, monitor_mask;
>>> unsigned int trigger_index;
>>>
>>> trigger_index = monitor_id / HV_MON_TRIG_LEN;
>>> monitor_mask = 1u << (monitor_id % HV_MON_TRIG_LEN);
>>>
>>> - monitor_addr = &channel->monitor_page->trigs[trigger_index].pending;
>>> + monitor_addr =
>>> + (uint32_t __rte_atomic
>>> +*)&channel->monitor_page->trigs[trigger_index].pending;
>>
>> Why is "pending" not RTE_ATOMIC()?
>
> The usage is okay. The value is used to notify the VSP (Hyper-V). It's always set (no read) from DPDK.
>
OK, so my question was not "does it need to be atomic", but rather "why
isn't it marked RTE_ATOMIC() when it's treated as atomic".
But what you are saying is that it need not be atomic? Just the
equivalent of WRITE_ONCE()? Or a relaxed atomic store?
> Linux kernel driver does the same thing.
>
> Long
More information about the dev
mailing list