netdev - Re: [PATCH 0/2] net: davinci_cpdma: reduce latency on -rt

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:	Wed, 27 Jul 2016 17:11:54 +0300
From:	Grygorii Strashko <grygorii.strashko@...com>
To:	Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
CC:	Mugunthan V N <mugunthanvnm@...com>, <linux-omap@...r.kernel.org>,
	<netdev@...r.kernel.org>, <kernel@...gutronix.de>
Subject: Re: [PATCH 0/2] net: davinci_cpdma: reduce latency on -rt

On 07/27/2016 10:03 AM, Uwe Kleine-König wrote:
> On Tue, Jul 26, 2016 at 05:36:49PM +0300, Grygorii Strashko wrote:
>> On 07/26/2016 03:02 PM, Uwe Kleine-König wrote:
>>> Hello,
>>>
>>> these patches are based on next-20160726. I didn't check yet how latency
>>> improves by using these patches, but even if the improvment is small,
>>> it's still a good idea to have them.
>>
>> Sry, but how this will affect on -RT? This is not a raw locks, so
>> they will be converted to rt-mutexes which are sleepable.
>> Or I've missed smth?
> 
> They are still locks after all. On -rt I saw for the relevant
> application:
> 
>   send package         |
>     take lock          |
>     write pckt to hw   |
>                        | rcv irq
> 		       |   take lock
> 		       |     schedule
>     drop lock	       | 
>       schedule         |
>                        |   get pckt from hw
> 		       |   drop lock
> 
> So reducing the time a lock is taken reduces the chances that the lock
> is contended for another thread which results in extra context switches.
> 
Thanks a lot for explanation. So, this is not exactly rt-latency reduction,
but it might improve net performance on -RT. correct?

Thanks.
-- 
regards,
-grygorii