From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Tan, Jianfeng" <jianfeng.tan@intel.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: Wed, 24 Aug 2016 09:28:08 +0200 [thread overview]
Message-ID: <3192bcbb-346e-f7f4-d1a9-76a37b778fac@redhat.com> (raw)
In-Reply-To: <a4dc6da5-3f0b-fab9-eb02-c6bb6b017e23@intel.com>
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.
>
>>
>> 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.
Pankaj, so I organize myself , do you have an idea of when the RFC
patch will be available?
Thanks,
Maxime
next prev parent reply other threads:[~2016-08-24 7:28 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
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 [this message]
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=3192bcbb-346e-f7f4-d1a9-76a37b778fac@redhat.com \
--to=maxime.coquelin@redhat.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=jianfeng.tan@intel.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).