Re: [openib-general] [PATCH] IB/SRP Userspace: srptools/srp_daemon - Fix connect bug and add support for user specified initiator extension
From: Ishai Rabinovitz [mailto:[EMAIL PROTECTED] Subject: Re: [openib-general] [PATCH] IB/SRP Userspace: srptools/srp_daemon - Fix connect bug and add support for user specified initiator extension Thanks for your patch. I agree with some of the changes you suggest and disagree with others. It will be useful to post a different patch for each logical change. Thanks for the comments. I will make sure to separate out the logical changes into discrete patches the next time I submit a patch. 1. Fixes bug in srp_daemon for the case where if it is invoked with the '-e' option, it fails to connect to the SRP targets because of a newline character in the parameter string. You are right that the '\n' is redundant, but I have not seen the bug it creates. The last parameter in the string is considered to be a string by ib_srp and therefore ib_srp will ignore the newline. I saw the following error message in /var/log/messages before I fixed the newline: messages:Oct 17 06:14:25 aspen kernel: ib_srp: unknown parameter or missing valu e 'io_class=ff00 messages:Oct 17 06:14:25 aspen kernel: ib_srp: unknown parameter or missing valu e 'io_class=ff00 messages:Oct 18 05:43:42 aspen kernel: ib_srp: unknown parameter or missing valu e 'io_class=ff00 Do you suspect the problem to be elsewhere? I was testing against Silverstorm SRP targets, but considering the error message, that should not have been relevant. The connection, of course, never got created, which is what prompted me to make the above fix. 2. Changes the name of the constant 'MAX_TRAGET_CONFIG_STR_STRING' to 'MAX_TARGET_CONFIG_STR_STRING'. Thanks, I will apply this change. Didn't really mean to nitpick on this typo. I decided to fix it only when I grep'ed for TARGET and found no matches. 3. Changes the behavior of the '-n' option to srp_daemon. The earlier behavior printed the initiator extension. The new behavior allows the user to specify an initiator extension as an argument to the '-n' option. I do not think we want to change the -n behavior to this one. First of all your approach induces the same initiator_ext to all the targets discovered by this srp_daemon. The point you raise actually prompts another related question about srp_daemon behavior. Currently, srp_daemon connects to all the targets it finds, when given the '-e' option. I think adding a flag that would allow a user to specify the target IOC guid to connect to would help, and that flag when used with the initiator extension would be more useful. What do you think? Secondly If someone uses random values for the initiator_ext it may cause a waste of resources in the target: the target can never tell when a connection had failed (or an initiator performed a boot) and will keep the connection alive. When there is an attempt to reconnect to this target with the same initiator_ext, the target knows he can close the old connection. This is the reason we decided to have a convention. The convention is to use the target port guid. The advantage of this convention is that it allows us to have two connection on the same time from an initiator to both ports of the target. I understand that some targets may need a different initiator_ext, Yes, Silverstorm SRP targets support multiple connections from a single HCA port to a single SRP target, for the purposes of establishing unique connections to specific storage devices that are *behind* an FC switch but all being accessible through the same target port. In summary, to fully support such SRP targets and the increased functionality that becomes possible because of them, supporting multiple initiator extension becomes a necessity. but you should add a new flag for actually setting the initiator_ext and leave -n untouched. You are welcome to send such a patch. I agree, I will leave '-n' untouched and add a new flag, say '-x', that will allow a user to specify the initiator extension. Ishai There is another issue that we need to tackle as well. Currently, the check in srp_daemon, to see whether a target is already connected, does not take into account the initiator extension that a user could specify. That would need to be added to the check as well. From a quick examination of the code, it appears that the changes are both to the kernel module as well as to srp_daemon. I hope to have a separate patch for that ready in a few days. Thanks, appreciate your comments and feedback, Madhu. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] IB/SRP Userspace: srptools/srp_daemon - Fix connect bug and add support for user specified initiator extension
The patch addresses 3 issues:
1. Fixes bug in srp_daemon for the case where if it is invoked with the
'-e' option, it fails to connect to the SRP targets because of a newline
character in the parameter string.
2. Changes the name of the constant 'MAX_TRAGET_CONFIG_STR_STRING' to
'MAX_TARGET_CONFIG_STR_STRING'.
3. Changes the behavior of the '-n' option to srp_daemon. The earlier
behavior printed the initiator extension. The new behavior allows the
user to specify an initiator extension as an argument to the '-n'
option.
Signed-off-by: Madhu Lakshmanan [EMAIL PROTECTED]
---
--- 1.1-orig/src/userspace/srptools/srp_daemon/srp_daemon.c
2006-10-17 06:32:14.0 -0400
+++ 1.1/src/userspace/srptools/srp_daemon/srp_daemon.c 2006-10-17
06:10:12.0 -0400
@@ -78,7 +78,7 @@ static char *sysfs_path = /sys;
static void usage(const char *argv0)
{
- fprintf(stderr, Usage: %s [-vVceo] [-d umad device | -i
infiniband device [-p port_num]] [-t timoeout (ms)] [-r retries]
[-R Rescan time]\n, argv0);
+ fprintf(stderr, Usage: %s [-vVceo] [-d umad device | -i
infiniband device [-p port_num]] [-n initiator_ext] [-t timoeout
(ms)] [-r retries] [-R Rescan time]\n, argv0);
fprintf(stderr, -v Verbose\n);
fprintf(stderr, -V debug Verbose\n);
fprintf(stderr, -c prints connection
Commands\n);
@@ -91,7 +91,7 @@ static void usage(const char *argv0)
fprintf(stderr, -R Rescan time perform complete Rescan
every Rescan time seconds\n);
fprintf(stderr, -t timoeout Timeout for mad response
in milisec \n);
fprintf(stderr, -r retries number of send Retries
for each mad\n);
- fprintf(stderr, -n New print - prints also
initiator extention\n);
+ fprintf(stderr, -n initiator_ext New: use initiator
extension\n);
fprintf(stderr, \nExample: srp_daemon -e -i mthca0 -p 1 -R
60\n);
}
@@ -114,7 +114,7 @@ void pr_cmd(char *target_str, int not_co
int ret;
if (config-cmd)
- printf(%s, target_str);
+ printf(%s\n, target_str);
if (config-execute not_connected) {
int fd = open(config-add_target_file, O_WRONLY);
@@ -122,6 +122,7 @@ void pr_cmd(char *target_str, int not_co
pr_err(unable to open %s, maybe ib_srp is not
loaded\n, config-add_target_file);
return;
}
+ pr_debug(Add target str: %s\n, target_str);
ret = write(fd, target_str, strlen(target_str));
pr_debug(Adding target returned %d\n, ret);
close(fd);
@@ -174,8 +175,8 @@ static void add_non_exist_traget(char *i
char *subdir_name_ptr;
int prefix_len;
uint8_t dgid_val[16];
- const int MAX_TRAGET_CONFIG_STR_STRING = 255;
- char target_config_str[MAX_TRAGET_CONFIG_STR_STRING];
+ const int MAX_TARGET_CONFIG_STR_STRING = 255;
+ char target_config_str[MAX_TARGET_CONFIG_STR_STRING];
int len, len_left;
int not_connected = 1;
@@ -190,8 +191,7 @@ static void add_non_exist_traget(char *i
prefix_len = strlen(scsi_host_dir);
subdir_name_ptr = scsi_host_dir + prefix_len;
- subdir = (void *) 1; /* Dummy value to enter the loop */
- while (subdir) {
+ do {
subdir = readdir(dir);
if (!subdir)
@@ -237,9 +237,9 @@ static void add_non_exist_traget(char *i
return;
- }
+ } while (subdir);
- len = snprintf(target_config_str, MAX_TRAGET_CONFIG_STR_STRING,
id_ext=%s,
+ len = snprintf(target_config_str, MAX_TARGET_CONFIG_STR_STRING,
id_ext=%s,
ioc_guid=%016llx,
dgid=%016llx%016llx,
pkey=,
@@ -249,41 +249,40 @@ static void add_non_exist_traget(char *i
(unsigned long long) subnet_prefix,
(unsigned long long) h_guid,
(unsigned long long) h_service_id);
- if (len = MAX_TRAGET_CONFIG_STR_STRING) {
+ if (len = MAX_TARGET_CONFIG_STR_STRING) {
pr_err(Target conifg string is too long, ignoring
target\n);
closedir(dir);
return;
}
if (ioc_prof.io_class != htons(SRP_REV16A_IB_IO_CLASS)) {
- len_left = MAX_TRAGET_CONFIG_STR_STRING - len;
+ len_left = MAX_TARGET_CONFIG_STR_STRING - len;
len += snprintf(target_config_str+len,
- MAX_TRAGET_CONFIG_STR_STRING - len,
+ MAX_TARGET_CONFIG_STR_STRING - len,
,io_class=%04hx,
ntohs(ioc_prof.io_class));
- if (len = MAX_TRAGET_CONFIG_STR_STRING) {
+ if (len = MAX_TARGET_CONFIG_STR_STRING) {
pr_err(Target conifg string is too long,
ignoring target\n);
Re: [openib-general] srp trouble on RHEL4 U4
Which SRP target are you using? Could you also give some more details on the fabric setup; i.e. what IB switch / gateway your host is connected to, and what kind of storage you wish to access? The full command that you used (echo -n /add_target) to configure the SRP target would be very useful as well. The Silverstorm 7000 is an HCA (Host Channel Adapter). By itself, it should in most cases not be the primary reason for the error code you are seeing. The issue is more likely to be due to the SRP target you are attempting to connect to. Thanks, Madhu Lakshmanan Silverstorm Technologies, Inc. [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mirochnick Natalia Sent: Tuesday, October 17, 2006 10:47 AM To: openib-general@openib.org Subject: [openib-general] srp trouble on RHEL4 U4 Hello, I'm trying to setup SRP connection (SRP in OFED 1.0). IB card is Silverstorm 7000. ib_srp module is loaded, but after attempt to to create an SRP device (as it was described in manual srp_release_notes.txt) the error appears in /var/log/messages: kernel: REJ reason 0x0 What's wrong? -- Thanks in advance, Mirochnick Natalia ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] srp trouble on RHEL4 U4
Madhu Lakshmanan wrote: Which SRP target are you using? Could you also give some more details on the fabric setup; i.e. what IB switch / gateway your host is connected to, and what kind of storage you wish to access? The full command that you used (echo -n /add_target) to configure the SRP target would be very useful as well. From: Mirochnick Natalia [mailto:[EMAIL PROTECTED] Subject: Re: [openib-general] srp trouble on RHEL4 U4 2. Here's the details: IB switch: Silverstorm 5000 Storage: NetApp FAS 320 [EMAIL PROTECTED] /usr/ofed/sbin/ibsrpdm -c id_ext=0001,ioc_guid=00066a01380001de,dgid=fe8 66a0261de,pkey=,service_id=49435353525 0,io_class=ff00 id_ext=0001,ioc_guid=00066a02380001de,dgid=fe8 66a0261de,pkey=,service_id=49435353525 0,io_class=ff00 [EMAIL PROTECTED] echo -n id_ext=0001,ioc_guid=00066a01380001de,dgid=fe8 66a0261de,pkey=,service_id=494353535250 /sys/class/infiniband_srp/srp-mthca0-1/add_target The problem is with the echo string you are giving. The command should be invoked as: echo -n id_ext=0001,ioc_guid=00066a01380001de,dgid=fe8 66a0261de,pkey=,service_id=494353535250, io_class=ff00 /sys/class/infiniband_srp/srp-mthca0-1/add_target You were missing the 'io_class=ff00' bit. Let me know if it works. Madhu ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] srp trouble on RHEL4 U4
From: Mirochnick Natalia [mailto:[EMAIL PROTECTED] Subject: Re: [openib-general] srp trouble on RHEL4 U4 I've changed the string as you've advised, but it didn't work. The only difference is that string was added in /var/log/messages. [EMAIL PROTECTED] echo -n id_ext=0001,ioc_guid=00066a01380001de,dgid=fe8 66a0261de,pkey=,service_id=49435353525 0,io_class=ff00 /sys/class/infiniband_srp/srp-mthca0-1/add_target [EMAIL PROTECTED] tail /var/log/messages Oct 18 14:01:26 ... kernel: REJ reason 0x0 Oct 18 14:01:26 ... kernel: ib_srp: Connection failed By the way, in ofed srp_release_notes.txt hasn't been said that io_class is mandatory parameter. Natalia It is an error in the OFED 1.0 srp_release_notes.txt. For all Silverstorm SRP targets (like the Silverstorm 5000 switch with Fiber Channel IOC), the 'io_class=ff00' parameter is mandatory. Let me investigate a little more, and get back to you. Madhu ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] FW: [PATCH fixed] [RFC] IB/srp: enable multiple connections to the same target
Quoting r. Roland Dreier [EMAIL PROTECTED]: Thanks, queued for 2.6.19 I tested the patches, which are included in OFED 1.1 RC7, against Silverstorm SRP targets. The patch breaks backward compatibility for fabrics that use Silverstorm targets, due to the following: It defaults the new parameter initiator_ext to 0. Silverstorm SRP targets, when configured for working with OFED stacks, are usually set to expect an initiator extension of 1, to overcome the earlier limitation of OFED stacks setting initiator extension to the port number. This implies that a user must, without exception, add initiator_ext=n to the add target echo string. It'd be useful if either or both of the following could be done: 1. Release note the above requirement of adding the initiator_ext=n string to the add target echo string, for all Silverstorm targets. 2. Maintain the earlier default of the initiator extension being equal to the port number. I have prepared a patch that does step 2 above, which I'll send in a separate e-mail based on the feedback to the above suggestions. Madhu ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] FW: [PATCH fixed] [RFC] IB/srp: enable multiple connections to the same target
I tested the patches, which are included in OFED 1.1 RC7, against Silverstorm SRP targets. The patch breaks backward compatibility for fabrics that use Silverstorm targets, due to the following: It defaults the new parameter initiator_ext to 0. Silverstorm SRP targets, when configured for working with OFED stacks, are usually set to expect an initiator extension of 1, to overcome the earlier limitation of OFED stacks setting initiator extension to the port number. Sounds like a target bug - why does it expect *anything* specific in the initiator extension? The Silverstorm SRP targets can be configured to accept connections from specific hosts (identified by GUID) and / or specific initiator extensions. This allows for a scenario where a group of hosts can gain access to the same back-end storage device, by using the same initiator extension across all the hosts, with the host GUID being ignored / wildcarded on the SRP target. It also facilitates a level of access control to back-end storage devices and permits the grouping of hosts into logical groups. In order to interoperate successfully with the OFED 1.0 stack, such SRP targets were configured to expect the initiator extension reported by the OFED 1.0 SRP implementation, i.e. an initiator extension of 1. Note that for this particular configuration the host GUID is wildcarded, and the only unique identifier is the initiator extension. 1. Release note the above requirement of adding the initiator_ext=n string to the add target echo string, for all Silverstorm targets. I don't think we'll be touching OFED 1.1 anymore. So maybe this is the best choice for kernel.org, too. Are the release notes / docs frozen as well? 2. Maintain the earlier default of the initiator extension being equal to the port number. Hmm. What, exactly, is the target assumption? -- MST The target doesn't assume or default anything. It is how it is configured. The current patch breaks existing Silverstorm SRP target configurations, unless either: 1. The user specifies the initiator_ext=n when adding a target, which is not to be found anywhere in the release notes, or 2. The configuration on the SRP target is modified to reflect the changes in OFED 1.1 where the initiator extension is passed to the target as 0, if the user doesn't specify it, which again is not specified in the release notes. Madhu ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] FW: [PATCH fixed] [RFC] IB/srp: enable multiple connections to the same target
From: Scott Weitzenkamp (sweitzen) [mailto:[EMAIL PROTECTED] I am also having new problems configuring SRP with OFED 1.1 rc7, I have asked Roland to take a look on my test networks. Scott Weitzenkamp I had to add the following string to the parameters that are echo'ed to '/sys/class/infiniband_srp//add_target', to get it to work with the Silverstorm SRP targets: ,initiator_ext=0001 I have absolutely no idea what test setup you are using, but maybe that, or something similar, works for you as well? I haven't tried HA, just been sticking to the basics. Madhu ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] FW: [PATCH fixed] [RFC] IB/srp: enable multiple connections to the same target
From: Michael S. Tsirkin [mailto:[EMAIL PROTECTED] Quoting r. Lakshmanan, Madhu [EMAIL PROTECTED]: Subject: RE: FW: [PATCH fixed] [RFC] IB/srp: enable multiple connections to the same target I tested the patches, which are included in OFED 1.1 RC7, against Silverstorm SRP targets. The patch breaks backward compatibility for fabrics that use Silverstorm targets, due to the following: It defaults the new parameter initiator_ext to 0. Silverstorm SRP targets, when configured for working with OFED stacks, are usually set to expect an initiator extension of 1, to overcome the earlier limitation of OFED stacks setting initiator extension to the port number. Sounds like a target bug - why does it expect *anything* specific in the initiator extension? The Silverstorm SRP targets can be configured to accept connections from specific hosts (identified by GUID) and / or specific initiator extensions. This allows for a scenario where a group of hosts can gain access to the same back-end storage device, by using the same initiator extension across all the hosts, with the host GUID being ignored / wildcarded on the SRP target. It also facilitates a level of access control to back-end storage devices and permits the grouping of hosts into logical groups. In order to interoperate successfully with the OFED 1.0 stack, such SRP targets were configured to expect the initiator extension reported by the OFED 1.0 SRP implementation, i.e. an initiator extension of 1. Note that for this particular configuration the host GUID is wildcarded, and the only unique identifier is the initiator extension. 1. Release note the above requirement of adding the initiator_ext=n string to the add target echo string, for all Silverstorm targets. I don't think we'll be touching OFED 1.1 anymore. So maybe this is the best choice for kernel.org, too. Are the release notes / docs frozen as well? Not yet. 2. Maintain the earlier default of the initiator extension being equal to the port number. Hmm. What, exactly, is the target assumption? The target doesn't assume or default anything. It is how it is configured. The current patch breaks existing Silverstorm SRP target configurations, unless either: 1. The user specifies the initiator_ext=n when adding a target, which is not to be found anywhere in the release notes, or 2. The configuration on the SRP target is modified to reflect the changes in OFED 1.1 where the initiator extension is passed to the target as 0, if the user doesn't specify it, which again is not specified in the release notes. OK,thanks. So we need to document this. Could you pls post a short text describing the issue, who is affected and what needs to be done by the user? -- MST Vendor specific notes: Hosts that are connected to Silverstorm SRP targets need to do either of the following steps after they are upgraded to the OFED 1.1 release in order to continue to access their storage successfully: 1. When issuing the echo command to add a new SRP target, the host must append the string ,initiator_ext=0001 to the original echo string. Example: If 'ibsrpdm -c' shows, and you want to connect to the first target: id_ext=0001,ioc_guid=00066a0138000165,dgid=fe8 66a026165,pkey=,service_id=494353535250,io_class=ff00 id_ext=0001,ioc_guid=00066a0238000165,dgid=fe8 66a026165,pkey=,service_id=494353535250,io_class=ff00 the echo command must be: echo -n id_ext=0001,ioc_guid=00066a0138000165,dgid=fe8 66a026165,pkey=,service_id=494353535250,io_class=ff00, initiator_ext=0001 /sys/class/inifiniband_srp/srp-mthca0-1/add_target OR 2. Change the SRP map on the Silverstorm SRP target to set the expected initiator extension to 0. For details on how to change the SRP map on a Silverstorm SRP target, please refer to product documentation. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH fixed] IB/srp: enable multiple connections to the same target
Enable multiple concurrent connections to the same SRP target 1) Use port guid instead of node guid in the initiator port identifier. 2) Let the user specify the identifier extention when adding the device. Signed-off-by: Ishai Rabinovitz [EMAIL PROTECTED] Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED] --- Looks like the last patch Ishai posted didn't apply to the upstream srp. Here's the version that does. Comments? I had some trouble applying the patch as well. I'll try again and let you know soon. From reviewing the code, it appears to fulfill the requirements we agreed upon. Madhu ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH 0/10] [RFC] Support for SilverStorm Virtual Ethernet I/O controller (VEx)
Ramachandra In that case, can you please consider this for the Ramachandra for-2.6.20 branch ? I'm happy to keep this in a vex branch or something like that, but as the emails I just sent show, this is not ready for merging yet (which is to be expected -- it's never been reviewed). Thanks. That's pretty much what we are expecting at this early stage. I fully agree that it is not ready for merging yet. We'll work on the items pointed out by the various IB reviewers and then take it from there. It is premature at this point to discuss when, where and how to merge. Madhu ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] IB/SRP: Enable multichannel
Quoting r. Vu Pham [EMAIL PROTECTED]: Subject: Re: [PATCH] IB/SRP: Enable multichannel What is the advantage to have multiple connections/qps on the same physical port to the same target? The disavantages are wasting resources, instability, no fail-over on physical port error... The advantage is if the target in question is an IOC that connects to a FC SAN for example. In this case, the host is physically connected to the same IOC, but can maintain independent logical connections to specific storage devices on the SAN that are behind the IOC. Quoting r. Michael S. Tsirkin [EMAIL PROTECTED] Subject: Re: [PATCH] IB/SRP: Enable multichannel Maybe we should just use the port GUID instead of the node GUID to form the initiator ID? That would solve this pretty cleanly I think. Sounds good. I think we should also stick the pkey into the identifier extension - I think it's nice for each partition to be able to act as a separate virtual network, not affecting others. What do you think? -- MST Sticking the pkey into the identifier extension may once again restrict the ability of the host to have multiple logical connections to an SRP IOC target. The most flexible approach appears to be: Identifier ID = Port GUID Identifier Extension = User specified Ishai's IB-SRP patch of 09/27 appears to accomplish the above. Madhu ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Conflicting typedefs for ib_gid_t
In .../include/infiniband/mad.h, it is:
typedef uint8_t ib_gid_t[16];
In .../include/infiniband/iba/ib_types.h, it is:
#include complib/cl_packon.h
typedef union _ib_gid
{
uint8_t raw[16];
struct _ib_gid_unicast
{
ib_gid_prefix_t prefix;
ib_net64_t interface_id;
} PACK_SUFFIX unicast;
struct _ib_gid_multicast
{
uint8_t header[2];
uint8_t raw_group_id[14];
} PACK_SUFFIX multicast;
} PACK_SUFFIX ib_gid_t;
#include complib/cl_packoff.h
I need to include both files for a user space tool and I'm getting a compile
error due to the conflict. Is it not the norm for a user space application to
include both files?
Appreciate any thoughts on this.
Madhu Lakshmanan
Silverstorm Technologies, Inc.
[EMAIL PROTECTED]
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Conflicting typedefs for ib_gid_t
I concur with your categorization of the application I mentioned. I was curious about the way going forward, as to whether anyone anticipated this to be a more commonly recurring issue. Thanks in advance for the patch. -- Madhu -Original Message- From: Hal Rosenstock [mailto:[EMAIL PROTECTED] Sent: Monday, August 14, 2006 4:39 PM To: Lakshmanan, Madhu; Michael S. Tsirkin Cc: openib-general@openib.org Subject: RE: Conflicting typedefs for ib_gid_t To answer your questions: I'm not totally sure about your application but it seems to me to fall in the category being discussed. Not all of the definitions in ib_types.h are elsewhere. I am working on a patch to get you past this issue. -- Hal From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Mon 8/14/2006 4:35 PM To: Hal Rosenstock; Michael S. Tsirkin Cc: [EMAIL PROTECTED]; openib-general@openib.org Subject: Re: Conflicting typedefs for ib_gid_t I don't think the way forward is using iba/ in all applications. I see it mostly as a legacy header for opensm and related apps that want their own layer for portability between stacks. I agree with your view on iba/ib_types.h Does that imply that the definitions in iba/ib_types.h are not expected to be required or used by user-space applications other than those categories mentioned above? If iba/ib_types.h is only a legacy header, are the definitions also present in another header file? Madhu ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
