On Wed, 2011-10-26 at 20:23 +0200, Bart Van Assche wrote: > On Mon, Oct 24, 2011 at 10:25 PM, Nicholas A. Bellinger > <nab@xxxxxxxxxxxxxxx> wrote: > > On Mon, 2011-10-24 at 21:57 +0200, Bart Van Assche wrote: > >> On Mon, Oct 24, 2011 at 7:33 AM, Nicholas A. Bellinger > >> <nab@xxxxxxxxxxxxxxx> wrote: > >> > + snprintf(sport->port_guid, sizeof(sport->port_guid), > >> > + "0x0000000000000000%016llx", > >> > + be64_to_cpu(sport->gid.global.interface_id)); > >> > >> If I interpret Roland's e-mail correctly Roland asked to use GID table > >> entry 0 (http://www.spinics.net/lists/linux-rdma/msg09751.html) ? > >> > > > > I'll defer to Roland on this, as the port->gid.global.interface_id you > > recommended does exactly what we need. I'm happy to test another code > > snippet if you have one handy. > > Something like this should generate GID 0 in ASCII format (not tested > in any way, and using separators will help to make the output easier > to read): > > snprintf(sport->port_gid, sizeof(sport->port_gid), > "0x%016llx%016llx", > be64_to_cpu(sport->gid.global.subnet_prefix), > be64_to_cpu(sport->gid.global.interface_id)); > So adding the subnet_prefix here works as expected, and as previously mentioned I'm OK to change the /var/target/fabric/ib_srpt.spec formatting in rtslib for SRP target ports to accommodate this.. But the bit that now looks kinda odd with this change is that NodeACLs would still not be using the subnet_prefix. Here's a bit of targetcli output to demonstrate: /ib_srpt> info Fabric module name: ib_srpt ConfigFS path: /sys/kernel/config/target/srpt Allowed WWNs list (free type): 0xfe800000000000000002c903000e8ace, 0xfe800000000000000002c903000e8acd Fabric module specfile: /var/target/fabric/ib_srpt.spec Fabric module features: acls Corresponding kernel module: ib_srpt /ib_srpt> ls o- ib_srpt ......................................................... [2 Targets] o- 0xfe800000000000000002c903000e8acd .............................. [enabled] | o- acls ............................................................ [1 ACL] | | o- 0x00000000000000000002c903000e8be9 .................... [1 Mapped LUNs] | | o- mapped_lun0 ............................................. [lun0 (rw)] | o- luns ........................................................... [1 LUNs] | o- lun0 ................................... [iblock/scsi_debug (/dev/sdb)] o- 0xfe800000000000000002c903000e8ace .............................. [enabled] o- acls ............................................................ [1 ACL] | o- 0x00000000000000000002c903000e8bea .................... [1 Mapped LUNs] | o- mapped_lun0 ............................................. [lun0 (rw)] o- luns ........................................................... [1 LUNs] o- lun0 .................................. [iblock/scsi_debug2 (/dev/sdc)] /ib_srpt> So I don't see an easy way to get subnet_prefix for the incoming initiator port in srpt_cm_req_recv(), as what's being passed in from srp_login_req->initiator_port_id seems to have subnet_prefix already stripped off..? So the two question here for Roland and yourself are: Is using a real subnet prefix for target ports, but not the explict NodeACLs for initiator ports acceptable for an initial merge..? If not, how is it possible to obtain the remote initiator port's subnet_prefix during login in srpt_cm_req_recv() so we can keep subnet_prefix usage consistent between target ports and explict NodeACL initiator ports in /sys/kernel/config/target/srpt/ Thank you, . --nab -- 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
