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.)
Regards -- Andy
--
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
