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

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

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.