>>
>> _If_ there will indeed be dedicated FCoE HBAs in the future, the
>> following stack could exist in addition to the one above:
>>
>> - SCSI core,
>> scsi_transport_fc
>> - FCoE HBA driver(s)
>
>Agreed. My FCoE initiator design would be something like:
>
>scsi-ml
>fcoe initiator driver
>libfcoe
>fc_transport_class (inclusing fcoe support)
>
>And FCoE HBA LLDs work like:
>
>scsi-ml
>FCoE HBA LLDs (some of them might use libfcoe)
>fc_transport_class (inclusing fcoe support)
>
>
>That's the way that other transport classes do, I think. For me, the
>current code tries to invent another fc class. For example, the code
>newly defines:
>
>struct fc_remote_port {
> struct list_head rp_list; /* list under fc_virt_fab */
> struct fc_virt_fab *rp_vf; /* virtual fabric */
> fc_wwn_t rp_port_wwn; /* remote port world wide name
*/
> fc_wwn_t rp_node_wwn; /* remote node world wide name
*/
> fc_fid_t rp_fid; /* F_ID for remote_port if known
*/
> atomic_t rp_refcnt; /* reference count */
> u_int rp_disc_ver; /* discovery instance */
> u_int rp_io_limit; /* limit on outstanding I/Os */
> u_int rp_io_count; /* count of outstanding I/Os */
> u_int rp_fcp_parm; /* remote FCP service parameters
*/
> u_int rp_local_fcp_parm; /* local FCP service
parameters */
> void *rp_client_priv; /* HBA driver private data */
> void *rp_fcs_priv; /* FCS driver private data */
> struct sa_event_list *rp_events; /* event list */
> struct sa_hash_link rp_fid_hash_link;
> struct sa_hash_link rp_wwpn_hash_link;
>
> /*
> * For now, there's just one session per remote port.
> * Eventually, for multipathing, there will be more.
> */
> u_char rp_sess_ready; /* session ready to be used */
> struct fc_sess *rp_sess; /* session */
> void *dns_lookup; /* private dns lookup */
> int dns_lookup_count; /* number of attempted lookups
*/
>};
>
>/*
> * remote ports are created and looked up by WWPN.
> */
>struct fc_remote_port *fc_remote_port_create(struct fc_virt_fab *,
fc_wwn_t);
>struct fc_remote_port *fc_remote_port_lookup(struct fc_virt_fab *,
> fc_fid_t, fc_wwn_t wwpn);
>struct fc_remote_port *fc_remote_port_lookup_create(struct fc_virt_fab
*,
> fc_fid_t,
> fc_wwn_t wwpn,
> fc_wwn_t wwnn);
>
>
>The FCoE LLD needs to exploit the exsting struct fc_rport and APIs.
The openfc is software implementation of FC services such as FC login
and target discovery and it is already using/exploiting existing fc
transport class including fc_rport struct. You can see openfc using
fc_rport in openfc_queuecommand() and using fc transport API
fc_port_remote_add() for fc_rport.
The fcoe module is just a first example of possible openfc transport but
openfc can be used with other transports or HW HBAs also.
The openfc does provide generic transport interface using fcdev which is
currently used by FCoE module.
One can certainly implement partly or fully openfc and fcoe modules in
FCoE HBA.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
