Hi Hal
We have reviewed the patch for the above and figured out there is an
issue with it:
Currently when MTU_SEL=3 the quirk applies.
We think this is wrong behavior as MTU_SEL=3 means "max possible MTU" by
the IBTA spec. So if an application/ULP would like to get the max MTU possible
the correct answer is 2K for Tavor by the spec.
So this patch fxies the quirk and when MTU_SEL=3 it does not apply the MTU
limit quirk for Tavor devices.
Thanks
Eitan
Signed-off-by: Eitan Zahavi <[EMAIL PROTECTED]>
Index: 1.1/src/userspace/management/osm/opensm/osm_sa_multipath_record.c
===================================================================
--- 1.1/src/userspace/management/osm/opensm/osm_sa_multipath_record.c
(revision 9500)
+++ 1.1/src/userspace/management/osm/opensm/osm_sa_multipath_record.c
(working copy)
@@ -203,9 +203,13 @@ boolean_t
break;
case 1: /* must be less than */
- case 3: /* largest available */
/* can't be disqualified by this one */
break;
+ case 3: /* largest available */
+ /* the ULP intentionally requested */
+ /* the largest MTU possible */
+ return(FALSE);
+ break;
default:
/* if we're here, there's a bug in ib_multipath_rec_mtu_sel() */
Index: opensm/osm_sa_path_record.c
===================================================================
--- 1.1/src/userspace/management/osm/opensm/osm_sa_path_record.c
(revision 9500)
+++ 1.1/src/userspace/management/osm/opensm/osm_sa_path_record.c
(working copy)
@@ -204,9 +204,13 @@ static boolean_t
break;
case 1: /* must be less than */
- case 3: /* largest available */
/* can't be disqualified by this one */
break;
+ case 3: /* largest available */
+ /* the ULP intentionally requested */
+ /* the largest MTU possible */
+ return(FALSE);
+ break;
default:
/* if we're here, there's a bug in ib_path_rec_mtu_sel() */
_______________________________________________
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
