netdev - Re: [net-next 3/8] i40e: driver ethtool core

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, 20 Jun 2013 20:59:12 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	"Nelson, Shannon" <shannon.nelson@...el.com>
CC:	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gospo@...hat.com" <gospo@...hat.com>,
	"sassmann@...hat.com" <sassmann@...hat.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Subject: Re: [net-next 3/8] i40e: driver ethtool core

On Thu, 2013-06-20 at 19:47 +0000, Nelson, Shannon wrote:
> > From: Ben Hutchings [mailto:bhutchings@...arflare.com]
> > Sent: Wednesday, June 19, 2013 11:27 AM
> > 
> > On Thu, 2013-06-13 at 20:55 -0700, Jeff Kirsher wrote:
> > > From: Jesse Brandeburg <jesse.brandeburg@...el.com>
[...]
> > > +static struct i40e_stats i40e_gstrings_stats[] = {
> > > +	I40E_PF_STAT("rx_bytes", stats.eth.rx_bytes),
> > > +	I40E_PF_STAT("tx_bytes", stats.eth.tx_bytes),
> > > +	I40E_PF_STAT("rx_errors", stats.eth.rx_errors),
> > > +	I40E_PF_STAT("tx_errors", stats.eth.tx_errors),
> > 
> > Duplicates.
> 
> Well, not really are they duplicates - the NETDEV_STAT numbers are
> specifically for each netdev that is attached to this device.  Because
> the XL710 supports VMDq, SR-IOV, and some other device multiplexing
> schemes, each netdev's NETDEV_STAT struct is the subset of the traffic
> going through its portion of the device.
>
> The PF_STAT struct holds the stats for what actually goes through the
> physical port.  This is not necessarily a summation of the various
> NETDEV_STAT structs, because some connections may be talking to each
> other and not out the physical port.
> 
> When ethtool -S is called on the PF's netdev, we see both the netdev
> and the ports stats printed.  When called on non-PF connection we only
> see the netdev stats, none of the port stats.

Good point.  And this is something I've been meaning to bring up for
discussion on netdev myself - we should have some naming convention to
distinguish per-port and per-function/per-netdev statistics.

> > [...]
> > > +#define I40E_QUEUE_STATS_LEN \
> > > +  ((((struct i40e_netdev_priv *)netdev_priv(netdev))->vsi-
> > >num_queue_pairs + \
> > > +    ((struct i40e_netdev_priv *)netdev_priv(netdev))->vsi-
> > >num_queue_pairs) * 2)
> > 
> > netdev should be a macro parameter.  Actually this could just as well be
> > a function.
> 
> Sure.
> Can you tell we inherited a lot from our previous drivers?

Just a little. :-)

[...]
> > > +static int i40e_set_phys_id(struct net_device *netdev,
> > > +			    enum ethtool_phys_id_state state)
> > > +{
> > > +	struct i40e_netdev_priv *np = netdev_priv(netdev);
> > > +	struct i40e_pf *pf = np->vsi->back;
> > > +	struct i40e_hw *hw = &pf->hw;
> > > +	int blink_freq = 2;
> > > +	static u32 led_status;
> > 
> > Ugh, no.
> > 
> > Since ETHTOOL_PHYSID drops the RTNL between calls to set_phys_id, it's
> > possible to invoke it on multiple devices at the same time...
> 
> Yep, that should become PF netdev specific.
[...]

My point was that you have a static variable here, whose use is not
serialised.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html