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