On Jan 15, 2008 2:18 PM, James Smart <James.Smart@xxxxxxxxxx> wrote: > True - it should become rather evident that FC should be its own > i/o bus, with the hba LLDD providing bindings to each of the FC4 stacks. > This would have worked really well for FCOE, with it creating a fc_port > object, which could then layer a scsi_host on top of it, etc. > Right now there's too much assumption that SCSI is the main owner of the > port. The NPIV vport stuff is a good illustration of this concept (why is > the vport a subobject of the scsi_host ?). In thinking about how FC should be represented, it seems to me that in order to provide good interfaces at multiple levels of functionality we have to make sure the we have the right data structures at each level. At the highest level there's scsi_cmd, then there's sequence based interfaces that would need some sort of a sequence structure with a scatter gather list, and at the lowest level interfaces work directly with FC frames. I'd like to talk about how we should go about representing FC frames. Currently, our libfc code introduces an fc_frame struct but allows the LLDD to provide an allocation function and control how the fc_frames are allocated. The fcoe module uses this capability to map the data buffer of an fc_frame to that of an sk_buff. As someone coming from a networking background, and interested in FCoE which ends up sending frames via an Ethernet driver, I tend to think this is overly complex and just want to use sk_buffs directly. Would SCSI/FC developers be opposed to dealing with sk_buffs for frame level interfaces, or do we need to keep a seperate fc_frame structure around? I'd argue that skbs do a fine job of representing all sorts of frame structures, that any device that supports IP over FC has to deal with skbs in its driver anyway, and that at the frame level FC is just another network. But then again, I am biased as skbs seem friendly and familiar to me as I venture further into the alien landscape that is scsi. - Chris - 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
