[Open-FCoE] [RFC] FIP support

Love, Robert W robert.w.love at intel.com
Fri Jan 30 21:09:02 UTC 2009


Joe Eykholt wrote:
> Hi All,
> 
> I'm getting ready to resubmit the FIP support patches for the
> fcoe-fixes tree. 
> Is it likely to be accepted and integrated?
> 
I'd be glad to create a fcoe-features tree to put it in. As well
as fnic for that matter (if I can get some updated patches),
since -initiator is becoming stale. The fcoe-fixes tree I'm
using as a staging tree for just fixes, so although I think
preparing your patches against it is the right thing to do, I
don't think FIP should be committed there until there's some
degree of buy off from linux-scsi about it being in-kernel.

> One issue I'd like comments on is:  where does it live.   The
> alternatives I 
> can see are:
> 	1.  fcoe.ko
> 	2.  libfc.ko
> 	3.  fcoe_ctlr.ko
> 
> There are two files: fcoe_ctlr.c and fcoe_ctlr.h.   I'm now putting
> them in the fcoe.ko module, which makes some sense because FIP is
> purely FCoE-related, 
> and libfc should not have transport-specific code in it IMO.  For
> example, 
> if there were an FCIP transport, just for sake of argument, we
> wouldn't 
> need or want FCoE code loaded in order to run that.
> 
> Having it in fcoe.ko, however, causes other LLDs like the fnic driver
> to load fcoe.ko even though no fcoe instances would be created so the
> bulk of the code would be unused. We would want to make changes so
> that resources like the per-CPU threads weren't created just because
> the module is loaded, perhaps, instead waiting until the first
> instance of fcoe was created. 
> 
> A third alternative is to make yet another module just for FIP, and
> have both 
> fcoe.ko and fnic.ko use it.   It seems like it might be too small a
> piece of 
> code to allocate a whole module for it.  However, there are some very
> small modules like scsi_wait_scan.ko, so why not?
>
At first glance, I like this third aproach. I don't see size as a
limiting factor and I wouldn't want to hack up fcoe.ko because fnic
only wants the FIP portions. 

Would there be any sense in having a libfcoe.ko that FIP and some of
the more generic code would be in and the fcoesw.ko for the SW FCoE
stack? Open-iSCSI has libiscsi.ko and iscsi_tcp.ko.



More information about the devel mailing list