Re: [openstack-dev] [kolla] Building Kolla containers with 3rd party vendor drivers

[Sandhya Dasu (sadasu)]

Hi Paul,
I am happy to use the changes you proposed to
 https://github.com/openstack/kolla/blob/master/kolla/common/config.py

I was under the impression that this was disallowed for drivers that weren’t
considered “reference drivers”. If that is no longer the case, I am happy to go
this route and abandon the approach I took in my diffs in:
https://review.openstack.org/#/c/552119/.

I agree with the reasoning that Kolla cannot possibly maintain a large
number of neutron-server containers, one per plugin.

To support operators that want to build their own images, I was hoping that
we could come up with a mechanism by which the 3rd party driver owners
provide the code (template-override.j2 or Dockerfile.j2 as the case maybe)
to build their containers. This code can definitely live out-of-tree with the
drivers themselves.

Optionally, we could have them reside in-tree in Kolla in a separate directory, 
say “additional drivers”. Kolla will not be responsible for building a container
per driver or for building a huge (neutron-server) container containing all
interested drivers.

Operators that need one or more of these “additional drivers” will be provided
with documentation on how the code in the “additional drivers” path can be
used to build their own containers. This documentation will also detail how
to combine more than one 3rd party drivers into their own container.

I would like the community’s input on what approach best aligns with Kolla’s
and the larger OpenStack community’s goals.

Thanks,
Sandhya

On 5/11/18, 5:35 AM, "Paul Bourke" <paul.bou...@oracle.com> wrote:

Hi Sandhya,

Thanks for starting this thread. I've moved it to the mailing list so 
the discussion can be available to anyone else who is interested, I hope 
you don't mind.

If your requirement is to have third party plugins (such as Cisco) that 
are not available on tarballs.openstack.org, available in Kolla, then 
this is already possible.

Using the Cisco case as an example, you would simply need to submit the 
following patch to 
https://github.com/openstack/kolla/blob/master/kolla/common/config.py

"""
 'neutron-server-plugin-networking-cisco': {
 'type': 'git',
 'location': ('https://github.com/openstack/networking-cisco')},
"""

This will then include that plugin as part of the future neutron-server 
builds.

If the requirement is to have Kolla publish a neutron-server container 
with *only* the Cisco plugin, then this is where it gets a little more 
tricky. Sure, we can go the route that's proposed in your patch, but we 
end up then maintaining a massive number of neutron-server containers, 
one per plugin. It also does not address then the issue of what people 
want to do when they want a combination or mix of plugins together.

So right now I feel Kolla takes a middle ground, where we publish a 
neutron-server container with a variety of common plugins. If operators 
have specific requirements, they should create their own config file and 
build their own images, which we expect any serious production setup to 
be doing anyway.

-Paul
    
On 10/05/18 18:12, Sandhya Dasu (sadasu) wrote:
> Yes, I think there is some misunderstanding on what I am trying to 
accomplish here.
> 
> I am utilizing existing Kolla constructs to prove that they work for 3rd 
party out of tree vendor drivers too.
> At this point, anything that a 3rd party vendor driver does (the way they 
build their containers, where they publish it and how they generate config) is 
completely out of scope of Kolla.
> 
> I want to use the spec as a place to articulate and discuss best 
practices and figure out what part of supporting 3rd party vendor drivers can 
stay within the Kolla tree and what should be out.
> I have witnessed many discussions on this topic but they only take away I 
get is “there are ways to do it but it can’t be part of Kolla”.
> 
> Using the existing kolla constructs of template-override, plugin-archive 
and config-dir, let us say the 3rd party vendor builds a container.
> OpenStack TC does not want these containers to be part of 
tarballs.openstack.org. Kolla publishes its containers to DockerHub under the 
Kolla project.
> If these 3rd party vendor drivers publish to Dockerhub they will have to 
publish under a different project. So, an OpenStack installation that needs 
these drivers will have to pull images from 2 or more Dokerhub projects?!
> 
> Or do you prefer if the OpenStack operator build their own images using 
the out-of-tree Dockerfile for that vendor?
> 
> Again, should the config changes to support these drivers be part of the 
kolla-ansible repo or should they be out-of-tree?
> 
> It is

Re: [openstack-dev] Need advice on https://review.openstack.org/#/c/521632/

[Sandhya Dasu (sadasu)]

Thanks for your comments Emilien!
Yes, planning to keep the manifest, just removing the ping test and the code 
that is dependent on that succeeding.

Uploading a new PS to reflect this approach.

Thanks,
Sandhya

On 12/11/17, 12:22 PM, "Emilien Macchi" <emil...@redhat.com> wrote:

Hi Sandhya,

See inline:

