"Paul E. McKenney" <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
