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��������+%������w��{.n�����{������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f