All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Chiang <achiang-VXdhtT5mjnY@public.gmane.org>
To: Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	justin.chen-VXdhtT5mjnY@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 0/7] Increase maximum Infiniband HCAs per-system
Date: Fri, 29 Jan 2010 16:41:45 -0700	[thread overview]
Message-ID: <20100129234145.GC5177@ldl.fc.hp.com> (raw)
In-Reply-To: <adar5p8ldxv.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>

* Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>:
> 
> Have you considered drivers/infiniband/core/user_mad.c and ucm.c?

Ah, darn. I had not considered those drivers. You're gonna make
me learn a lot more about IB than I'd originally intended. ;)

> I think user_mad.c is somewhat more important, as that is what
> allows an adapter to be used for running the SM.  So I think
> we're still left with some potential issues around lots of
> adapters in one system.  (I think use of ucm by real apps is
> minimal to nonexistent, but someday we should deal with that
> too)

Ok, a quick glance through those drivers shows:

	enum {
		IB_UMAD_MAX_PORTS  = 64,
		IB_UMAD_MAX_AGENTS = 32,

		IB_UMAD_MAJOR      = 231,
		IB_UMAD_MINOR_BASE = 0
	};

and

	enum {
		IB_UCM_MAJOR = 231,
		IB_UCM_BASE_MINOR = 224,
		IB_UCM_MAX_DEVICES = 32
	};

They're all sharing the same major number, so they'll all have to
get the same treatment as the uverbs driver wrt overflow (to
prevent minor number overlap).

What I'm a little unsure of is, does IB_UMAD_MAX_AGENTS need to
double too? We don't export the agent id in the filesystem
anywhere, but we do give it to the user via an ioctl. That's just
used for book keeping purposes but...

Currently, there are 2x as many ports as there are agents. Do we
want to keep that ratio, or would it be ok to have 4x as many
ports as there are agents?

Thanks (and sorry for the n00b questions).

/ac
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Alex Chiang <achiang@hp.com>
To: Roland Dreier <rdreier@cisco.com>
Cc: linux-rdma@vger.kernel.org, justin.chen@hp.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] Increase maximum Infiniband HCAs per-system
Date: Fri, 29 Jan 2010 16:41:45 -0700	[thread overview]
Message-ID: <20100129234145.GC5177@ldl.fc.hp.com> (raw)
In-Reply-To: <adar5p8ldxv.fsf@roland-alpha.cisco.com>

* Roland Dreier <rdreier@cisco.com>:
> 
> Have you considered drivers/infiniband/core/user_mad.c and ucm.c?

Ah, darn. I had not considered those drivers. You're gonna make
me learn a lot more about IB than I'd originally intended. ;)

> I think user_mad.c is somewhat more important, as that is what
> allows an adapter to be used for running the SM.  So I think
> we're still left with some potential issues around lots of
> adapters in one system.  (I think use of ucm by real apps is
> minimal to nonexistent, but someday we should deal with that
> too)

Ok, a quick glance through those drivers shows:

	enum {
		IB_UMAD_MAX_PORTS  = 64,
		IB_UMAD_MAX_AGENTS = 32,

		IB_UMAD_MAJOR      = 231,
		IB_UMAD_MINOR_BASE = 0
	};

and

	enum {
		IB_UCM_MAJOR = 231,
		IB_UCM_BASE_MINOR = 224,
		IB_UCM_MAX_DEVICES = 32
	};

They're all sharing the same major number, so they'll all have to
get the same treatment as the uverbs driver wrt overflow (to
prevent minor number overlap).

What I'm a little unsure of is, does IB_UMAD_MAX_AGENTS need to
double too? We don't export the agent id in the filesystem
anywhere, but we do give it to the user via an ioctl. That's just
used for book keeping purposes but...

Currently, there are 2x as many ports as there are agents. Do we
want to keep that ratio, or would it be ok to have 4x as many
ports as there are agents?

Thanks (and sorry for the n00b questions).

/ac

  parent reply	other threads:[~2010-01-29 23:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-29 21:44 [PATCH 0/7] Increase maximum Infiniband HCAs per-system Alex Chiang
2010-01-29 21:44 ` Alex Chiang
2010-01-29 21:45 ` [PATCH 1/7] IB/uverbs: convert *cdev to cdev in struct ib_uverbs_device Alex Chiang
2010-01-29 21:45 ` [PATCH 3/7] IB/uverbs: use stack variable 'devnum' in ib_uverbs_add_one Alex Chiang
2010-01-29 21:45 ` [PATCH 4/7] IB/uverbs: use stack variable 'base' " Alex Chiang
2010-01-29 21:45 ` [PATCH 7/7] IB/core: pack struct ib_device a little tighter Alex Chiang
     [not found] ` <20100129214039.17745.38679.stgit-tBlMHHroXgg@public.gmane.org>
2010-01-29 21:45   ` [PATCH 2/7] IB/uverbs: remove dev_table Alex Chiang
2010-01-29 21:45     ` Alex Chiang
2010-01-29 21:45   ` [PATCH 5/7] IB/uverbs: increase maximum devices supported Alex Chiang
2010-01-29 21:45     ` Alex Chiang
2010-01-29 21:45   ` [PATCH 6/7] IB/uverbs: pack struct ib_uverbs_event_file tighter Alex Chiang
2010-01-29 21:45     ` Alex Chiang
2010-01-29 22:54   ` [PATCH 0/7] Increase maximum Infiniband HCAs per-system Roland Dreier
2010-01-29 22:54     ` Roland Dreier
     [not found]     ` <adar5p8ldxv.fsf-BjVyx320WGW9gfZ95n9DRSW4+XlvGpQz@public.gmane.org>
2010-01-29 23:41       ` Alex Chiang [this message]
2010-01-29 23:41         ` Alex Chiang
     [not found]         ` <20100129234145.GC5177-e+Ta4ugHZmL3oGB3hsPCZA@public.gmane.org>
2010-01-30  7:13           ` Roland Dreier
2010-01-30  7:13             ` Roland Dreier
2010-02-01 12:55           ` Hal Rosenstock
2010-02-01 12:55             ` Hal Rosenstock

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=20100129234145.GC5177@ldl.fc.hp.com \
    --to=achiang-vxdhtt5mjny@public.gmane.org \
    --cc=justin.chen-VXdhtT5mjnY@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.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.