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:45:33 PM PDT, Love, Robert W wrote:
> 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.

Ignore this statement. Setting the ctlr's mode to VN2VN should work. I 
meant to say that I didn't add anything to fcoemon for VN2VN.