Chris Leech wrote:
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 think the only thing that will actually talk frames will either be a fc mac, which we haven't seen yet, or a FCOE entity. Consider the latter to be the predominant case.
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.
If the predominant user is fcoe, then I think describing the frame in the context of a sk_buff is fine.
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
-- james s - 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
