hi irena, in the proposal of andreas you want to enforce the non-promisc mode per l2-agent? so every port managed by this agent will have to be in a non-promisc state? at a first read of the mail, I understood that you want to manage that per port with an extension. By using an extension, an agent could host promisc and non-promisc net-adapters, and other MD could potentially leverage this info (at least LB MD).
On Wed, Aug 27, 2014 at 3:45 PM, Irena Berezovsky <ire...@mellanox.com> wrote: > Hi Mathieu, > We had a short discussion with Andreas about the use case stated below and > also considered the SR-IOV related use case. > It seems that all required changes can be encapsulated in the L2 OVS agent, > since it requires to add fdb mac registration on adapted interface. > What was your idea related to extension manager in ML2? > > Thanks, > Irena > > -----Original Message----- > From: Mathieu Rohon [mailto:] > Sent: Wednesday, August 27, 2014 3:11 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non > promic mode adapters > > you probably should consider using the future extension manager in ML2 : > > https://review.openstack.org/#/c/89211/ > > On Mon, Aug 25, 2014 at 12:54 PM, Irena Berezovsky <ire...@mellanox.com> > wrote: >> Hi Andreas, >> We can definitely set some time to discuss this. >> I am usually available from 5 to 14:00 UTC. >> Let's follow up on IRC (irenab). >> >> BR, >> Irena >> >> -----Original Message----- >> From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] >> Sent: Monday, August 25, 2014 11:00 AM >> To: Irena Berezovsky >> Cc: OpenStack Development Mailing List (not for usage questions) >> Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support >> for non promic mode adapters >> >> Hi Irena, >> thanks for your reply. Yes sure, collaboration would be great. >> Do you already have a blueprint out there? Maybe wen can synchup this week >> to discuss more details? Cause I would like to understand what exactly >> you're looking for. Normally I'm available form 7 UTC to 16 utc (today only >> until 13 utc). My irc name is scheuran. Maybe we can get in contact this >> week! >> >> You also where talking about sriov. I saw some blueprint mentioning sriov & >> macvtap. Do you have any insights into this one, too? What we also would >> like to do is to introduce macvtap as network virtualization option. Macvtap >> also registers mac addresses to network adapters... >> >> >> Thanks, >> Andreas >> >> >> On Sun, 2014-08-24 at 08:51 +0000, Irena Berezovsky wrote: >>> Hi Andreas, >>> Thank you for this initiative. >>> We were looking on similar problem for mixing OVS and SR-IOV on same >>> network adapter, which also requires mac addresses registration of OVS >>> ports. >>> Please let me know if you would like to collaborate on this effort. >>> >>> BR, >>> Irena >>> >>> -----Original Message----- >>> From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] >>> Sent: Friday, August 22, 2014 11:16 AM >>> To: openstack-dev@lists.openstack.org >>> Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support >>> for non promic mode adapters >>> >>> Thanks for your feedback. >>> >>> No, I do not yet have code for it. Just wanted to get a feeling if such a >>> feature would get acceptance in the community. >>> But if that helps I can sit down and start some prototyping while I'm >>> preparing a blueprint spec in parallel. >>> >>> The main part of the implementation I wanted to do on my own to get more >>> familiar with the code base and to get more in touch with the community. >>> But of course advice and feedback of experienced neutron developers is >>> essential! >>> >>> So I will proceed like this >>> - Create a blueprint >>> - Commit first pieces of code to get early feedback (e.g. ask via the >>> mailing list or irc) >>> - Upload a spec (as soon as the repo is available for K) >>> >>> Does that make sense for you? >>> >>> Thanks, >>> Andreas >>> >>> >>> >>> On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote: >>> > I think this sounds reasonable. Do you have code for this already, >>> > or are you looking for a developer to help implement it? >>> > >>> > >>> > On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring >>> > <scheu...@linux.vnet.ibm.com> wrote: >>> > Hi, >>> > last week I started discussing an extension to the existing >>> > neutron >>> > openvswitch agent to support network adapters that are not in >>> > promiscuous mode. Now I would like to enhance the round to get >>> > feedback >>> > from a broader audience via the mailing list. >>> > >>> > >>> > The Problem >>> > When driving vlan or flat networking, openvswitch requires an >>> > network >>> > adapter in promiscuous mode. >>> > >>> > >>> > Why not having promiscuous mode in your adapter? >>> > - Admins like to have full control over their environment and >>> > which >>> > network packets enter the system. >>> > - The network adapter just does not have support for it. >>> > >>> > >>> > What to do? >>> > Linux net-dev driver offer an interface to manually register >>> > additional >>> > mac addresses (also called secondary unicast addresses). >>> > Exploiting this >>> > one can register additional mac addresses to the network >>> > adapter. This >>> > also works via a well known ip user space tool. >>> > >>> > `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0` >>> > >>> > >>> > What to do in openstack? >>> > As neutron is aware of all the mac addresses that are in use >>> > it's the >>> > perfect candidate for doing the mac registrations. The idea is >>> > to modify >>> > the neutron openvswitch agent that it does the registration on >>> > "port >>> > add" and "port remove" via the bridge command. >>> > There would be a new optional configuration parameter, >>> > something like >>> > 'non-promisc-mode' that is by default set to false. Only when >>> > set to >>> > true, macs get manually registered. Otherwise the agent >>> > behaves like it >>> > does today. So I guess only very little changes to the agent >>> > code are >>> > required. From my current point of view we do not need any >>> > changes to >>> > the ml2 plug-in. >>> > >>> > >>> > Blueprint or a bug? >>> > I guess it's a blueprint. >>> > >>> > What's the timeframe? >>> > K would be great. >>> > >>> > >>> > >>> > I would be thankful for any feedback on this! Feel free to >>> > contact me >>> > anytime. Thanks in advance! >>> > >>> > Regards, >>> > Andreas >>> > >>> > (irc: scheuran) >>> > >>> > >>> > _______________________________________________ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> > >>> > >>> > >>> > -- >>> > Kevin Benton >>> > _______________________________________________ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
