Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces

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

On Tue 11 Sep 2012 10:06:29 AM PDT, Chris Leech wrote:
> On Mon, Sep 10, 2012 at 3:59 PM, Robert Love <robert.w.love@intel.com> wrote:

<snip>

>> 1) Create/alloc the port
>>     - Allocate kernel memory and create per-instance sysfs devices
>>     - No discovery or login
>>

# echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_create

results in:

/sys/bus/fcoe/devices/ctlr_0/

>> 2) Configure the port
>>     - Change mode, set ddp_min, etc...
>>

# echo "Fabric" > /sys/bus/fcoe/devices/ctlr_0/mode

no visible change

>> 3) Start the port
>>     - Begins discovery and/or login (depending on mode)
>>

# echo 1 > /sys/bus/fcoe/devices/ctlr_0/start

Begins discovery and login. Assuming there are FCFs then results in:

/sys/bus/fcoe/devices/fcf_0

>> 4) Destroy the port
>>     - Logout and free all memory

# echo eth3.172-fcoe > /sys/bus/fcoe/ctlr_destroy

/sys/bus/fcoe/devices/ctlr_0 is removed.

>>
>> I'm looking for feedback on using sysfs files as control interfaces that
>> the user (application) would write interface names to. I modeled this
>> series off of the bonding sysfs interface, but it was suggested to me that
>> it might not be a good example. I belive bonding uses two values per-file
>> a '+' or a '-" to add or delete and then the ifname apended. I am simply
>> writing the ifname to the ctlr_create or ctlr_destroy.
>
> Can you give an example session that goes through the 4 steps above
> and what the sysfs hierarchy looks like at each step?  I mostly get it
> from the patch descriptions, but I think it would help discussion of
> your proposed interfaces to see an example of them in use.
>

See above. bash-style.

> This feels a little awkward with all the special control files.  Have
> you thought about something designed for creating kernel objects, like
> configfs?  Similarly the separate start, enable, disable files vs.

Let me do some more reading about configfs. I may not have given it 
enough thought.

> having some sort of status attribute that can take different values.
> I feel like these need to be rethought as attributes instead of
> triggers.  Is there a big difference between start and enable?  Can
> you achieve the split between create and start by having it come up in
> a disabled state by default?
>

It's a good idea. I'll look into it.

> 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.

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.

Thanks, //Rob