Re: [RFC] FC pass thru - Rev IV

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



James Smart wrote:
> Sven Schuetz wrote:
>> Shouldn't we add FC_BSG_HST_CT_NOLOGIN as well?
> 
> I didn't add this as FC-GS-6 r9.21, which defines the CT protocol, says:
>  4.5.2.1 Fabric login and N_Port login
>   An Nx_Port shall perform Fabric Login, and shall perform N_Port Login
>   with the WKA or N_Port Identifier where the Service is offered, in the
>   manner that is specified in FC-FS, before making any requests
>   of a Server provided by the Service. An Nx_Port that has completed its
>   registration with a Server shall perform explicit N_Port Logout with
>   the Service. An Nx_Port that has completed any other requests with a
>   Server should also perform explicit N_Port Logout with the Service.
> 
> So - a login for CT requests is a must (at least as I read it).
> 
> That's not the case for ELS's, which can usually survive on an implicit
> login - especially things like ADISC/PDISC.   Login is also the
> distinction in my opinion for whether something should or should not be
> exported via an rport in the transport.

Hi James,

I agree.

>> As far as I can see from looking over the patch (correct me when I am
>> wrong),
>> the way to issue a CT request now is to send an FC_BSG_HST_ADD_RPORT
>> for the wka
>> port in question (if not enumerated by the driver, which zfcp does not
>> do), then
>> send the FC_BSG_RPT_CT followed by a FC_BSG_HST_DEL_RPORT. I was under
>> the
>> impression the CT stuff was one of the main reasons to have devices
>> for the
>> fc_host. What do you think?
> 
> Your flow is exactly what I intended...

OK, let me be a bit more precise. Maybe I shouldn't have called it
FC_BSG_HST_CT_NOLOGIN but something like FC_BSG_HST_CT_NOT_ENUMERATE.

As the FS-GS dictates, we do a port login and logout for CT requests, but
completely in the driver. We do that for some internal CT stuff and I have
implemented it for userspace CT requests with Seokmanns patch as well. We just
do not advertise the ports to fc_transport (we are only logged in for the
duration of the request). Having to react to FC_BSG_HST_ADD_RPORT would mean to
rewrite our wka port handling, plus some of it is done in our firmware and not
in zfcp.

So my suggestion would be to add something like FC_BSG_HST_CT_NOT_ENUMERATE for
drivers that do the port logins on their own. Other drivers can respond with an
error code, making it necessary for the app to do the port login on their own
(FC_BSG_HST_ADD_RPORT), that means following the procedure I outlined in my
previous mail.

In addition, userspace apps that deal with complete CT frames (like
implementations of HBA API) would not have to rip the frame apapart to find out
the generic service/wka port in question and then do the port login. They can
just send the frame to the driver and rely on the driver to do the port
login/logout.

Sven
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux