Message-ID: <504F836C.3040907@broadcom.com>
Date:	Tue, 11 Sep 2012 11:31:08 -0700
From:	"Bhanu Prakash Gollapudi" <bprakash@...adcom.com>
To:	"Love, Robert W" <robert.w.love@...el.com>
cc:	"Chris Leech" <leech@...ox.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"devel@...n-fcoe.org" <devel@...n-fcoe.org>
Subject: Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces

On 9/11/2012 10:36 AM, Love, Robert W wrote:
> 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@...el.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

I'm assuming the existing functionality of automatically creating the 
vlan interface by fcoemon (using the cfg-ethX) continues to exist and 
the above is not a replacement for fcoeadm -c.

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

I'm also assuming that the above three steps can be clubbed by 
fcoeutils, perhaps by adding 'mode' parameter into the cfg-ethX file. 
That way 'service fcoe start' will be no different with the proposed 
model, except that there will be multiple entry points into the driver 
(alloc, config, start) instead of just one (create).

>
>>> 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.�{.n�+�������+%��lzwm��b�맲��r��zX��..�(��.��ܨ}���Ơz�&j:+v���.����zZ+��+zf���h���~����i���z�.�w���?����&�)ߢ.f
>


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists