[Open-FCoE] [RFC] FIP support

Joe Eykholt jeykholt at cisco.com
Sat Jan 31 23:05:36 UTC 2009



Love, Robert W wrote:
> 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.

I'm going ahead with using that name, libfcoe, for now.  Should we 
rename the existing libfcoe.[ch] files since they won't be in libfcoe?

It may not matter all that much but it may confuse people.

	Joe




More information about the devel mailing list