Re: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
On Mon, 22 Mar 2010 11:16:31 -0400 James Smart james.sm...@emulex.com wrote: About the implementation, I think that it's better to have the common library code rather than just copying the fs bsg code into iscsi. Note: I tried to library-ize the transport implementation on the first pass of the RFC. But it was making things more complex. I tried to explain this, perhaps not very well (http://marc.info/?l=linux-scsim=125725904205688w=2). Ah, I overlooked it. I'll think about it later. Maybe Mike already has some ideas about it. Anyway, library-izing is not urgent at all. We can work on it later. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
FUJITA Tomonori wrote: If vendors use the common data structures via bsg, it's totally fine by me. I see why bsg is preferable. The only thing that I care about is managing any iSCSI HBA with iscsiadm instead of various vendor specific utilities. agreed About the implementation, I think that it's better to have the common library code rather than just copying the fs bsg code into iscsi. Note: I tried to library-ize the transport implementation on the first pass of the RFC. But it was making things more complex. I tried to explain this, perhaps not very well (http://marc.info/?l=linux-scsim=125725904205688w=2). -- james s -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
On Fri, 19 Mar 2010 08:56:30 -0400 James Smart james.sm...@emulex.com wrote: I still want to know why vendors can't do this via the existing netlink interface. open-iscsi uses the netlink interface for some pdu so I guess that having a different channel for management might be a good idea. Separate this request into two needs: The first need is for the iscsi driver to have some kind of entry point to kick off a vendor specific thing - primarily diagnostics and internal f/w and flash mgmt items. Here, using the same mechanism that we had on the FC side, which also supports dma payloads, made a lot of sense. I like and prefer the symmetry. The second need is for common iscsi link/stack mgmt. All vendors would be expected to implement the same items the same way - thus the formalization of the api in the transport. It also makes sense that all use of these common interfaces comes via the open-iscsi mgmt utilities. Given the data set, it could be done by netlink or bsg. I gave some pros/cons on the interfaces in (http://marc.info/?l=linux-scsim=124811693510903w=2). In my mind, the main reason these settings ended up in bsg vs netlink is - the functionality is typically migrating from a vendor-specific ioctl set, which maps rather easily to the bsg model. Not that netlink is that more difficult (although to NLA_ or not may confuse some of the contributors). And, if you already had the bsg infrastructure for the first need, you had to add very little to support it. Thus, the main reason they are together is one of expediency. The first had to be done, so it was very easy to use the same methodology for the second. If vendors use the common data structures via bsg, it's totally fine by me. I see why bsg is preferable. The only thing that I care about is managing any iSCSI HBA with iscsiadm instead of various vendor specific utilities. About the implementation, I think that it's better to have the common library code rather than just copying the fs bsg code into iscsi. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
FUJITA Tomonori wrote: On Thu, 18 Mar 2010 16:02:52 -0500 Mike Christie micha...@cs.wisc.edu wrote: On 03/18/2010 08:58 AM, FUJITA Tomonori wrote: - You invent your hardware specific data structure for the simplest operation such as setting IP address. I think this is what Jay is not trying to do. I think the patch has some extra code like the ISCSI_BSG_HST_VENDOR parts that makes it confusing - it got me too. The ISCSI_BSG_HST_VENDOR code in be2iscsi looks like it is basically disabled (should remove for a formal patch when he sends for merging). It looks like there is a common struct iscsi_bsg_common_format that is getting passed around, and then in be2iscsi the driver is using that info to make a be2iscsi specific command. So scsi_transport_iscsi / ISCSI_SET_IP_ADDR / iscsi_bsg_common_format gets translated by b2iscsi to b2iscsi / OPCODE_COMMON_ISCSI_NTWK_MODIFY_IP_ADDR / be_modify_ip_addr. Yeah, seems you are right. But looks like this patchset also adds the vendor specific message support (ISCSI_BSG_HST_VENDOR)? I still want to know why vendors can't do this via the existing netlink interface. open-iscsi uses the netlink interface for some pdu so I guess that having a different channel for management might be a good idea. Separate this request into two needs: The first need is for the iscsi driver to have some kind of entry point to kick off a vendor specific thing - primarily diagnostics and internal f/w and flash mgmt items. Here, using the same mechanism that we had on the FC side, which also supports dma payloads, made a lot of sense. I like and prefer the symmetry. The second need is for common iscsi link/stack mgmt. All vendors would be expected to implement the same items the same way - thus the formalization of the api in the transport. It also makes sense that all use of these common interfaces comes via the open-iscsi mgmt utilities. Given the data set, it could be done by netlink or bsg. I gave some pros/cons on the interfaces in (http://marc.info/?l=linux-scsim=124811693510903w=2). In my mind, the main reason these settings ended up in bsg vs netlink is - the functionality is typically migrating from a vendor-specific ioctl set, which maps rather easily to the bsg model. Not that netlink is that more difficult (although to NLA_ or not may confuse some of the contributors). And, if you already had the bsg infrastructure for the first need, you had to add very little to support it. Thus, the main reason they are together is one of expediency. The first had to be done, so it was very easy to use the same methodology for the second. -- james s -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
On Thu, 18 Mar 2010 16:02:52 -0500 Mike Christie micha...@cs.wisc.edu wrote: On 03/18/2010 08:58 AM, FUJITA Tomonori wrote: - You invent your hardware specific data structure for the simplest operation such as setting IP address. I think this is what Jay is not trying to do. I think the patch has some extra code like the ISCSI_BSG_HST_VENDOR parts that makes it confusing - it got me too. The ISCSI_BSG_HST_VENDOR code in be2iscsi looks like it is basically disabled (should remove for a formal patch when he sends for merging). It looks like there is a common struct iscsi_bsg_common_format that is getting passed around, and then in be2iscsi the driver is using that info to make a be2iscsi specific command. So scsi_transport_iscsi / ISCSI_SET_IP_ADDR / iscsi_bsg_common_format gets translated by b2iscsi to b2iscsi / OPCODE_COMMON_ISCSI_NTWK_MODIFY_IP_ADDR / be_modify_ip_addr. Yeah, seems you are right. But looks like this patchset also adds the vendor specific message support (ISCSI_BSG_HST_VENDOR)? I still want to know why vendors can't do this via the existing netlink interface. open-iscsi uses the netlink interface for some pdu so I guess that having a different channel for management might be a good idea. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
On 03/18/2010 06:10 PM, FUJITA Tomonori wrote: On Thu, 18 Mar 2010 16:02:52 -0500 Mike Christiemicha...@cs.wisc.edu wrote: On 03/18/2010 08:58 AM, FUJITA Tomonori wrote: - You invent your hardware specific data structure for the simplest operation such as setting IP address. I think this is what Jay is not trying to do. I think the patch has some extra code like the ISCSI_BSG_HST_VENDOR parts that makes it confusing - it got me too. The ISCSI_BSG_HST_VENDOR code in be2iscsi looks like it is basically disabled (should remove for a formal patch when he sends for merging). It looks like there is a common struct iscsi_bsg_common_format that is getting passed around, and then in be2iscsi the driver is using that info to make a be2iscsi specific command. So scsi_transport_iscsi / ISCSI_SET_IP_ADDR / iscsi_bsg_common_format gets translated by b2iscsi to b2iscsi / OPCODE_COMMON_ISCSI_NTWK_MODIFY_IP_ADDR / be_modify_ip_addr. Yeah, seems you are right. But looks like this patchset also adds the vendor specific message support (ISCSI_BSG_HST_VENDOR)? Yeah, you are right. That should go in a separate patch and sent later. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
On Wed, 17 Mar 2010 23:37:07 +0530
Jayamohan Kallickal jayamoh...@serverengines.com wrote:
This patch contains the necessary changes to support
the bsg interface
Signed-off-by: Jayamohan Kallickal jayamoh...@serverengines.com
---
drivers/scsi/be2iscsi/be_cmds.h | 137 ---
drivers/scsi/be2iscsi/be_iscsi.c |3 +-
drivers/scsi/be2iscsi/be_main.c | 99 ++--
drivers/scsi/be2iscsi/be_main.h |6 +-
drivers/scsi/be2iscsi/be_mgmt.c | 230
+-
drivers/scsi/be2iscsi/be_mgmt.h | 107 ++
include/scsi/scsi_bsg_iscsi.h|1 +
7 files changed, 547 insertions(+), 36 deletions(-)
diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h
index 49fcc78..d5c14cf 100644
--- a/drivers/scsi/be2iscsi/be_cmds.h
+++ b/drivers/scsi/be2iscsi/be_cmds.h
@@ -18,6 +18,7 @@
#ifndef BEISCSI_CMDS_H
#define BEISCSI_CMDS_H
+#include scsi/scsi_bsg_iscsi.h
/**
* The driver sends configuration and managements command requests to the
* firmware in the BE. These requests are communicated to the processor
@@ -162,6 +163,13 @@ struct be_mcc_mailbox {
#define OPCODE_COMMON_ISCSI_CFG_POST_SGL_PAGES 2
#define OPCODE_COMMON_ISCSI_CFG_REMOVE_SGL_PAGES3
#define OPCODE_COMMON_ISCSI_NTWK_GET_NIC_CONFIG 7
+#define OPCODE_COMMON_ISCSI_NTWK_SET_VLAN14
+#define OPCODE_COMMON_ISCSI_NTWK_CONFIGURE_STATELESS_IP_ADDR 17
+#define OPCODE_COMMON_ISCSI_NTWK_MODIFY_IP_ADDR 21
+#define OPCODE_COMMON_ISCSI_NTWK_GET_DEFAULT_GATEWAY 22
+#define OPCODE_COMMON_ISCSI_NTWK_MODIFY_DEFAULT_GATEWAY 23
+#define OPCODE_COMMON_ISCSI_NTWK_GET_ALL_IF_ID 24
+#define OPCODE_COMMON_ISCSI_NTWK_GET_IF_INFO 25
So this patchset adds the user-kernel space interface for management
via bsg, right?
Then I have two questions.
- open-iscsi already has the user-kernel space interface for
management via netlink. Why do you need another via bsg? IOW, why
can't you do this via the existing netlink interface?
- You invent your hardware specific data structure for the simplest
operation such as setting IP address. It means that every vendor
invents their hardware specific data structure for management. Users
have to use the vendor specific management software or open-iscsi
management tool (iscsiadm) needs all the vendor specific code to
build the vendor specific data structure (and parse the response). I
think that it is exactly what open-iscsi tries to avoid. iscsiadm
builds the generic management data structure and
scsi_transport_iscsi.c passes it to the drivers. Then the drivers
have to handle it. That's the way open-iscsi works now.
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Re: [PATCH 2/2] RFC: The be2iscsi driver support for bsg
On 03/18/2010 08:58 AM, FUJITA Tomonori wrote: - You invent your hardware specific data structure for the simplest operation such as setting IP address. I think this is what Jay is not trying to do. I think the patch has some extra code like the ISCSI_BSG_HST_VENDOR parts that makes it confusing - it got me too. The ISCSI_BSG_HST_VENDOR code in be2iscsi looks like it is basically disabled (should remove for a formal patch when he sends for merging). It looks like there is a common struct iscsi_bsg_common_format that is getting passed around, and then in be2iscsi the driver is using that info to make a be2iscsi specific command. So scsi_transport_iscsi / ISCSI_SET_IP_ADDR / iscsi_bsg_common_format gets translated by b2iscsi to b2iscsi / OPCODE_COMMON_ISCSI_NTWK_MODIFY_IP_ADDR / be_modify_ip_addr. So the approach using a common struct/cmd is ok with me, and if we can get a struct format works for everyone (qla4xxx, be2iscsi, cxgb4i) then I am fine. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
