Messages in this thread |  | | | Date | Wed, 04 Nov 2009 00:03:21 +0100 | | From | Eric Dumazet <> | | Subject | Re: [net-next-2.6 PATCH RFC] TCPCT part 1d: generate Responder Cookie |
| |
William Allen Simpson a écrit : > Eric Dumazet wrote: >> This patch looks fine, but I dont see how this new function is used. >> >> Some points : >> >> 1) We are working hard to remove rwlocks from network stack, so please >> dont >> add a new one. You probably can use a seqlock or RCU, or a server >> handling 10.000 connections request per second on many NIC will hit >> this rwlock. >> > This is my attempt at using RCU, as seqlock didn't seem to apply (and is > missing any Documentation.) >
That seems very good, thanks, we can sort out details later, when full picture is available.
> After the discussion about context, one question that I have is the need > for the _bh suffix? > > + rcu_read_lock_bh(); > + memcpy(&xvp->cookie_bakery[0], > + &rcu_dereference(tcp_secret_generating)->secrets[0], > + sizeof(tcp_secret_generating->secrets)); > + rcu_read_unlock_bh(); >
Well, you dont need to disable BH in this code running in softirq context only.
Just use rcu_read_lock() (like you use spin_lock() in same function/context)
> > Documentation/RCU/checklist.txt #7 says: > > One exception to this rule: rcu_read_lock() and rcu_read_unlock() > may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh() > in cases where local bottom halves are already known to be > disabled, for example, in irq or softirq context. Commenting > such cases is a must, of course! And the jury is still out on > whether the increased speed is worth it. >
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |