From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Dangaard Brouer Subject: Re: [net-next PATCH V2 8/9] net: frag queue locking per hash bucket Date: Fri, 30 Nov 2012 13:55:32 +0100 Message-ID: <1354280132.11754.435.camel@localhost> References: <20121129161019.17754.29670.stgit@dragon> <20121129161512.17754.93933.stgit@dragon> <1354208920.14302.1907.camel@edumazet-glaptop> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: "David S. Miller" , Florian Westphal , netdev@vger.kernel.org, Pablo Neira Ayuso , Thomas Graf , Cong Wang , Patrick McHardy , "Paul E. McKenney" , Herbert Xu To: Eric Dumazet Return-path: Received: from mx1.redhat.com ([209.132.183.28]:9804 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751036Ab2K3M4y (ORCPT ); Fri, 30 Nov 2012 07:56:54 -0500 In-Reply-To: <1354208920.14302.1907.camel@edumazet-glaptop> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, 2012-11-29 at 09:08 -0800, Eric Dumazet wrote: > So we still have this huge contention on the reader-writer lock cache > line... > I would just remove it. (And remove hash rebuild, or make it RCU > compatible ) I vote for removing the rebuild feature. It really doesn't make sense to protect a 256Kb memory (using) hash, with very short lived elements, against hash collision attacks, every 10 minutes. (Especially as we saw a 7 GBit/s performance improvement) Making the hash RCU "compatible" is not going to work, because the elements are too short lived, thus we cannot free them fast enough (call_rcu stuff). (I actually did the RCU implementation, to realize this...)