From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============0666173710513423512==" MIME-Version: 1.0 From: Shahar Salzman Subject: Re: [SPDK] Updating discovery for ACL Date: Wed, 27 Feb 2019 08:31:08 +0000 Message-ID: In-Reply-To: EA913ED399BBA34AA4EAC2EDC24CDD009C27254D@FMSMSX105.amr.corp.intel.com List-ID: To: spdk@lists.01.org --===============0666173710513423512== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I started sketching up the implementation yesterday, and am contemplating t= wo directions. The first is to malloc a jump buffer the size of the already existing disco= very log page, and then copy the relevant part of the discovery log page. The other direction is to use the existing log page, and only copy the rele= vant subsystem information to the iovec. The additional caveat is that in either case, the numrec needs to be update= d to the filtered number of subsystems. The first adds a malloc/free on every discovery, the second is much more co= mplicated in that we need to save the iovec_offset and handle all sorts of = gnarly corner cases. Regarding getting the subsystems, I was actually thinking of a "softer" mec= hanism such as saving, along with the discovery log page an ordered mapping= between subsystem and nqn, so when copying the "relevant" part we can do: for (i =3D 0; i < subsys_map->num_subsystems; i++) { if (!spdk_nvmf_subsystem_host_allowed(subsys_map->subsystems[i], ho= stnqn) { continue; } /* copy listener info to the jump buffer */ } ________________________________ From: SPDK on behalf of Howell, Seth Sent: Monday, February 25, 2019 8:01 PM To: Storage Performance Development Kit Subject: Re: [SPDK] Updating discovery for ACL Hi Shahar, I think that placing the hostnqn in the controller is the right thing to do= . It will still be accessible from the request object when we do the discov= ery a few commands later. When it comes to the actual discovery mechanism, what is your plan? Current= ly, we only regenerate the discovery log when the generation counter has ch= anged and the log is stored as a collection of strings. We will have to fin= d a way to get back to the subsystems from the log page entries to check ac= cess controls. One would be to regenerate the discovery log every time someone asks for it= and check the hostnqn in nvmf_update_discovery_log. Another way would be to add a new function such as get_nvmf_subsystem_by_nq= n to the internal api. That would allow you to loop over the already genera= ted log page buffer and copy over only the allowed entries. I think this wa= y would be more efficient than the first. Thanks, Seth -----Original Message----- From: SPDK [mailto:spdk-bounces(a)lists.01.org] On Behalf Of Shahar Salzman Sent: Sunday, February 24, 2019 12:51 PM To: Storage Performance Development Kit Subject: [SPDK] Updating discovery for ACL Hi, I am following up on bug # 576 - nvme discover shows all target subsystems,= even those that are not accessible by the host. I looked at the discovery subsystem code, and it seems that a good option w= ould be to copy only the relevant part of the discovery log page (i.e. only= information about subsystems that the host has access to). The problem is, that on the discover request there is no hostnqn informatio= n, Looking at the connect, I see that the hostnqn is checked, but not saved an= ywhere, so it looks like a good option to save it on the controller, so tha= t we can later reference this value. Now upon discovery we can copy the relevant portions of the log page. WDYT? Shahar _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk _______________________________________________ SPDK mailing list SPDK(a)lists.01.org https://lists.01.org/mailman/listinfo/spdk --===============0666173710513423512==--