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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
