RE: DCB support for iSCSI
-Original Message- From: Mike Christie [mailto:micha...@cs.wisc.edu] Sent: Monday, January 03, 2011 3:39 PM To: open-iscsi@googlegroups.com Cc: Iyer, Shyam; mark.d.rus...@intel.com Subject: Re: DCB support for iSCSI On 12/22/2010 11:22 PM, shyam_i...@dell.com wrote: VLAN creation. From what I've seen iSCSI support in DCB would work similar to FCoE, ie the iSCSI traffic will be sent via a separate VLAN. Which we would need to create, eventually. So basically we would need something similar to 'fipvlan' or integrate this functionality into open-iscsi. Well there are more methods actually. Separating them into separate VLAN's would tag them to the priority of the VLAN(8 in all) however sometimes the tag is based on the application type port number. So, in the iSCSI case the well known port number 3260 becomes the priority decider. I actually broke the code to support ports other than 3260 in a rhel test release, and so I know people use other ports in real life setups :) I would bet the vast majority of times it is 3260, but it is not always so I do not think you can count on it if that is what you are saying. The spec tries to make it easy by assigning a priority tag based on the application's well known port number. As long as the lldp peers know what port number to use for priority tagging it should be fine. Usecase - Tag all iSCSI traffic to a specific port type in a virtualized environment. Its very cumbersome to manage vlans in the virtualized environments. Also ETS determines that within the same priority group the bandwidth could be split further. Now, this could be per connection. My hunch is that we need more flexible ways of splitting the bandwidth within a priority group per connection via the lldpad. What is ETS? Sorry for the acronym.. It means enhanced transmission selection. This link is pretty good.. http://www.ieee802.org/1/files/public/docs2008/az-wadekar-ets-proposal-0608-v1.01.pdf -- 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: on-off periodic hangs in scsi commands
Spelic, on 01/05/2011 09:56 PM wrote: I am cc-ing the open-iscsi and scst people to see if they can suggest a way to debug the iscsi one. In particular it would be very interesting to get the number of commands received and replied from target side, and match it to the number of commands submitted from initiator side. (but I suspect these status variables do not exist) If target side says it has already replied, but initiator side sees the reply after 1 second... that would be very meaningful. The bad thing is that I do not have much time to debug this :-( For SCST you can enable scsi logging. Then you will see all the coming SCSI commands and responses for them in the kernel log. To deal with the large volume of logs this facility can produce, you will need to switch your logging application (syslogd?) into async mode (no fsync after each logged line). Vlad -- 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 06/16] BNX2I: Added code to handle the binding of an existing connection
On 01/06/2011 12:54 AM, Or Gerlitz wrote:
Mike Christie wrote:
I went a different way. In the attached patch we detect the problem when
binding and will force a disconnect of the old ep before binding a new one.
Try it out and let me know.
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -651,8 +651,7 @@ free_addr:
static int
iscsi_sw_tcp_conn_bind(struct iscsi_cls_session *cls_session,
- struct iscsi_cls_conn *cls_conn, uint64_t transport_eph,
- int is_leading)
+ struct iscsi_cls_conn *cls_conn, uint64_t transport_eph)
{
struct Scsi_Host *shost = iscsi_session_to_shost(cls_session);
struct iscsi_host *ihost = shost_priv(shost);
@@ -685,7 +684,7 @@ iscsi_sw_tcp_conn_bind(struct iscsi_cls_session
*cls_session,
if (err)
goto free_socket;
- err = iscsi_conn_bind(cls_session, cls_conn, is_leading);
+ err = iscsi_conn_bind(cls_session, cls_conn, NULL);
should this be transport_eph instead of NULL?
No. iscsi_tcp does not use the iscsi_endpoint abstraction becuase it
actually uses normal old sockets that are created in userspace.
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -3137,16 +3137,18 @@ void iscsi_conn_stop(struct iscsi_cls_conn *cls_conn,
int flag)
EXPORT_SYMBOL_GPL(iscsi_conn_stop);
int iscsi_conn_bind(struct iscsi_cls_session *cls_session,
- struct iscsi_cls_conn *cls_conn, int is_leading)
+ struct iscsi_cls_conn *cls_conn,
+ struct iscsi_endpoint *ep)
{
struct iscsi_session *session = cls_session-dd_data;
struct iscsi_conn *conn = cls_conn-dd_data;
spin_lock_bh(session-lock);
- if (is_leading)
- session-leadconn = conn;
+ session-leadconn = conn;
spin_unlock_bh(session-lock);
+ ep-conn = cls_conn;
+ cls_conn-ep = ep;
if not, it doesn't look like ep can be null here...
Will fix. Tested offload and did not test software iscsi.
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -388,7 +388,7 @@ extern void iscsi_conn_teardown(struct iscsi_cls_conn *);
extern int iscsi_conn_bind(struct iscsi_cls_session *, struct iscsi_cls_conn
*,
- int);
+ struct iscsi_endpoint *);
--- a/include/scsi/scsi_transport_iscsi.h
+++ b/include/scsi/scsi_transport_iscsi.h
@@ -95,7 +95,7 @@ struct iscsi_transport {
uint32_t cid);
int (*bind_conn) (struct iscsi_cls_session *session,
struct iscsi_cls_conn *cls_conn,
- uint64_t transport_eph, int is_leading);
+ uint64_t transport_eph);
so we're implicitly casting from u64 to ep pointer? I guess this should be fine.
No. The transport-bind_conn takes the u64 id. The driver then looks
that up and passes iscsi_bind_conn a pointer to the ep struct.
--
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 0/8] Added bug fixes and several features for BNX2I
On 01/05/2011 02:44 PM, Eddie Wai wrote: Hello, This patch set contains two fixes and added various features as titled. The two fixes are: 1 - connection cleanup fix which fixes a chip panic issue 2 - nopout LUN field fix which fixes nopout timeouts The features added includes TCP timestamp, jumbo MTU, text pdu support for discovery offload, and 57712(E) support. All patches but [PATCH 5/8] BNX2I: Added TCP timestamps option support look ok. I am working on a common way to set tcp settings for 2.6.39, so lets wait on that. BNX2I: Added TCP timestamps option support -- 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.
