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

["Tan, Jianfeng" <jianfeng.tan@intel.com>]

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:
> > Hi Maxime,
> >
> > On 8/17/2016 7:18 PM, Maxime Coquelin wrote:
> >> Hi Jianfeng,
> >>
> >> On 08/17/2016 04:33 AM, Tan, Jianfeng wrote:
> >>> 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
> >>> 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.

> 
> >
> >>
> >> 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.
> 
> >
> >>
> >>> 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.
> 
> > 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.
> 
> >>
> >> 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
> 
> >
> > Thanks,
> > Jianfeng
> >
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >> Maxime
> >