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]

Date:	Thu, 20 Jun 2013 13:52:39 -0700
From:	Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@...el.com>
To:	"Nelson, Shannon" <shannon.nelson@...el.com>,
	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>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Subject: Re: [net-next 1/8] i40e: main driver core

On 06/20/2013 01:01 PM, Nelson, Shannon wrote:
>> 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.
Without a pool of statically-allocated random bytes for the seeds, RSS 
determinism is impossible.  From test to test, workloads would be 
completely different, unless your test harness always used the same 
source and destination ports, which is not aligned with reality.

-PJ

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

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