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. > > (I like the first one, if you have quite limited time, please read > number 1). > > (1)I think this idea may work, using configFS, we can create a configFS > group like tcmu/rbd(or other handler entries)/rbd_name/command_id(we > already have it in the command entry header, not require the header file > chagnes), then store some key-value pairs there, like "initiator_name" > as key(file name) and "iqn.xxxx-xxx.xxxxxx" as value(file content), when > we need to exchange session information, we can create such groups and > attributes, after processing them, we can delete/free them. Yes, this > may require an additional lock. I think it is simple, easy, not messy. > And someday if we need to send some information to kernel side other > than sense buffer, we can also use it! > If we end up passing PRs to userspace again, then #1 seems fine for PRs management type of commands like registration/reservations. However, we need to check for reservations on each command, so I am not sure if we want to pass the command to userspace, then go back down to the kernel to read a bunch of files to get the I_T nexus info, do the resevation check in userspace, then go back down to the kernel again to complete it. > > (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. > 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. 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? -- 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
