netdev - RE: [net-next 1/8] i40e: main driver 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]

Message-ID: <FC41C24E35F18A40888AACA1A36F3E4168533F1F@FMSMSX102.amr.corp.intel.com>
Date:	Thu, 20 Jun 2013 20:01:08 +0000
From:	"Nelson, Shannon" <shannon.nelson@...el.com>
To:	Ben Hutchings <bhutchings@...arflare.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 1/8] i40e: main driver core

> From: Ben Hutchings [mailto:bhutchings@...arflare.com]
> Sent: Thursday, June 20, 2013 12:55 PM
> 
> On Thu, 2013-06-20 at 19:46 +0000, Nelson, Shannon wrote:
> > > From: Ben Hutchings [mailto:bhutchings@...arflare.com]
> > > Sent: Wednesday, June 19, 2013 11:13 AM
> > >
> > > On Thu, 2013-06-13 at 20:55 -0700, Jeff Kirsher wrote:
> > > > From: Jesse Brandeburg <jesse.brandeburg@...el.com>
> [...]

> > >
> > > You should be using rtnl_device_stats64; at 40G a 32-bit counter is
> > > ridiculous (using this in a 32-bit machine is a bit ridiculous too,
> > > though...)
> >
> > You mean rtnl_link_stats64?  Sure.
> 
> Right, yes.
> 
> > Yes, this driver is really not meant for a 32-bit machine.  We've
> > discussed making sure it would only build for 64-bit, but hadn't quite
> > gotten around to implementing the restriction.  It seems the right
> > thing to do - would anyone in the community get bent out of shape if
> > we added that?
> 
> I'm afraid they probably would.

Yeah, that was our thought.  We're going to try to make sure it at least compiles cleanly, but I'm not sure we'll be able to guarantee useful performance.

> 
> [...]
> > > > +/**
> > > > + * i40e_config_rss - Prepare for RSS if used
> > > > + * @pf: board private structure
> > > > + **/
> > > > +static s32 i40e_config_rss(struct i40e_pf *pf)
> > > > +{
> > > > +	struct i40e_hw *hw = &pf->hw;
> > > > +	u32 lut = 0;
> > > > +	int i, j;
> > > > +	u64 hena;
> > > > +	/* Set of random keys generated using kernel random number
> > > generator */
> > > > +	static const u32 seed[I40E_PFQF_HKEY_MAX_INDEX + 1] =
> {0x41b01687,
> > > > +				0x183cfd8c, 0xce880440, 0x580cbc3c,
> 0x35897377,
> > > > +				0x328b25e1, 0x4fa98922, 0xb7d90c14,
> 0xd5bad70d,
> > > > +				0xcd15a2c1, 0xe8580225, 0x4a1e9d11,
> 0xfe5731be};
> > >
> > > Chosen by a fair dice roll?
> >
> > Well, as fair as /dev/random gets.
> [...]
> 
> My point is: once you turn a random choice into a constant, it's no
> longer random.

Point taken, but we just wanted a random set of bits to start, just as we did in ixgbe.

Thanks,
sln