Re: future FCoE ideas (Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces)
On Thu 13 Sep 2012 03:45:33 PM PDT, Love, Robert W wrote: 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. Ignore this statement. Setting the ctlr's mode to VN2VN should work. I meant to say that I didn't add anything to fcoemon for VN2VN.
Re: future FCoE ideas (Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces)
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�r��yb�X��ǧv�^�){.n�+{{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
On Mon, Sep 10, 2012 at 3:59 PM, Robert Love robert.w.l...@intel.com wrote: The following series implements a move from using module parameters as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure was added to the kernel a few cycles ago, this series builds on that work. It moves the create, vn2vn_create, destroy, enable and disable interfaces from /sys/module/libfcoe/parameters/ to various places under /sys/bus/fcoe/. These interfaces simply are not module configurations- they are control interfaces. A second goal of this series is to change the initialization sequence for a FCoE device. The result of this series is that interfaces created using libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the following starting steps- 1) Create/alloc the port - Allocate kernel memory and create per-instance sysfs devices - No discovery or login 2) Configure the port - Change mode, set ddp_min, etc... 3) Start the port - Begins discovery and/or login (depending on mode) 4) Destroy the port - Logout and free all memory 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. 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. 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? 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? - Chris -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
On Mon, Sep 10, 2012 at 5:05 PM, Bhanu Prakash Gollapudi bprak...@broadcom.com wrote: I'm concerned that we will be breaking user space compatibility with this change, as there should be a corresponding fcoemon/fipvlan change along with this, and existing utilities will not work. Also the way we start fcoe will be completely different and the user may need to do the scripting changes, if any. I agree with Bhanu on these concerns, even though I hope everyone's using fcoeadm/fcoemon/fipvlan. I think there needs to be more of a transition plan than requiring everyone moving to a new kernel to update the user-space tools at the same time. Removing the module parameters with the last patch might be rushed, they should probably remain for a few kernel cycles with a warning. When the tools are updated for the new interface, they should probably maintain fallback support for the module parameters for a while as well. - Chris -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
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.l...@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
Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
On Tue 11 Sep 2012 10:12:09 AM PDT, Chris Leech wrote: On Mon, Sep 10, 2012 at 5:05 PM, Bhanu Prakash Gollapudi bprak...@broadcom.com wrote: I'm concerned that we will be breaking user space compatibility with this change, as there should be a corresponding fcoemon/fipvlan change along with this, and existing utilities will not work. Also the way we start fcoe will be completely different and the user may need to do the scripting changes, if any. I agree with Bhanu on these concerns, even though I hope everyone's using fcoeadm/fcoemon/fipvlan. I think there needs to be more of a transition plan than requiring everyone moving to a new kernel to update the user-space tools at the same time. Removing the module parameters with the last patch might be rushed, they should probably remain for a few kernel cycles with a warning. When the tools are updated for the new interface, they should probably maintain fallback support for the module parameters for a while as well. Deprecating the old interfaces instead of immediately removing them sounds like a good idea to me. I hope everyone is using fcoeadm/fcoemon/fipvlan too. We do still carry the 'fcc.sh' script in fcoe-utils.git/contrib/. I don't use it, but I know others do. I did not update 'fcc.sh' with my user space change. I'll post the fcoemon changes to de...@open-fcoe.org. I think I have a bunch of cleanup patches that the change depends on, so the series will probably be half cleanup and half feature. Thanks, //Rob
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.l...@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
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
On Tue 11 Sep 2012 11:31:08 AM PDT, Bhanu Prakash Gollapudi wrote: 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.l...@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 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. Yes, you're right. These examples are only if you were using the interfaces from BASH. It's all coded up for fcoemon and there shouldn't be any user experience change with the new code. I'll post that code to de...@open-fcoe.org once I get it rebased and quickly tested. 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). Yes, you're right here too. However, the default is 'Fabric' so fcoemon won't actually have to change the mode. However, I'd like to see VN2VN support added to fcoeadm/fcoemon. It's on the TODO list. Once that's implemented fcoemon would need to change the mode depending on the user's selection.
Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
On 9/10/2012 3:59 PM, Robert Love wrote: The following series implements a move from using module parameters as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure was added to the kernel a few cycles ago, this series builds on that work. It moves the create, vn2vn_create, destroy, enable and disable interfaces from /sys/module/libfcoe/parameters/ to various places under /sys/bus/fcoe/. These interfaces simply are not module configurations- they are control interfaces. A second goal of this series is to change the initialization sequence for a FCoE device. The result of this series is that interfaces created using libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the following starting steps- 1) Create/alloc the port - Allocate kernel memory and create per-instance sysfs devices - No discovery or login 2) Configure the port - Change mode, set ddp_min, etc... 3) Start the port - Begins discovery and/or login (depending on mode) 4) Destroy the port - Logout and free all memory Robert, Can you please let me now what is the motivation for this change and what problem are we solving with this approach? Is this primarily to allow user to set the mode? I'm concerned that we will be breaking user space compatibility with this change, as there should be a corresponding fcoemon/fipvlan change along with this, and existing utilities will not work. Also the way we start fcoe will be completely different and the user may need to do the scripting changes, if any. Thanks, Bhanu 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. Series compiled and tested against v3.5. libfcoe.ko compile warning fixed upstream after v3.5, anyone who compiles this can ignore section mismatch warning. Also note that a modified fcoemon is needed to use the fcoe system service against this kernel modification. I'd be happy to provide that fcoemon code on request. --- Robert Love (5): libfcoe, fcoe: Allow user to set a ctlr's mode libfcoe: Create new libfcoe control interfaces fcoe: Use new fcoe_sysfs control interface bnx2fc: Use new fcoe_sysfs control interface libfcoe, fcoe: Remove libfcoe module parameters Documentation/ABI/testing/sysfs-bus-fcoe | 51 +++ drivers/scsi/bnx2fc/bnx2fc_fcoe.c| 98 - drivers/scsi/fcoe/fcoe.c | 229 +++--- drivers/scsi/fcoe/fcoe.h |9 + drivers/scsi/fcoe/fcoe_ctlr.c| 24 +++ drivers/scsi/fcoe/fcoe_sysfs.c | 139 ++ drivers/scsi/fcoe/fcoe_transport.c | 174 --- include/scsi/fcoe_sysfs.h|5 + include/scsi/libfcoe.h | 20 ++- 9 files changed, 445 insertions(+), 304 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
On Mon 10 Sep 2012 05:05:20 PM PDT, Bhanu Prakash Gollapudi wrote: On 9/10/2012 3:59 PM, Robert Love wrote: The following series implements a move from using module parameters as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure was added to the kernel a few cycles ago, this series builds on that work. It moves the create, vn2vn_create, destroy, enable and disable interfaces from /sys/module/libfcoe/parameters/ to various places under /sys/bus/fcoe/. These interfaces simply are not module configurations- they are control interfaces. A second goal of this series is to change the initialization sequence for a FCoE device. The result of this series is that interfaces created using libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the following starting steps- 1) Create/alloc the port - Allocate kernel memory and create per-instance sysfs devices - No discovery or login 2) Configure the port - Change mode, set ddp_min, etc... 3) Start the port - Begins discovery and/or login (depending on mode) 4) Destroy the port - Logout and free all memory Robert, Can you please let me now what is the motivation for this change and what problem are we solving with this approach? Is this primarily to allow user to set the mode? The main problem is that our control interfaces shouldn't be module parameters. I think of module parameters as things that globally alter the module. I also think that moving to a create/configure/start model gives us more flexibility going forward. We don't have too many FC/FCoE knobs to tune right now, but if we wanted to add more we don't have a good way to do it without starting the whole discovery/login process and then making changes during the discovery/login. I think the module parameter problem is the justification, but I'm trying to be comprehensive in coming up with a flexible interface that will allow us to evolve as well. I'm concerned that we will be breaking user space compatibility with this change, as there should be a corresponding fcoemon/fipvlan change along with this, and existing utilities will not work. Also the way we start fcoe will be completely different and the user may need to do the scripting changes, if any. See the last statement from my initial posting (it's below). I have patches to modify fcoemon to use these new interfaces. I'd be happy to share them, I just didn't want to spam this broad of a audience. Thanks, Bhanu 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. Series compiled and tested against v3.5. libfcoe.ko compile warning fixed upstream after v3.5, anyone who compiles this can ignore section mismatch warning. Also note that a modified fcoemon is needed to use the fcoe system service against this kernel modification. I'd be happy to provide that fcoemon code on request.
Re: [RFC PATCH 0/5] Reorganize libfcoe control interfaces
On 9/10/2012 6:41 PM, Love, Robert W wrote: On Mon 10 Sep 2012 05:05:20 PM PDT, Bhanu Prakash Gollapudi wrote: On 9/10/2012 3:59 PM, Robert Love wrote: The following series implements a move from using module parameters as control interfaces to /sys/bus/fcoe based interfaces. A sysfs infrastructure was added to the kernel a few cycles ago, this series builds on that work. It moves the create, vn2vn_create, destroy, enable and disable interfaces from /sys/module/libfcoe/parameters/ to various places under /sys/bus/fcoe/. These interfaces simply are not module configurations- they are control interfaces. A second goal of this series is to change the initialization sequence for a FCoE device. The result of this series is that interfaces created using libfcoe.ko interfaces (i.e. fcoe.ko or bnx2fc.ko) will have the following starting steps- 1) Create/alloc the port - Allocate kernel memory and create per-instance sysfs devices - No discovery or login 2) Configure the port - Change mode, set ddp_min, etc... 3) Start the port - Begins discovery and/or login (depending on mode) 4) Destroy the port - Logout and free all memory Robert, Can you please let me now what is the motivation for this change and what problem are we solving with this approach? Is this primarily to allow user to set the mode? The main problem is that our control interfaces shouldn't be module parameters. I think of module parameters as things that globally alter the module. I also think that moving to a create/configure/start model gives us more flexibility going forward. We don't have too many FC/FCoE knobs to tune right now, but if we wanted to add more we don't have a good way to do it without starting the whole discovery/login process and then making changes during the discovery/login. I think the module parameter problem is the justification, but I'm trying to be comprehensive in coming up with a flexible interface that will allow us to evolve as well. I'm concerned that we will be breaking user space compatibility with this change, as there should be a corresponding fcoemon/fipvlan change along with this, and existing utilities will not work. Also the way we start fcoe will be completely different and the user may need to do the scripting changes, if any. See the last statement from my initial posting (it's below). I have patches to modify fcoemon to use these new interfaces. I'd be happy to share them, I just didn't want to spam this broad of a audience. Thanks Robert for the explanation. Appreciate if you could share the fcoeutils patches also. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
