Re: Open-FCoE on linux-scsi

[James Smart <James.Smart@Emulex.Com>]

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