[Open-FCoE] [RFC] FIP support

Abhijeet Joglekar ajoglekar at nuovasystems.com
Fri Jan 30 22:21:27 UTC 2009


> -----Original Message-----
> From: devel-bounces at open-fcoe.org [mailto:devel-bounces at open-fcoe.org]
On
> Behalf Of Joe Eykholt
> Sent: Friday, January 30, 2009 2:11 PM
> To: Love, Robert W
> Cc: devel at open-fcoe.org
> Subject: Re: [Open-FCoE] [RFC] FIP support
> 
> 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.
> 
> 	Thanks,
> 	Joe
> 

Joe, 

As we already discussed, I would prefer it in the order (3), (2), (1).
The idea of making (3) have a more generic name sounds best as suggested
by others.

-- abhijeet





More information about the devel mailing list