netdev - Re: [net-next 04/13] net/mlx5e: Vxlan, replace spinlock with read-write lock

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] [day] [month] [year] [list]

Date:   Fri, 27 Jul 2018 15:29:26 -0700
From:   Saeed Mahameed <saeedm@....mellanox.co.il>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     Saeed Mahameed <saeedm@...lanox.com>,
        "David S. Miller" <davem@...emloft.net>,
        Linux Netdev List <netdev@...r.kernel.org>,
        Gal Pressman <galp@...lanox.com>
Subject: Re: [net-next 04/13] net/mlx5e: Vxlan, replace spinlock with
 read-write lock

On Fri, Jul 27, 2018 at 2:48 PM, Stephen Hemminger
<stephen@...workplumber.org> wrote:
> On Fri, 27 Jul 2018 14:15:09 -0700
> Saeed Mahameed <saeedm@...lanox.com> wrote:
>
>> From: Gal Pressman <galp@...lanox.com>
>>
>> The VXLAN database is mainly used by readers in data path, and rarely
>> used by control path writers.
>> Multiple readers (threads) should not block each other and cause an
>> unnecessary contention on the lock.
>>
>> Replacing the spinlock with rwlock optimizes the common use case where
>> adding ports to the table (adding VXLAN interfaces) is quite rare, but
>> the table is accessed for each VXLAN TX skb.
>>
>> Signed-off-by: Gal Pressman <galp@...lanox.com>
>> Signed-off-by: Saeed Mahameed <saeedm@...lanox.com>
>
> Did you know that for small sections a spinlock is significantly faster than
> a reader-writer lock. It turns out that reader-writer locks the reader
> creates a cache line bounce.
>
> https://www.kernel.org/doc/Documentation/locking/spinlocks.txt
>
>
> Lesson 2: reader-writer spinlocks.
>
> If your data accesses have a very natural pattern where you usually tend
> to mostly read from the shared variables, the reader-writer locks
> (rw_lock) versions of the spinlocks are sometimes useful. They allow multiple
> readers to be in the same critical region at once, but if somebody wants
> to change the variables it has to get an exclusive write lock.
>
>    NOTE! reader-writer locks require more atomic memory operations than
>    simple spinlocks.  Unless the reader critical section is long, you
>    are better off just using spinlocks.

Thanks Stephen, very usefull information !
I will drop this patch for now, I will consider  using rcu lock
instead in a future patch.