All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Matthew Wilcox <willy@infradead.org>
Cc: hans.westgaard.ry@oracle.com,
	"Doug Ledford" <dledford@redhat.com>,
	linux-rdma@vger.kernel.org,
	"Håkon Bugge" <haakon.bugge@oracle.com>,
	"Parav Pandit" <parav@mellanox.com>,
	"Jack Morgenstein" <jackm@dev.mellanox.co.il>,
	"Pravin Shedge" <pravin.shedge4linux@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] IB/mad: Use IDR instead of per-port list
Date: Thu, 7 Jun 2018 20:11:25 -0600	[thread overview]
Message-ID: <20180608021125.GB19611@ziepe.ca> (raw)
In-Reply-To: <20180607234926.GA8260@bombadil.infradead.org>

On Thu, Jun 07, 2018 at 04:49:26PM -0700, Matthew Wilcox wrote:
> On Thu, Jun 07, 2018 at 04:26:46PM -0600, Jason Gunthorpe wrote:
> > On Thu, Jun 07, 2018 at 12:08:32PM -0700, Matthew Wilcox wrote:
> > > 
> > > Hans reports a bug where the mlx4 driver uses the MSB of the agent number
> > > to store slave number, meaning we can only use agent numbers up to 2^24.
> > > Fix this by using an IDR to assign the agent numbers and also look up the
> > > agent when a MSD packet is received.
> > > 
> > > I've changed the locking substantially, so this may well have a
> > > performance issue.  There are a few different possibilities for fixing
> > > that, including moving to an RCU-based lookup.
> > 
> > I do like this better than the last series..
> > 
> > This are is somewhat performance sensitive and it would be nice to
> > avoid this global lock.
> 
> OK, I wasn't sure whether it was worth it.
> 
> > What about using a read/write spinlock instead of the IDR internal
> > lock? Then all the per-port reading threads calling find_mad_agent can
> > run concurrently..
> 
> It'd be better to switch to RCU ... the IDR is RCU-safe, but the
> version/class/method or OUI match isn't.  Do you have any feeling on
> the relative frequency of the two types of "routing"?

I would say they are close to equally important, perhaps the
version/class/method is slightly more important.

> Actually, I think we can use the radix tree data structure for the
> version/class/method too ... that's going to take a little more work.

I was wondering about that as well, this code is very old so there
must be better data structure helpers these days.

Jason

      reply	other threads:[~2018-06-08  2:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07 19:08 [RFC] IB/mad: Use IDR instead of per-port list Matthew Wilcox
2018-06-07 22:26 ` Jason Gunthorpe
2018-06-07 23:49   ` Matthew Wilcox
2018-06-08  2:11     ` Jason Gunthorpe [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180608021125.GB19611@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=dledford@redhat.com \
    --cc=haakon.bugge@oracle.com \
    --cc=hans.westgaard.ry@oracle.com \
    --cc=jackm@dev.mellanox.co.il \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=parav@mellanox.com \
    --cc=pravin.shedge4linux@gmail.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.