netdev - Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the timecompare method

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:	Tue, 27 Mar 2012 14:51:51 -0400
From:	chetan loke <loke.chetan@...il.com>
To:	"Keller, Jacob E" <jacob.e.keller@...el.com>
Cc:	Richard Cochran <richardcochran@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"john.stultz@...aro.org" <john.stultz@...aro.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>
Subject: Re: [PATCH net V4 2/2] igb: offer a PTP Hardware Clock instead of the
 timecompare method

On Tue, Mar 27, 2012 at 2:43 PM, chetan loke <loke.chetan@...il.com> wrote:
> On Tue, Mar 27, 2012 at 2:29 PM, Keller, Jacob E
> <jacob.e.keller@...el.com> wrote:
>
>>>
>>
>> It isn't so much about performance gains as it is about preventing poorly written user apps from stalling the clean descriptor routines. I am working on a test case that should prove whether this is even an issue (at least with ixgbe). Once I have data on that it can be determined if the extra lock would alleviate it. The conceptual issue is that spamming get-time could cause the clean tx/rx irq routines to stall inside the interrupt for too long. (thereby not freeing up descriptors on the ring to
>
> What would be interesting to see is something like:
>
> 1) App1(getter/setter calls), executed '1000' ioctls per sec on eth0.
> Other 'M' apps(execute just get calls), where M = 1 .. 10(?). And one
> buggy app executed - 10K getter calls per sec.
>
> 2) eth0 receives PTP traffic and also around 80-90%(link rate)
> regular/mixed traffic.
>
> And BTW, eth0 is the management IP.
>
> While the test is running, if we are still able to reach the host and
> manage it via SSH then we can stop being paranoid.
>
>

Guys please correct me if I'm wrong but if RPS/RFS is enabled then at
a minimum we would need "N * 2" apps (where N == num_cpus). That way
there will be contention w/ the completions and we will be able to see
the real effect?

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