Re: [Qemu-devel] Testing NPIV Feature with Qemu-KVM
On 13-09-05 07:15 AM, Stefan Hajnoczi wrote: On Mon, Sep 2, 2013 at 2:34 PM, chandrashekar shastri cshas...@oc2505588478.ibm.com wrote: I am testing NPIV feature on upstream Qemu, I have configured the zone and able to see the created vport on the storage array. Since, I am learning on how to setup the NPIV, I haven't created the different zone for the vport and the array, I just added in the existing zone. Now, how do pass the LUN to the qemu, from Dr. Hannes Reineckei mail thread I got to know that lspci command on the host doesn't show the virtual HBA. I didn't understand why there is limitation on that and if I specify /usr/libexec/qemu-kvm -enable-kvm Fedora19 -m 3000 -smp 2 -net nic -net \ user -vnc 127.0.0.1:0 -drive if=scsi,file=/dev/sdj How do I make sure that qemu is using the virtual HBA or (vport)? From my limited knowledge of NPIV, after you create the vport on the host you'll have a new SCSI host which scans LUNs. That means new SCSI devices appear on the host. You can use ls -al /sys/class/scsi_host to see the SCSI hosts that are active. You can use virsh nodedev-list --tree to see the details of the devices. This should help you find the NPIV LUNs which can be passed to QEMU. Also, there will be a /sys/class/fc_host, associated with the scsi_host. It will have a port_type, that when read, should show NPIV VPORT. //Rob-- 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: [Qemu-devel] Testing NPIV Feature with Qemu-KVM
snip How do I make sure that qemu is using the virtual HBA or (vport)? From my limited knowledge of NPIV, after you create the vport on the host you'll have a new SCSI host which scans LUNs. That means new SCSI devices appear on the host. You can use ls -al /sys/class/scsi_host to see the SCSI hosts that are active. Also, there will be a /sys/class/fc_host, associated with the scsi_host. It will have a port_type, that when read, should show NPIV VPORT. //Rob -- 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
fcoe pull request for 3.12(+)
The following changes since commit 6e4664525b1db28f8c4e1130957f70a94c19213e: Linux 3.11 (2013-09-02 13:46:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git tags/show for you to fetch changes up to 1c2c1b4fbd413fd814807768d2aba9023722ed76: fcoe: Reduce fcoe_sysfs_fcf_add() stack usage (2013-09-04 14:14:21 -0700) Pull request tag for 3.12 merge window. Bart Van Assche (13): libfc: Source code comment spelling fixes libfc: Debug code fixes libfc: Micro-optimize fc_setup_exch_mgr() libfc: Clarify fc_exch_find() libfc: Fix a race in fc_exch_timer_set_locked() libfc: Protect ep-esb_stat changes via ex_lock libfc: Avoid that sending after an abort triggers a kernel warning libfc: Reduce exchange lock contention in fc_exch_recv_abts() libfc: Do not invoke the response handler after fc_exch_done() fcp: Do not interpret check condition as underrun fcoe: Declare fcoe_ctlr_mode_set() static fcoe: Add missing newlines in debug messages fcoe: Reduce fcoe_sysfs_fcf_add() stack usage Neil Horman (3): fcoe: ensure that skb placed on the fip_recv_list are unshared fcoe: make sure fcoe frames are unshared prior to manipulating them fcoe: cleanup return codes from fcoe_rcv drivers/scsi/fcoe/fcoe.c | 22 ++-- drivers/scsi/fcoe/fcoe_ctlr.c | 47 +--- drivers/scsi/fcoe/fcoe_sysfs.c | 12 +- drivers/scsi/libfc/fc_exch.c | 251 ++-- drivers/scsi/libfc/fc_fcp.c| 10 +- drivers/scsi/libfc/fc_lport.c |4 +- drivers/scsi/libfc/fc_rport.c |6 +- include/scsi/fc/fc_fc2.h |2 +- include/scsi/libfc.h |9 ++ 9 files changed, 229 insertions(+), 134 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
fcoe pull-request - fixes for 3.11 merge window or RC
The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376: Linux 3.10 (2013-06-30 15:13:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git tags/fixes_for_3.10 for you to fetch changes up to 7a5ed75a782a1f2de7fc773981ecd88bfa7595b1: fcoe: Reduce number of sparse warnings (2013-07-09 11:19:00 -0700) A short series of fixes to libfc, libfcoe and fcoe. Most patches fix formatting problems, one changes the behavior of which discovered ports can/will be logged into and another fixes a memory leak. Bart Van Assche (1): fcoe: Reduce number of sparse warnings Mark Rustad (2): libfc: Reject PLOGI from nodes with incompatible role fcoe: Stop fc_rport_priv structure leak Neerav Parikh (1): fcoe: Fix smatch warning in fcoe_fdmi_info function Robert Love (3): libfc: Remove extra space in fc_exch_timer_cancel definition libfc: Differentiate echange timer cancellation debug statements libfcoe: Fix meaningless log statement Yi Zou (1): fcoe: fix the link error status block sparse warnings drivers/scsi/fcoe/fcoe.c | 26 +++--- drivers/scsi/fcoe/fcoe_ctlr.c |4 drivers/scsi/fcoe/fcoe_sysfs.c | 24 drivers/scsi/fcoe/fcoe_transport.c | 28 ++-- drivers/scsi/libfc/fc_exch.c |4 ++-- drivers/scsi/libfc/fc_rport.c | 27 +++ 6 files changed, 66 insertions(+), 47 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: fcoe pull request for 3.9-rc
On Wed 26 Jun 2013 11:14:02 PM PDT, James Bottomley wrote: On Tue, 2013-06-25 at 20:55 +, Love, Robert W wrote: The following changes since commit 1e876e3b1a9df25bb04682b0d48aaa7e8ae1fc82: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2013-06-25 09:08:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git tags/critical_fix_for_3.9 This is simple and I can review from the attached patch, so I'll take it this time. But, please, next time follow proper process. That means the individual patches should go over the SCSI mailing list for review *before* they're sent in a pull request. The reason I sent this pull request directly to Linus was that the patches I mailed at (2013-05-21) RC2 had not yet seen any attention since they were posted to linux-scsi. It is now RC7 and with 5 weeks of inactivity on my initial 3.10 patch series I had no faith that this critical fix would make it through the SCSI tree before the 3.10 kernel was released. FYI, Linus has taken this change already. I would have preferred to send the patch to linux-scsi for review first, but it had been thoroughly reviewed on the FCoE list, it's a fairly trivial change and I was a hurry to get it into Linus' inbox given his statement about finding new ways to insult your pets. The patch is also part of the pull request, so it was review-able by anyone on linux-scsi or linux-kernel. Thanks, //Rob PS: I totally botched the title of this pull request, obviously it should say fcoe pull request for 3.10-rc.
fcoe pull request for 3.9-rc
The following changes since commit 1e876e3b1a9df25bb04682b0d48aaa7e8ae1fc82:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux (2013-06-25
09:08:07 -1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git
tags/critical_fix_for_3.9
for you to fetch changes up to 2884d4230867c8a46cf701214051e923301e7429:
fcoe: Use correct API to set vlan tag for FCoE Ethertype skbs
(2013-06-25 12:23:19 -0700)
This patch fixes a critical bug that was introduced in 3.9
related to VLAN tagging FCoE frames.
Robert Love (1):
fcoe: Use correct API to set vlan tag for FCoE Ethertype skbs
drivers/scsi/fcoe/fcoe.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index 292b24f..32ae6c6 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -1656,9 +1656,12 @@ static int fcoe_xmit(struct fc_lport *lport,
struct fc_frame *fp)
if (fcoe-netdev-priv_flags IFF_802_1Q_VLAN
fcoe-realdev-features NETIF_F_HW_VLAN_CTAG_TX) {
-skb-vlan_tci = VLAN_TAG_PRESENT |
-vlan_dev_vlan_id(fcoe-netdev);
+/* must set skb-dev before calling vlan_put_tag */
skb-dev = fcoe-realdev;
+skb = __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q),
+ vlan_dev_vlan_id(fcoe-netdev));
+if (!skb)
+return -ENOMEM;
} else
skb-dev = fcoe-netdev;
--
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
Pull Request for 3.10-rc (FCoE)
The following changes since commit c1be5a5b1b355d40e6cf79cc979eb66dafa24ad1: Linux 3.9 (2013-04-28 17:36:01 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git tags/for-3.10-rc for you to fetch changes up to f4aaea6d5106f6092a80a648b5a12d31b6cb3335: MAINTAINERS: Fix fcoe mailing list (2013-05-10 10:19:25 -0700) 3.10 fixes Krishna Mohan (1): libfcoe: Fix Conflicting FCFs issue in the fabric Mark Rustad (1): libfc: Correct check for initiator role Neil Horman (2): libfc: extend ex_lock to protect all of fc_seq_send MAINTAINERS: Fix fcoe mailing list MAINTAINERS |2 +- drivers/scsi/fcoe/fcoe_ctlr.c | 15 +-- drivers/scsi/libfc/fc_exch.c | 37 - drivers/scsi/libfc/fc_rport.c |2 +- 4 files changed, 31 insertions(+), 25 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
fcoe pull-request 3.9-rc5
The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git
tags/for-3.9-rc
for you to fetch changes up to 0db0e377ab5be5d507a2fca3d78215cd2e83b974:
libfcoe: Fix fcoe_sysfs VN2VN mode (2013-03-25 16:04:22 -0700)
Critical patches to fix FCoE VN2VN mode with new interfaces targeting 3.9-rc
Robert Love (5):
bnx2fc: Make the fcoe_cltr the SCSI host parent
fcoe: Fix deadlock between create and destroy paths
libfc, fcoe, bnx2fc: Always use fcoe_disc_init for discovery
layer initialization
libfc, fcoe, bnx2fc: Split fc_disc_init into fc_disc_{init, config}
libfcoe: Fix fcoe_sysfs VN2VN mode
drivers/scsi/bnx2fc/bnx2fc_fcoe.c |6 ++--
drivers/scsi/fcoe/fcoe.c | 15 +++---
drivers/scsi/fcoe/fcoe_ctlr.c | 60
-
drivers/scsi/libfc/fc_disc.c | 26 +++-
include/scsi/libfc.h |3 +-
5 files changed, 80 insertions(+), 30 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
fcoe pull-request 3.9-rc
The following changes since commit 8bb9660418e05bb1845ac1a2428444d78e322cc7:
Linux 3.9-rc4 (2013-03-23 16:52:44 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git
tags/for-3.9-rc
for you to fetch changes up to 0db0e377ab5be5d507a2fca3d78215cd2e83b974:
libfcoe: Fix fcoe_sysfs VN2VN mode (2013-03-25 16:04:22 -0700)
Critical patches to fix FCoE VN2VN mode with new interfaces targeting 3.9-rc
Robert Love (5):
bnx2fc: Make the fcoe_cltr the SCSI host parent
fcoe: Fix deadlock between create and destroy paths
libfc, fcoe, bnx2fc: Always use fcoe_disc_init for discovery
layer initialization
libfc, fcoe, bnx2fc: Split fc_disc_init into fc_disc_{init, config}
libfcoe: Fix fcoe_sysfs VN2VN mode
drivers/scsi/bnx2fc/bnx2fc_fcoe.c |6 ++--
drivers/scsi/fcoe/fcoe.c | 15 +++---
drivers/scsi/fcoe/fcoe_ctlr.c | 60
-
drivers/scsi/libfc/fc_disc.c | 26 +++-
include/scsi/libfc.h |3 +-
5 files changed, 80 insertions(+), 30 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: [PATCH 00/21] libfc, libfcoe and fcoe updates for 3.9
On 2/19/2013 11:30 AM, Robert Love wrote: This series is mostly a resend of previously sent patches. The primary change in this series is the addition of the fcoe_sysfs control interfaces. Additionally there are a few fix/cleanup patches and UAPI conversions. Almost all of these patches have already been reviewed on linux-scsi. I will compose a pull-request and send it soon, but I wanted to make sure the most recent versions of these patches were posted to linux-scsi first. --- I missed one patch in this series. I will send it now. It is included in the patch set covered by the signed-tag in the forthcoming request-pull mail. Sorry for the confusion. Thanks, //Rob
3.9 request-pull for libfc, libfcoe and fcoe
The following changes since commit 5b97fabdc815b4b60bac2328b58c5c7274debf58:
libfc: fix REC handling (2012-12-04 10:16:38 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git
tags/for-next-02-19-13
for you to fetch changes up to 1f953b0dbc2549318afcc0a70af5542dffbce34a:
libfcoe: Check for unusable FCFs before looking for conflicting FCFs
(2013-02-19 12:23:07 -0800)
FCoE Updates for 3.9
Al Viro (1):
debris left by [SCSI] libfcoe: Remove
mutex_trylock/restart_syscall checks
Bhanu Prakash Gollapudi (2):
libfcoe: Handle CVL while waiting to select an FCF
libfcoe: Check for unusable FCFs before looking for conflicting FCFs
David Howells (1):
UAPI: (Scripted) Disintegrate include/scsi/fc
Krishna Mohan (1):
libfc: XenServer fails to mount root filesystem.
Neerav Parikh (1):
fcoe: Fix deadlock while deleting FCoE interface with NPIV ports
Neil Horman (1):
fcoe: close race on link speed detection in fcoe code
Robert Love (7):
Documentation: Add missing devices/ to devices path
libfcoe: Save some memory and optimize name lookups
libfcoe: Add fcoe_sysfs debug logging level
libfcoe, fcoe, bnx2fc: Add new fcoe control interface
fcoe: Use the fcoe_sysfs control interface
bnx2fc: Use the fcoe_sysfs control interface
libfc, libfcoe, fcoe: Convert debug_logging macros to pr_info
Yi Zou (7):
fcoe: prep work to start consolidate the usage of fcoe_netdev
fcoe: add support to the get_netdev() for fcoe_interface
libfcoe, fcoe: move fcoe_link_speed_update() to libfcoe and export it
libfcoe, fcoe: consolidate the fcoe_ctlr_get_lesb/fcoe_get_lesb
bnx2fc: add support to get_netdev for bnx2f_interface
bnx2fc: use fcoe_link_speed_update() from the exported symbol in
libfcoe
bnx2fc: use fcoe_get_lesb/fcoe_ctlr_get_lesb() directly from libfcoe
Documentation/ABI/testing/sysfs-bus-fcoe | 45 -
drivers/scsi/bnx2fc/bnx2fc_fcoe.c| 256
drivers/scsi/fcoe/fcoe.c | 266
--
drivers/scsi/fcoe/fcoe.h |6 +-
drivers/scsi/fcoe/fcoe_ctlr.c| 45 ++---
drivers/scsi/fcoe/fcoe_sysfs.c | 186 +
drivers/scsi/fcoe/fcoe_transport.c | 199 +-
drivers/scsi/fcoe/libfcoe.h | 20 ++-
drivers/scsi/libfc/fc_libfc.h| 38 ++---
drivers/scsi/libfc/fc_rport.c|2 +-
include/scsi/fc/Kbuild |4 -
include/scsi/fcoe_sysfs.h| 11 +-
include/scsi/libfcoe.h | 32 +++-
include/uapi/scsi/fc/Kbuild |4 +
include/{ = uapi}/scsi/fc/fc_els.h |0
include/{ = uapi}/scsi/fc/fc_fs.h |0
include/{ = uapi}/scsi/fc/fc_gs.h |0
include/{ = uapi}/scsi/fc/fc_ns.h |0
18 files changed, 819 insertions(+), 295 deletions(-)
rename include/{ = uapi}/scsi/fc/fc_els.h (100%)
rename include/{ = uapi}/scsi/fc/fc_fs.h (100%)
rename include/{ = uapi}/scsi/fc/fc_gs.h (100%)
rename include/{ = uapi}/scsi/fc/fc_ns.h (100%)
--
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: FCoE Updates for 3.8 (v2)
On 12-12-14 02:33 PM, Robert Love wrote: The following changes since commit b69f0859dc8e633c5d8c06845811588fe17e68b3: Linux 3.7-rc8 (2012-12-03 11:22:37 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git tags/for-next-12-14-12 for you to fetch changes up to 4f670ff8eb4cb3e9e6ae0c0c6976faa0a4503751: debris left by [SCSI] libfcoe: Remove mutex_trylock/restart_syscall checks (2012-12-14 10:38:56 -0800) James, Was there a problem with this pull-request? I just returned from vacation and I see that it wasn't taken, but I also didn't get any feedback. Can you please advise me what I should do differently? Thanks, //Rob-- 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: [PATCH 03/16] libfcoe: Save some memory and optimize name lookups
On Wed 12 Dec 2012 11:54:10 PM PST, Bart Van Assche wrote:
On 12/13/12 00:22, Robert Love wrote:
@@ -210,25 +210,23 @@ static ssize_t
show_fcoe_fcf_device_##field(struct device *dev,\
#define fcoe_enum_name_search(title, table_type, table)\
static const char *get_fcoe_##title##_name(enum table_type
table_key)\
{\
-int i;\
-char *name = NULL;\
-\
-for (i = 0; i ARRAY_SIZE(table); i++) {\
-if (table[i].value == table_key) {\
-name = table[i].name;\
-break;\
-}\
-}\
-return name;\
+if (table_key = ARRAY_SIZE(table))\
+return NULL;\
+return table[table_key];\
}
The old code was safe if table_key 0 but the new code not. Can
table_key be negative ?
+static char *fip_conn_type_names[] = {
+[ FIP_CONN_TYPE_UNKNOWN ] = Unknown,
+[ FIP_CONN_TYPE_FABRIC ] = Fabric,
+[ FIP_CONN_TYPE_VN2VN ] = VN2VN,
+};
A minor nit: indentation style is inconsistent here. Two elements are
indented with a tab and another with eight spaces.
Bart.
Thanks for the review and comments, Bart. I agree with both of your
points. I'll send an updated patch shortly. //Rob
Re: FCoE Updates for 3.8
On Wed 12 Dec 2012 04:45:50 PM PST, Robert Love wrote:
The following changes since commit b69f0859dc8e633c5d8c06845811588fe17e68b3:
Linux 3.7-rc8 (2012-12-03 11:22:37 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/rwlove/fcoe.git
for-next-12-12-12
for you to fetch changes up to 04f0ac991b5dd2a32c3fa3dcb2cf34830949afa5:
debris left by [SCSI] libfcoe: Remove mutex_trylock/restart_syscall
checks (2012-12-11 10:22:36 -0800)
Al Viro (1):
debris left by [SCSI] libfcoe: Remove mutex_trylock/restart_syscall
checks
Robert Love (7):
Documentation: Add missing devices/ to devices path
libfcoe: Save some memory and optimize name lookups
libfcoe: Add fcoe_sysfs debug logging level
libfcoe, fcoe, bnx2fc: Add new fcoe control interface
fcoe: Use the fcoe_sysfs control interface
bnx2fc: Use the fcoe_sysfs control interface
libfc, libfcoe, fcoe: Convert debug_logging macros to pr_info
Vasu Dev (1):
libfc: fix REC handling
Yi Zou (7):
fcoe: prep work to start consolidate the usage of fcoe_netdev
fcoe: add support to the get_netdev() for fcoe_interface
libfcoe, fcoe: move fcoe_link_speed_update() to libfcoe and export it
libfcoe, fcoe: consolidate the fcoe_ctlr_get_lesb/fcoe_get_lesb
bnx2fc: add support to get_netdev for bnx2f_interface
bnx2fc: use fcoe_link_speed_update() from the exported symbol in
libfcoe
bnx2fc: use fcoe_get_lesb/fcoe_ctlr_get_lesb() directly from libfcoe
Documentation/ABI/testing/sysfs-bus-fcoe | 45 +-
drivers/scsi/bnx2fc/bnx2fc_fcoe.c| 256
+-
drivers/scsi/fcoe/fcoe.c | 212 +++--
drivers/scsi/fcoe/fcoe.h |6 +-
drivers/scsi/fcoe/fcoe_ctlr.c| 17 +-
drivers/scsi/fcoe/fcoe_sysfs.c | 186 ++
drivers/scsi/fcoe/fcoe_transport.c | 199 ++-
drivers/scsi/fcoe/libfcoe.h | 20 ++-
drivers/scsi/libfc/fc_fcp.c |6 +-
drivers/scsi/libfc/fc_libfc.h| 38 ++---
include/scsi/fcoe_sysfs.h| 11 +-
include/scsi/libfcoe.h | 32 +++-
12 files changed, 749 insertions(+), 279 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
Please ignore this request. A new (v2) pull request is coming that
addresses Bart's feedback on one patch.
Thanks, //Rob
N�r��yb�X��ǧv�^�){.n�+{{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: Request for improved commit tracking between fcoe and scsi trees
On 10/3/2012 12:23 PM, Neil Horman wrote: James, Robert- I've been doing lots of backports of FCoE code to the RHEL tree these last few months, and I've noticed something fairly irritating, and I was wondering if you two could help me out with it (in fact you two are the only two which can). I noticed that commits which are accepted into the FCoE tree that get passed upstream through the scsi tree have their commit hashes altered. I can't find any examples currently, due to the fact that you, Robert, have recently re-cloned your git tree at open-fcoe.org, so all this nastiness has been covered up currently, but if things don't change, this issue will quickly resurface. Regardless, This makes it _really_ difficult to track a given patchs' traversal between trees upstream, and makes my life as a distro subsystem maintainer fairly painful. Normally I would just live with it, but I can't see any reason why it should be this way, given that git can easily prevent this with a pull. James, Robert, could you two please work out a way to provide commit hash consistency between your trees? It would make mine (and I'm sure many other people's) lives, much easier. I had included pull URLs in the covermails of my updates, but I haven't lately. I will make sure to do that from now on. Bart had a complaint about a misspelling in a commit message of a patch in my last update. I just resent that three patch series with the corrected commit message. I included a signed-tag to pull from in the covermail. Consistent commit IDs between linux-fcoe.git and scsi.git would help me as well. It would allow me to track commit IDs from my tree all the way into the distros, so that I can make sure nothing gets missed. Thanks, //Rob -- 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: [Open-FCoE] [PATCH] scsi_transport_fc: Add sysfs entry for HBA API management library
On 10/4/2012 12:08 AM, Hannes Reinecke wrote:
On 10/03/2012 10:12 PM, Robert Love wrote:
The user space HBA API vendor libraries need to know which HBA/CNAs
hosts to manage. Currently, libhbalinux is used to manage a few drivers
that use libfcoe and libfc. Right now libhbalinux keys off of the
string over in the FC Host's symbolic_name attribute to determine
if it should manage a given host. fnic, bnx2fc and fcoe/netdev based
hosts all use over in their symboic_names and that is currently
what libhbalinux looks for to determine if it should manage hosts
created by those drivers.
Clearly using over in the symbolic_name isn't descriptive
and it is an awkward way to determine whether libhbalinux should
manage a host. Also, drivers may wish to use more descriptive
and accurate symbolic_names because these strings are displayed
in fabric management applications; forcing them to use over
in their symbolic_name is unnecessarily restrictive.
This patch adds a read-only attribute to the FC Host that will expose
which management library should be used to manage it.
This attribute will not be present in sysfs for drivers that
do no implement the .show_hbaapi_lib routine.
Signed-off-by: Robert Love robert.w.l...@intel.com
Tested-by: Ross Brattain ross.b.bratt...@intel.com
---
drivers/scsi/bnx2fc/bnx2fc_fcoe.c |4
drivers/scsi/fcoe/fcoe.c |4
drivers/scsi/fnic/fnic_main.c |4
drivers/scsi/scsi_transport_fc.c |5 -
include/scsi/libfc.h |2 ++
include/scsi/scsi_transport_fc.h |4
6 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index ae1cb76..97f60d8 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -731,6 +731,9 @@ static int bnx2fc_shost_config(struct fc_lport
*lport, struct device *dev)
BNX2FC_NAME, BNX2FC_VERSION,
interface-netdev-name);
+strncpy(fc_host_hbaapi_library(lport-host), FC_LIBHBALINUX_NAME,
+FC_SYMBOLIC_NAME_SIZE);
+
return 0;
}
@@ -2583,6 +2586,7 @@ static struct fc_function_template
bnx2fc_transport_function = {
.get_host_port_state = fc_get_host_port_state,
.show_host_port_state = 1,
.show_host_symbolic_name = 1,
+.show_host_hbaapi_library = 1,
.dd_fcrport_size = (sizeof(struct fc_rport_libfc_priv) +
sizeof(struct bnx2fc_rport)),
diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
index 078d262..812876f 100644
--- a/drivers/scsi/fcoe/fcoe.c
+++ b/drivers/scsi/fcoe/fcoe.c
@@ -201,6 +201,7 @@ static struct fc_function_template
fcoe_nport_fc_functions = {
.get_host_port_state = fc_get_host_port_state,
.show_host_port_state = 1,
.show_host_symbolic_name = 1,
+.show_host_hbaapi_library = 1,
.dd_fcrport_size = sizeof(struct fc_rport_libfc_priv),
.show_rport_maxframe_size = 1,
@@ -755,6 +756,9 @@ static int fcoe_shost_config(struct fc_lport
*lport, struct device *dev)
%s v%s over %s, FCOE_NAME, FCOE_VERSION,
fcoe_netdev(lport)-name);
+strncpy(fc_host_hbaapi_library(lport-host), FC_LIBHBALINUX_NAME,
+FC_SYMBOLIC_NAME_SIZE);
+
return 0;
}
diff --git a/drivers/scsi/fnic/fnic_main.c
b/drivers/scsi/fnic/fnic_main.c
index fc98eb6..783bd3d 100644
--- a/drivers/scsi/fnic/fnic_main.c
+++ b/drivers/scsi/fnic/fnic_main.c
@@ -138,6 +138,7 @@ static struct fc_function_template
fnic_fc_functions = {
.get_host_port_state = fc_get_host_port_state,
.show_host_port_state = 1,
.show_host_symbolic_name = 1,
+.show_host_hbaapi_library = 1,
.show_rport_maxframe_size = 1,
.show_rport_supported_classes = 1,
.show_host_fabric_name = 1,
@@ -704,6 +705,9 @@ static int __devinit fnic_probe(struct pci_dev
*pdev,
sprintf(fc_host_symbolic_name(lp-host),
DRV_NAME v DRV_VERSION over %s, fnic-name);
+strncpy(fc_host_hbaapi_library(lp-host), FC_LIBHBALINUX_NAME,
+FC_SYMBOLIC_NAME_SIZE);
+
spin_lock_irqsave(fnic_list_lock, flags);
list_add_tail(fnic-list, fnic_list);
spin_unlock_irqrestore(fnic_list_lock, flags);
diff --git a/drivers/scsi/scsi_transport_fc.c
b/drivers/scsi/scsi_transport_fc.c
index e894ca7..ed19b42 100644
--- a/drivers/scsi/scsi_transport_fc.c
+++ b/drivers/scsi/scsi_transport_fc.c
@@ -313,7 +313,7 @@ static void fc_scsi_scan_rport(struct work_struct
*work);
#define FC_STARGET_NUM_ATTRS 3
#define FC_RPORT_NUM_ATTRS10
#define FC_VPORT_NUM_ATTRS9
-#define FC_HOST_NUM_ATTRS29
+#define FC_HOST_NUM_ATTRS30
struct fc_internal {
struct scsi_transport_template t;
@@ -422,6 +422,7 @@ static int fc_host_setup(struct
transport_container *tc, struct device *dev,
fc_host-speed =
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 1/5] libfcoe, fcoe: Allow user to set a ctlr's mode
On Mon 10 Sep 2012 10:51:41 PM PDT, Bart Van Assche wrote:
On 09/11/12 00:59, Robert Love wrote:
+static enum fip_conn_type fcoe_parse_mode(const char *buf,
+ const struct fcoe_ctlr_mode_table *tbl)
+{
+int modeint = -1, i, rv;
+char *p, modestr[FCOE_MAX_MODENAME_LEN + 1] = { 0, };
+
+for (p = (char *)buf; *p; p++)
+if (!(isdigit(*p) || isspace(*p)))
+break;
If you change the declaration of p from char *p into const char *p
you won't need a cast in the above for loop.
[ ... ]
-static FCOE_DEVICE_ATTR(ctlr, mode, S_IRUGO,
-show_ctlr_mode, NULL);
+
+static ssize_t store_ctlr_mode(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+struct fcoe_ctlr_device *ctlr = dev_to_ctlr(dev);
+
+if (!ctlr-f-set_fcoe_ctlr_mode)
+return -EINVAL;
+
+ctlr-mode = fcoe_parse_mode(buf, ctlr_mode_tbl);
As far as I know sysfs doesn't terminate buf with a '\0' before calling
a store method. Does that mean that you are passing a string that is not
'\0'-terminated to a function that expects a '\0'-terminated string ?
Bart.
Hey Bart. I just wanted to acknowledge your comments. I will make sure
that they're addressed after figuring out if sysfs is the right place
for the interfaces.
Thanks, //Rob
Re: [Open-FCoE] [RFC PATCH 0/5] Reorganize libfcoe control interfaces
On 12-09-11 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 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. I read though the configfs documentation and the fact that it's designed for user driven object creation does fit with what I'm trying to do. I have a couple concerns that I'm trying to sort through now- 1) This adds a new dependency for boot. I don't know if that is a problem or not. Are there any examples of configfs being mounted in an initrd? 2) Using configfs would likely mean that I'd be creating controller instances and possibly FCF instances in configfs, since they're already there in sysfs these objects would be duplicated. I'm not sure there's harm in that, but it certainly feels disjointed and messy. I suppose we could remove the /sys/bus/fcoe stuff in favor of configfs if it's the right thing to do. Thanks, //Rob-- 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: [Open-FCoE] [RFC PATCH 0/5] Reorganize libfcoe control interfaces
On Tue 11 Sep 2012 10:36:35 AM PDT, 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 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. My fcoe-utils.git change here also allows the user to drive this fabric selection using a new variable in the /etc/fcoe/cfg-ethX files that the 'fcoe service' uses.
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 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: [PATCH] [SCSI] libfcoe: use list_move instead of list_del/list_add
On 9/5/2012 9:36 PM, Wei Yongjun wrote: From: Wei Yongjun yongjun_...@trendmicro.com.cn Using list_move() instead of list_del() + list_add(). spatch with a semantic match is used to found this problem. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Robert Love robert.w.l...@intel.com -- 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: [PATCH 6/8] csiostor: Chelsio FCoE offload driver submission (headers part 1).
On 8/23/2012 3:27 PM, Naresh Kumar Inna wrote: This patch contains the first set of the header files for csiostor driver. Signed-off-by: Naresh Kumar Inna nar...@chelsio.com --- drivers/scsi/csiostor/csio_defs.h | 143 ++ drivers/scsi/csiostor/csio_fcoe_proto.h | 843 +++ I think most of these protocol definitions can be found in include/scsi/fc/ and possibly incluse/scsi/scsi_transport_fc.h. I think any protocol stuff missing should be added to the common header files. Thanks, //Rob-- 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: [PATCH] fcoe: Remove redundant 'less than zero' check
On 12-07-09 04:29 PM, Andrew Morton wrote: On Thu, 05 Jul 2012 07:52:25 -0700 Robert Loverobert.w.l...@intel.com wrote: strtoul returns an 'unsigned long' so there is no reason to check if the value is less than zero. strtoul already checks for the '-' character deep in its bowels. It will return an error if the user has provided a negative value and fcoe_str_to_dev_loss will return that error to its caller. huh, I never knew that. So if we feed -1 to kstrtoul() it gets treated as an error? That seems a bit surprising. You're sure about that? I believe so. kstrtoul-kstrtoull-_kstrtoull-_parse_integer When the call chain ultimately hits _parse_integer it breaks out of parsing if it hits a non-numeric or alphabetic character outside of the 'a' to 'f' range. _kstrtoull notices that the buffer wasn't completely parsed and returns an error. I think the error will be -EINVAL. //Rob-- 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: Open-FCoE on linux-scsi
-Original Message-
From: James Smart [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 15, 2008 2:19 PM
To: Love, Robert W
Cc: Stefan Richter; Dev, Vasu; FUJITA Tomonori; [EMAIL PROTECTED]; Zou, Yi;
Leech, Christopher; linux-scsi@vger.kernel.org; James Smart
Subject: Re: Open-FCoE on linux-scsi
Love, Robert W wrote:
The interconnect layer could be split further:
SCSI command set layer -- SCSI core -- SCSI transport layer (FCP) --
Fibre Channel core -- Fibre Channel card drivers, FCoE drivers.
This is how I see the comparison. ('/' indicates 'or')
You suggest Open-FCoE
SCSI-ml SCSI-ml
scsi_transport_fc.h scsi_tranport_fc.h
scsi_transport_fc.c (FC core) / HBA openfc / HBA
fcoe / HBA fcoe / HBA
From what I can see the layering is roughly the same with the main
difference being that we should be using more of (and putting more
into)
scsi_transport_fc.h. Also we should make the FCP implementation
(openfc)
fit in a bit nicer as scsi_transport_fc.c. We're going to look into
making better use of scsi_transport_fc.h as a first step.
I don't know what the distinction is between scsi_transport_fc.h vs
scsi_transport_fc.c is. They're all one and the same - the fc
transport.
One contains the data structures and api between LLD and transport,
the other (the .c) contains the code to implement the api, transport
objects
and sysfs handlers.
From my point of view, the fc transport is an assist library for the
FC
LLDDs.
Currently, it interacts with the midlayer only around some scan and
block/unblock
functions. Excepting a small helper function used by the LLDD, it does
not
get
involved in the i/o path.
So my view of the layering for a normal FC driver is:
SCSI-ml
LLDD - FC transport
bus code (e.g. pci)
Right now, the assists provided in the FC transport are:
- Presentation of transport objects into the sysfs tree, and thus sysfs
attribute handling around those objects. This effectively is the FC
management interface.
- Remote Port Object mgmt - interaction with the midlayer.
Specifically:
- Manages the SCSI target id bindings for the remote port
- Knows when the rport is present or not.
On new connectivity:
Kicks off scsi scans, restarts blocked i/o.
On connectivity loss:
Insulates midlayer from temporary disconnects by block of
the target/luns, and manages the timer for the allowed period
of
disconnect.
Assists in knowing when/how to terminate pending i/o after a
connectivity loss (fast fail, or wait).
- Provides consistent error codes for i/o path and error handlers
via
helpers that are used by LLDD.
Note that the above does not contain the FC login state machine, etc.
We have discussed this in the past. Given the 4 FC LLDDs we had, there
was
a wide difference on who did what where. LSI did all login and FC ELS
handling in their firmware. Qlogic did the initiation of the login in
the
driver, but the ELS handling in the firmware. Emulex did the ELS
handling
in the driver. IBM/zfcp runs a hybrid of login/ELS handling over it's
pseudo
hba interface. Knowing how much time we spend constantly debugging
login/ELS
handling and the fact that we have to interject adapter resource
allocation
steps into the statemachine, I didn't want to go to a common library
until
there was a very clear and similar LLDD. Well, you can't get much
clearer
than a full software-based login/ELS state machine that FCOE needs. It
makes
sense to at least try to library-ize the login/ELS handling if
possible.
Here's what I have in mind for FCOE layering. Keep in mind, that one of
the
goals here is to support a lot of different implementations which may
range
from s/w layers on a simple Ethernet packet pusher, to more and more
levels
of offload on an FCOE adapter. The goal is to create the s/w layers
such
that
different LLDD's can pick and choose the layer(s) (or level) they want
to
integrate into. At a minimum, they should/must integrate with the base
mgmt
objects.
For FC transport, we'd have the following layers or api sections :
Layer 0: rport and vport objects (current functionality)
Layer 1: Port login and ELS handling
Layer 2: Fabric login, PT2PT login, CT handling, and discovery/RSCN
Layer 3: FCP I/O Assist
Layer 4: FC2 - Exchange and Sequence handling
Layer 5: FCOE encap/decap
Layer 6: FCOE FLOGI handler
Layer 1 would work with an api to the LLDD based on a send/receive ELS
interface
coupled with a login/logout to address interface. The code within
layer
1
would make calls to layer 0 to instantiate the different objects. If
layer 1
needs to track additional rport data, it should specify dd_data on
the
rport_add call. (Note: all of the LLDDs today have their own node
structure
that is independent from the rport struct. I
RE: Open-FCoE on linux-scsi
-Original Message-
From: Stefan Richter [mailto:[EMAIL PROTECTED]
Sent: Friday, January 04, 2008 4:10 PM
To: Dev, Vasu
Cc: FUJITA Tomonori; Love, Robert W; [EMAIL PROTECTED]; Zou, Yi; Leech,
Christopher; linux-scsi@vger.kernel.org
Subject: Re: Open-FCoE on linux-scsi
Stefan Richter wrote:
I.e. you have SCSI command set layer -- SCSI core -- SCSI transport
layer -- interconnect layer.
The interconnect layer could be split further:
SCSI command set layer -- SCSI core -- SCSI transport layer (FCP) --
Fibre Channel core -- Fibre Channel card drivers, FCoE drivers.
This is how I see the comparison. ('/' indicates 'or')
You suggest Open-FCoE
SCSI-ml SCSI-ml
scsi_transport_fc.h scsi_tranport_fc.h
scsi_transport_fc.c (FC core) / HBA openfc / HBA
fcoe / HBA fcoe / HBA
From what I can see the layering is roughly the same with the main
difference being that we should be using more of (and putting more into)
scsi_transport_fc.h. Also we should make the FCP implementation (openfc)
fit in a bit nicer as scsi_transport_fc.c. We're going to look into
making better use of scsi_transport_fc.h as a first step.
I'm a little confused though; in a prior mail it seemed that you were
clubbing openfc and fcoe together, and at one point Fujita's stack
showed a libfcoe and fcoe fitting directly under scsi_transport_fc. I
think the layering is nicer at this point in the thread, where SCSI only
knows that it's using FC and the SW implementation of FCP knows the
transport. It's closer to my understanding of Open-iSCSI.
Open-iSCSI Open-FCoE
scsi_transport_iscsi.c scsi_transport_fc.c
iscsi_tcp.c fcoe
I'm curious how aware you think scsi_transport_fc.h should be of FCoE?
But this would only really make sense if anybody would implement
additional FC-4 drivers besides FCP, e.g. RFC 2625, which would also
sit
on top of Fibre Channel core.
--
Stefan Richter
-=-==--- ---= --=-=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Open-FCoE on linux-scsi
From: Love, Robert W [EMAIL PROTECTED] Subject: RE: Open-FCoE on linux-scsi Date: Mon, 31 Dec 2007 08:34:38 -0800 Hello SCSI mailing list, I'd just like to introduce ourselves a bit before we get started. My name is Robert Love and I'm joined by a team of engineers including Vasu Dev, Chris Leech and Yi Zou. We are committed to maintaining the Open-FCoE project. Aside from Intel engineers we expect engineers from other companies to contribute to Open-FCoE. Our goal is to get the initiator code upstream. We have a lot of working code but recognize that we're early in this project's development. We're looking for direction from you, the experts, on what this project should grow into. I've just added a new fcoe target driver to tgt: http://stgt.berlios.de/ That's great; we'll check it out as soon as everyone is back from the holidays. It's still an experiment. Patches are welcome. The driver runs in user space unlike your target mode driver (I just modified your FCoE code to run it in user space). There seems to be a trend to move non-data-path code userspace, however, Implementing FCoE target drive in user space has no connection with a trend to move non-data-path code user space. It does all the data-path in user space. The examples of the trend to move non-data-path code userspace are open-iscsi, multi-path, etc, I think. I don't like having so much duplicate code. We were going to investigate if we could redesign the target code to have less of a profile and just depend on the initiator modules instead of recompiling openfc as openfc_tgt. What's the general opinion on this? Duplicate code vs. more kernel code? I can see that you're already starting to clean up the code that you ported. Does that mean the duplicate code isn't an issue to you? When we fix bugs in the initiator they're not going to make it into your tree unless you're diligent about watching the list. It's hard to convince the kernel maintainers to merge something into mainline that which can be implemented in user space. I failed twice (with two iSCSI target implementations). Yeah, duplication is not good but the user space code has some great advantages. Both approaches have the pros and cons. The initiator driver succeeded to log in a target, see logical units, and perform some I/Os. It's still very unstable but it would be useful for FCoE developers. I would like to help you push the Open-FCoE initiator to mainline too. What are on your todo list and what you guys working on now? We would really appreciate the help! The best way I could come up with to coordinate this effort was through the BZ- http://open-fcoe.org/bugzilla. I was going to write a BZ wiki entry to help new contributors, but since I haven't yet, here's the bottom line. Sign-up to the BZ, assign bugs to yourself from my name (I'm the default assignee now) and also file bugs as you find them. I don't want to impose much process, but this will allow all of us to know what everyone else is working on. The main things that I think need to be fixed are (in no particular order)- 1) Stability- Just straight up bug fixing. This is ongoing and everyone is looking at bugs. Talking about stability is a bit premature, I think. The first thing to do is finding a design that can be accepted into mainline. How can we get this started? We've provided our current solution, but need feedback to guide us in the right direction. We've received little quips about libsa and libcrc and now it looks like we should look at what we can move to userspace (see below), but that's all the feedback we've got so far. Can you tell us what you think about our current architecture? Then we could discuss your concerns... 2) Abstractions- We consider libsa a big bug, which we're trying to strip down piece by piece. Vasu took out the LOG_SA code and I'm looking into changing the ASSERTs to BUG_ON/WARN_ONs. That isn't all of it, but that's how we're breaking it down. Agreed, libsa (and libcrc) should be removed. 3) Target- The duplicate code of the target is too much. I want to integrate the target into our -upstream tree. Without doing that, fixes to the -upstream tree won't benefit the target and it will get into worse shape than it already is, unless someone is porting those patches to the target too. I think that ideally we'd want to reduce the target's profile and move it to userspace under tgt. 4) Userspace/Kernel interaction- It's our belief that netlink is the preferred mechanism for kernel/userspace interaction. Yi has converted the FCoE ioctl code to netlink and is looking into openfc next. There are other options and I'm not sure that netlink is the best. I think that there is no general consensus about the best mechanism for kernel/userspace interaction. Even ioctl is still accepted into mainline (e.g. kvm). I expect you get an idea to use netlink from open-iscsi, but unlike open
RE: [OpenFCoE PATCH] [PATCH] Performance improvement, combine received data copy with CRC.
Rob Love wrote: Joe Eykholt wrote: [PATCH] Performance improvement, combine received data copy with CRC. Shouldn't we remove openfc_cp_to_user() if we're moving that functionality into openfc_scsi_recv_data()? Yes. That was an oversight. I did intend to remove it. Do you want a new patch for that or will you take care of it? I can take care of it. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Open-FCoE - Fibre Channel over Ethernet Project
Hello Linux Community, I'd like to introduce a new Open Source project named Open-FCoE. FCoE is the acronym for Fibre Channel over Ethernet, which is the encapsulation of Fibre Channel frames within Ethernet packets. FCoE will allow systems with an Ethernet adapter and a Fibre Channel Forwarder to login to a Fibre Channel fabric (the FCF is a gateway that bridges the LAN and the SAN). That fabric login was previously reserved exclusively for Fibre Channel HBAs. This technology reduces complexity in the data center by aiding network convergence. It is targeted for 10Gps Ethernet NICs but will work on any Ethernet NIC supporting pause frames. Our code base provides a Fibre Channel protocol processing module as well as an Ethernet based transport module. The Open-FC module acts as a LLD for SCSI and the Open-FCoE transport uses net_device to send and receive packets. We've set up a web home for this project at www.Open-FCoE.org. Its purpose is to support development and users; it's very light on content right now. We have a lot of code and it will take time for us to harden and improve upon it. We're still early in development but are making this code available as soon as possible so that our project's development can truly be open. This is our code's organization as it is today. 1) git://open-fcoe.org/openfc/open-fcoe-upstream.git This repository is based on the SCSI 2.6.24 bug fix tree. Two patches are applied to add our code and resolve any compatibility problems between our code and 2.6.24. 2) git://open-fcoe.org/openfc/open-fcoe.git This repository contains our user space tools. It also contains an out-of-kernel Makefile that allows a user to build the kernel modules within this layout. Pulling our kernel code from open-fcoe-upstream into this code base and then tarring it up provides an easily distributable package. 3) git://open-fcoe.org/openfc/open-fcoe-misc.git This repository contains our SW target code. The SW target allows someone to connect two systems back-to-back and run FCoE traffic from one to another. Currently our target uses SCST which is not upstream. This is causing us a problem because the target shares code with the initiator. Since the initiator is building with 2.6.24 and SCST isn't we're in a bind. A priority of ours will be to get the target back to a better shape as it's our primary development tool. We also have a lot of things to fix. Here are our initial concerns, 1) Kernel/Userspace interaction needs direction. Currently we're using ioctls, which are no longer desirable. We're planning to change the implementation to netlink. Also, some non-data path code will probably need to move to user space. Open-iSCSI has spent a lot of time on its kernel to user interaction; we will likely borrow from that model as much as we can. 2) SW Target and its integration with the kernel. 3) Reduction of code, removal of unnecessary abstraction. 4) Non-GPL code. We're currently using a BSD queue.h and some CRC code from BSD as well. We need to convert this code to use kernel code. 5) Documentation. Our basic documentation needs some help so people can use the initiator and target easily. We have a mailing list established on our website, but believe that the community will want us to discuss this technology on the SCSI mailing list. That is where we plan to start discussing this code. We're looking forward to building a strong community around this technology and code base. We're eager to start coding and improving our code with any other community contributors! Robert Love Open-FCoE.org - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Open-FCoE on linux-scsi
Hello SCSI mailing list, I'd just like to introduce ourselves a bit before we get started. My name is Robert Love and I'm joined by a team of engineers including Vasu Dev, Chris Leech and Yi Zou. We are committed to maintaining the Open-FCoE project. Aside from Intel engineers we expect engineers from other companies to contribute to Open-FCoE. Our goal is to get the initiator code upstream. We have a lot of working code but recognize that we're early in this project's development. We're looking for direction from you, the experts, on what this project should grow into. My concern is that we're going to bombard the SCSI list, but upon James' recommendation we'll start on your list and if it's too much move to our own list. Thanks, //Rob - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Open-FCoE on linux-scsi
On Tue, 27 Nov 2007 15:40:05 -0800 Love, Robert W [EMAIL PROTECTED] wrote: Hello SCSI mailing list, I'd just like to introduce ourselves a bit before we get started. My name is Robert Love and I'm joined by a team of engineers including Vasu Dev, Chris Leech and Yi Zou. We are committed to maintaining the Open-FCoE project. Aside from Intel engineers we expect engineers from other companies to contribute to Open-FCoE. Our goal is to get the initiator code upstream. We have a lot of working code but recognize that we're early in this project's development. We're looking for direction from you, the experts, on what this project should grow into. A quick start guide to setup initiator and target and connect them is available? Yeah, there's a page in our wiki. It's mentioned the first post on www.Open-FCoE.org. Here's a direct link- http://www.open-fcoe.org/openfc/wiki/index.php/Quickstart. Unfortunately it's a bit rocky to get everything working even with the quickstart, I'm working on improving that right now. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
