netdev - RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands

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:	Thu, 28 Jul 2011 14:34:57 -0700
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
Subject: RE: [RFC net-next PATCH 3/4] ethtool: Add new set commands

> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
> On Behalf Of Ben Hutchings
> Sent: Thursday, July 28, 2011 2:20 PM
> To: Rose, Gregory V
> Cc: netdev@...r.kernel.org; davem@...emloft.net; Kirsher, Jeffrey T
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
> 
> On Wed, 2011-07-27 at 15:17 -0700, Greg Rose wrote:
> > Add new set commands to configure the number of SR-IOV VFs, the
> > number of VM queues and spoof checking on/off switch.
> >
> > Signed-off-by: Greg Rose <gregory.v.rose@...el.com>
> > ---
> >
> >  include/linux/ethtool.h |   11 ++++++++++-
> >  1 files changed, 10 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > index c6e427a..c4972ba 100644
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -36,12 +36,14 @@ struct ethtool_cmd {
> >  	__u8	mdio_support;
> >  	__u32	maxtxpkt;	/* Tx pkts before generating tx int */
> >  	__u32	maxrxpkt;	/* Rx pkts before generating rx int */
> > +	__u32	num_vfs;	/* Enable SR-IOV VFs */
> 
> What are the semantics of changing this after VFs have already been set
> up?

There's an example of it patch 4/4 in this set.  The PF driver checks if any VFs are assigned and active and if not then it will disable and destroy all the current VFs via a call to pci_disable_sriov() and then call pci_enable_sriov() with the new number of VFs.  Or, if the number of new VFs is zero then SR-IOV is left disabled on that PF.

Mostly this is to accommodate customer requests to be able to set a different number of VFs per PF or to only have specified PFs enable VFs.  The current usage of the max_vfs module parameter is unwieldy in this sense as you must enable SR-IOV VFs on all physical functions found during the device probe with the same number of VFs.

> 
> > +	__u32	num_vmqs;	/* Set number of queues for VMDq */
> 
> VMDq is an Intel proprietary name.  Please specify this in generic
> terms.

I'll use the more generic term VM queues.

> 
> >  	__u16	speed_hi;       /* The forced speed (upper
> >  				 * bits) in Mbps. Please use
> >  				 * ethtool_cmd_speed()/_set() to
> >  				 * access it */
> >  	__u8	eth_tp_mdix;
> > -	__u8	reserved2;
> > +	__u8	spoof_check;	/* Enable/Disable anti-spoofing */
> >  	__u32	lp_advertising;	/* Features the link partner advertises */
> >  	__u32	reserved[2];
> >  };
> > @@ -1121,6 +1123,13 @@ struct ethtool_ops {
> >  #define AUTONEG_DISABLE		0x00
> >  #define AUTONEG_ENABLE		0x01
> >
> > +/* Enable or disable MAC and/or VLAN spoofchecking.If this is
> > + * set to enable, then depending on the controller capabilities
> > + * MAC and/or VLAN spoofing will be turned on.
> > + */
> > +#define SPOOFCHECK_DISABLE     0x00
> > +#define SPOOFCHECK_ENABLE      0x01
> 
> I'm not sure it's necessary to continue defining macros for booleans.

OK.  I tend to just follow the conventions in the code I see when I'm not that familiar with it but in this case I'll just use true and false.

> 
> This should not 'depend on controller capabilities'.  If the
> administrator tries to enable this feature on a device that does not
> support it, the request must return an error rather than failing
> silently.  (This is another reason to define new commands.)

Alright, I'll fix it up to work that way.

- Greg