Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 1398934 - [RFE] Recognize SRIOV PF and set its num_vfs
[RFE] Recognize SRIOV PF and set its num_vfs
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.2
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Beniamino Galvani
Desktop QE
Mirek Jahoda
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-11-27 07:46 EST by Edward Haas
Modified: 2017-08-01 05:22 EDT (History)
12 users (show)

See Also:
Fixed In Version: NetworkManager-1.8.0-0.4.rc3.el7
Doc Type: Enhancement
Doc Text:
*NetworkManager* now supports VFs for SR-IOV devices With this update, the *NetworkManager* system service supports creating virtual functions (VFs) for Single Root I/O Virtualization (SR-IOV) PCI devices. The number of VFs can be specified using the "sriov-num-vfs" option in the device section of the *NetworkManager* configuration file. After VFs are created, *NetworkManager* can activate connection profiles on them. Note that some properties of a VF interface, such as the Maximum Transmission Unit (MTU), can only be set to values compatible with those that are set on the physical interface.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-01 05:22:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2299 normal SHIPPED_LIVE Moderate: NetworkManager and libnl3 security, bug fix and enhancement update 2017-08-01 08:40:28 EDT

  None (edit)
Description Edward Haas 2016-11-27 07:46:39 EST
Description of problem:

Control SRIOV devices and support their configuration.

Specifically, in RHV we would like to be able and recognize a SRIOV PF device and set the number of VF it should work with (num_vfs).
Comment 2 Beniamino Galvani 2017-03-15 13:35:29 EDT
Can you please give an overview on how do you plan to use this
functionality and if there are other parameters that you need for
SR-IOV?

We support per-device settings (as opposed to the standard
per-connection ones); some of them can be changed through D-Bus on a
device, but they are not persistent. There is also support for
persistent device settings, that can be put in the NetworkManager.conf
configuration file, for example:

 [device]
 match-device=interface-name:eth3
 unmanaged=1

These device sections can also be put in snippets in the
{/etc,/usr/lib,/var/run}/NetworkManager/conf.d/ directories.

I guess an easy way to implement this RFE would be to accept a new
'sriov-numvfs' parameter in device sections of NM.conf; you would have
to write a file in one of the supported conf.d directories and send
SIGHUP to tell NM to reload the configuration from file.
Comment 4 Edward Haas 2017-04-12 03:18:36 EDT
(In reply to Beniamino Galvani from comment #2)
> Can you please give an overview on how do you plan to use this
> functionality and if there are other parameters that you need for
> SR-IOV?

At the moment, we perform these tasks:
- Detect which network (PF) devices are SR-IOV.
- Allow the user to specify the number of VF per PF device.
- For the intel devices, a small hack was required related to the VF default mac address:
-- The default mac address of a vf is zeroed, but setting it back to zero is not possible, which collides with libvirt logic of restoring the original mac address when releasing the VF. Workaround: set the mac address of the vf with a non zeroed address on init.

> 
> We support per-device settings (as opposed to the standard
> per-connection ones); some of them can be changed through D-Bus on a
> device, but they are not persistent. There is also support for
> persistent device settings, that can be put in the NetworkManager.conf
> configuration file, for example:
> 
>  [device]
>  match-device=interface-name:eth3
>  unmanaged=1
> 
> These device sections can also be put in snippets in the
> {/etc,/usr/lib,/var/run}/NetworkManager/conf.d/ directories.
> 
> I guess an easy way to implement this RFE would be to accept a new
> 'sriov-numvfs' parameter in device sections of NM.conf; you would have
> to write a file in one of the supported conf.d directories and send
> SIGHUP to tell NM to reload the configuration from file.

I would prefer to set-and-forget, not having to manage it through configuration files or through external persistence.
But it seems reasonable to have the proposal as the first phase, examining the usage and then proceed with another phase that is more integrated into NM.
Will the two phase plan be ok?
Comment 5 Beniamino Galvani 2017-04-15 04:22:25 EDT
(In reply to Edward Haas from comment #4)
> (In reply to Beniamino Galvani from comment #2)
> > Can you please give an overview on how do you plan to use this
> > functionality and if there are other parameters that you need for
> > SR-IOV?
> 
> At the moment, we perform these tasks:
> - Detect which network (PF) devices are SR-IOV.
> - Allow the user to specify the number of VF per PF device.
> - For the intel devices, a small hack was required related to the VF default
> mac address:
> -- The default mac address of a vf is zeroed, but setting it back to zero is
> not possible, which collides with libvirt logic of restoring the original
> mac address when releasing the VF. Workaround: set the mac address of the vf
> with a non zeroed address on init.
> 
> > 
> > We support per-device settings (as opposed to the standard
> > per-connection ones); some of them can be changed through D-Bus on a
> > device, but they are not persistent. There is also support for
> > persistent device settings, that can be put in the NetworkManager.conf
> > configuration file, for example:
> > 
> >  [device]
> >  match-device=interface-name:eth3
> >  unmanaged=1
> > 
> > These device sections can also be put in snippets in the
> > {/etc,/usr/lib,/var/run}/NetworkManager/conf.d/ directories.
> > 
> > I guess an easy way to implement this RFE would be to accept a new
> > 'sriov-numvfs' parameter in device sections of NM.conf; you would have
> > to write a file in one of the supported conf.d directories and send
> > SIGHUP to tell NM to reload the configuration from file.
> 
> I would prefer to set-and-forget, not having to manage it through
> configuration files or through external persistence.
> But it seems reasonable to have the proposal as the first phase, examining
> the usage and then proceed with another phase that is more integrated into
> NM.
> Will the two phase plan be ok?

Yes. I pushed some commits to branch bg/sriov-numvfs-rh1398934 that add a new "sriov" device capability on D-Bus and nmcli, and allow setting the number of VFs in NM configuration.
Comment 6 Thomas Haller 2017-04-17 09:49:55 EDT
+         num_vfs = nm_config_data_get_sriov_num_vfs (nm_config_get_data (config), self);


let's use NM_CONFIG_GET_DATA ?

nm_config_data_get_sriov_num_vfs() has only one caller, and I don't think it will ever have more. I would drop it process the config value directly.


Anyway, only minor complains, ignore if you disagree.
Branch lgtm
Comment 7 Beniamino Galvani 2017-04-19 03:01:43 EDT
(In reply to Thomas Haller from comment #6)
> +         num_vfs = nm_config_data_get_sriov_num_vfs (nm_config_get_data
> (config), self);
> 
> 
> let's use NM_CONFIG_GET_DATA ?
> 
> nm_config_data_get_sriov_num_vfs() has only one caller, and I don't think it
> will ever have more. I would drop it process the config value directly.
> 
> 
> Anyway, only minor complains, ignore if you disagree.
> Branch lgtm

Both fixed. Branch merged to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=45e4cc67b33914bb960ceae78ae540739c411651

and nm-1-8:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=nm-1-8&id=3cabd60b96cf84d785b6558d25905e89f3d3d4ad
Comment 8 Vladimir Benes 2017-06-26 06:17:08 EDT
lspci
Comment 10 errata-xmlrpc 2017-08-01 05:22:07 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2299

Note You need to log in before you can comment on or make changes to this bug.