* Re: netfilter conntrack tcp lock [not found] <20090421210412.268fc4e7@nehalam> @ 2009-04-22 4:20 ` Paul E. McKenney 2009-04-22 4:57 ` Eric Dumazet 1 sibling, 0 replies; 3+ messages in thread From: Paul E. McKenney @ 2009-04-22 4:20 UTC (permalink / raw) To: Stephen Hemminger; +Cc: Eric Dumazet, netfilter-devel On Tue, Apr 21, 2009 at 09:04:12PM -0700, Stephen Hemminger wrote: > Not sure what the performance impact would be but simply changing tcp_lock > (in nf_conntrack_proto_tcp) to a spin_lock might get a performance boost. > I thought I heard Paul say read_locks are way slower than spin_lock. In -rt, read_locks are really exclusive locks. :-/ And an uncontended read_lock is somewhat slower than a spin_lock, but not overwhelmingly so. > Alternatively, going to some form of bit based hash lock might work. I have to ask the stupid question... Can conntrack entries be hashed or otherwise partitioned, with a lock then assigned to each partition? Thanx, Paul ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: netfilter conntrack tcp lock [not found] <20090421210412.268fc4e7@nehalam> 2009-04-22 4:20 ` netfilter conntrack tcp lock Paul E. McKenney @ 2009-04-22 4:57 ` Eric Dumazet 2009-04-22 16:04 ` Patrick McHardy 1 sibling, 1 reply; 3+ messages in thread From: Eric Dumazet @ 2009-04-22 4:57 UTC (permalink / raw) To: Stephen Hemminger; +Cc: Paul E. McKenney, netfilter-devel Stephen Hemminger a écrit : > Not sure what the performance impact would be but simply changing tcp_lock > (in nf_conntrack_proto_tcp) to a spin_lock might get a performance boost. > I thought I heard Paul say read_locks are way slower than spin_lock. > > Alternatively, going to some form of bit based hash lock might work. > > I thought Patrick was OK with adding a spinlock into each nf_conn struct ? (We shrunk this struct with the rcu_head removal) A straight forward locking schem. We have spinlocks everywhere in kernel afterall, and conntracking deserves this. Just resubmit one of your prior patch perhaps ? I can dig it in a couple of hours eventually. Thanks -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: netfilter conntrack tcp lock 2009-04-22 4:57 ` Eric Dumazet @ 2009-04-22 16:04 ` Patrick McHardy 0 siblings, 0 replies; 3+ messages in thread From: Patrick McHardy @ 2009-04-22 16:04 UTC (permalink / raw) To: Eric Dumazet; +Cc: Stephen Hemminger, Paul E. McKenney, netfilter-devel Eric Dumazet wrote: > Stephen Hemminger a écrit : >> Not sure what the performance impact would be but simply changing tcp_lock >> (in nf_conntrack_proto_tcp) to a spin_lock might get a performance boost. >> I thought I heard Paul say read_locks are way slower than spin_lock. >> >> Alternatively, going to some form of bit based hash lock might work. >> > I thought Patrick was OK with adding a spinlock into each nf_conn struct ? > (We shrunk this struct with the rcu_head removal) Yes, my main concern was the further size increase. > A straight forward locking schem. We have spinlocks everywhere in kernel afterall, and > conntracking deserves this. > > Just resubmit one of your prior patch perhaps ? I can dig it in a couple of hours eventually. Yes, please. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-04-22 16:04 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20090421210412.268fc4e7@nehalam>
2009-04-22 4:20 ` netfilter conntrack tcp lock Paul E. McKenney
2009-04-22 4:57 ` Eric Dumazet
2009-04-22 16:04 ` Patrick McHardy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).