sriov bonding

Manuel Sopena Ballesteros at
Fri Mar 1 01:59:24 UTC 2019


My nic is mellanox connect-4 lx so I was thinking this:
Create bonding at the PF level
use bond interface as br-ext
Do ovs offload

That would mean I don't need to change my switch configuration and keep my LACP.

Does it sounds feasible?

Second question:

OVS offload needs Linux Kernel >= 4.13 can I use CentOS Linux release 7.5.1804 (Core) with kernel 3.10.0-862.el7.x86_64?

Thank you


-----Original Message-----
From: Sean Mooney [mailto:smooney at]
Sent: Wednesday, February 27, 2019 9:36 PM
To: Bence Romsics; openstack at
Subject: Re: sriov bonding

On Wed, 2019-02-27 at 08:38 +0100, Bence Romsics wrote:
> Hi,
> On Wed, Feb 27, 2019 at 8:00 AM Manuel Sopena Ballesteros
> < at> wrote:
> > Is there a documentation that explains how to setup bonding on SR-IOV neutron?
> Not right now to my knowledge, but I remember seeing effort to design
> and introduce this feature. I think there may have been multiple
> rounds of design already, this is maybe the last one that's still
> ongoing:
> Neutron side:
> Nova side:

most of the previous attempts have not proceeded as they have tried to hide the bonding from
nova's and neutron's data models vai  configs or opaque strings.

for bonding to really be supported  at the openstack level we will need to take a similar
a approch to trunk ports. e.g. we create a logical bond port and a set of bond peer ports
at the neutron api level then we attach the bond port to the vm.

currently im not aware of any proposal that really has tracktion.

you can manually create a bond in the guest but you cannot today guarentee that the
vf will come from different pfs.

one of the reason i think we need to go the logical bond port direction is that it will allow us to constuct
resouce requests using the fucntionality that is being added for bandwidth based schduleing.
that will make expressing affinity and anti affinty simpler useing the request groups syntax.
i personally have stopped trying to add bond support untill that bandwith based schduling effort is finished.
> Hope that helps,
> Bence

Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

More information about the openstack-discuss mailing list