Hi Mike, On Sun, 11 Jun 2017 16:31:00 -0500, Mike Christie wrote: > Hey Zhu, > > On 06/11/2017 12:06 PM, Zhu Lingshan wrote: > > Hello experts: > > > > I am working on PR support for RBD in user space, aka, give tcmu-runner > > rbd handler ability to handle Persistent Reservation operations. Now RBD > > handler side works fine, I can capture the CDBs, analyze it, store/ read > > keys, also other supportive codes done and works fine. > > > > But I need to pass through some session information to tcmu-runner, like > > initiator name and port information. I have three proposals on this > > feature, hope and eager to get some suggestions > > With Bryant's PR patches merged, does this work like you are expecting > below? tcmu does not set the TRANSPORT_FLAG_PASSTHROUGH_PGR, so PR > commands are now being executed by the kernel. Userspace does not know > about them, so we would never get to access the info below. > > If we are keeping processing in the kernel, then for PRs you would need > to add a netlink like interface to pass userspace the processed info > like PR type and also the I_T Nexus info. Interesting, so IIUC this method would then see the tcmu backends treat PR state like an opaque blob. In that case we'd also need something in the opposite direction for bootstrapping new active/passive target nodes, or for notification of state changes via alternate paths for the active/active case, right? ... > > (2)Add such information in the command entry header( tcmu_cmd_entry.hdr > > ) like command id which is already there. But just for initiator name > > this may require 224 bytes at most, and we may need another bool bit to > > tell user space whether there is an initiator sent out, because is would > > I did not get why only the initiator name would be needed? For some > commands we need the all of the I_T Nexus into don't we? > > A backend device could be exported through multiple targets/ports and > through multiple initiators/ports. Different combos of those might be > registered for PRs. Indeed. > > be a waste if we pass initiator name every time even not needed. Maybe > > this is not a good idea, because when we need to pass through other > > information, we may make the header quite messy, I think it is nice to > > keep it simple. The biggest problem is, the header file > > /usr/include/linux/target_core_user.h belongs to the package > > "linux-glibc-devel", this package always take half a year for updating. > > This means if we changed this header file(it is a copy of kernel > > header), we need to wait almost half a year for sync, or tcmu-runner can > > not build. So I think this is not a workable idea. > > > > (3)Add such information in the io_vec, this means > > entry->req.iov[iov_cnt], this can work, but will make io vec quite > > messy. And ugly, because such session information are not operational > > data which is io_vec should contain. And we also need additional bool > > bit to tell user space which kind of session information we pass through > > to tcmu-runner. So I think it is also not a workable idea. > > > > There is also a 4th option for the userspace PR handling method. We > could just go the tgt route where when a session/I_T_nexus is > established, then the kernel tells userspace about it. On each command > sent to userspace you get a int session id to match by. You then do not > have to pass a lot of info upwards for each command, but you would still > have the header installation problem. This sounds like a nice proposal. > There is also a INQURIY problem still. tcmu-runner currently executes > it, and it does not know what target group and port it has been received > on, so we can only support 1 right now. For XCOPY I think we could have > a problem where we the list identifier is per I_T Nexus. Maybe we could > just fix this once for all commands? Could target port group registration be done alongside session/I_T_nexus establishment notification here? Cheers, David -- 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
