On 2015-10-14 10:20, Andy Grover wrote:
On 10/13/2015 09:20 PM, Oleg Smolsky wrote:
Hi there! I'm looking at tcmu-runner/file_example.c. The code handles
Read requests in a blocking fashion by looking at tcmu_cmd_entry/req and
dumping data into req.iov.
Is async req completion supported? If so, what is the protocol? (IE what
is the SAM_ code and what do I have to stash away in order to complete
the op at a later stage?)
Hi Oleg,
TCMU does not currently support async req completion but it was
envisioned as an early enhancement we could make. The primary
technical issue with the kernel code is that the data area is
allocated and freed with a simple circular stack allocation mechanism.
See alloc_and_scatter_data_area() and gather_and_free_data_area().
This would need to be replaced with something more flexible that could
free areas out of order. Once we had that, then adding a feature flag
to the mailbox would let user processes know that they can change the
cmd_id field when completing cmds by moving cmd_tail, allowing out of
order completions.
(That is, if cmds A and B were on the cmd ring and B finished first, B
would use A's old entry in the cmd ring for its response, and then
whenever A finished it would use B's.)
Then, if using tcmu-runner there's a separate issue of how to enable
TCMU handler modules to use the ability to complete requests out of
order. Maybe we'll need to define an entirely new handler API? For
developing the current handler API, the needs of the handlers we have
so far have driven the handler->core and core->handler interfaces. One
approach might be to have a goal to make a current (or new) handler
async, and design the API most convenient for that handler.
One last point is that the tcmu-runner async support work need not
wait for the kernel support. We could develop an async handler API but
make the core put them back in order, if the kernel support is not
present yet. (We'd need this anyway to use async handlers on older
kernels.)
Hi Andy, thank you for the detailed response!
While I cannot comment on the kernel-mode code, the user-mode part
certainly needs love. Today, tcmu-runner owns the worker threads, thus
forcing the users' code into the plugin structure. This certainly works
for minimal examples, but prevents any kind of embedding into larger
3rd-party applications.
Production-grade applications generally have their own threading
structure and want to deal with socket/file/tcmu notifications in an
async way. As such, I just need a library with add_device(),
handle_device_events() and handle_one_command() from main.c and most of
api.c to talk to the kernel. Tcmu-runner could use the very same library
and maintain the existing threading model.
I can contribute the changes if such a structure is agreeable.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
