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
N�����r��y����b�X��ǧv�^�){.n�+����{���"�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�m��������zZ+�����ݢj"��!�i
