[dpdk-dev] Missing an increment on vq->log_cache_nb_elem ?

Maxime Coquelin maxime.coquelin at redhat.com
Fri Jun 15 15:24:58 CEST 2018


Hi,

On 06/15/2018 02:32 PM, Ilya Maximets wrote:
>> Hi,
>>
>>
>> In the latest dpdk master branch, in the function *vhost_log_cache_page*:
>>
>>
>> static __rte_always_inline void
>> vhost_log_cache_page(struct virtio_net *dev, struct vhost_virtqueue *vq,
>> 			uint64_t page)
>> {
>> 	uint32_t bit_nr = page % (sizeof(unsigned long) << 3);
>> 	uint32_t offset = page / (sizeof(unsigned long) << 3);
>> 	int i;
>>
>> 	for (i = 0; i < vq->log_cache_nb_elem; i++) {
>> 		struct log_cache_entry *elem = vq->log_cache + i;
>>
>> 		if (elem->offset == offset) {
>> 			elem->val |= (1UL << bit_nr);
>> 			return;
>> 		}
>> 	}
>>
>> 	if (unlikely(i >= VHOST_LOG_CACHE_NR)) {
>> 		/*
>> 		 * No more room for a new log cache entry,
>> 		 * so write the dirty log map directly.
>> 		 */
>> 		rte_smp_wmb();
>> 		vhost_log_page((uint8_t *)(uintptr_t)dev->log_base, page);
>>
>> 		return;
>> 	}
>>
>> 	vq->log_cache[i].offset = offset;
>> 	vq->log_cache[i].val = (1UL << bit_nr);
>> }
>>
>> Did it just miss an increment on vq->log_cache_nb_elem ?
> 
> Hi. Thanks for pointing that.
> 
> I looked through the code and I see no updates of 'vq->log_cache_nb_elem'.
> Looks like it always equal to initial zero value.
> 
> Maxime, I'm afraid that this means that currently pages logging is not
> performed at all. Could you please check?
> 
> Best regards, Ilya Maximets.
> 

Thanks Ilya for the heads-up and HePeng for reporting the issue.
It is broken indeed... We didn't noticed corruption when running
our non-reg tests, I guess they have to be improved.

I will post a patch shortly to fix this.

HePeng, how does your name spells in the form "$firstname $lastname"?
I would need this info to credit you for reporting the issue.

Regards,
Maxime


More information about the dev mailing list