Hi Andy, Please find my comments inline. On Wed, Apr 01, 2015 at 12:15PM, Andy Grover wrote: > On 04/01/2015 08:35 AM, Ilias Tsitsimpis wrote: > >Hi Nicholas & Andy, > >I am working on adding support for BIDI operations to the TCM Userspace > >module and I would like to discuss the implementation details with you, > >before submitting the patches. > > <snip correct analysis> > > >The problem is, that BIDI commands need both data-in and data-out > >buffers, but the current tcmu_cmd_entry only contains a single iov_cnt > >field. > > Hi Ilias, > > I'm not too familiar with BIDI ops, but using XDWRITEREAD as an example, I > think we could specify that req.iov[] contains Data-In initially and then > Data-Out overwrites req.iov[] (which must be sized as max(in, out)). Or, if > overwriting Data-In is best avoided, then we can size req.iov[] for both and > find where the Data-Out section starts without requiring the new field. I am not sure I understand what you are suggesting. How can we find where the Data-Out section starts without requiring the new field? Even when req.iov[] is sized as max(in, out), don't we need to pass both Data-In and Data-Out buffer lengths? Can you elaborate a bit? (As an aside note, it seems your narration has reversed the meaning of Data-In and Data-Out buffers, but this does not affect our discussion). Cheers, Ilias > Your email also made me realize that one of TCMU's backwards-compatible > extension mechanisms -- new tcmu_opcodes -- is not workable. There's no way > for the kernel to differentiate between a completed new opcode that was > handled by userspace that knew about it, and one that was skipped but not > handled by userspace because it was an unknown opcode. But maybe we don't > need this mechanism. If BIDI cmds can be handled with the existing struct > tcmu_cmd_entry, I have a hard time coming up with other tcmu_opcodes we > might ever need. > > Regards -- Andy
Attachment:
signature.asc
Description: Digital signature
