netdev - RE: [PATCH net-next V0 19/21] mlx4_core: Modify driver initialization flow to accommodate SRIOV for Ethernet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Dec 2011 08:09:14 +0000
From:	Yevgeny Petrilin <yevgenyp@...lanox.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
	"roland@...estorage.com" <roland@...estorage.com>,
	Liran Liss <liranl@...lanox.com>,
	"jackm@....mellanox.co.il" <jackm@....mellanox.co.il>,
	Marcel Apfelbaum <marcela@...lanox.com>
Subject: RE: [PATCH net-next V0 19/21] mlx4_core: Modify driver
 initialization flow to accommodate SRIOV for Ethernet

> > 1. Added module parameters sr_iov and probe_vf for controlling enablement of
> >    SRIOV mode.
> 
> This sort of option is useful in many drivers, and ideally would be
> specified in some generic way rather than a module parameters.  However
> I can't see a good way to make it configurable after the net device is
> registered.
> 
> Currently the in-tree drivers have:
> 
> be2net: num_vfs
> cxgb4:  num_vfs [array]
> igb:    max_vfs
> ixgbe:  max_vfs
> 
> Consider renaming 'sr_iov' to one of the above rather than adding to the variation.

Good point, we probably should rename it.

> 
> The 'probe_vf' parameter is very odd.  Why do you think it is necessary
> to make this a module parameter?  It should be possible to bind and
> unbind the driver from each VF dynamically via sysfs but this parameter
> appears to restrict that.
>
 
We have same driver acting both as VF and PF, so once the VFs are being created (pci_enable_sriov),
The probe function is being called for all of them.
In many cases this is not what we want, but rather pass the vfs to guest OS.
The module parameter is meant to ease the life of the administrator.
 
> [...]
> > 3. Added port_type_array as a module parameter to allow driver startup with
> >    ports configured as desired.
> >    In SRIOV mode, only ETH is supported, and this array is ignored; otherwise,
> >    for the case where the FW supports both port types (ETH and IB), the
> >    port_type_array parameter is used.
> >    By default, the port_type_array is set to configure both ports as IB.
> [...]
> 
> You seem to be saying that this can be reconfigured after startup - in
> which case is the module parameter really necessary?  Maybe I misunderstand.

In SRIOV mode we don't allow dynamic link layer type changes, so the type is set by module parameter.
 

Thanks,
Yevgeny