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:

quoted

On Mon, Sep 10, 2012 at 3:59 PM, Robert Love [off-list ref] wrote:

<snip>

quoted

quoted

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/

quoted

quoted

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

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

no visible change

quoted

quoted

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

quoted

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

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.

quoted

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 linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html