On Mon, Dec 11, 2017 at 8:49 AM, Sandhya Dasu (sadasu) <sad...@cisco.com> 
wrote:
> Hi Steven and Emilien,
>
> I need your advice on how to proceed with the fix in
> https://review.openstack.org/#/c/521632/.
>
>
>
> The issue in question is that code in puppet-neutron for the Nexus switch,
> performs a ping test to see if all the Nexus switches specified in the
> configuration are actually reachable.
>
> After that it performs a ssh-keyscan and adds the list of Nexus switches 
to
> the list on known hosts on the Controllers.
>
> Code can be viewed here:
> 
https://github.com/openstack/puppet-neutron/blob/master/manifests/plugins/ml2/cisco/nexus_creds.pp
> (starting from line #104)
>
> I spoke to Emilien about this during the Sydney summit.
>
>
>
> Since then I have tried a bunch of different ways to solve this problem 
and
> I am trying to figure out the best way to proceed:
>
>
>
> 1.   Adding retry login around the ping test:
> https://review.openstack.org/#/c/521632/2
>
> 2.   Changing the order in which Neutron ML2 plugins/services were
> initialized in https://review.openstack.org/#/c/521632/8 (Failed gate
> checks)
>
> 3.   I also tried to remove a dependency between the ping test and the
> ssh-keyscan steps. (code in https://review.openstack.org/#/c/521632/7)
>
> 4.   Finally, in the latest version of the fix I completely removed 
the
> ping test and ssh-keyscan steps to make progress.
> (https://review.openstack.org/#/c/521632/)
>
>
>
> Although, the ping test and ssh-keyscan are not essential for the
> functioning of the Nexus driver, I would like to find a way to keep this
> code.
>
>
>
> Please let me know what would be the best way to proceed.

IMHO this code shouldn't exist. I've never seen any Puppet code
testing "ping" during a deployment.
You should rather make sure that Nexus switches are ready and
available before performing any deployment with puppet-neutron (with
Ansible for example).
But doing it with Puppet is kind of the wrong way I think.
Let me know if that makes sense but I would rather keep his manifest
to manage config files and remove this code in the future.
-- 
Emilien Macchi


__
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-dev] Need advice on https://review.openstack.org/#/c/521632/

[Sandhya Dasu (sadasu)]

Hi Steven and Emilien,
I need your advice on how to proceed with the fix in 
https://review.openstack.org/#/c/521632/.

The issue in question is that code in puppet-neutron for the Nexus switch, 
performs a ping test to see if all the Nexus switches specified in the 
configuration are actually reachable.
After that it performs a ssh-keyscan and adds the list of Nexus switches to the 
list on known hosts on the Controllers.
Code can be viewed here: 
https://github.com/openstack/puppet-neutron/blob/master/manifests/plugins/ml2/cisco/nexus_creds.pp
 (starting from line #104)
I spoke to Emilien about this during the Sydney summit.

Since then I have tried a bunch of different ways to solve this problem and I 
am trying to figure out the best way to proceed:


1.   Adding retry login around the ping test: 
https://review.openstack.org/#/c/521632/2

2.   Changing the order in which Neutron ML2 plugins/services were 
initialized in https://review.openstack.org/#/c/521632/8 (Failed gate checks)

3.   I also tried to remove a dependency between the ping test and the 
ssh-keyscan steps. (code in https://review.openstack.org/#/c/521632/7)

4.   Finally, in the latest version of the fix I completely removed the 
ping test and ssh-keyscan steps to make progress. 
(https://review.openstack.org/#/c/521632/)

Although, the ping test and ssh-keyscan are not essential for the functioning 
of the Nexus driver, I would like to find a way to keep this code.

Please let me know what would be the best way to proceed.

Thanks,
Sandhya

__
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

Re: [openstack-dev] Re : [Neutron] Denver Team Dinner

[Sandhya Dasu (sadasu)]

+1

Thanks for organizing.

On 9/13/17, 7:28 AM, "Thomas Morin"  wrote:

+1

-Thomas


Takashi Yamamoto, 2017-09-13 03:05:
> +1
> 
> On Wed, Sep 13, 2017 at 2:56 AM, IWAMOTO Toshihiro
>  wrote:
> > +1
> > thanks for organizing!
> > 
> > On Wed, 13 Sep 2017 14:18:45 +0900,
> > Brian Haley wrote:
> > > 
> > > +1
> > > 
> > > On 09/12/2017 10:44 PM, Ihar Hrachyshka wrote:
> > > > +1
> > > > 
> > > > On Tue, Sep 12, 2017 at 9:44 PM, Kevin Benton  > > > > wrote:
> > > > > +1
> > > > > 
> > > > > On Tue, Sep 12, 2017 at 8:50 PM, Sławek Kapłoński  > > > > lonski.pl>
> > > > > wrote:
> > > > > > 
> > > > > > +1
> > > > > > 
> > > > > > —
> > > > > > Best regards
> > > > > > Slawek Kaplonski
> > > > > > sla...@kaplonski.pl
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > Wiadomość napisana przez Miguel Lavalle  > > > > > > com> w dniu
> > > > > > > 12.09.2017, o godz. 17:23:
> > > > > > > 
> > > > > > > Dear Neutrinos,
> > > > > > > 
> > > > > > > Our social event will take place on Thursday September
> > > > > > > 12th at 7:30pm.
> > > > > > > The venue is going to be https://www.famousdaves.com/Denv
> > > > > > > er-Stapleton. It is
> > > > > > > located 0.4 miles from the Renaissance Hotel, which
> > > > > > > translates to an easy 9
> > > > > > > minutes walk.
> > > > > > > 
> > > > > > > I have a reservation for a group of 30 people under my
> > > > > > > name. Please
> > > > > > > respond to this message with your attendance confirmation
> > > > > > > by Wednesday
> > > > > > > night, so I can get a more accurate head count.
> > > > > > > 
> > > > > > > Looking forward to see y'all Thursday night
> > > > > > > 
> > > > > > > Best regards
> > > > > > > 
> > > > > > > Miguel
> > > > > > > 
> > > > > > > _
> > > > > > > _
> > > > > > > OpenStack Development Mailing List (not for usage
> > > > > > > questions)
> > > > > > > Unsubscribe:
> > > > > > > openstack-dev-requ...@lists.openstack.org?subject:unsubsc
> > > > > > > ribe
> > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opens
> > > > > > > tack-dev
> > > > > > 
> > > > > > 
> > > > > > ___
> > > > > > ___
> > > > > > OpenStack Development Mailing List (not for usage
> > > > > > questions)
> > > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
> > > > > > ect:unsubscribe
> > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/opensta
> > > > > > ck-dev
> > > > > > 
> > > > > 
> > > > > 
> > > > > _
> > > > > _
> > > > > OpenStack Development Mailing List (not for usage questions)
> > > > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subjec
> > > > > t: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-d
> > > > ev
> > > > 
> > > 
> > > 
> > > _
> > > _
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
> > > subscribe
> > > 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:unsu
> > bscribe
> > 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:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Sandhya Dasu (sadasu)]

+1

Looking fwd to it.

Sandhya

From: Sukhdev Kapur >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, October 27, 2016 at 5:57 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

+1

Count me in...

-Sukhdev


On Fri, Oct 14, 2016 at 11:30 AM, Miguel Lavalle 
> wrote:
Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30. After 
doing some Google research, I am proposing Raco de la Vila, which is located in 
Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a 
final count.

Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel

__
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

Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

[Sandhya Dasu (sadasu)]

Hi Miguel,
Both time slots work for me. Thanks for rekindling this effort.

Thanks,
Sandhya

From: Miguel Ángel Ajo majop...@redhat.commailto:majop...@redhat.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, April 7, 2015 1:45 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote:
On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando 
sorla...@nicira.commailto:sorla...@nicira.com wrote:


On 7 April 2015 at 00:33, Armando M. 
arma...@gmail.commailto:arma...@gmail.com wrote:

On 6 April 2015 at 08:56, Miguel Ángel Ajo 
majop...@redhat.commailto:majop...@redhat.com wrote:
I’d like to co-organized a QoS weekly meeting with Sean M. Collins,

In the last few years, the interest for QoS support has increased, Sean has 
been leading
this effort [1] and we believe we should get into a consensus about how to 
model an extension
to let vendor plugins implement QoS capabilities on network ports and tenant 
networks, and
how to extend agents, and the reference implementation  others [2]

As you surely know, so far every attempt to achieve a consensus has failed in a 
pretty miserable way.
This mostly because QoS can be interpreted in a lot of different ways, both 
from the conceptual and practical perspective.
Yes, I’m fully aware of it, it was also a new feature, so it was out of scope 
for Kilo.
It is important in my opinion to clearly define the goals first. For instance a 
simple extensions for bandwidth limiting could be a reasonable target for the 
Liberty release.
I quite agree here, but IMHO, as you said it’s a quite open field (limiting, 
guaranteeing,
marking, traffic shaping..), we should do our best in trying to define a model 
allowing us
to build that up in the future without huge changes, on the API side I guess 
micro versioning
is going to help in the API evolution.

Also, at some point, we should/could need to involve the nova folks, for 
example, to define
port flavors that can be associated to nova
instance flavors, providing them
1) different types of network port speeds/guarantees/priorities,
2) being able to schedule instance/ports in coordination to be able to met 
specified guarantees.

yes, complexity can sky rocket fast,
Moving things such as ECN into future works is the right thing to do in my 
opinion. Attempting to define a flexible framework that can deal with advanced 
QoS policies specification is a laudable effort, but I am a bit skeptical about 
its feasibility.

++, I think focusing on perhaps bandwidth limiting may make a lot of sense
Yes, I believe we should look into the future , but at the same pick our very 
first feature (or a
very simple set of them) for L, stick to it, and try to make a design that can 
be extended.



As per discussion we’ve had during the last few months [3], I believe we 
should start simple, but
prepare a model allowing future extendibility, to allow for example specific 
traffic rules (per port,
per IP, etc..), congestion notification support [4], …

Simple in my mind is even more extreme then what you're proposing here... I'd 
start with bare APIs for specifying bandwidth limiting, and then phase them out 
once this framework is in place.
Also note that this kind of design bears some overlap with the flavor framework 
which is probably going to be another goal for Liberty.

Indeed, and the flavor framework is something I'm hoping we can land by 
Liberty-1 (yes, I just said Liberty-1).
Yes it’s something I looked at, I must admit I wasn’t able to see it work 
together (It doesn’t
mean it doesn’t play well, but most probably I was silly enough not to see it 
:) ),

I didn’t want to distract attention from the Kilo cycle focus making questions, 
so it should
be a good thing to talk about during the first meetings.

Who are the flavor fathers/mothers? ;)


Morever, consider using common tools such as the specs repo to share and 
discuss design documents.

Also a good idea.
Yes, that was the plan now, we didn’t use it before to avoid creating 
unnecessary noise during this cycle.



It’s the first time I’m trying to organize an openstack/neutron meeting, 
so, I don’t know what’s the
best way to do it, or find the best timeslot. I guess interested people may 
have a saying, so I’ve
looped anybody I know is interested in the CC of this mail.

I think that's a good idea. Incidentally I was speaking with Sean regarding 
Summit session [1], and we were hoping we could get some folks together either 
prior or during the summit, to try and get some momentum going behind this 
initiative, once again.
Very interesting [1]!, nice to see we start to have a bunch of people with an 
interest in QoS.

I think is a good idea as well.  I 

Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

[Sandhya Dasu (sadasu)]

Hi Steve,
For SR-IOV testing we have a CI job running on a multi node setup with
Cisco SR-IOV NIC doing API testing on Neutron patches. It is not reporting
results up to Neutron yet and currently is used for internal testing only.

We are working on the following:
1. Getting the full Tempest tests to pass on this testbed.
2. Writing new tempest tests specifically for SR-IOV
3. Running CI tests on Nova patches (in addition to Neutron patches)

I would be the point of contact for this CI testbed.

Thanks,
Sandhya

