On Wed, Sep 14, 2016 at 9:39 AM, Liping Mao (limao) <li...@cisco.com> wrote:
> > Though, not the best person to comment on macvlan vs ipvlan, one > limitation of macvlan is that on physical interfaces, maximum possible > number of random mac generations may not cope-up with large number of > containers on same vm. > > Thanks, yes, it is a limitation, Vikas. > This happened if you use vlan as tenant network. If tenant network use > overlay mode, maybe it will be a little bit better for the mac problem. > The reason why I mention macvlan can be one of choice is because ipvlan > need a very new kernel , it maybe a little bit hard to use in prod > env(AFAIK). > You have a valid point regarding ipvlan support in newer kernel versions but IIUC overlay mode might not help if nic has a limit on max number of macs that it supports in hardware. > > Regards, > Liping Mao > > From: Vikas Choudhary <choudharyvika...@gmail.com> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: 2016年9月14日 星期三 上午11:50 > > To: OpenStack List <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal > > > > On Wed, Sep 14, 2016 at 7:10 AM, Liping Mao (limao) <li...@cisco.com> > wrote: > >> Hi Ivan and Gary, >> >> maybe we can use macvlan as ipvlan need very new kernel. >> allow-address-pairs can aslo allow different mac in vm. >> Do we consider macvlan here? Thanks. >> > > Though, not the best person to comment on macvlan vs ipvlan, one > limitation of macvlan is that on physical interfaces, maximum possible > number of random mac generations may not cope-up with large number of > containers on same vm. > > >> >> Regards, >> Liping Mao >> >> From: Liping Mao <li...@cisco.com> >> Reply-To: OpenStack List <openstack-dev@lists.openstack.org> >> Date: 2016年9月13日 星期二 下午9:09 >> To: OpenStack List <openstack-dev@lists.openstack.org> >> >> Subject: Re: [openstack-dev] [Kuryr] IPVLAN data path proposal >> >> Hi Gary, >> >> I mean maybe that can be one choice in my mind. >> >> Security Group is for each neutron port,in this case,all the docker on >> one vm will share one neutron port(if I understand correct),then they will >> share the security group on that port,it is not per container per security >> group,not sure how to use security group in this case? >> >> Regards, >> Liping Mao >> >> 在 2016年9月13日,20:31,Loughnane, Gary <gary.loughn...@intel.com> 写道: >> >> Hi Liping, >> >> >> >> Thank you for the feedback! >> >> >> >> Do you mean to have disabled security groups as an optional configuration >> for Kuryr? >> >> Do you have any opinion on the consequences/acceptability of disabling SG? >> >> >> >> Regards, >> >> Gary >> >> >> >> *From:* Liping Mao (limao) [mailto:li...@cisco.com <li...@cisco.com>] >> *Sent:* Tuesday, September 13, 2016 12:56 PM >> *To:* OpenStack Development Mailing List (not for usage questions) < >> openstack-dev@lists.openstack.org> >> *Subject:* Re: [openstack-dev] [Kuryr] IPVLAN data path proposal >> >> >> >> Hi Ivan, >> >> >> >> It sounds cool! >> >> >> >> for security group and allowed address pair, >> >> Maybe we can disable port-security,because all the docker in one vm will >> share one security group on the vm port. I'm not sure how to use sg for >> each docker,maybe just disable port-security can be one of the choice. >> then do not need allowed address pairs in this case. >> >> >> >> >> >> Regards, >> >> Lipimg Mao >> >> >> 在 2016年9月12日,19:31,Coughlan, Ivan <ivan.cough...@intel.com> 写道: >> >> >> >> *Overview* >> >> Kuryr proposes to address the issues of double encapsulation and exposure >> of containers as neutron entities when containers are running within VMs. >> >> As an alternative to the vlan-aware-vms and use of ovs within the VM, we >> propose to: >> >> - Use allowed-address-pairs configuration for the VM neutron >> port >> >> - Use IPVLAN for wiring the Containers within VM >> >> >> >> In this way: >> >> - Achieve efficient data path to container within VM >> >> - Better leverage OpenStack EPA(Enhanced Platform Awareness) >> features to accelerate the data path (more details below) >> >> - Mitigate the risk of vlan-aware-vms not making neutron in time >> >> - Provide a solution that works on existing and previous >> openstack releases >> >> >> >> This work should be done in a way permitting the user to optionally >> select this feature. >> >> >> >> >> *Required Changes* >> >> The four main changes we have identified in the current kuryr codebase >> are as follows: >> >> · Introduce an option of enabling “IPVLAN in VM” use case. This >> can be achieved by using a config file option or possibly passing a command >> line argument. The IPVLAN master interface must also be identified. >> >> · If using “IPVLAN in VM” use case, Kuryr should no longer >> create a new port in Neutron or the associated VEth pairs. Instead, Kuryr >> will create a new IPVLAN slave interface on top of the VM’s master >> interface and pass this slave interface to the Container netns. >> >> · If using “IPVLAN in VM” use case, the VM’s port ID needs to be >> identified so we can associate the additional IPVLAN addresses with the >> port. This can be achieved by querying Neutron’s show-port function and >> passing the VMs IP address. >> >> · If using “IPVLAN in VM” use case, Kuryr should associate the >> additional IPVLAN addresses with the VMs port. This can be achieved using >> Neutron’s allowed-address-pairs flag in the port-update function. We >> intend to make use of Kuryr’s existing IPAM functionality to request these >> IPs from Neutron. >> >> >> >> *Asks* >> >> We wish to discuss the pros and cons. >> >> For example, containers exposure as proper neutron entities and the >> utility of neutron’s allowed-address-pairs is not yet well understood. >> >> >> >> We also wish to understand if this approach is acceptable for kuryr? >> >> >> >> >> >> *EPA* >> >> The Enhanced Platform Awareness initiative is a continuous program to >> enable fine-tuning of the platform for virtualized network functions. >> >> This is done by exposing the processor and platform capabilities through >> the management and orchestration layers. >> >> When a virtual network function is instantiated by an Enhanced Platform >> Awareness enabled orchestrator, the application requirements can be more >> efficiently matched with the platform capabilities. >> >> http://itpeernetwork.intel.com/openstack-kilo-release-is-sha >> ping-up-to-be-a-milestone-for-enhanced-platform-awareness/ >> >> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf >> >> https://www.brighttalk.com/webcast/12229/181563/epa-features >> -in-openstack-kilo >> >> >> >> >> >> Regards, >> >> Ivan…. >> >> -------------------------------------------------------------- >> Intel Research and Development Ireland Limited >> Registered in Ireland >> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare >> Registered Number: 308263 >> >> This e-mail and any attachments may contain confidential material for the >> sole use of the intended recipient(s). Any review or distribution by others >> is strictly prohibited. If you are not the intended recipient, please >> contact the sender and delete all copies. >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> -------------------------------------------------------------- >> Intel Research and Development Ireland Limited >> Registered in Ireland >> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare >> Registered Number: 308263 >> >> This e-mail and any attachments may contain confidential material for the >> sole use of the intended recipient(s). Any review or distribution by others >> is strictly prohibited. If you are not the intended recipient, please >> contact the sender and delete all copies. >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev