From: Sudeep Dutt <sudeep.dutt@intel.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Rusty Russell <rusty@rustcorp.com.au>,
"Michael S. Tsirkin" <mst@redhat.com>,
Rob Landley <rob@landley.net>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org,
linux-doc@vger.kernel.org, Nikhil Rao <nikhil.rao@intel.com>,
Ashutosh Dixit <ashutosh.dixit@intel.com>,
Caz Yokoyama <Caz.Yokoyama@intel.com>,
Dasaratharaman Chandramouli
<dasaratharaman.chandramouli@intel.com>,
Harshavardhan R Kharche <harshavardhan.r.kharche@intel.com>,
"Yaozu (Eddie) Dong" <eddie.dong@intel.com>,
Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>,
Sudeep Dutt <sudeep.dutt@intel.com>
Subject: Re: [PATCH 0/5] Enable Drivers for Intel MIC X100 Coprocessors.
Date: Fri, 16 Aug 2013 09:59:29 -0700 [thread overview]
Message-ID: <1376672369.93110.13.camel@blbiskey-desk1.amr.corp.intel.com> (raw)
In-Reply-To: <20130815101455.GA25528@amd.pavel.ucw.cz>
On Thu, 2013-08-15 at 12:14 +0200, Pavel Machek wrote:
> Hi!
>
Hi!
> > > > Since it is a PCIe card, it does not have the ability to host hardware
> > > > devices for networking, storage and console. We provide these devices
> > > > on X100 coprocessors thus enabling a self-bootable equivalent environment
> > > > for applications. A key benefit of our solution is that it leverages
> > > > the standard virtio framework for network, disk and console devices,
> > > > though in our case the virtio framework is used across a PCIe bus.
> > >
> > > Interesting...
> > >
> > > > Documentation/mic/mic_overview.txt | 48 +
> > > > Documentation/mic/mpssd/.gitignore | 1 +
> > > > Documentation/mic/mpssd/Makefile | 20 +
> > > > Documentation/mic/mpssd/micctrl | 157 +++
> > > > Documentation/mic/mpssd/mpss | 246 +++++
> > > > Documentation/mic/mpssd/mpssd.c | 1732 ++++++++++++++++++++++++++++++++++
> > > > Documentation/mic/mpssd/mpssd.h | 105 +++
> > > > Documentation/mic/mpssd/sysfs.c | 108 +++
> > > > drivers/misc/Kconfig | 1 +
> > > > drivers/misc/Makefile | 1 +
> > > > drivers/misc/mic/Kconfig | 56 ++
> > > > drivers/misc/mic/Makefile | 6 +
> > > > drivers/misc/mic/card/Makefile | 11 +
> > > > drivers/misc/mic/card/mic_common.h | 43 +
> > > > drivers/misc/mic/card/mic_debugfs.c | 139 +++
> > > > drivers/misc/mic/card/mic_debugfs.h | 40 +
> > > > drivers/misc/mic/card/mic_device.c | 311 ++++++
> > > > drivers/misc/mic/card/mic_device.h | 106 +++
> > > > drivers/misc/mic/card/mic_virtio.c | 643 +++++++++++++
> > > > drivers/misc/mic/card/mic_virtio.h | 79 ++
> > > > drivers/misc/mic/card/mic_x100.c | 253 +++++
> > > > drivers/misc/mic/card/mic_x100.h | 53 ++
> > > > drivers/misc/mic/common/mic_device.h | 85 ++
> > > > drivers/misc/mic/host/Makefile | 13 +
> > > > drivers/misc/mic/host/mic_boot.c | 181 ++++
> > >
> > > So... there are basically separate computers running on PCIe card
> > > plugged into host computer, right?
> > >
> >
> > They are PCIe form factor Coprocessors plugged into the host.
> >
> > > Maybe we should have something more promintent than drivers/misc for
> > > this, then? Like drivers/multicomputer?
> > >
> >
> > multicomputer" is an interesting name for these kind of devices but has
> > several issues:
> > a) The definition I found for multicomputer online was "A computer made
> > up of several computers. The term generally refers to an architecture in
> > which each processor has its own memory rather than multiple processors
> > with a shared memory. A multicore computer, although it sounds similar,
> > would not be a multicomputer because the multiple cores share a common
> > memory." Intel MIC X100 devices typically have upto 244 CPUs (61 cores)
> > on the card sharing common card memory so multicomputer would not be
> > accurate based on this definition.
>
> Well... you have your "host" computer, and than (potentially several)
> Intel MIC devices, which are basically separate computers. So X100 is
> not a multicomputer, but machine with several X100 cards certainly is
> multicomputer.
>
> > b) X100 MIC devices have always been referred to Coprocessors and never
> > as multicomputers in product specifications @
> > http://software.intel.com/en-us/mic-developer
>
> Coprocessor sounds like i487, but why not.
>
> > c) multicomputer is a very long path name.
>
> Agreed it is long. drivers/coproc?
>
> [I guess we'll get similar hardware from different vendors in
> future. It would make sense having it at common place.]
>
drivers/coproc is a good, short suggestion. Intel MIC X100 devices are
likely unique since they can run a general purpose OS in a PCIe form
factor Coprocessor plugged to the host. This might result in MIC
potentially being the only driver under drivers/coproc till another
general purpose Coprocessor comes along. Is it recommended to create a
new driver directory (drivers/coproc) in anticipation of future devices?
Do you think it would be better if we revive this discussion, once
another Coprocessor with similar capabilities comes along?
Thanks,
Sudeep Dutt
> Pavel
>
next prev parent reply other threads:[~2013-08-16 17:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 3:31 [PATCH 0/5] Enable Drivers for Intel MIC X100 Coprocessors Sudeep Dutt
2013-07-25 3:31 ` [PATCH 1/5] Intel MIC Host Driver for X100 family Sudeep Dutt
2013-08-01 1:44 ` Greg Kroah-Hartman
2013-08-01 1:45 ` Greg Kroah-Hartman
2013-08-02 0:38 ` Sudeep Dutt
2013-08-01 1:51 ` Greg Kroah-Hartman
2013-08-02 0:36 ` Sudeep Dutt
2013-08-02 0:46 ` Greg Kroah-Hartman
2013-07-25 3:31 ` [PATCH 2/5] Intel MIC Card " Sudeep Dutt
2013-07-25 3:31 ` [PATCH 3/5] Intel MIC Host Driver Changes for Virtio Devices Sudeep Dutt
2013-07-29 7:05 ` Michael S. Tsirkin
2013-08-02 0:40 ` Sudeep Dutt
2013-08-06 3:47 ` Rusty Russell
2013-07-25 3:31 ` [PATCH 4/5] Intel MIC Card " Sudeep Dutt
2013-07-25 4:41 ` Greg Kroah-Hartman
2013-07-25 18:00 ` Sudeep Dutt
2013-07-29 1:58 ` Rusty Russell
2013-07-25 3:31 ` [PATCH 5/5] Sample Implementation of Intel MIC User Space Daemon Sudeep Dutt
2013-08-01 1:46 ` [PATCH 0/5] Enable Drivers for Intel MIC X100 Coprocessors Greg Kroah-Hartman
2013-08-01 7:45 ` Asias He
2013-08-02 0:37 ` Sudeep Dutt
2013-08-02 0:34 ` Sudeep Dutt
2013-08-13 12:43 ` Pavel Machek
2013-08-14 20:24 ` Sudeep Dutt
2013-08-15 10:14 ` Pavel Machek
2013-08-16 16:59 ` Sudeep Dutt [this message]
2013-08-16 17:08 ` Waskiewicz Jr, Peter P
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=1376672369.93110.13.camel@blbiskey-desk1.amr.corp.intel.com \
--to=sudeep.dutt@intel.com \
--cc=Caz.Yokoyama@intel.com \
--cc=arnd@arndb.de \
--cc=ashutosh.dixit@intel.com \
--cc=dasaratharaman.chandramouli@intel.com \
--cc=eddie.dong@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=harshavardhan.r.kharche@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=nikhil.rao@intel.com \
--cc=pavel@ucw.cz \
--cc=peter.p.waskiewicz.jr@intel.com \
--cc=rob@landley.net \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).