Bug 1398934

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.

(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?

(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.

+         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

(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

lspci

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