RE: Open-FCoE on linux-scsi

[FUJITA Tomonori <tomof@acm.org>]

On Fri, 4 Jan 2008 14:07:28 -0800
"Dev, Vasu" <vasu.dev@intel.com> wrote:

> 
> >>
> >> _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.

You just calls fc_remote_port_add. I don't think that reinventing the
whole rport management like reference counting doesn't mean exploiting
the exsting struct fc_rport and APIs.


> 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.

As pointed out in other mails, I believe that the similar job has done
in other transport classes using scsi transport class infrastructure
and the FCoE needs to follow the existing examples.