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