[Open-FCoE] [PATCH v2] fcoe-utils: add DRIVER_NAME to specify the FCoE low-level driver
robert.w.love at intel.com
Tue Jan 18 19:52:37 UTC 2011
On Mon, 2011-01-17 at 18:22 -0800, Bhanu Gollapudi wrote:
> On Mon, 2011-01-17 at 17:35 -0800, Robert Love wrote:
> > On Wed, 2011-01-12 at 18:42 -0800, Nithin Sujir wrote:
> > > This patch adds support to fcoe-utils to send the low-level driver name into
> > > the libfcoe driver. This complements yi's driver v3 patches that change the
> > > sysfs path and add the transport attach support.
> > >
> > > https://lists.open-fcoe.org/pipermail/devel/2011-January/010946.html
> > >
> > > The following changes are added.
> > >
> > > 1. DRIVER_NAME field in cfg-ethx file. fcoemon will now send "interface:driver
> > > name" string into the libfcoe driver to allow it to invoke the right transport
> > > driver functions.
> > >
> > > 2. SUPPORTED_DRIVERS field in the config file allows the service to load all
> > > supported drivers if they exist.
> > >
> > > 3. The check for if driver is loaded is moved to the fcoe service since it
> > > already knows which are the supported drivers.
> > >
> > >
> > > Signed-off-by: Nithin Nayak Sujir <nsujir at broadcom.com>
> > > ---
> > > doc/fcoemon.txt | 3 ++
> > > etc/cfg-ethx | 5 ++++
> > > etc/config | 4 +++
> > > etc/initd/initd.fedora | 23 +++++++++++++++++-
> > > etc/initd/initd.suse | 25 ++++++++++++++++++-
> > > fcoemon.c | 59 +++++++++++++++++++++++++++++++++++-------------
> > > include/fcoe_utils.h | 4 ++-
> > > 7 files changed, 102 insertions(+), 21 deletions(-)
> > >
> > Hi Nithin, Bhanu and Yi,
> > We need an update to the fcoeadm man page, can you resend this with
> > that addition?
> Hi Robert,
> There are no changes to fcoadm man page, since none of the options have
> > Also, I was trying to test Yi/Bhanu's v3 kernel series with this
> > fcoe-utils patch and I can't get things to work.
> > After running 'fipvlan -ac' interface 'eth3.170-fcoe' is created.
> > When I try to create on that interface using 'fcoeadm -c eth3.170-fcoe'
> > nothing happens except for the kernel reporting, "fcoe_transport_create:
> > transport n/a failed to create fcoe on n/a"
> Shouldn't we pass physical ethernet interface (eth4) instead of the vlan
Possibly. Passing the physical interface to the kernel would mean that
we'd need to do VLAN discovery in the kernel. Since the general kernel
attitude is to do as much as possible in user space and the fact that
the current solution seems to work fine, nobody has tried to push VLAN
discovery into the kernel.
I would be fine with moving LVAN discovery into the kernel if we come
across a good reason- so far I'm not aware of one.
> I tried similar call 'fcoeadm -c eth4.4-fcoe', but it gave the following
> 'fcoeadm: Connection already created on interface eth4.4-fcoe'. I think
> this is a default error message when fcoemon fails to create.
I hit this a few times when I was testing too. I think it was because I
had a mismatch of fcoe-utils an kernel modules. This is such a
misleading error message though, we need to fix it.
> > When I try 'fcoeadm -c eth3.170-fcoe:fcoe' I get the following system
> > panic.
> > With fcoe.ko how are you expecting the user to use 'fcoeadm -c', with
> > the ':<driver>' or not?
> We expect user to use 'fcoeadm -c' without a :<driver>
How will the bnx2fc driver be selected if there is no config file? Also,
with this patch if the user doesn't have the foresight to edit the
DRIVER_NAME before starting fcoemon then they're stuck with the default.
Just a few talking points:
We have talked about adding a 'save' option to fcoeadm, so that any
non-persistent connections will be written to new config files. With
this functionality you could do 'fcoeadm -c ethX.vlan-fcoe:foo' and then
'fcoeadm --save' and you'd then have a persistent connection on that
interface using the foo driver.
We've also talked about adding 'reload' functionality to the fcoe
service. This would have fcoemon re-read the config files, check for
differences from when it started, and take action on any of those
differences. Assuming the user starts the fcoe service without
specifying the correct driver, he could update the DRIVER_NAME=foo
and then reload the service to recreate the connection using the correct
Either of those two solutions would help so that you don't need to
'restart' the fcoe service to bring up LUNs on a new interface. The
reason you don't want to 'restart' is because it will tear-down and
recreate any existing logins to the fabric.
Also, I'd really prefer a way that the user didn't have to choose the
driver, since I think it makes the solution more user-friendly, maybe
this is something we can evolve towards.
> > I think that it should default to the SW FCoE if
> > there isn't a driver specified so that the current interface for SW FCoE
> > doesn't have to change (scripts, etc...).
> SW FCoE is the default driver that gets updated in
> the /etc/fcoe/cfg-ethX file and /etc/fcoe/config files when installing
> the new fcoeutils.
> in /etc/fcoe/cfg-ethX the DRIVER_NAME is set to "fcoe", and
> in /etc/fcoe/config file the SUPPORTED_DRIVERS will have "fcoe".
> We found that if you have an existing config file, installing the new
> fcoeutils, for some reason, does not overwrite the config file with the
> new one. So you may want to rename the old config and install new
I ran into this issue too when testing...
> We have found another issue that can panic if lookup fails. Will send
> out those patches soon.
More information about the devel