Re: future FCoE ideas (Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces)

["Love, Robert W" <robert.w.love@intel.com>]

On Thu 13 Sep 2012 03:32:50 PM PDT, Chris Leech wrote:
> <cutting down the CC list, as this bit isn't really about patch review anymore>
>
>>> That being said, I'm glad this is being reworked.  Do you have any
>>> other functionality in mind that this is laying the groundwork for?
>>>
>>
>> I have one feature and a few ideas. I currently have a patch that adds
>> a fabric selection feature. I add another RW attribute to the ctlr_X
>> device. If the user writes fabric name to the file libfcoe uses it in
>> it's FCF selection algorithm. Here's my commit message from that patch.
>> I can share the patch if people would like to see it too. The current
>> implementation also allows the user to force the login through a
>> specific FCF.
>>
>>       libfcoe, bnx2fc, fcoe: Add 'selection' attribute
>>
>>      This patch adds a 'selection' attribute to the
>>      fcoe_ctlr_device. The user can write either a
>>      '0x' prefixed fabric name or a ':' separated
>>      MAC address to this file. If a fabric name is
>>      provided the fcoe ctlr will only consider FCFs
>>      with the fabric name when choosing a FCF to login
>>      to. If a MAC address is provided the initiator
>>      will only login to a FCF with the given Ethernet
>>      address. Only one selection is valid at a time.
>>
>>      There are corresponding changes to fcoe-utils
>>      to take advantage of this kernel feature and
>>      to make it more accessible for the user.
>>
>> To accompany this feature I created a new fipfcf application based on
>> fipvlan that sends out a discovery solicitation and displays
>> advertising FCFs.
>
> Cool, I think you know that the lack of control over FCF selection has
> bothered me for a while :)
>
> Another option to think about, instead of configuring a preferred FCF
> prior to discovery (using your command line tool to find out what's
> available) what if it was possible to disable the auto-login behavior
> (leaving it on by default) and then enable login to an FCF using the
> representation you've added to sysfs?  Basically, allow a user-space
> policy agent to disable the auto-selection and take control.
>
> So the steps could be
>
> 1) create and FCoE controller for a network interface
> 2) configure the controller, disabling auto-fabric-selection
> 3) enable the controller, starting FCF discovery
> 4) select from the discovered FCF objects
> 5) enable fabric login on the desires FCFs
>
> That could even work for native PCI-function FCoE devices, where
> fipvlan/fipfcf have issues because the netdev might not be up (or even
> have a driver loaded), as long as they support the interface and
> provide the OS with information about discovered FCFs.
>
>> I've also been talking with Mark Rustad about doing an 'auto' mode
>> where Fabric discovery is attempted first and if it fails then it tries
>> VN2VN discovery, but so for we've only had hallway conversations about
>> it and nothing has been flushed out.
>
> I'm trying to get caught up on what's getting traction with the
> FC-BB-6 working group, but it looks like VN2VN for both true
> point-to-point and multipoint might get nailed down.  As well as
> establishing shortest-path connections between native FCoE endpoints
> in fabric mode, to avoid shoving all data through the FCF if it
> doesn't need to.  All exciting work to think about.
>
> Do we have a better indication of what network interface an fc_host is
> created on, or is parsing for 'fcoe v0.1 over <ifname>' in the
> symbolic name still the best thing going?
>

Just some quick thoughts.

I have a patch to add a hbaapi_library (or something like that) 
attribute to the fc_host where LLDs that want to be managed by 
libhbalinux could set this to "libhbalinux". I know this isn't exactly 
what you're asking for, but I thought I should mention it. This effort 
was simply designed to get rid the " over " parsing and wasn't intended 
to be related to the fabric selection effort.

> Sorry if it seems like I've got lots of opinions but no patches right now :)
> I'm testing your RFC patchset out, at least to the extent that I can
> with VN2VN mode right now.

Hmm.. There might not be anything to test with VN2VN since I only 
changed the selection FCF algorith.

The last thing I've been thinking of lately regarding the new interface 
effort is that if we do move to a create/configure/start or 
create-disabled/configure/enable. We could move the dcb_required check 
in kernel and thin down fcoemon considerably.

Thanks for the review/comments, //Rob