Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

2016-02-25 Thread Wuhongning
Pipes [jaypi...@gmail.com] Sent: Tuesday, February 23, 2016 10:51 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios On 02/22/2016 10:25 PM, Wuhongning wrote: > Hi all, > > There is also a control plane pe

Re: [openstack-dev] [Neutron] - DVR L3 data plane performance results and scenarios

2016-02-22 Thread Wuhongning
Hi all, There is also a control plane performance issue when we try to catch on the spec of typical AWS limit (200 subnets per router). When a router with 200 subnets is scheduled on a new host, a 30s delay is watched when all data plane setup is finished.

Re: [openstack-dev] [Neutron] OVS flow modification performance

2016-01-29 Thread Wuhongning
List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] OVS flow modification performance At Thu, 21 Jan 2016 02:59:16 +, Wuhongning wrote: > > I don't think 400 flows can show the difference , do you have setup any > tunnel peer? > > In fact we may set the network

Re: [openstack-dev] [Neutron] OVS flow modification performance

2016-01-20 Thread Wuhongning
I don't think 400 flows can show the difference , do you have setup any tunnel peer? In fact we may set the network type as "vxlan", then make a fake MD simulate sending l2pop fdb add messages, to push ten's of thousands flows into the testing ovs agent.

Re: [openstack-dev] [neutron][L3][DVR][arp]

2015-12-01 Thread Wuhongning
comment for VLAN network, since DVR also support in VLAN network and L2population is not necessary in it, what is your consideration in this case? At 2015-11-29 14:15:11, "Wuhongning" <wuhongn...@huawei.com> wrote: >Is it a good idea to add a configuration item for dvr,

[openstack-dev] [neutron][L3][DVR][arp]

2015-11-28 Thread Wuhongning
Is it a good idea to add a configuration item for dvr, to disable any arp entry processing, and reuse arp response from L2population? When no static arp entry is found in qrouter namespace, it would cause a temp arp request, then it reached the br-tun, and replied by the OVS flow table. In a

Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

2014-11-03 Thread Wuhongning
Is the trunk port use case like the super vlan? Also there is another typical use case maybe not covered: extended flat network. Traffic on the port carries multiple vlans, but these vlans are not necessarily managed by neutron-network, so can not be classified to trunk port. And they don't

Re: [openstack-dev] [Nova] Add scheduler-hints when migration/rebuild/evacuate

2014-10-29 Thread Wuhongning
+1, the hint should be persistent as other server instance metadata. From: Alex Xu [sou...@gmail.com] Sent: Wednesday, October 29, 2014 9:11 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] Add scheduler-hints

Re: [openstack-dev] [all] [tc] Multi-clouds integration by OpenStack cascading

2014-10-29 Thread Wuhongning
Hi keshava, Thanks for interested in Cascading. Here are some very simple explanation: Basically Datacenter is not in the 2-level tree of cascading. We use term POD to represent a cascaded child openstack (same meaning of your term Zone?). There may be single or multiple PODs in one

[openstack-dev] [neutron] what happened to ModularL2Agent?

2014-10-10 Thread Wuhongning
Hi, In the Juno cycle there is proposal of ModularL2Agent [1,2], which is very useful to develop agent for new backend with much less redundant code. Without that, we have to either fork a new agent by copying large amount of existing l2agent code, or patch existing l2agent. However in the K

Re: [openstack-dev] [Neutron] Enabling vlan trunking on neutron port.

2014-09-24 Thread Wuhongning
Internal vlan is not necessarily obstacle to vlan trunk, no qinq support in ovs is the key factor. If ovs suppport qinq, vlan trunk could be treated as a generalized flat type network, which let packets from tenant VM go to the wire unmodified, if packets carry no tag, then it's the same as

Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

