Re: Q: locking mechanisms

[Urs Thuermann]

"Paul E. McKenney" <paulmck@xxxxxxxxxx> writes:

> > I have code that receives network packets by registering with
> > dev_add_pack().  Each packet received is then delivered to a list
> > of receivers, where this list can contain quite a lot of items:
> > 
> > 	receive_function(struct sk_buff *skb, struct net_device *dev,
> > 			struct packet_type *pt, struct net_device *orig_dev)
> > 	{
> > 		...
> > 		rcu_read_lock();
> >             head = find_list(dev);
> > 		hlist_for_each_entry_rcu(p, n, head, list) {
> > 			deliver_packet_to_receiver(skb, p);
> > 		}
> > 		rcu_read_unlock();
> > 	}
> > 
> > The deliver_packet_to_receiver() function finally ends up in a call to
> > sock_queue_rcv_skb().

> "Holding" rcu_read_lock() for long time periods is much less of a
> concern than holding other types of synchronization mechanisms.

Why is that?  I thought, if I hold a spinlock (or rw_lock in my case)
I only block other threads that try to get that same lock.  With
rcu_read_lock() I disable preemption which I thought affects more
(all) other parts of the kernel.

> But I have to ask: roughly how long is "quite long"?

Depends on how many and what types of sockets are opened and which
packets they want to receive.  The code is part of a new protocol
family implementation for CAN (controller area network), which you can
see at belios.de, project name socket-can.  It implements several
types of PF_CAN sockets, which register for packets of certain CAN
IDs, which are then lightly processed (filtered) and eventually
delivered into a queue using sock_queue_rcv_skb().  Usually, the list
has one receiver per open PF_CAN sockets.  Typical usage here has
shown list lengths of 30-100 entries, i.e. 30-100 packets delivered
with sock_queue_rcv_skb().  But it all depends on what the user space
does, how many PF_CAN sockets are opened by all processes.

Is that value of "quite long" also "too long" for doing an
rcu_read_lock()?


urs


BTW, while implementing PF_CAN and reading kernel code and
documentation I often run into questions on details like this which
I'd like answered to get a better understanding of kernel internals,
sometimes not directly related to some concrete implementation
problem.  Is LKML the right place for these questions?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/