On 06/20/2013 01:01 PM, Nelson, Shannon wrote:
>> From: Ben Hutchings [mailto:[email protected]]
>> Sent: Thursday, June 20, 2013 12:55 PM
>>
>> On Thu, 2013-06-20 at 19:46 +0000, Nelson, Shannon wrote:
>>>> From: Ben Hutchings [mailto:[email protected]]
>>>> Sent: Wednesday, June 19, 2013 11:13 AM
>>>>
>>>> On Thu, 2013-06-13 at 20:55 -0700, Jeff Kirsher wrote:
>>>>> From: Jesse Brandeburg <[email protected]>
>> [...]
>>>> 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
>


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit 
http://communities.intel.com/community/wired

Reply via email to