Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device drivers

[Maxime Coquelin <maxime.coquelin@redhat.com>]

On 1/9/20 10:49 AM, Xu, Rosen wrote:
> 
> 
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Thursday, January 09, 2020 17:24
>> To: Thomas Monjalon <thomas@monjalon.net>; Xu, Rosen
>> <rosen.xu@intel.com>
>> Cc: Matan Azrad <matan@mellanox.com>; Bie, Tiwei <tiwei.bie@intel.com>;
>> Wang, Zhihong <zhihong.wang@intel.com>; Wang, Xiao W
>> <xiao.w.wang@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>;
>> dev@dpdk.org; Pei, Andy <andy.pei@intel.com>
>> Subject: Re: [dpdk-dev] [PATCH v1 0/3] Introduce new class for vDPA device
>> drivers
>>
>>
>>
>> On 1/9/20 9:41 AM, Thomas Monjalon wrote:
>>> 09/01/2020 03:27, Xu, Rosen:
>>>> Hi,
>>>>
>>>> From: Thomas Monjalon <thomas@monjalon.net>
>>>>> 08/01/2020 13:39, Xu, Rosen:
>>>>>> From: Matan Azrad <matan@mellanox.com>
>>>>>>> From: Xu, Rosen
>>>>>>>> Did you think about OVS DPDK?
>>>>>>>> vDPA is a basic module for OVS, currently it will take some
>>>>>>>> exception path packet processing for OVS, so it still needs to
>>>>>>>> integrate
>>>>> eth_dev.
>>>>>>>
>>>>>>> I don't understand your question.
>>>>>>>
>>>>>>> What do you mean by "integrate eth_dev"?
>>>>>>
>>>>>> My questions is in OVS DPDK scenario vDPA device implements eth_dev
>>>>>> ops, so create a new class and move ifc code to this new class is not ok.
>>>>>
>>>>> 1/ I don't understand the relation with OVS.
>>>>>
>>>>> 2/ no, vDPA device implements vDPA ops.
>>>>> If it implements ethdev ops, it is an ethdev device.
>>>>>
>>>>> Please show an example of what you claim.
>>>>
>>>> Answers of 1 and 2.
>>>>
>>>> In OVS DPDK, each network device(such as NIC, vHost etc) of DPDK
>>>> needs to be implemented as rte_eth_dev and provides eth_dev_ops such
>> as packet TX/RX for OVS.
>>>
>>> No, OVS is also using the vhost API for vhost port.
>>>
>>>> Take vHost(Virtio back end) for example, OVS startups vHost interface like
>> this:
>>>> ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1
>>>> type=dpdkvhostuser drivers/net/vhost implements vHost as rte_eth_dev
>> and integrated in OVS.
>>>> OVS can send/receive packets to/from VM with rte_eth_tx_burst()
>>>> rte_eth_rx_burst() which call eth_dev_ops implementation of
>> drivers/net/vhost.
>>>
>>> No, it is using rte_vhost_dequeue_burst() and
>>> rte_vhost_enqueue_burst() which are not in ethdev.
>>>
>>>> vDPA is also Virtio back end and works like vHost, same as vHost, it
>>>> will be implemented as rte_eth_dev and also be integrated into OVS.
>>>
>>> No, vDPA is not "implemented as rte_eth_dev".
>>>
>>>> So, it's not ok to move ifc code from drivers/net.
>>>
>>> drivers/net/ifc has no ethdev implementation at all.
>>>
>>>
>>> Rosen, I'm sorry, these arguments look irrelevant, so I won't consider
>>> them as blocking the integration of this patch.
>>>
>>>
>>
>> I agree with Thomas, the vDPA drivers do not implement the ethdev ops.
> 
> For OVS hasn't integrated vDPA, it doesn't implement ethdev ops, but there are many
> discussions in OVS community about vDPA, it seems vDPA will be supported in OVS in
> the near feature.

I agree with this statement, but if you look at Mellanox series being
reviewed, it is defining a new type of port and not use the regular DPDK
port type.

>> And OVS does not use the Vhost PMD for the Vhost-user ports, but directly
>> call the librte_vhost APIs.
> 
> I'm afraid you are wrong, pls read these documents which introduce how to use vHost-user PMD in OVS:
> http://docs.openvswitch.org/en/latest/topics/dpdk/vhost-user/
> http://docs.openvswitch.org/en/latest/topics/dpdk/pmd/

I can confirm that below command to add ports is not using Vhost PMD but
directly the  librte_vhost API:

$ ovs-vsctl add-port br0 dpdkvhostclient0 \
    -- set Interface dpdkvhostclient0 type=dpdkvhostuserclient \
       options:vhost-server-path=/tmp/dpdkvhostclient0

Please check the OVS source code.

It is possible  to use the Vhost PMD as a regular DPDK port, but this is
not with above command, and not the recommended way.

>> Regards,
>> Maxime
>