netdev - Re: [PATCH net-next 2/2] sunvnet: Re-check for a VIO_DESC_READY data descriptor after short udelay()

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: <665366D4-384B-45E1-B371-239EA87F5A15@oracle.com>
Date:	Tue, 2 Sep 2014 09:43:46 -0700
From:	Raghuram Kothakota <Raghuram.Kothakota@...cle.com>
To:	sowmini.varadhan@...cle.com
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] sunvnet: Re-check for a VIO_DESC_READY data descriptor after short udelay()


On Sep 2, 2014, at 3:27 AM, Sowmini Varadhan <sowmini.varadhan@...cle.com> wrote:

> On 09/01/2014 11:47 PM, David Miller wrote:
> 
>> 
>> If there were no more packets coming, this is wasted useless polling
>> time in atomic context.
> 
> turns out that this gives a 20-30% perf improvement for tests like
> iperf.
> 
> when there are no more packets coming, the extra 12 microsecond
> delay is not that big of a deal anyway. The point was that the extra
> 12 micro-second tax in the quiescent network state is less expensive
> than exiting interrupt context, taking another interrupt and doing
> another ldc_read, when there is actually a burst of packets.
> 

We could optimize this a bit by not wait for normal traffic, I mean, non-burst traffic
and apply the retry  only  when we detect a stream of packets?
We could detect a stream based on how many packets are picked
up in this function, picking up 3 or more could be considered as a stream,
of course tune based on testing.

You probably tried it already, but checking to see if you tried with less number
of iterations, we could reduce the iterations if the numbers are equally good
with less iterations.

-Raghuram

> notice that there are many other such udelay() loops elsewhere in
> the code.
> 
> I can remove the retries and submit patch 1/1 again later today.
> 
>> 
>> Everything should be event based, and we should not be compensating
>> and making sacrifices for a producer slower than we are as a consumer.
>> --
>> 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
>> 
> 

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