On 11/16/14 8:31 AM, Irena Berezovsky ire...@mellanox.com wrote:

Hi Steve,
Regarding SR-IOV testing, at Mellanox we have CI job running on bare
metal node with Mellanox SR-IOV NIC.  This job is reporting on neutron
patches. Currently API tests are executed.
The contact person for SRIOV CI job is listed at driverlog:
https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#
L1439

The following items are in progress:
 - SR-IOV functional testing
 - Reporting CI job on nova patches
 - Multi-node setup
It worth to mention that we   want to start the collaboration on SR-IOV
testing effort as part of the pci pass-through subteam activity.
Please join the weekly meeting if you want to collaborate or have some
inputs: https://wiki.openstack.org/wiki/Meetings/Passthrough

BR,
Irena

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com]
Sent: Wednesday, November 12, 2014 9:11 PM
To: itai mendelsohn; Adrian Hoban; Russell Bryant; Ian Wells (iawells);
Irena Berezovsky; ba...@cisco.com
Cc: Nikola Đipanov; Russell Bryant; OpenStack Development Mailing List
(not for usage questions)
Subject: [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other
features that can't be tested on current infra.

Hi all,

We had some discussions last week - particularly in the Nova NFV design
session [1] - on the subject of ensuring that telecommunications and
NFV-related functionality has adequate continuous integration testing. In
particular the focus here is on functionality that can't easily be tested
on the public clouds that back the gate, including:

- NUMA (vCPU pinning, vCPU layout, vRAM layout, huge pages, I/O device
locality)
- SR-IOV with Intel, Cisco, and Mellanox devices (possibly others)
  
In each case we need to confirm where we are at, and the plan going
forward, with regards to having:

1) Hardware to run the CI on.
2) Tests that actively exercise the functionality (if not already in
existence).
3) Point person for each setup to maintain it and report into the
third-party meeting [2].
4) Getting the jobs operational and reporting [3][4][5][6].

In the Nova session we discussed a goal of having the hardware by K-1
(Dec 18) and having it reporting at least periodically by K-2 (Feb 5).
I'm not sure if similar discussions occurred on the Neutron side of the
design summit.

SR-IOV
==

Adrian and Irena mentioned they were already in the process of getting up
to speed with third party CI for their respective SR-IOV configurations.
Robert are you attempting similar with regards to Cisco devices? What is
the status of each of these efforts versus the four items I lifted above
and what do you need assistance with?

NUMA


We still need to identify some hardware to run third party CI for the
NUMA-related work, and no doubt other things that will come up. It's
expected that this will be an interim solution until OPNFV resources can
be used (note cdub jokingly replied 1-2 years when asked for a rough
estimate - I mention this because based on a later discussion some people
took this as a serious estimate).

Ian did you have any luck kicking this off? Russell and I are also
endeavouring to see what we can do on our side w.r.t. this short term
approach - in particular if you find hardware we still need to find an
owner to actually setup and manage it as discussed.

In theory to get started we need a physical multi-socket box and a
virtual machine somewhere on the same network to handle job control etc.
I believe the tests themselves can be run in VMs (just not those exposed
by existing public clouds) assuming a recent Libvirt and an appropriately
crafted Libvirt XML that ensures the VM gets a multi-socket topology etc.
(we can assist with this).

Thanks,

Steve

[1] https://etherpad.openstack.org/p/kilo-nova-nfv
[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
[3] http://ci.openstack.org/third_party.html
[4] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
[5] 
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-sys
tem/
[6] 
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-sys
tem-part-2/
___
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

Re: [openstack-dev] Informal meeting before SR-IOV summit presentation

[Sandhya Dasu (sadasu)]

Developer Lounge at 1 PM today!!

Thanks,
Sandhya

On 5/12/14 10:23 AM, Irena Berezovsky ire...@mellanox.com wrote:

Hi all,
Where are we going to meet for this meeting at 1:00 pm today?

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Friday, May 09, 2014 10:52 PM
To: Sandhya Dasu (sadasu); Brent Eagles; Steve Gordon
Cc: Dan Smith; OpenStack Development Mailing List (not for usage
questions); John Garbutt; Russell Bryant; yunhong-jiang; Itzik Brown;
Yongli He; Jay Pipes; Irena Berezovsky
Subject: Re: Informal meeting before SR-IOV summit presentation

the program pods area should be open.

On 5/9/14, 3:33 PM, Sandhya Dasu (sadasu) sad...@cisco.com wrote:

I have no idea, how to pick a location.
Should we meet at the Cisco booth at 1pm and then take it from there?

Any other ideas?

Thanks,
sandhya

On 5/9/14 3:17 PM, Brent Eagles beag...@redhat.com wrote:

On 09/05/14 04:21 PM, Sandhya Dasu (sadasu) wrote:
 Thanks for all your replies.

 Thanks for the great inputs on how to frame the discussion in the
etherpad  so it becomes easier for people to get on board. We will
add author indent  to track the source of the changes. Will work on
cleaning that up.

 Regarding the session itself, as you probably know, there was an
attempt  in Icehouse to get the sr-iov work going. We found that the
time allotted  for the session was not sufficient to get to all the
use cases and discuss  alternate views.

 This time around we want to be better prepared and so would like to
keep  only a couple of open times for the actual session. Hence, the
request for  the early meeting.

 How does Monday 1pm sound?

 Thanks,
 Sandhya

That time is good with me.

Cheers,

Brent





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Informal meeting before SR-IOV summit presentation

[Sandhya Dasu (sadasu)]

Thanks for all your replies.

Thanks for the great inputs on how to frame the discussion in the etherpad
so it becomes easier for people to get on board. We will add author indent
to track the source of the changes. Will work on cleaning that up.

Regarding the session itself, as you probably know, there was an attempt
in Icehouse to get the sr-iov work going. We found that the time allotted
for the session was not sufficient to get to all the use cases and discuss
alternate views. 

This time around we want to be better prepared and so would like to keep
only a couple of open times for the actual session. Hence, the request for
the early meeting. 

How does Monday 1pm sound?

Thanks,
Sandhya

On 5/9/14 11:44 AM, Steve Gordon sgor...@redhat.com wrote:

- Original Message -
 From: Robert Li (baoli) ba...@cisco.com
 Subject: Re: Informal meeting before SR-IOV summit presentation
 
 This is the one that Irena created:
 https://etherpad.openstack.org/p/pci_passthrough_cross_project

Thanks, I missed this as it wasn't linked from the design summit Wiki
page.

-Steve

 On 5/8/14, 4:33 PM, Steve Gordon sgor...@redhat.com wrote:
 
 - Original Message -
   It would be nice to have an informal discussion / unconference
session
   before the actual summit session on SR-IOV. During the previous IRC
   meeting, we were really close to identifying the different use
cases.
   There was a dangling discussion on introducing another level of
   indirection between the vnic_types exposed via the nova boot API
and
 how
   it would be represented internally. It would be ideal to have
these 2
   discussions converged before the summit session.
  
  What would be the purpose of doing that before the session? IMHO, a
  large part of being able to solve this problem is getting everyone
up to
  speed on what this means, what the caveats are, and what we're
trying to
  solve. If we do some of that outside the scope of the larger
audience, I
  expect we'll get less interaction (or end up covering it again) in
the
  session.
  
  That said, if there's something I'm missing that needs to be resolved
  ahead of time, then that's fine, but I expect the best plan is to
just
  keep the discussion to the session. Afterwards, additional things
can be
  discussed in a one-off manner, but getting everyone on the same page
is
  largely the point of having a session in the first place IMHO.
 
 Right, in spite of my previous response...looking at the etherpad there
 is nothing there to frame the discussion at the moment:
 
 https://etherpad.openstack.org/p/juno-nova-sriov-support
 
 I think populating this should be a priority rather than organizing
 another session/meeting?
 
 Steve
 
 

-- 
Steve Gordon, RHCE
Product Manager, Red Hat Enterprise Linux OpenStack Platform
Red Hat Canada (Toronto, Ontario)


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Informal meeting before SR-IOV summit presentation

[Sandhya Dasu (sadasu)]

I have no idea, how to pick a location.
Should we meet at the Cisco booth at 1pm and then take it from there?

Any other ideas?

Thanks,
sandhya

On 5/9/14 3:17 PM, Brent Eagles beag...@redhat.com wrote:

On 09/05/14 04:21 PM, Sandhya Dasu (sadasu) wrote:
 Thanks for all your replies.

 Thanks for the great inputs on how to frame the discussion in the
etherpad
 so it becomes easier for people to get on board. We will add author
indent
 to track the source of the changes. Will work on cleaning that up.

 Regarding the session itself, as you probably know, there was an attempt
 in Icehouse to get the sr-iov work going. We found that the time
allotted
 for the session was not sufficient to get to all the use cases and
discuss
 alternate views.

 This time around we want to be better prepared and so would like to keep
 only a couple of open times for the actual session. Hence, the request
for
 the early meeting.

 How does Monday 1pm sound?

 Thanks,
 Sandhya

That time is good with me.

Cheers,

Brent



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Informal meeting before SR-IOV summit presentation

[Sandhya Dasu (sadasu)]

Hi,
  It would be nice to have an informal discussion / unconference session
before the actual summit session on SR-IOV. During the previous IRC
meeting, we were really close to identifying the different use cases.
There was a dangling discussion on introducing another level of
indirection between the vnic_types exposed via the nova boot API and how
it would be represented internally. It would be ideal to have these 2
discussions converged before the summit session.

If you are interested in attending please reply and also add a date and
time that would work for you.

Thanks,
Sandhya



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

[Sandhya Dasu (sadasu)]

Hi Irena,
My MD has to take care of admin state changes since I have no L2
agent. I think that is what Bob also alluded to. That being said, I am not
doing anything specific to handle admin_state_up/down. The SR-IOV port on
my device is always going to be up, for now atleast.

Thanks,
Sandhya

On 3/5/14 1:56 AM, Irena Berezovsky ire...@mellanox.com wrote:

Hi Robert,
Seems to me that many code lines are duplicated following your proposal.
For agent based MDs, I would prefer to inherit from
SimpleAgentMechanismDriverBase and add there verify method for
supported_pci_vendor_info. Specific MD will pass the list of supported
pci_vendor_info list. The  'try_to_bind_segment_for_agent' method will
call 'supported_pci_vendor_info', and if supported continue with binding
flow. 
Maybe instead of a decorator method, it should be just an utility method?
I think that the check for supported vnic_type and pci_vendor info
support, should be done in order to see if MD should bind the port. If
the answer is Yes, no more checks are required.

Coming back to the question I asked earlier, for non-agent MD, how would
you deal with updates after port is bound, like 'admin_state_up' changes?
I'll try to push some reference code later today.

BR,
Irena

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Wednesday, March 05, 2014 4:46 AM
To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for
usage questions); Irena Berezovsky; Robert Kukura; Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
binding of ports

