lkml.org 
[lkml]   [2005]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [openib-general] Re: [PATCH 10/13] [RFC] ipath verbs, part 1
From
Date
The quick answer is the qp_list is traversed w/o the lock held in
ipath_ib_rcv(). The intent is to be able to do a lookup on the GID
to get a reference to the struct ipath_mcast and then walk the qp_list
w/o locks being held while processing the received packets at
interrupt level.


On Sun, 2005-12-18 at 11:59 -0800, Paul E. McKenney wrote:
> On Fri, Dec 16, 2005 at 03:48:55PM -0800, Roland Dreier wrote:
> > First half of ipath verbs driver
>
> Some RCU-related questions interspersed. Basic question is "where is
> the lock-free read-side traversal?"
>
> Thanx, Paul
>
> > ---
> >
> > drivers/infiniband/hw/ipath/ipath_verbs.c | 3244 +++++++++++++++++++++++++++++
> > 1 files changed, 3244 insertions(+), 0 deletions(-)
> > create mode 100644 drivers/infiniband/hw/ipath/ipath_verbs.c
...
> > +/*
> > + * Insert the multicast GID into the table and
> > + * attach the QP structure.
> > + * Return zero if both were added.
> > + * Return EEXIST if the GID was already in the table but the QP was added.
> > + * Return ESRCH if the QP was already attached and neither structure was added.
> > + */
> > +static int ipath_mcast_add(struct ipath_mcast *mcast,
> > + struct ipath_mcast_qp *mqp)
> > +{
> > + struct rb_node **n = &mcast_tree.rb_node;
> > + struct rb_node *pn = NULL;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&mcast_lock, flags);
> > +
> > + while (*n) {
> > + struct ipath_mcast *tmcast;
> > + struct ipath_mcast_qp *p;
> > + int ret;
> > +
> > + pn = *n;
> > + tmcast = rb_entry(pn, struct ipath_mcast, rb_node);
> > +
> > + ret = memcmp(mcast->mgid.raw, tmcast->mgid.raw,
> > + sizeof(union ib_gid));
> > + if (ret < 0) {
> > + n = &pn->rb_left;
> > + continue;
> > + }
> > + if (ret > 0) {
> > + n = &pn->rb_right;
> > + continue;
> > + }
> > +
> > + /* Search the QP list to see if this is already there. */
> > + list_for_each_entry_rcu(p, &tmcast->qp_list, list) {
>
> Given that we hold the global mcast_lock, how is RCU helping here?

Its not really. I'm just trying to be consistent where ever the
qp_list is traversed.

> Is there a lock-free read-side traversal path somewhere that I am
> missing?

The lock free traversal is in ipath_ib_rcv() which is an interrupt
routine.

> > + if (p->qp == mqp->qp) {
> > + spin_unlock_irqrestore(&mcast_lock, flags);
> > + return ESRCH;
> > + }
> > + }
> > + list_add_tail_rcu(&mqp->list, &tmcast->qp_list);
>
> Ditto...
>
> > + spin_unlock_irqrestore(&mcast_lock, flags);
> > + return EEXIST;
> > + }
> > +
> > + list_add_tail_rcu(&mqp->list, &mcast->qp_list);
>
> Ditto...
>
> > + spin_unlock_irqrestore(&mcast_lock, flags);
> > +
> > + atomic_inc(&mcast->refcount);
> > + rb_link_node(&mcast->rb_node, pn, n);
> > + rb_insert_color(&mcast->rb_node, &mcast_tree);
> > +
> > + spin_unlock_irqrestore(&mcast_lock, flags);
> > +
> > + return 0;
> > +}

--
Ralph Campbell <ralphc@pathscale.com>

-
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/

\
 
 \ /
  Last update: 2005-12-19 21:53    [from the cache]
©2003-2011 Jasper Spaans