From: Oded Gabbay <oded.gabbay@gmail.com>
To: linux-kernel@vger.kernel.org, oshpigelman@habana.ai,
ttayar@habana.ai, gregkh@linuxfoundation.org
Subject: [PATCH 0/9] habanalabs: support open device by multiple processes
Date: Sun, 28 Jul 2019 14:28:09 +0300 [thread overview]
Message-ID: <20190728112818.30397-1-oded.gabbay@gmail.com> (raw)
This patch-set removes the limitation in the driver's code that only a
single process will have a file-descriptor of the device at any point of
time.
This limitation needs to be removed because of two reasons:
1. Blocking multiple processes and trying to account them was stupid and
doomed to fail.
2. The driver needs to support system management applications that just
want to inquire about the device's status while a deep-learning
application is also running and sending work to the device.
With this patch-set, there can be unlimited number of open
file-descriptors of the device by unlimited number of user space
processes.
Having said that, only a single process can submit work to the device, or
do any change in the device itself via IOCTLs. All the processes can
perform inqueries about the device using the INFO IOCTL. This is enforced
by using an object called "context".
The "context" object is created as part of the private data the driver
saves per an open file-descriptor. For backward compatibility with
existing user-space code, the "context" is created in a lazy way (it is
created on the first call to an IOCTL). There can be only a single context
per process, and only a single context on the entire device is considered
"compute context". Only the FD which owns the "compute context" can
call IOCTLs which require this context, such as command submissions,
memory map, etc.
Only when an FD is completely released, its context will be closed. It
doesn't matter if the FD is duplicated or shared in user-space, as the
driver will keep a single private data structure (and single context) per
that FD.
In addition, a context that was open as a "non-compute context" can be
upgraded to a "compute context", if there isn't any other "compute
context". This is because the application usually calls the INOF IOCTL
before it calls other IOCTLs.
Thanks,
Oded
Oded Gabbay (9):
habanalabs: add handle field to context structure
habanalabs: verify context is valid in IOCTLs
habanalabs: create context in lazy mode
habanalabs: don't change frequency if user context is valid
habanalabs: maintain a list of file private data objects
habanalabs: define user context as compute context
habanalabs: protect only pointer dereference in hard-reset
habanalabs: kill user process after CS rollback
habanalabs: allow multiple processes to open FD
drivers/misc/habanalabs/command_buffer.c | 6 +
drivers/misc/habanalabs/command_submission.c | 12 ++
drivers/misc/habanalabs/context.c | 145 ++++++++++++++++---
drivers/misc/habanalabs/debugfs.c | 4 +-
drivers/misc/habanalabs/device.c | 144 +++++++++---------
drivers/misc/habanalabs/goya/goya_hwmgr.c | 11 +-
drivers/misc/habanalabs/habanalabs.h | 39 ++---
drivers/misc/habanalabs/habanalabs_drv.c | 54 ++-----
drivers/misc/habanalabs/habanalabs_ioctl.c | 20 ++-
drivers/misc/habanalabs/memory.c | 6 +
10 files changed, 285 insertions(+), 156 deletions(-)
--
2.17.1
next reply other threads:[~2019-07-28 11:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-28 11:28 Oded Gabbay [this message]
2019-07-28 11:28 ` [PATCH 1/9] habanalabs: add handle field to context structure Oded Gabbay
2019-07-28 11:28 ` [PATCH 2/9] habanalabs: verify context is valid in IOCTLs Oded Gabbay
2019-07-28 11:28 ` [PATCH 3/9] habanalabs: create context in lazy mode Oded Gabbay
2019-07-28 11:28 ` [PATCH 4/9] habanalabs: don't change frequency if user context is valid Oded Gabbay
2019-07-28 11:28 ` [PATCH 5/9] habanalabs: maintain a list of file private data objects Oded Gabbay
2019-07-28 11:28 ` [PATCH 6/9] habanalabs: define user context as compute context Oded Gabbay
2019-07-28 11:28 ` [PATCH 7/9] habanalabs: protect only pointer dereference in hard-reset Oded Gabbay
2019-07-28 11:28 ` [PATCH 8/9] habanalabs: kill user process after CS rollback Oded Gabbay
2019-07-28 11:28 ` [PATCH 9/9] habanalabs: allow multiple processes to open FD Oded Gabbay
2019-07-28 11:44 ` Greg KH
2019-07-28 11:56 ` Oded Gabbay
2019-07-28 12:04 ` Greg KH
2019-07-28 12:06 ` Oded Gabbay
2019-07-28 12:12 ` Greg KH
2019-07-28 12:18 ` Oded Gabbay
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=20190728112818.30397-1-oded.gabbay@gmail.com \
--to=oded.gabbay@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oshpigelman@habana.ai \
--cc=ttayar@habana.ai \
/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).