Hi Sandhya,

I agree with you except that I think that the class should inherit from
MechanismDriver. I took a crack at it, and here is what I got:

# Copyright (c) 2014 OpenStack Foundation # All Rights Reserved.
#
#Licensed under the Apache License, Version 2.0 (the License); you
may
#not use this file except in compliance with the License. You may
obtain
#a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
#Unless required by applicable law or agreed to in writing, software
#distributed under the License is distributed on an AS IS BASIS,
WITHOUT
#WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
the
#License for the specific language governing permissions and
limitations
#under the License.

from abc import ABCMeta, abstractmethod

import functools
import six

from neutron.extensions import portbindings from neutron.openstack.common
import log from neutron.plugins.ml2 import driver_api as api

LOG = log.getLogger(__name__)


DEFAULT_VNIC_TYPES_SUPPORTED = [portbindings.VNIC_DIRECT,
portbindings.VNIC_MACVTAP]

def check_vnic_type_and_vendor_info(f):
@functools.wraps(f)
def wrapper(self, context):
vnic_type = context.current.get(portbindings.VNIC_TYPE,
portbindings.VNIC_NORMAL)
if vnic_type not in self.supported_vnic_types:
LOG.debug(_(%(func_name)s: skipped due to unsupported 
vnic_type: %(vnic_type)s),
  {'func_name': f.func_name, 'vnic_type': vnic_type})
return

if self.supported_pci_vendor_info:
profile = context.current.get(portbindings.PROFILE, {})
if not profile:
LOG.debug(_(%s: Missing profile in port binding),
  f.func_name)
return
pci_vendor_info = profile.get('pci_vendor_info')
if not pci_vendor_info:
LOG.debug(_(%s: Missing pci vendor info in profile),
  f.func_name)
return
if pci_vendor_info not in self.supported_pci_vendor_info:
LOG.debug(_(%(func_name)s: unsupported pci vendor 
info: %(info)s),
  {'func_name': f.func_name, 'info':
pci_vendor_info})
return
f(self, context)
return wrapper

@six.add_metaclass(ABCMeta)
class SriovMechanismDriverBase(api.MechanismDriver):
Base class for drivers that supports SR-IOV

The SriovMechanismDriverBase provides common code for mechanism
drivers that supports SR-IOV. Such a driver may or may not require
an agent to be running on the port's host.

MechanismDrivers that uses this base class and requires an agent must
pass the agent type to __init__(), and must implement
try_to_bind_segment_for_agent() and check_segment_for_agent().

MechanismDrivers that uses this base class may provide supported
vendor
information, and must provide the supported vnic types.

def __init__(self, agent_type=None, supported_pci_vendor_info=[],
 supported_vnic_types=DEFAULT_VNIC_TYPES_SUPPORTED):
Initialize base class for SR-IOV capable Mechanism Drivers

:param agent_type: Constant identifying agent type in agents_db

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

[Sandhya Dasu (sadasu)]

Hi,
During today's meeting, it was decided that we would re-purpose
Robert's   
https://blueprints.launchpad.net/neutron/+spec/pci-passthrough-sriov to
take care of adding a Base class to take care of common processing for
SR-IOV ports.

This class would:

1. Inherits from AgentMechanismDriverBase.
2. Implements bind_port() where the binding:profile would be checked to
see if the port's vnic_type is VNIC_DIRECT or VNIC_MACVTAP.
3. Also checks to see that port belongs to vendor/product that supports
SR-IOV.
4. This class could be used by MDs that may or may not have a valid L2
agent.
5. Implement validate_port_binding(). This will always return True for Mds
that do not have an L2 agent.

Please let me know if I left out anything.

Thanks,
Sandhya
On 2/25/14 9:18 AM, Sandhya Dasu (sadasu) sad...@cisco.com wrote:

Hi,
As a follow up from today's IRC, Irena, are you looking to write the
below mentioned Base/Mixin class that inherits from
AgentMechanismDriverBase class? When you mentioned port state, were you
referring to the validate_port_binding() method?

Pls clarify.

Thanks,
Sandhya

On 2/6/14 7:57 AM, Sandhya Dasu (sadasu) sad...@cisco.com wrote:

Hi Bob and Irena,
   Thanks for the clarification. Irena, I am not opposed to a
SriovMechanismDriverBase/Mixin approach, but I want to first figure out
how much common functionality there is. Have you already looked at this?

Thanks,
Sandhya

On 2/5/14 1:58 AM, Irena Berezovsky ire...@mellanox.com wrote:

Please see inline my understanding

