[ovs-dev] [PATCH] netdev-dpdk: Add vHost User PMD

Ilya Maximets i.maximets at samsung.com
Tue May 10 09:51:15 UTC 2016


On 10.05.2016 12:38, Loftus, Ciara wrote:
>>
>> On 10.05.2016 11:31, Ilya Maximets wrote:
>>> On 03.05.2016 14:28, ciara.loftus at intel.com (Loftus, Ciara) wrote:
>>>>> This patch seem to remove a lot of txq remapping functions (like
>>>>> netdev_dpdk_remap_txqs).Ã,  How does it handle the case of a
>> disabled txq in
>>>>> the guest kernel?
>>>> There is a difference in the amount of information we can get about
>> vrings
>>>> in OVS now. With the PMD, we no longer have direct access to the
>> virtio_net
>>>> structure. We used to use virto_net->virt_qp_nb to determine the
>> number of
>>>> vrings (enabled and disabled) in the guest kernel, and we could map
>> disabled
>>>> onto enabled accordingly. Now with the PMD, we only get vring
>> information as
>>>> their state changes. eg. VM with 2 vrings enabled -> we assume there are
>> only
>>>> 2 vrings, even though there may be many more that are disabled. We
>> don't need
>>>> to map because we aren't aware of the disabled queues.
>>>
>>> virtio protocol still allows to disable random queue in guest. This patch will
>>> work only with linux kernel virtio driver on guest side and just because linux
>>> kernel driver always enables/disables queues sequentially. For example,
>> you may
>>> write your own application with virtio-user with 2 rx/tx queues in guest and
>>> disable rx queue #0. This scenario will lead to broken connection while
>>> queue #1 still enabled.
>>>
>>> Best regards, Ilya Maximets.
>>>
> 
> Hi Ilya,
> 
> Apologies I didn't see your mail before I sent a v2 of the patch.
> Thanks for the information. My testing involved the kernel driver and DPDK driver in the guest so it did not expose this type of issue.
> 
> With the PMD we now receive the following data struct during vring_state_changed_callback:
> 
> struct rte_eth_vhost_queue_event {
> 	uint16_t queue_id;
> 	bool rx;
> 	bool enable;
> };
> 
> Since we have queue_id information we should be able correctly handle the case you mentioned above. I will look to implement a solution to this in the v3.

OK. But solution already exists. You may just preserve mechanism of remapping.
It was implemented exactly for this situation.

Best regards, Ilya Maximets.



More information about the dev mailing list