From: Roland Dreier <rdreier@cisco.com>
To: Alex Chiang <achiang@hp.com>
Cc: linux-rdma@vger.kernel.org, justin.chen@hp.com,
       linux-kernel@vger.kernel.org
Subject: Re: infiniband limit of 32 cards per system?
References: <20100125235013.GD2828@grease.ALLEYCAT>
	<adaiqapplv7.fsf@roland-alpha.cisco.com>
	<20100126220333.GB12035@ldl.fc.hp.com>
Date: Tue, 26 Jan 2010 16:09:13 -0800
In-Reply-To: <20100126220333.GB12035@ldl.fc.hp.com> (Alex Chiang's message of
	"Tue, 26 Jan 2010 15:03:33 -0700")
Message-ID: <adaljfko1cm.fsf@roland-alpha.cisco.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1119
Lines: 30


 > It looks like we have a hole from [128, 192).
 > 
 > Would it be something as simple as this?

 > -       IB_UVERBS_BASE_MINOR  = 192,
 > -       IB_UVERBS_MAX_DEVICES = 32
 > +       IB_UVERBS_BASE_MINOR  = 128,
 > +       IB_UVERBS_MAX_DEVICES = 64

I don't think this is a good idea for two reasons:

 - It doesn't take into account the fact that the infiniband_mad and
   infiniband_cm drivers will take up more minors if more devices appear
   (in the best case, you would only be able to run opensm on the first
   32 HCAs or something like that).

 - It changes the minor of the first uverbs device, so something like a
   system with hardcoded static /dev would break in a mysterious way.

I think unfortunately we have to extend the device # assignment so the
first 32 HCAs get the same minors they would have and then overflow into
some dynamic region.

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