[Open-FCoE] [RFC] FIP support
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
>> if there were an FCIP transport, just for sake of argument, we
>> 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.
More information about the devel