-Original Message-
From: Robert Kukura [mailto:rkuk...@redhat.com]
Sent: Tuesday, February 04, 2014 11:57 PM
To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for
usage questions); Irena Berezovsky; Robert Li (baoli); Brian Bowen
(brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
binding of ports

On 02/04/2014 04:35 PM, Sandhya Dasu (sadasu) wrote:
 Hi,
  I have a couple of questions for ML2 experts regarding support of
 SR-IOV ports.

I'll try, but I think these questions might be more about how the
various
SR-IOV implementations will work than about ML2 itself...

 1. The SR-IOV ports would not be managed by ova or linuxbridge L2
 agents. So, how does a MD for SR-IOV ports bind/unbind its ports to
 the host? Will it just be a db update?

I think whether or not to use an L2 agent depends on the specific SR-IOV
implementation. Some (Mellanox?) might use an L2 agent, while others
(Cisco?) might put information in binding:vif_details that lets the nova
VIF driver take care of setting up the port without an L2 agent.
[IrenaB] Based on VIF_Type that MD defines, and going forward with other
binding:vif_details attributes, VIFDriver should do the VIF pluging
part.
As for required networking configuration is required, it is usually done
either by L2 Agent or external Controller, depends on MD.

 
 2. Also, how do we handle the functionality in mech_agent.py, within
 the SR-IOV context?

My guess is that those SR-IOV MechanismDrivers that use an L2 agent
would
inherit the AgentMechanismDriverBase class if it provides useful
functionality, but any MechanismDriver implementation is free to not use
this base class if its not applicable. I'm not sure if an
SriovMechanismDriverBase (or SriovMechanismDriverMixin) class is being
planned, and how that would relate to AgentMechanismDriverBase.

[IrenaB] Agree with Bob, and as I stated before I think there is a need
for SriovMechanismDriverBase/Mixin that provides all the generic
functionality and helper methods that are common to SRIOV ports.
-Bob

 
 Thanks,
 Sandhya
 
 From: Sandhya Dasu sad...@cisco.com mailto:sad...@cisco.com
 Reply-To: OpenStack Development Mailing List (not for usage
questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Monday, February 3, 2014 3:14 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org, Irena Berezovsky
 ire...@mellanox.com mailto:ire...@mellanox.com, Robert Li
(baoli)
 ba...@cisco.com mailto:ba...@cisco.com, Robert Kukura
 rkuk...@redhat.com mailto:rkuk...@redhat.com, Brian Bowen
 (brbowen) brbo...@cisco.com mailto:brbo...@cisco.com
 Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
 extra hr of discussion today
 
 Hi,
 Since, openstack-meeting-alt seems to be in use, baoli and myself
 are moving to openstack-meeting. Hopefully, Bob Kukura  Irena can
 join soon.
 
 Thanks,
 Sandhya
 
 From: Sandhya Dasu sad...@cisco.com mailto:sad...@cisco.com
 Reply-To: OpenStack Development Mailing List (not for usage
questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Monday, February 3, 2014 1:26 PM
 To: Irena Berezovsky ire...@mellanox.com
 mailto:ire...@mellanox.com, Robert Li (baoli) ba...@cisco.com
 mailto:ba...@cisco.com, Robert Kukura rkuk...@redhat.com
 mailto:rkuk...@redhat.com, OpenStack

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

[Sandhya Dasu (sadasu)]

Hi,
As a follow up from today's IRC, Irena, are you looking to write the
below mentioned Base/Mixin class that inherits from
AgentMechanismDriverBase class? When you mentioned port state, were you
referring to the validate_port_binding() method?

Pls clarify.

Thanks,
Sandhya

On 2/6/14 7:57 AM, Sandhya Dasu (sadasu) sad...@cisco.com wrote:

Hi Bob and Irena,
   Thanks for the clarification. Irena, I am not opposed to a
SriovMechanismDriverBase/Mixin approach, but I want to first figure out
how much common functionality there is. Have you already looked at this?

Thanks,
Sandhya

On 2/5/14 1:58 AM, Irena Berezovsky ire...@mellanox.com wrote:

Please see inline my understanding

-Original Message-
From: Robert Kukura [mailto:rkuk...@redhat.com]
Sent: Tuesday, February 04, 2014 11:57 PM
To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for
usage questions); Irena Berezovsky; Robert Li (baoli); Brian Bowen
(brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
binding of ports

On 02/04/2014 04:35 PM, Sandhya Dasu (sadasu) wrote:
 Hi,
  I have a couple of questions for ML2 experts regarding support of
 SR-IOV ports.

I'll try, but I think these questions might be more about how the various
SR-IOV implementations will work than about ML2 itself...

 1. The SR-IOV ports would not be managed by ova or linuxbridge L2
 agents. So, how does a MD for SR-IOV ports bind/unbind its ports to
 the host? Will it just be a db update?

I think whether or not to use an L2 agent depends on the specific SR-IOV
implementation. Some (Mellanox?) might use an L2 agent, while others
(Cisco?) might put information in binding:vif_details that lets the nova
VIF driver take care of setting up the port without an L2 agent.
[IrenaB] Based on VIF_Type that MD defines, and going forward with other
binding:vif_details attributes, VIFDriver should do the VIF pluging part.
As for required networking configuration is required, it is usually done
either by L2 Agent or external Controller, depends on MD.

 
 2. Also, how do we handle the functionality in mech_agent.py, within
 the SR-IOV context?

My guess is that those SR-IOV MechanismDrivers that use an L2 agent would
inherit the AgentMechanismDriverBase class if it provides useful
functionality, but any MechanismDriver implementation is free to not use
this base class if its not applicable. I'm not sure if an
SriovMechanismDriverBase (or SriovMechanismDriverMixin) class is being
planned, and how that would relate to AgentMechanismDriverBase.

[IrenaB] Agree with Bob, and as I stated before I think there is a need
for SriovMechanismDriverBase/Mixin that provides all the generic
functionality and helper methods that are common to SRIOV ports.
-Bob

 
 Thanks,
 Sandhya
 
 From: Sandhya Dasu sad...@cisco.com mailto:sad...@cisco.com
 Reply-To: OpenStack Development Mailing List (not for usage
questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Monday, February 3, 2014 3:14 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org, Irena Berezovsky
 ire...@mellanox.com mailto:ire...@mellanox.com, Robert Li (baoli)
 ba...@cisco.com mailto:ba...@cisco.com, Robert Kukura
 rkuk...@redhat.com mailto:rkuk...@redhat.com, Brian Bowen
 (brbowen) brbo...@cisco.com mailto:brbo...@cisco.com
 Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
 extra hr of discussion today
 
 Hi,
 Since, openstack-meeting-alt seems to be in use, baoli and myself
 are moving to openstack-meeting. Hopefully, Bob Kukura  Irena can
 join soon.
 
 Thanks,
 Sandhya
 
 From: Sandhya Dasu sad...@cisco.com mailto:sad...@cisco.com
 Reply-To: OpenStack Development Mailing List (not for usage
questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Monday, February 3, 2014 1:26 PM
 To: Irena Berezovsky ire...@mellanox.com
 mailto:ire...@mellanox.com, Robert Li (baoli) ba...@cisco.com
 mailto:ba...@cisco.com, Robert Kukura rkuk...@redhat.com
 mailto:rkuk...@redhat.com, OpenStack Development Mailing List (not
for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org, Brian Bowen (brbowen)
 brbo...@cisco.com mailto:brbo...@cisco.com
 Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
 extra hr of discussion today
 
 Hi all,
 Both openstack-meeting and openstack-meeting-alt are available
 today. Lets meet at UTC 2000 @ openstack-meeting-alt.
 
 Thanks,
 Sandhya
 
 From: Irena Berezovsky ire...@mellanox.com
 mailto:ire...@mellanox.com
 Date: Monday, February 3, 2014 12:52 AM
 To: Sandhya Dasu sad...@cisco.com mailto:sad...@cisco.com, Robert
 Li (baoli) ba...@cisco.com mailto:ba...@cisco.com, Robert Kukura
 rkuk...@redhat.com mailto:rkuk...@redhat.com, OpenStack
 Development Mailing List (not for usage questions)
 openstack-dev

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

[Sandhya Dasu (sadasu)]

Hi Bob and Irena,
   Thanks for the clarification. Irena, I am not opposed to a
SriovMechanismDriverBase/Mixin approach, but I want to first figure out
how much common functionality there is. Have you already looked at this?

Thanks,
Sandhya

On 2/5/14 1:58 AM, Irena Berezovsky ire...@mellanox.com wrote:

Please see inline my understanding

-Original Message-
From: Robert Kukura [mailto:rkuk...@redhat.com]
Sent: Tuesday, February 04, 2014 11:57 PM
To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for
usage questions); Irena Berezovsky; Robert Li (baoli); Brian Bowen
(brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
binding of ports

On 02/04/2014 04:35 PM, Sandhya Dasu (sadasu) wrote:
 Hi,
  I have a couple of questions for ML2 experts regarding support of
 SR-IOV ports.

I'll try, but I think these questions might be more about how the various
SR-IOV implementations will work than about ML2 itself...

 1. The SR-IOV ports would not be managed by ova or linuxbridge L2
 agents. So, how does a MD for SR-IOV ports bind/unbind its ports to
 the host? Will it just be a db update?

I think whether or not to use an L2 agent depends on the specific SR-IOV
implementation. Some (Mellanox?) might use an L2 agent, while others
(Cisco?) might put information in binding:vif_details that lets the nova
VIF driver take care of setting up the port without an L2 agent.
[IrenaB] Based on VIF_Type that MD defines, and going forward with other
binding:vif_details attributes, VIFDriver should do the VIF pluging part.
As for required networking configuration is required, it is usually done
either by L2 Agent or external Controller, depends on MD.

 
 2. Also, how do we handle the functionality in mech_agent.py, within
 the SR-IOV context?

My guess is that those SR-IOV MechanismDrivers that use an L2 agent would
inherit the AgentMechanismDriverBase class if it provides useful
functionality, but any MechanismDriver implementation is free to not use
this base class if its not applicable. I'm not sure if an
SriovMechanismDriverBase (or SriovMechanismDriverMixin) class is being
planned, and how that would relate to AgentMechanismDriverBase.

[IrenaB] Agree with Bob, and as I stated before I think there is a need
for SriovMechanismDriverBase/Mixin that provides all the generic
functionality and helper methods that are common to SRIOV ports.
-Bob

 
 Thanks,
 Sandhya
 
 From: Sandhya Dasu sad...@cisco.com mailto:sad...@cisco.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Monday, February 3, 2014 3:14 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org, Irena Berezovsky
 ire...@mellanox.com mailto:ire...@mellanox.com, Robert Li (baoli)
 ba...@cisco.com mailto:ba...@cisco.com, Robert Kukura
 rkuk...@redhat.com mailto:rkuk...@redhat.com, Brian Bowen
 (brbowen) brbo...@cisco.com mailto:brbo...@cisco.com
 Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
 extra hr of discussion today
 
 Hi,
 Since, openstack-meeting-alt seems to be in use, baoli and myself
 are moving to openstack-meeting. Hopefully, Bob Kukura  Irena can
 join soon.
 
 Thanks,
 Sandhya
 
 From: Sandhya Dasu sad...@cisco.com mailto:sad...@cisco.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Monday, February 3, 2014 1:26 PM
 To: Irena Berezovsky ire...@mellanox.com
 mailto:ire...@mellanox.com, Robert Li (baoli) ba...@cisco.com
 mailto:ba...@cisco.com, Robert Kukura rkuk...@redhat.com
 mailto:rkuk...@redhat.com, OpenStack Development Mailing List (not
for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org, Brian Bowen (brbowen)
 brbo...@cisco.com mailto:brbo...@cisco.com
 Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV
 extra hr of discussion today
 
 Hi all,
 Both openstack-meeting and openstack-meeting-alt are available
 today. Lets meet at UTC 2000 @ openstack-meeting-alt.
 
 Thanks,
 Sandhya
 
 From: Irena Berezovsky ire...@mellanox.com
 mailto:ire...@mellanox.com
 Date: Monday, February 3, 2014 12:52 AM
 To: Sandhya Dasu sad...@cisco.com mailto:sad...@cisco.com, Robert
 Li (baoli) ba...@cisco.com mailto:ba...@cisco.com, Robert Kukura
 rkuk...@redhat.com mailto:rkuk...@redhat.com, OpenStack
 Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org, Brian Bowen (brbowen)
 brbo...@cisco.com mailto:brbo...@cisco.com
 Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on
 Jan. 30th
 
 Hi Sandhya,
 
 Can you please elaborate how do you suggest to extend the below bp for
 SRIOV Ports managed by different Mechanism Driver?
 
 I am

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

[Sandhya Dasu (sadasu)]

Hi,
 I have a couple of questions for ML2 experts regarding support of SR-IOV 
ports.
1. The SR-IOV ports would not be managed by ova or linuxbridge L2 agents. So, 
how does a MD for SR-IOV ports bind/unbind its ports to the host? Will it just 
be a db update?

2. Also, how do we handle the functionality in mech_agent.py, within the SR-IOV 
context?

Thanks,
Sandhya

From: Sandhya Dasu sad...@cisco.commailto:sad...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, February 3, 2014 3:14 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com, Robert Li 
(baoli) ba...@cisco.commailto:ba...@cisco.com, Robert Kukura 
rkuk...@redhat.commailto:rkuk...@redhat.com, Brian Bowen (brbowen) 
brbo...@cisco.commailto:brbo...@cisco.com
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV extra hr of 
discussion today

Hi,
Since, openstack-meeting-alt seems to be in use, baoli and myself are 
moving to openstack-meeting. Hopefully, Bob Kukura  Irena can join soon.

Thanks,
Sandhya

From: Sandhya Dasu sad...@cisco.commailto:sad...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, February 3, 2014 1:26 PM
To: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com, Robert 
Li (baoli) ba...@cisco.commailto:ba...@cisco.com, Robert Kukura 
rkuk...@redhat.commailto:rkuk...@redhat.com, OpenStack Development Mailing 
List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV extra hr of 
discussion today

Hi all,
Both openstack-meeting and openstack-meeting-alt are available today. Lets 
meet at UTC 2000 @ openstack-meeting-alt.

Thanks,
Sandhya

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Monday, February 3, 2014 12:52 AM
To: Sandhya Dasu sad...@cisco.commailto:sad...@cisco.com, Robert Li 
(baoli) ba...@cisco.commailto:ba...@cisco.com, Robert Kukura 
rkuk...@redhat.commailto:rkuk...@redhat.com, OpenStack Development Mailing 
List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi Sandhya,
Can you please elaborate how do you suggest to extend the below bp for SRIOV 
Ports managed by different Mechanism Driver?
I am not biased to any specific direction here, just think we need common layer 
for managing SRIOV port at neutron, since there is a common pass between nova 
and neutron.

BR,
Irena


From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com]
Sent: Friday, January 31, 2014 6:46 PM
To: Irena Berezovsky; Robert Li (baoli); Robert Kukura; OpenStack Development 
Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi Irena,
  I was initially looking at 
https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port-info 
to take care of the extra information required to set up the SR-IOV port. When 
the scope of the BP was being decided, we had very little info about our own 
design so I didn't give any feedback about SR-IOV ports. But, I feel that this 
is the direction we should be going. Maybe we should target this in Juno.

Introducing, SRIOVPortProfileMixin would be creating yet another way to take 
care of extra port config. Let me know what you think.

Thanks,
Sandhya

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Thursday, January 30, 2014 4:13 PM
To: Robert Li (baoli) ba...@cisco.commailto:ba...@cisco.com, Robert 
Kukura rkuk...@redhat.commailto:rkuk...@redhat.com, Sandhya Dasu 
sad...@cisco.commailto:sad...@cisco.com, OpenStack Development Mailing 
List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Robert,
Thank you very much for the summary.
Please, see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Thursday, January 30, 2014 10:45 PM
To: Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky; OpenStack 
Development Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi,

We made a lot of progress today. We agreed that:
-- vnic_type will be a top level attribute

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV extra hr of discussion today

[Sandhya Dasu (sadasu)]

Hi all,
Both openstack-meeting and openstack-meeting-alt are available today. Lets 
meet at UTC 2000 @ openstack-meeting-alt.

Thanks,
Sandhya

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Monday, February 3, 2014 12:52 AM
To: Sandhya Dasu sad...@cisco.commailto:sad...@cisco.com, Robert Li 
(baoli) ba...@cisco.commailto:ba...@cisco.com, Robert Kukura 
rkuk...@redhat.commailto:rkuk...@redhat.com, OpenStack Development Mailing 
List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi Sandhya,
Can you please elaborate how do you suggest to extend the below bp for SRIOV 
Ports managed by different Mechanism Driver?
I am not biased to any specific direction here, just think we need common layer 
for managing SRIOV port at neutron, since there is a common pass between nova 
and neutron.

BR,
Irena


From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com]
Sent: Friday, January 31, 2014 6:46 PM
To: Irena Berezovsky; Robert Li (baoli); Robert Kukura; OpenStack Development 
Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi Irena,
  I was initially looking at 
https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port-info 
to take care of the extra information required to set up the SR-IOV port. When 
the scope of the BP was being decided, we had very little info about our own 
design so I didn't give any feedback about SR-IOV ports. But, I feel that this 
is the direction we should be going. Maybe we should target this in Juno.

Introducing, SRIOVPortProfileMixin would be creating yet another way to take 
care of extra port config. Let me know what you think.

Thanks,
Sandhya

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Thursday, January 30, 2014 4:13 PM
To: Robert Li (baoli) ba...@cisco.commailto:ba...@cisco.com, Robert 
Kukura rkuk...@redhat.commailto:rkuk...@redhat.com, Sandhya Dasu 
sad...@cisco.commailto:sad...@cisco.com, OpenStack Development Mailing 
List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Robert,
Thank you very much for the summary.
Please, see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Thursday, January 30, 2014 10:45 PM
To: Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky; OpenStack 
Development Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi,

We made a lot of progress today. We agreed that:
-- vnic_type will be a top level attribute as binding:vnic_type
-- BPs:
 * Irena's 
https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type for 
binding:vnic_type
 * Bob to submit a BP for binding:profile in ML2. SRIOV input info will be 
encapsulated in binding:profile
 * Bob to submit a BP for binding:vif_details in ML2. SRIOV output info 
will be encapsulated in binding:vif_details, which may include other 
information like security parameters. For SRIOV, vlan_id and profileid are 
candidates.
-- new arguments for port-create will be implicit arguments. Future release may 
make them explicit. New argument: --binding:vnic_type {virtio, direct, macvtap}.
I think that currently we can make do without the profileid as an input 
parameter from the user. The mechanism driver will return a profileid in the 
vif output.

Please correct any misstatement in above.

Issues:
  -- do we need a common utils/driver for SRIOV generic parts to be used by 
individual Mechanism drivers that support SRIOV? More details on what would be 
included in this sriov utils/driver? I'm thinking that a candidate would be the 
helper functions to interpret the pci_slot, which is proposed as a string. 
Anything else in your mind?
[IrenaB] I thought on some SRIOVPortProfileMixin to handle and persist SRIOV 
port related attributes

  -- what should mechanism drivers put in binding:vif_details and how nova 
would use this information? as far as I see it from the code, a VIF object is 
created and populated based on information provided by neutron (from get 
network and get port)

Questions:
  -- nova needs to work with both ML2 and non-ML2 plugins. For regular plugins, 
binding:vnic_type will not be set, I guess. Then would it be treated as a 
virtio type? And if a non-ML2 plugin wants to support SRIOV, would it need to  
implement vnic-type, binding:profile, binding:vif-details for SRIOV itself?
[IrenaB] vnic_type will be added as an additional attribute to binding 
extension. For persistency it should be added

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV extra hr of discussion today

[Sandhya Dasu (sadasu)]

Hi,
Since, openstack-meeting-alt seems to be in use, baoli and myself are 
moving to openstack-meeting. Hopefully, Bob Kukura  Irena can join soon.

Thanks,
Sandhya

From: Sandhya Dasu sad...@cisco.commailto:sad...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, February 3, 2014 1:26 PM
To: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com, Robert 
Li (baoli) ba...@cisco.commailto:ba...@cisco.com, Robert Kukura 
rkuk...@redhat.commailto:rkuk...@redhat.com, OpenStack Development Mailing 
List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV extra hr of 
discussion today

Hi all,
Both openstack-meeting and openstack-meeting-alt are available today. Lets 
meet at UTC 2000 @ openstack-meeting-alt.

Thanks,
Sandhya

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Monday, February 3, 2014 12:52 AM
To: Sandhya Dasu sad...@cisco.commailto:sad...@cisco.com, Robert Li 
(baoli) ba...@cisco.commailto:ba...@cisco.com, Robert Kukura 
rkuk...@redhat.commailto:rkuk...@redhat.com, OpenStack Development Mailing 
List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi Sandhya,
Can you please elaborate how do you suggest to extend the below bp for SRIOV 
Ports managed by different Mechanism Driver?
I am not biased to any specific direction here, just think we need common layer 
for managing SRIOV port at neutron, since there is a common pass between nova 
and neutron.

BR,
Irena


From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com]
Sent: Friday, January 31, 2014 6:46 PM
To: Irena Berezovsky; Robert Li (baoli); Robert Kukura; OpenStack Development 
Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi Irena,
  I was initially looking at 
https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port-info 
to take care of the extra information required to set up the SR-IOV port. When 
the scope of the BP was being decided, we had very little info about our own 
design so I didn't give any feedback about SR-IOV ports. But, I feel that this 
is the direction we should be going. Maybe we should target this in Juno.

Introducing, SRIOVPortProfileMixin would be creating yet another way to take 
care of extra port config. Let me know what you think.

Thanks,
Sandhya

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Thursday, January 30, 2014 4:13 PM
To: Robert Li (baoli) ba...@cisco.commailto:ba...@cisco.com, Robert 
Kukura rkuk...@redhat.commailto:rkuk...@redhat.com, Sandhya Dasu 
sad...@cisco.commailto:sad...@cisco.com, OpenStack Development Mailing 
List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Robert,
Thank you very much for the summary.
Please, see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Thursday, January 30, 2014 10:45 PM
To: Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky; OpenStack 
Development Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi,

We made a lot of progress today. We agreed that:
-- vnic_type will be a top level attribute as binding:vnic_type
-- BPs:
 * Irena's 
https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type for 
binding:vnic_type
 * Bob to submit a BP for binding:profile in ML2. SRIOV input info will be 
encapsulated in binding:profile
 * Bob to submit a BP for binding:vif_details in ML2. SRIOV output info 
will be encapsulated in binding:vif_details, which may include other 
information like security parameters. For SRIOV, vlan_id and profileid are 
candidates.
-- new arguments for port-create will be implicit arguments. Future release may 
make them explicit. New argument: --binding:vnic_type {virtio, direct, macvtap}.
I think that currently we can make do without the profileid as an input 
parameter from the user. The mechanism driver will return a profileid in the 
vif output.

Please correct any misstatement in above.

Issues:
  -- do we need a common utils/driver for SRIOV generic parts to be used by 
individual Mechanism drivers that support SRIOV? More details on what would be 
included in this sriov utils/driver? I'm thinking that a candidate would be the 
helper

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

[Sandhya Dasu (sadasu)]

Hi Irena,
  I was initially looking at 
https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port-info 
to take care of the extra information required to set up the SR-IOV port. When 
the scope of the BP was being decided, we had very little info about our own 
design so I didn't give any feedback about SR-IOV ports. But, I feel that this 
is the direction we should be going. Maybe we should target this in Juno.

Introducing, SRIOVPortProfileMixin would be creating yet another way to take 
care of extra port config. Let me know what you think.

Thanks,
Sandhya

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Date: Thursday, January 30, 2014 4:13 PM
To: Robert Li (baoli) ba...@cisco.commailto:ba...@cisco.com, Robert 
Kukura rkuk...@redhat.commailto:rkuk...@redhat.com, Sandhya Dasu 
sad...@cisco.commailto:sad...@cisco.com, OpenStack Development Mailing 
List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
Brian Bowen (brbowen) brbo...@cisco.commailto:brbo...@cisco.com
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Robert,
Thank you very much for the summary.
Please, see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Thursday, January 30, 2014 10:45 PM
To: Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky; OpenStack 
Development Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi,

We made a lot of progress today. We agreed that:
-- vnic_type will be a top level attribute as binding:vnic_type
-- BPs:
 * Irena's 
https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type for 
binding:vnic_type
 * Bob to submit a BP for binding:profile in ML2. SRIOV input info will be 
encapsulated in binding:profile
 * Bob to submit a BP for binding:vif_details in ML2. SRIOV output info 
will be encapsulated in binding:vif_details, which may include other 
information like security parameters. For SRIOV, vlan_id and profileid are 
candidates.
-- new arguments for port-create will be implicit arguments. Future release may 
make them explicit. New argument: --binding:vnic_type {virtio, direct, macvtap}.
I think that currently we can make do without the profileid as an input 
parameter from the user. The mechanism driver will return a profileid in the 
vif output.

Please correct any misstatement in above.

Issues:
  -- do we need a common utils/driver for SRIOV generic parts to be used by 
individual Mechanism drivers that support SRIOV? More details on what would be 
included in this sriov utils/driver? I'm thinking that a candidate would be the 
helper functions to interpret the pci_slot, which is proposed as a string. 
Anything else in your mind?
[IrenaB] I thought on some SRIOVPortProfileMixin to handle and persist SRIOV 
port related attributes

  -- what should mechanism drivers put in binding:vif_details and how nova 
would use this information? as far as I see it from the code, a VIF object is 
created and populated based on information provided by neutron (from get 
network and get port)

Questions:
  -- nova needs to work with both ML2 and non-ML2 plugins. For regular plugins, 
binding:vnic_type will not be set, I guess. Then would it be treated as a 
virtio type? And if a non-ML2 plugin wants to support SRIOV, would it need to  
implement vnic-type, binding:profile, binding:vif-details for SRIOV itself?
[IrenaB] vnic_type will be added as an additional attribute to binding 
extension. For persistency it should be added in PortBindingMixin for non ML2. 
I didn’t think to cover it as part of ML2 vnic_type bp.
For the rest attributes, need to see what Bob plans.

 -- is a neutron agent making decision based on the binding:vif_type?  In that 
case, it makes sense for binding:vnic_type not to be exposed to agents.
[IrenaB] vnic_type is input parameter that will eventually cause certain 
vif_type to be sent to GenericVIFDriver and create network interface. Neutron 
agents periodically scan for attached interfaces. For example, OVS agent will 
look only for OVS interfaces, so if SRIOV interface is created, it won’t be 
discovered by OVS agent.

Thanks,
Robert
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

[Sandhya Dasu (sadasu)]

Hi Irena,
   Thanks for pointing out an alternative to the network xml solution to live 
migration. I am still not clear about the solution.

Some questions:

  1.  Where does the rename of the PCI device network interface name occur?
  2.  Can this rename be done for a VF? I think your example shows rename of a 
PF.

Thanks,
Sandhya

From: Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, January 16, 2014 4:43 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

Ian,
Thank you for putting in writing the ongoing discussed specification.
I have added few comments on the Google doc [1].

As for live migration support, this can be done also without libvirt network 
usage.
Not very elegant, but working:  rename the interface of the PCI device to some 
logical name, let’s say based on neutron port UUID and put it into the 
interface XML, i.e.:
If PCI device network interface name  is eth8 and neutron port UUID is   
02bc4aec-b4f4-436f-b651-024 then rename it to something like: eth02bc4aec-b4'. 
The interface XML will look like this:

  ...
interface type='direct'
mac address='fa:16:3e:46:d3:e8'/
source dev='eth02bc4aec-b4' mode='passthrough'/
target dev='macvtap0'/
model type='virtio'/
alias name='net0'/
address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/
/interface


...

[1] 
https://docs.google.com/document/d/1vadqmurlnlvZ5bv3BlUbFeXRS_wh-dsgi5plSjimWjU/edit?pli=1#heading=h.308b0wqn1zde

BR,
Irena
From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Thursday, January 16, 2014 2:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

To clarify a couple of Robert's points, since we had a conversation earlier:
On 15 January 2014 23:47, Robert Li (baoli) 
ba...@cisco.commailto:ba...@cisco.com wrote:
  ---  do we agree that BDF address (or device id, whatever you call it), and 
node id shouldn't be used as attributes in defining a PCI flavor?

Note that the current spec doesn't actually exclude it as an option.  It's just 
an unwise thing to do.  In theory, you could elect to define your flavors using 
the BDF attribute but determining 'the card in this slot is equivalent to all 
the other cards in the same slot in other machines' is probably not the best 
idea...  We could lock it out as an option or we could just assume that 
administrators wouldn't be daft enough to try.
* the compute node needs to know the PCI flavor. [...]
  - to support live migration, we need to use it to create 
network xml

I didn't understand this at first and it took me a while to get what Robert 
meant here.

This is based on Robert's current code for macvtap based live migration.  The 
issue is that if you wish to migrate a VM and it's tied to a physical 
interface, you can't guarantee that the same physical interface is going to be 
used on the target machine, but at the same time you can't change the 
libvirt.xml as it comes over with the migrating machine.  The answer is to 
define a network and refer out to it from libvirt.xml.  In Robert's current 
code he's using the group name of the PCI devices to create a network 
containing the list of equivalent devices (those in the group) that can be 
macvtapped.  Thus when the host migrates it will find another, equivalent, 
interface.  This falls over in the use case under consideration where a device 
can be mapped using more than one flavor, so we have to discard the use case or 
rethink the implementation.

There's a more complex solution - I think - where we create a temporary network 
for each macvtap interface a machine's going to use, with a name based on the 
instance UUID and port number, and containing the device to map.  Before 
starting the migration we would create a replacement network containing only 
the new device on the target host; migration would find the network from the 
name in the libvirt.xml, and the content of that network would behave 
identically.  We'd be creating libvirt networks on the fly and a lot more of 
them, and we'd need decent cleanup code too ('when freeing a PCI device, delete 
any network it's a member of'), so it all becomes a lot more hairy.
--
Ian.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

[Sandhya Dasu (sadasu)]

Hi,
 One use case was brought up in today's meeting that I think is not valid.

It is the use case where all 3 vnic types : Virtio, direct and macvtap (the 
terms used in the meeting were slow, fast, faster/foobar) could be attached to 
the same VM.  The main difference between a direct and macvtap interface is 
that the former does not support live migration. So, attaching both direct and 
macvtap pci-passthrough interfaces to the same VM would mean that it cannot 
support live migration. In that case assigning the macvtap interface is in 
essence a waste.

So, it would be ideal to disallow such an assignment or at least warn the user 
that the VM will now not be able to support live migration.  We can  however 
still combine direct or macvtap pci-passthrough interfaces with virtio vmic 
types without issue.

Thanks,
Sandhya

From: Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Thursday, January 9, 2014 12:47 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

I think I'm in agreement with all of this.  Nice summary, Robert.

It may not be where the work ends, but if we could get this done the rest is 
just refinement.


On 9 January 2014 17:49, Robert Li (baoli) 
ba...@cisco.commailto:ba...@cisco.com wrote:
Hi Folks,

With John joining the IRC, so far, we had a couple of productive meetings in an 
effort to come to consensus and move forward. Thanks John for doing that, and I 
appreciate everyone's effort to make it to the daily meeting. Let's reconvene 
on Monday.

But before that, and based on our today's conversation on IRC, I'd like to say 
a few things. I think that first of all, we need to get agreement on the 
terminologies that we are using so far. With the current nova PCI passthrough

PCI whitelist: defines all the available PCI passthrough devices on a 
compute node. pci_passthrough_whitelist=[{ 
vendor_id:,product_id:}]
PCI Alias: criteria defined on the controller node with which requested 
PCI passthrough devices can be selected from all the PCI passthrough devices 
available in a cloud.
Currently it has the following format: 
pci_alias={vendor_id:, product_id:, name:str}

nova flavor extra_specs: request for PCI passthrough devices can be 
specified with extra_specs in the format for 
example:pci_passthrough:alias=name:count

As you can see, currently a PCI alias has a name and is defined on the 
controller. The implications for it is that when matching it against the PCI 
devices, it has to match the vendor_id and product_id against all the available 
PCI devices until one is found. The name is only used for reference in the 
extra_specs. On the other hand, the whitelist is basically the same as the 
alias without a name.

What we have discussed so far is based on something called PCI groups (or PCI 
flavors as Yongli puts it). Without introducing other complexities, and with a 
little change of the above representation, we will have something like:

pci_passthrough_whitelist=[{ vendor_id:,product_id:, 
name:str}]

By doing so, we eliminated the PCI alias. And we call the name in above as a 
PCI group name. You can think of it as combining the definitions of the 
existing whitelist and PCI alias. And believe it or not, a PCI group is 
actually a PCI alias. However, with that change of thinking, a lot of benefits 
can be harvested:

 * the implementation is significantly simplified
 * provisioning is simplified by eliminating the PCI alias
 * a compute node only needs to report stats with something like: PCI 
group name:count. A compute node processes all the PCI passthrough devices 
against the whitelist, and assign a PCI group based on the whitelist definition.
 * on the controller, we may only need to define the PCI group names. 
if we use a nova api to define PCI groups (could be private or public, for 
example), one potential benefit, among other things (validation, etc),  they 
can be owned by the tenant that creates them. And thus a wholesale of PCI 
passthrough devices is also possible.
 * scheduler only works with PCI group names.
 * request for PCI passthrough device is based on PCI-group
 * deployers can provision the cloud based on the PCI groups
 * Particularly for SRIOV, deployers can design SRIOV PCI groups based 
on network connectivities.

Further, to support SRIOV, we are saying that PCI group names not only can be 
used in the extra specs, it can also be used in the —nic option and the neutron 
commands. This allows the most flexibilities and functionalities afforded by 
SRIOV.

Further, we are saying that we