Re: [openstack-dev] [nova] Contributing support for Netronome Agilio adaptors

2017-04-12 Thread Jan Gutter
Hi,

Apologies for leaving this to the very last minute.

The blueprint and spec has been submitted for your consideration to:

https://blueprints.launchpad.net/nova/+spec/netronome-smartnic-enablement

https://review.openstack.org/#/c/456386/

We're in the final steps of getting the permission to share the
example code, but it might not make it in time for tomorrow.

Please feel free to email me for any questions: I'll try to be on IRC
tomorrow (my timezone is GMT+02:00).

-- 
Jan Gutter
Embedded Networking Software Engineer

Netronome | First Floor Suite 1, Block A, Southdowns Ridge Office Park,
Cnr Nellmapius and John Vorster St, Irene, Pretoria, 0157
Phone: +27 (12) 665-4427 | Skype: jangutter |  www.netronome.com

__
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] [nova] Contributing support for Netronome Agilio adaptors

2017-04-03 Thread Jay Pipes

On 04/03/2017 06:34 AM, Jan Gutter wrote:

Greetings,

Apologies for chiming in very late into the spec cycle. Netronome is
completing its internal processes in order to allow developers to
contribute code to OpenStack and we should be able to share patches
within the week. Additional apologies for the long wall of text that's
following.


LOL, definitely not a long wall of text. :) You should see some of our 
specs repos...



We would really like to upstream support for our NICs in Pike. We've
got patches that hook into core Nova (and make a tiny modification to
the Neutron ML2 OVS mechanism plugin) to allow VM's to be plugged into
our NIC's accelerated ports.


OK, looking forward to seeing that code.


The mechanism that we chose was to add another set of VNIC types (in
the same group where   VNIC_TYPE_NORMAL and VNIC_TYPE_DIRECT are
defined), for the two separate plugging methods that we support. It's
also very possible for us to just add one more (VNIC_TYPE_RELAY) and
have everything work for us.

(we also considered flavor and glance annotations, but chose this
method for flexibility)

We have two methods to plug VMs into the bridge. On Nova's side, they
look either like vhost-user, or SR-IOV passthrough. On Neutron's side,
everything look like an OVS bridge. Crucially, we support all three
methods (standard TAP, SR-IOV and vhost-user) on the _same_ bridge,
with SR-IOV and vhost-user accelerated, and with everything except
SR-IOV being live-migrateable.


Tough to tell, really, whether the approach you took is appropriate 
without seeing the code, so I'll just wait to see it. :)



I'm hoping that, by tomorrow, we'll have the necessary internal
permissions in place to start discussing code. We'd appreciate any
advice on processes and protocol to follow.


From a strictly technical perspective, you can read all about the 
actual contribution mechanics here:


https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer

https://docs.openstack.org/infra/manual/developers.html#development-workflow

We would probably need a short spec/blueprint written up that describes 
the use cases you intend to enable (even if that's just "customers that 
have Netronome NICs would like to allow their cloud users to fully 
utilize the capabilities of those NICs").


The spec process is relatively simple. Just:

 git clone g...@github.com:openstack/nova-specs
 cd nova-specs
 git checkout -b netronome-nic-enablement
 cp specs/pike-template.rst specs/pike/netronome-nic-enablement
 # edit specs/pike/netronome-nic-enablement
 git add .
 git commit
 git review


Would it still be possible to jump on the Pike release?


The deadline for specs is April 13th:

https://releases.openstack.org/pike/schedule.html#p-nova-spec-freeze

Get your spec written and submitted via the process above as soon as 
possible and we'll start reviewing. If you can do it today, that would 
be great since we have a spec review sprint tomorrow...


> There is

absolutely no emotional attachment to this code, so if a major
redesign is on the cards, we'd be very agreeable to do so.

Thanks again very much for reading this sizeable missive. I hope we
can get on board and start contributing to OpenStack as soon as
possible. (There's a lot of automatic tuning, pinning and scheduling
support bits we'd like to contribute as well.)


No worries, join us on #openstack-nova if you have any questions. Happy 
to help.


Best,
-jay

__
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] [nova] Contributing support for Netronome Agilio adaptors

2017-04-03 Thread Jan Gutter
Greetings,

Apologies for chiming in very late into the spec cycle. Netronome is
completing its internal processes in order to allow developers to
contribute code to OpenStack and we should be able to share patches
within the week. Additional apologies for the long wall of text that's
following.

We would really like to upstream support for our NICs in Pike. We've
got patches that hook into core Nova (and make a tiny modification to
the Neutron ML2 OVS mechanism plugin) to allow VM's to be plugged into
our NIC's accelerated ports.

The mechanism that we chose was to add another set of VNIC types (in
the same group where   VNIC_TYPE_NORMAL and VNIC_TYPE_DIRECT are
defined), for the two separate plugging methods that we support. It's
also very possible for us to just add one more (VNIC_TYPE_RELAY) and
have everything work for us.

(we also considered flavor and glance annotations, but chose this
method for flexibility)

We have two methods to plug VMs into the bridge. On Nova's side, they
look either like vhost-user, or SR-IOV passthrough. On Neutron's side,
everything look like an OVS bridge. Crucially, we support all three
methods (standard TAP, SR-IOV and vhost-user) on the _same_ bridge,
with SR-IOV and vhost-user accelerated, and with everything except
SR-IOV being live-migrateable.

I'm hoping that, by tomorrow, we'll have the necessary internal
permissions in place to start discussing code. We'd appreciate any
advice on processes and protocol to follow.

Would it still be possible to jump on the Pike release? There is
absolutely no emotional attachment to this code, so if a major
redesign is on the cards, we'd be very agreeable to do so.

Thanks again very much for reading this sizeable missive. I hope we
can get on board and start contributing to OpenStack as soon as
possible. (There's a lot of automatic tuning, pinning and scheduling
support bits we'd like to contribute as well.)

-- 
Jan Gutter
Embedded Networking Software Engineer

Netronome | First Floor Suite 1, Block A, Southdowns Ridge Office Park,
Cnr Nellmapius and John Vorster St, Irene, Pretoria, 0157
Phone: +27 (12) 665-4427 | Skype: jangutter |  www.netronome.com

__
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