[Open-FCoE] [RFC] FIP support

Joe Eykholt jeykholt at cisco.com
Fri Jan 30 22:11:09 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.

Keeping it separate until accepted upstream is fine.

I asked the SCSI alias that question back in November.
James Smart agreed with my justifications and to have it in the
kernel.  I got one other agreement, but I forget who it was.
I didn't get any dissent.

>> 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.

There isn't much more generic code that can be moved, but I guess
libfcoe.ko may be a better name since it doesn't limit the content to FIP.
Note that the non-FIP handling of FLOGI is already moved into this code now.

If we move more code into it, then we're back to the issue that not
all clients using libfcoe.ko will want the extra code, but as long as
it's small, that's OK.

Thanks, everyone, for the feedback, I'll wait a while to hear more,
then refresh the patch set accordingly.


More information about the devel mailing list