Re: vhost [query] : support for multiple ports and non VMDQ devices in vhost switch

Hi Maxime,

-----Original Message-----
From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
Sent: Thursday, August 18, 2016 3:43 PM
To: Tan, Jianfeng; Yuanhan Liu; Pankaj Chauhan
Cc: dev@dpdk.org; hemant.agrawal@nxp.com; shreyansh.jain@nxp.com
Subject: Re: [dpdk-dev] vhost [query] : support for multiple ports and non
VMDQ devices in vhost switch

Hi,

On 08/18/2016 04:35 AM, Tan, Jianfeng wrote:

quoted

Hi Maxime,

On 8/17/2016 7:18 PM, Maxime Coquelin wrote:

quoted

Hi Jianfeng,

On 08/17/2016 04:33 AM, Tan, Jianfeng wrote:

quoted

Hi,

Please review below proposal of Pankaj and myself after an offline
discussion. (Pankaj, please correct me if I'm going somewhere wrong).

a. Remove HW dependent option, --strip-vlan, because different kinds

of

quoted

quoted

quoted

NICs behave differently. It's a bug fix.
b. Abstract switching logic into a framework, so that we can develop
different kinds of switching logics. In this phase, we will have two
switching logics: (1) a simple software-based mac learning switching;
(2) VMDQ based switching. Any other advanced switching logics can be
proposed based on this framework.
c. Merge tep_termination example vxlan as a switching logic of the
framework.

I was also thinking of making physical port optional and add MAC
learning,
so this is all good for me.

To make it clear, we are not proposing to eliminate physical port,
instead, we just eliminate the binding of VMDQ and virtio ports,
superseding it with a MAC learning switching.

So you confirm we could have setup with only VMs, and no physical
NIC? That's what I meant when saying "making physical port optional".

Yes, this case would be supported too.

quoted

quoted

Let me know if I can help in implementation, I'll be happy to
contribute.

Thank you for participating. Currently, I'm working on item a (will be a
quick and simple fix). Pankaj is working on item b (which would be a
huge change). Item c is depending on item b. So let's wait RFC patch
from Pankaj and see what we can help.

Good, let's wait for Pankaj's RFC.

quoted

quoted

quoted

To be decided:
d. Support multiple physical ports.
e. Keep the current way to use vhost lib directly or use vhost pmd
instead.

Do you see advantages of using vhost lib directly vs. pmd?
Wouldn't using vhost pmd make achieving zero-copy harder?
(I'm not sure, I didn't investigate the topic much for now).

Yes, by using vhost lib, we can add back the removed feature zero-copy.
But my understanding is zero-copy (nic-to-vm or vm-to-nic) or delayed
copy (vm-to-vm) would be great and common features, which should be
integrated into vhost lib and enabled in vhost pmd, so that all
applications can benefit from it. And in fact, Yuanhan is working on the
delayed copy now. An exception is rx-side-zero-copy, I don't know if
it's common enough to be integrated in a vhost lib, because it'll
require hardware queue binding.

Ok, I'm interrested in knowing how vm-to-vm delayed copy will be
implemented.

quoted

Besides, vhost pmd would be easier to use than vhost lib (personal
opinion). Secondly, vhost pmd would be more clear in logic, 1:1:1
mapping among vhost port, unix socket path, and virtio port. Thirdly, by
using vhost pmd, we can treat vhost ports the way of physical ports,
otherwise, we use different API to receive/transmit packets.

I'm 100% aligned with you on this, the vhost pmd makes things more
standard, so more flexible.

quoted

quoted

Also, if we use pmd directly, then it would no more be a vhost switch
only, as it could potentially be used with physical NICs also.

You mean we are building a switch instead of vhost switch? Yes, a switch
can switch packets between virtio-virtio and virtio-physical nic.

And physical-physical also, as we will be standard API with the
vhost-pmd, nothing will prevent using it with only physical switches,
no?

Oh yes, I agree.

Thanks,
Jianfeng

Thanks,
Maxime

quoted

Thanks,
Jianfeng

quoted

Any thoughts?

Thanks,
Maxime