[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