From: Robert Walsh <rjwalsh@pathscale.com>
To: Roland Dreier <rdreier@cisco.com>
Cc: "Bryan O'Sullivan" <bos@pathscale.com>,
linux-kernel@vger.kernel.org, openib-general@openib.org,
greg@kroah.com
Subject: Re: [openib-general] Re: [PATCH 9 of 18] ipath - char devices for diagnostics and lightweight subnet management
Date: Thu, 23 Mar 2006 18:59:34 -0800 [thread overview]
Message-ID: <1143169174.29062.16.camel@phosphene.durables.org> (raw)
In-Reply-To: <adaodzwvdi1.fsf@cisco.com>
> I'm
> talking about all the kernel code like the following (and similar
> stuff for guidinfo, nodedescription, portinfo, pkeytable).
>
> You must have nearly identical code in your userspace SMA, since it
> also has to respond to the same SM queries, right?
>
> I'm trying to understand why you can't get down to one implementation
> of these functions.
Why does that make a difference? The way I see it, we handle MAD
packets by either diverting them somewhere or passing them through the
normal ib_mad channel. We divert them somewhere because we find it
convenient to do so: it allows us to provide an SMA to our customers
without them having to have the full IB stack running. The SMA we
provide for these circumstances runs in userspace. It doesn't make use
of the existing ipath_mad.c code because that's tailored to: 1) run in
the kernel; and 2) deal with the IB stack. Even if we ripped out the
guts of ipath_mad.c and had it pass the requests to the userspace SMA,
we'd still have to have the diversion path in there for cases where the
IB stack isn't around.
--
Robert Walsh Email: rjwalsh@pathscale.com
PathScale, Inc. Phone: +1 650 934 8117
2071 Stierlin Court, Suite 200 Fax: +1 650 428 1969
Mountain View, CA 94043.
next prev parent reply other threads:[~2006-03-24 2:59 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-23 0:04 [PATCH 0 of 18] [RFC] ipath - almost-final round of patches for submission Bryan O'Sullivan
2006-03-23 0:04 ` [PATCH 1 of 18] ipath - core driver header files Bryan O'Sullivan
2006-03-23 0:04 ` [PATCH 2 of 18] ipath - core device driver Bryan O'Sullivan
2006-03-23 0:04 ` [PATCH 3 of 18] ipath - copy and send routines for sending an skb Bryan O'Sullivan
2006-03-23 0:04 ` [PATCH 4 of 18] ipath - support for HyperTransport devices Bryan O'Sullivan
2006-03-23 0:04 ` [PATCH 5 of 18] ipath - support for PCI Express devices Bryan O'Sullivan
2006-03-23 0:04 ` [PATCH 6 of 18] ipath - chip initialisation code Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 7 of 18] ipath - misc driver support code Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 8 of 18] ipath - sysfs and ipathfs support for core driver Bryan O'Sullivan
2006-03-23 5:49 ` Greg KH
2006-03-23 8:44 ` Bryan O'Sullivan
2006-03-23 20:06 ` Robert Walsh
2006-03-23 23:25 ` Greg KH
2006-03-23 6:30 ` Michael S. Tsirkin
2006-03-23 8:46 ` Bryan O'Sullivan
2006-03-23 9:40 ` Michael S. Tsirkin
2006-03-23 0:05 ` [PATCH 9 of 18] ipath - char devices for diagnostics and lightweight subnet management Bryan O'Sullivan
2006-03-23 6:41 ` Michael S. Tsirkin
2006-03-23 8:48 ` Bryan O'Sullivan
2006-03-23 9:37 ` Michael S. Tsirkin
2006-03-23 9:51 ` Bryan O'Sullivan
2006-03-23 10:13 ` Michael S. Tsirkin
2006-03-23 10:19 ` Bryan O'Sullivan
2006-03-23 19:18 ` Roland Dreier
2006-03-23 23:58 ` Bryan O'Sullivan
2006-03-24 1:27 ` Roland Dreier
2006-03-24 2:59 ` Robert Walsh [this message]
2006-03-23 0:05 ` [PATCH 10 of 18] ipath - support for userspace apps using core driver Bryan O'Sullivan
2006-03-23 3:06 ` Andrew Morton
2006-03-23 8:37 ` Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 11 of 18] ipath - layering interfaces used by higher-level driver code Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 12 of 18] ipath - infiniband header files Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 13 of 18] ipath - infiniband UC and UD protocol support Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 14 of 18] ipath - infiniband RC " Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 15 of 18] ipath - misc infiniband code, part 1 Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 16 of 18] ipath - misc infiniband code, part 2 Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 17 of 18] ipath - infiniband verbs support Bryan O'Sullivan
2006-03-23 0:05 ` [PATCH 18 of 18] ipath - kbuild infrastructure Bryan O'Sullivan
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=1143169174.29062.16.camel@phosphene.durables.org \
--to=rjwalsh@pathscale.com \
--cc=bos@pathscale.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=openib-general@openib.org \
--cc=rdreier@cisco.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®