DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
	Yuanhan Liu <yuanhan.liu@linux.intel.com>,
	Pankaj Chauhan <pankaj.chauhan@nxp.com>
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
Date: Thu, 18 Aug 2016 10:35:57 +0800	[thread overview]
Message-ID: <a4dc6da5-3f0b-fab9-eb02-c6bb6b017e23@intel.com> (raw)
In-Reply-To: <d36243cd-df18-7404-abb8-e349c9d13979@redhat.com>

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.

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

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

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.

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

Thanks,
Jianfeng

>
> Any thoughts?
>
> Thanks,
> Maxime

  reply	other threads:[~2016-08-18  2:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <b25fa14e-1dae-da7d-a320-4ce53517ee85@nxp.com>
2016-08-09 11:12 ` Pankaj Chauhan
2016-08-16  2:56   ` Yuanhan Liu
2016-08-17  2:33     ` Tan, Jianfeng
2016-08-17 11:18       ` Maxime Coquelin
2016-08-18  2:35         ` Tan, Jianfeng [this message]
2016-08-18  7:43           ` Maxime Coquelin
2016-08-18 10:36             ` Tan, Jianfeng
2016-08-22 13:19               ` Thomas Monjalon
2016-08-24  7:28           ` Maxime Coquelin
2016-08-26  5:53             ` Pankaj Chauhan
2016-08-17 10:24     ` Pankaj Chauhan
2016-08-18  8:27       ` Yuanhan Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a4dc6da5-3f0b-fab9-eb02-c6bb6b017e23@intel.com \
    --to=jianfeng.tan@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=pankaj.chauhan@nxp.com \
    --cc=shreyansh.jain@nxp.com \
    --cc=yuanhan.liu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).