2014-09-01 Thread Wuhongning
It would satisfy everyone if horizon support all APIs, either in tree or in the lab, but at the perquisite that we have enough resource for horizon. Else for the limitation of resource, we have to sort by the priority, then should we focus on APIs being baked in the incubator first?

Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-20 Thread Wuhongning
things there in the first place? Since everything will require custom clients, the port ID can just be used as a foreign key to another API instead and the ML2 objects don't need to change at all. On Tue, Aug 19, 2014 at 6:11 PM, Wuhongning wuhongn...@huawei.commailto:wuhongn...@huawei.com wrote

Re: [openstack-dev] [Neutron][QoS] Request to be considered for neutron-incubator

2014-08-19 Thread Wuhongning
+1 to service plugin It's better to strip service related extensions from ML2 core plugin as possible as we can, and put them in separate service plugin. Not only QOS, but also SG or possible other extensions. For the binding issue, vif-detail dict might be used for foreign key association.

Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

2014-08-14 Thread Wuhongning
FWaas can't seamlessly work with DVR yet. A BP [1] has been submitted, but it can only handle NS traffic, leaving W-E untouched. If we implement the WE firewall in DVR, the iptable might be applied at a per port basis, so there are some overlapping with SG (Can we image a packet run into

Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

2014-08-14 Thread Wuhongning
. From: Sridar Kandaswamy (skandasw) [skand...@cisco.com] Sent: Thursday, August 14, 2014 10:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree Hi Wuhongning: Yes u are correct

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-13 Thread Wuhongning
Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward On 08/12/2014 06:46 PM, Wuhongning wrote: I couldn't have been at the IRC meeting for the time difference, are there any conclusion for this topic, or is it still open? I, the PTL, some core reviewers and many

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Wuhongning
Does it make sense to move all advanced extension out of ML2, like security group, qos...? Then we can just talk about advanced service itself, without bothering basic neutron object (network/subnet/port) Traditionally, SG is applied in CN, and FWaas is applied in NN (bound to L3 agent),

[openstack-dev] [neutron][DVR]: Will DVR support external gateway with snat disabled?

2014-07-25 Thread Wuhongning
Now in L3 API, we can create a router with external gateway, while enable_snat setting to false. Now in DVR code, all cenral NS processing is related with snat, so does it still support NS central gw without snat? Also, is it possible to separate the scheduling of NS central gateway and

Re: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2 plugin

2014-07-16 Thread Wuhongning
hi, It's a very important use case for multiple vswitchs. Now we use a fork version of ovs-dpdk to support NFV service chaining deployment, however all other traffic are still in the kernel ovs path, including management and storage traffic, and it will be very difficult to switch all these

Re: [openstack-dev] DVR and FWaaS integration

2014-07-01 Thread Wuhongning
From: Carl Baldwin [c...@ecbaldwin.net] Sent: Monday, June 30, 2014 3:43 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] DVR and FWaaS integration On Mon, Jun 30, 2014 at 3:43 AM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net

Re: [openstack-dev] [Neutron] DVR SNAT shortcut

2014-06-26 Thread Wuhongning
From: Zang MingJie [zealot0...@gmail.com] Sent: Thursday, June 26, 2014 6:29 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] DVR SNAT shortcut On Wed, Jun 25, 2014 at 10:29 PM, McCann, Jack

Re: [openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

2014-06-05 Thread Wuhongning
in the current Neutron implementation. Another interconnect subnet should not be needed here and would be overkill. I hope this helps. Let me know if you have any questions. Carl On Fri, May 16, 2014 at 1:57 AM, Wuhongning wuhongning at huawei.comhttp://lists.openstack.org/cgi-bin/mailman/listinfo

[openstack-dev] [Neutron] Default routes to SNAT gateway in DVR

2014-05-16 Thread Wuhongning
Hi DVRers, I didn't see any detail documents or source code on how to deal with routing packet from DVR node to SNAT gw node. If the routing table see a outside ip, it should be matched with a default route, so for the next hop, which interface will it select? Maybe another standalone