09/01/2020 03:27, Xu, Rosen:

Hi,

From: Thomas Monjalon <redacted>

quoted

08/01/2020 13:39, Xu, Rosen:

quoted

From: Matan Azrad <redacted>

quoted

From: Xu, Rosen

quoted

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.

quoted

quoted

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.