netdev - Re: [RFC 0/5] generic rx recycling

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sat, 15 May 2010 23:32:45 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	sebastian@...akpoint.cc
Cc:	netdev@...r.kernel.org, tglx@...utronix.de
Subject: Re: [RFC 0/5] generic rx recycling

From: Sebastian Andrzej Siewior <sebastian@...akpoint.cc>
Date: Wed,  5 May 2010 16:47:45 +0200

> This series merges the rx recycling code trying to come up with generic
> code. Recycling skbs from the tx path for incomming rx skips the memory
> allocater and improves latency during memory pressure.
> This is now used by just by just four drivers in the tree which were doing
> this on their own.

You're adding new unnecessary SMP locking to all of these drivers.

In the gianfar original code the recycle queue is accessed lockless
using __skb_dequeue() et al.  But you're using the skb_dequeue()
interface in the generic version which takes the SKB queue lock
which is absolutely unnecessary where these drivers make these
calls since they already need to have their chip RX path locked
already.
--
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