10/01/2020 03:38, Xu, Rosen:

From: Matan Azrad <redacted>

quoted

From: Xu, Rosen <redacted>

quoted

From: Thomas Monjalon <redacted>

quoted

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

quoted

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.

quoted

quoted

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

quoted

quoted

as

packet TX/RX for OVS.

No, OVS is also using the vhost API for vhost port.

Yes, vhost pmd is not a good example.

quoted

quoted

Take vHost(Virtio back end) for example, OVS startups vHost
interface like

this:

quoted

ovs-vsctl add-port br0 vhost-user-1 -- set Interface vhost-user-1
type=dpdkvhostuser drivers/net/vhost implements vHost as

rte_eth_dev

quoted

and integrated in OVS.

quoted

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.

quoted

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".

Currently, vDPA isn't integrated with OVS.

quoted

quoted

So, it's not ok to move ifc code from drivers/net.

drivers/net/ifc has no ethdev implementation at all.

For OVS hasn't integrated vDPA, it doesn't implement rte_eth_dev, but
there are many discussions in OVS community about vDPA, some are from
Mellanox, it seems vDPA port will be implemented as rte_eth_dev port
in OVS in the near feature.
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
h

work.ozlabs.org%2Fpatch%2F1178474%2F&data=02%7C01%7Cmatan%
4

quoted

0mellanox.com%7C9e84c2581e2f414e0aca08d794f22e8d%7Ca652971c7d2e4
d

quoted

9ba6a4d149256f461b%7C0%7C0%7C637141640216181763&sdata=TA%
2F

quoted

0zU495kXUqhC6eP09NDzBZfjJz1dbfkRcDpV%2BYAs%3D&reserved=0

Matan,
Could you clarify how OVS integrates vDPA in Mellanox patch?

quoted

Rosen, I'm sorry, these arguments look irrelevant, so I won't
consider them as blocking the integration of this patch.

What I mentioned is not blocking the integration of this patch, I just
want to get clarification from Matan how to integrate vDPA port in OVS.

Hi

OVS like any other application should use the current API of vDPA to attach a
probed vdpa device to a vhost device.
See example application /examples/vdpa.

Here, we just introduce a new class to hold all the vDPA drivers, no change in
the API.

As I understand, no vDPA device is currently integrated in OVS.

I think it can be integrated only when a full offload will be integrated since
the vDPA device forward the traffic from the HW directly to the virtio queue,
once it will be there, I guess the offload will be configured by the representor
of the vdpa device(VF) which is managed by an ethdev device.


Matan.

Hi,

I'm still confused about your last sentence " the representor of the vdpa device(VF) which is managed by an ethdev device".
My understanding is that there are some connections and dependency between rte_eth_dev and vdpa device?
Am I right or any other explanations from you?

A vDPA port does not allow any ethdev operations (like rte_flow).
In order to configure some offloads on the device, OVS needs an ethdev port.
In Mellanox case, an ethdev VF representor port can be instantiated.
So we may have two ports for the same device:
	- vDPA for data path with the VM
	- ethdev for offloads control path