Re: [ewg] ibdiagpath broken with TCL 8.5
On 03-Mar-11 4:22 PM, Mike Heinz wrote:
> If I get a chance, I'll take a look and see if I find an easy fix. One
> simple thing that occurred to me was to modify ibdebug.tcl to filter the
> field names out of the output string but I'm not sure what the side-effects
> would be.
That will probably work for ibdiagpath.
But still, if anyone has some script that uses
ibis, the fix won't resolve the problem for him.
-- YK
> -Original Message-
> From: Yevgeny Kliteynik [mailto:klit...@dev.mellanox.co.il]
> Sent: Thursday, March 03, 2011 5:45 AM
> To: Mike Heinz
> Cc: Linux RDMA; ewg@lists.openfabrics.org; Todd Rimmer
> Subject: Re: ibdiagpath broken with TCL 8.5
>
> Mike,
>
> On 01-Mar-11 11:13 PM, Mike Heinz wrote:
>> YK,
>>
>> I had a chance to go back and dig further into this. I just scratch-built
>> the ibis executable on an RHEL6 system, and started running it in
>> interactive mode. What I see is that results that return arrays are getting
>> garbage pre-pended to them - it looks like the root problem that John tried
>> to patch last fall, and that's causing problems for some of my systems here,
>> is that ibis isn't interfacing with TCL 8.5 correctly:
>>
>> % puts [smLftBlockMad dump]
>> -lft 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 % puts [smVlArbTableMad
>> dump] -vl_entry {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00}
>> {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0
>> 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0
>> 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0
>> 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0
>> 0x00} {0x0 0x00} {0x0 0x00}
>>
>> I do not see this behavior on systems running TCL 8.4:
>>
>> % ibis_init
>> 0
>> % ibis_set_port 0x00066a00a000707f
>> 0
>> % puts [smLftBlockMad dump]
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
>> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 % puts [smVlArbTableMad dump]
>> {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0
>> 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0
>> 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0
>> 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0
>> 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0
>> 0x00} {0x0 0x00}
>
> Interesting. I tried it, and I see same results as you.
> Looks like "dump" is supposed to include field names only if there are more
> than one field in the object.
>
> With TCL 8.4, I see this:
>
> % smVlArbTableMad dump
> {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00}
> {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00}
> {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00}
> {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00}
> {0x0 0x00} {0x0 0x00} {0x0 0x00} {0x0 0x00} % smSwitchInfoMad dump -lin_cap 0
> -rand_cap 0 -mcast_cap 0 -lin_top 0 -def_port 0 -def_mcast_pri_port 0
> -def_mcast_not_port 0 -life_state 0 -lids_per_port 0 -enforce_cap 0 -flags 0
>
> So VLArb Table doesn't have field name, while SwitchInfo has all its fields.
> I see similar behavior with other objects.
> Ibis has an implementation of dump function for "non-trivial" objects
> (objects that are not just set of standard data types). VLArbTable would be
> one of them - it consists of VLArbTable Elements, that have their own dump
> function:
>
> %typemap(tcl8, out) ib_vl_arb_element_t[ANY] {
> int i;
> char buff[16];
> for (i=0; i<$dim0 ; i++) {
> sprintf(buff, "{0x%x 0x%02x} ", $source[i].vl,
> $source[i].weight);
> Tcl_AppendResult(interp, buff, NULL);
> }
> }
>
> typedef struct _ibsm_vl_arb_table
> {
> ib_vl_arb_element_t
> vl_entry[IB_NUM_VL_ARB_ELEMENTS_IN_BLOCK];
> } smVlArbTable;
>
&
Re: [ewg] ibdiagpath broken with TCL 8.5
.org
>> Subject: Re: [ewg] Patch breaks OFED 1.5.3: [PATCH] ibdiagpath:
>> Properly index VlArbTable during QoS test
>>
>> YK,
>>
>> I just finished running an RC4 build on Redhat 6. I didn't get the same
>> error - but ibdiagpath still failed:
>>
>> [root@ifs004 1]# ibdiagpath -l 0x1,0x2
>> Loading IBDIAGPATH from: /usr/lib64/ibdiagpath1.5.6
>> -W- Topology file is not specified.
>> Reports regarding cluster links will use direct routes.
>> Loading IBDM from: /usr/lib64/ibdm1.5.6
>> -I- Using port 1 as the local port.
>>
>> -I---
>> -I- Traversing the path from local to source
>> -I---
>>
>> -I---
>> -I- Traversing the path from source to destination
>> -I---
>> -I- From: lid=0x0001 guid=0x00117578aca6 dev=29474 ifs004/P1
>> -I- To: lid=0x0003 guid=0x00066a01e5000108 dev=29472 Port=8
>>
>> -I- From: lid=0x0003 guid=0x00066a01e5000108 dev=29472 Port=8
>> -I- To: lid=0x0001 guid=0x00117578aca6 dev=29474 ifs004/P1
>>
>> can't read "PATH(1)": no such element in array
>> [root@ifs004 1]#
>>
>>
>> The problem appears to be occurring in this code fragment:
>>
>> if {[info exists NODE]} {
>> for {set i 0} {$i< [llength [array names NODE
>> *,PortGUID]]} {incr i} {
>> set portGuid $NODE($i,PortGUID)
>> set nodeGuid $G(data:NodeGuid.$portGuid)
>> if {$i % 2} {
>> set portNum $NODE($i,EntryPort)
>> } else {
>> set portNum [lindex [split $PATH([expr $i + 1]) ,]
>> end]<< -- Bug here. Line 2381, ibdebug_if.tcl
>> }
>> lappend CSV_ERRORS
>> $CSV_scope,$nodeGuid,$portGuid,$portNum,$desc,$msgBody,$CSV_severity,$e
>> xid,$err_type
>> }
>> } else {
>> lappend CSV_ERRORS
>> $CSV_scope,$nodeGuid,$portGuid,$portNum,$desc,$msgBody,$CSV_severity,$e
>> xid,$err_type
>> }
>> }
>>
>> I don't know if it matters, but I'm testing with a one-port HCA. I
>> added a puts in the offending code and got this:
>>
>> MHEINZ: i = 0. PATH(0) = 1
>> can't read "PATH(1)": no such element in array
>>
>> Please let me know if there are any tests I can run for you.
>>
>> -Original Message-
>> From: Mike Heinz
>> Sent: Monday, February 21, 2011 10:40 AM
>> To: 'klit...@dev.mellanox.co.il'; John Jolly
>> Cc: ewg@lists.openfabrics.org; Linux RDMA; Todd Rimmer; Eli Dorfman
>> (Voltaire)
>> Subject: RE: Patch breaks OFED 1.5.3: [ewg] [PATCH] ibdiagpath:
>> Properly index VlArbTable during QoS test
>>
>> Yevgeny,
>>
>> It did occur to me that this is a version issue; I tested with TCL 8.4,
>> which is the version included in RHEL5 and SLES10. The newest version
>> appears to be 8.5, skimming through the release notes I didn't see
>> anything about languages changes, but if it's working for you then
>> obviously the language has been changed.
>>
>> The thing is, I also noticed that John's original complaint - about an
>> extra item in the array - did not seem to be true on the RHEL 5.x boxes
>> I tried, which is why I suggested that the entire change should be
>> rolled back.
>>
>> I'm building RC4 on a Red Hat 6 box now, I'll see if it makes a
>> difference.
>>
>> -Original Message-
>> From: Yevgeny Kliteynik [mailto:klit...@dev.mellanox.co.il]
>> Sent: Sunday, February 20, 2011 9:05 AM
>> To: Mike Heinz; John Jolly
>> Cc: ewg@lists.openfabrics.org; Linux RDMA; Todd Rimmer; Eli Dorfman
>> (Voltaire)
>> Subject: Re: Patch breaks OFED 1.5.3: [ewg] [PATCH] ibdiagpath:
>> Properly index VlArbTable during QoS test
>>
>> Mike,
>>
>> This looks like a different tcl versions/implementation issue.
>>
>> I certainly can replace "$i+1" with "[expr $i+1]", but I'm not
>> sure about reverting the patch.
>>
>> John,
>>
>> What tcl version have you used?
>>
>> -- YK
>>
>>
>>
>> On 07-Feb-11 6:44 PM, Mike Heinz wrote:
>>> The version of ibdiagpath included with OFED 1.5.3-rc3 contains
>> syntax errors which prevent it from executing o
Re: [ewg] Patch breaks OFED 1.5.3: [PATCH] ibdiagpath: Properly index VlArbTable during QoS test
Mike, This looks like a different tcl versions/implementation issue. I certainly can replace "$i+1" with "[expr $i+1]", but I'm not sure about reverting the patch. John, What tcl version have you used? -- YK On 07-Feb-11 6:44 PM, Mike Heinz wrote: > The version of ibdiagpath included with OFED 1.5.3-rc3 contains syntax > errors which prevent it from executing on the systems I've tested (using TCL > 8.4). Attempts to use ibdiagpath fail with an error message: > >> -I--- >> -I- QoS on Path Check >> -I--- >> bad index "0+1": must be integer or end?-integer? > > After doing some research and debugging, I traced the problem to a patch > applied back in October: > > commit f3cf1f7c15ca24598fdf68b9ba71788b386b2f14 > Author: John Jolly > Date: Wed Oct 6 17:29:48 2010 +0200 > > ibdiagpath: Properly index VlArbTable during QoS test > > Description: ibdiagpath: Properly index VlArbTable during QoS test > Symptom: Error 'invalid bareword "vl_entry"' during "QoS on > Path Check" > Problem: The 'dump' command within the smVlArbTableMad command > appends '-vl_entry' to the beginning of the array. > The ibdebug.tcl script does not properly handle this > extra element at the beginning of the array. > Solution:Offset the index value by one when referencing the > array. > > Signed-off-by: John Jolly > Signed-off-by: Yevgeny Kliteynik > > Unfortunately, this patch isn't valid TCL code (at least not in TCL 8.4) and > does not appear to be needed at all. > > For example: > >> set entry [lindex $values $i+1] > > Is not syntactically correct TCL. In order for it to be correct it would > have to be > >> set entry [lindex $values [expr $i+1]] > > However, the patch does not appear to be needed at all. Reverting the patch, > allows ibdiagpath to complete successfully: > >> -I--- >> -I- QoS on Path Check >> -I--- >> -W- Blocked VLs:3 4 5 at node:homer lid=0x0002 guid=0x00066a00a000707f >> dev=25208> port:1 >> -W- SLs:3 4 5 6 7 8 9 10 11 12 13 14 15 are blocked due to VLArb node:homer >> lid=0x0002 guid=0x00066a00a000707f dev=25208 in-port:0 out-port:1 >> -W- Blocked VLs:3 4 5 at node: lid=0x0001 guid=0x00066a00d9000275 dev=47396 >> port:21 >> -W- SLs:3 4 5 6 7 8 9 10 11 12 13 14 15 mapped to VL> 5 at node: lid=0x0001 >> guid=0x00066a00d9000275 dev=47396 in-port:14 out-port:21 >> -I- The following SLs can be used:0 1 2 > > This message and any attached documents contain information from QLogic > Corporation or its wholly-owned subsidiaries that may be confidential. If you > are not the intended recipient, you may not read, copy, distribute, or use > this information. If you have received this transmission in error, please > notify the sender immediately by reply e-mail and then delete this message. > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] ibdiagpath: Properly index VlArbTable during QoS test
On 14-Sep-10 5:34 PM, John Jolly wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Description: ibdiagpath: Properly index VlArbTable during QoS test > Symptom: Error 'invalid bareword "vl_entry"' during "QoS on > Path Check" > Problem: The 'dump' command within the smVlArbTableMad command > appends '-vl_entry' to the beginning of the array. > The ibdebug.tcl script does not properly handle this > extra element at the beginning of the array. > Solution:Offset the index value by one when referencing the > array. > Problem-ID: 629166 > - --- Thanks, applied. -- YK ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] OFED 1.5.2: libibumad.so version bump
Hi all, In order to support RoCEE, a while ago I've added a new field to umad, thus introduced an ABI change. There already was a discussion on the linux-rdma list, but due to the proximity of the upcoming OFED 1.5.2 release these concerns were raised again. So my question is, other that *general* concerns about changing ABI, is anybody aware of the *actual* problem that will be caused by this? Any customer/3rd party solution that would be affected by this? -- Yevgeny ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Allowing ib dignostics to be run without being logged in as root.
Hi Woody, On 31-May-10 2:43 AM, Sasha Khapyorsky wrote: > Hi Woody, > > On 13:51 Tue 25 May , Woodruff, Robert J wrote: >> >> Some people were asking me if it would be possible to >> allow some of the IB diagnostic tools to be run without >> requiring being logged in as root. Would there be >> any problem in changing the installation to set their >> permissions to setuid root to allow this, i.e., >> >> chmod +s /usr/sbin/ibnetdiscover >> chmod +s /usr/sbin/ibaddr >> chmod +s /usr/sbin/smpquery >> chmod +s /usr/sbin/perfquery > > As many others I would also suggest to not make it (at least in default > installation). > > However you can try to run diagnostic tools as non-root user by doing > follow: > > 1. create some dedicated group, let's say 'umad'. > 2. add dedicated users to be a members of this group > 3. chown root:umad /dev/infiniband/umad* > 4. chmod 0660 /dev/infiniband/umad* > 5. update ib related udev rules file to match above > > This is how device access is granted to users normally. No need to mess with users/groups/owners. Udev configuration rules are in the following directory: /etc/udev/rules.d Infiniband-related rules are here: /etc/udev/rules.d/90-ib.rules $> cat /etc/udev/rules.d/90-ib.rules KERNEL=="umad*", NAME="infiniband/%k" ... You need to allow other users to get access to "umad*" devices. Don't modify the 90-ib.rules. Instead add a new file, something like 80-ib-umad.rules. The number in the beginning of the file (80) should be lower than the number in the file with the rule that you want to override (90): $> cat /etc/udev/rules.d/80-ib-umad.rules KERNEL=="umad*", NAME="infiniband/%k", MODE="0666" Restart the driver and you're done. -- Yevgeny > Sasha > ___ > ewg mailing list > ewg@lists.openfabrics.org > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg > ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [ANNOUNCE] Yevgeny K is taking the maintenance of the ibutils package
Hal, Hal Rosenstock wrote: Are there any other outstanding ibutils patches? Not AFAIK. Have the changes been pushed to the server ? Thanks. Yes, everything is in main trunk. -- Yevgeny ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [ANNOUNCE] Yevgeny K is taking the maintenance of the ibutils package
Hi Hal, Hal Rosenstock wrote: On Thu, Mar 19, 2009 at 8:12 AM, Oren Kladnitsky wrote: Hi. Yevgeny Kliteynik is taking the maintenance of the ibutils package from me. Will he be picking up the outstanding ibutils patches or do they need to be resubmitted ? Are there any other outstanding ibutils patches? -- Yevgeny -- Hal Ibutils git: git://git.openfabrics.org/~kliteyn/ibutils.git Thanks, Oren ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] RE: What is the branch that should be used formanagement packagefor OFED 1.4.1?
Hi Sasha, 1 is rare, that's true, but it may happen in any single switch fabric, such as some evaluation fabric (the last place you want to see bugs). 3 is limited to cache, but it's completing num. 2. 4 and 6 are logging issues (debugging issues), so we can leave them aside (although the fixes are very "local"). 5 jumps right at you when you run opensm with -Q. It doesn't break anything, but from a user perspective it's not minor at all. And the last - the new bug #1515. This is a serious bug, but we can discuss this bug severity (as well as the fix) on the openib list. -- Yevgeny > -Original Message- > From: Sasha Khapyorsky [mailto:sas...@voltaire.com] > > Hi Tziporet, > > On 17:05 Tue 17 Feb , Tziporet Koren wrote: > > Yevgeny Kliteynik wrote: > >> Hi Sasha, > >> > >> Below is the list of the OpenSM commits that should go > into OFED 1.4.1: > >> > >> 1. Commit aa25fcba61e75ac94af2b950c200cdde433f110c > >>Don't clear sw->need_update if port 0 is active. > >>In a single switch subnet, after a fast switch reset, OpenSM > >>doesn't configure LFT of the switch and the routing is lost. > >>Bug #1507. > >> > >> 2. Commit 595f2e30026f9ec85674e6d70661d26de6f77a6b > >>Update LFTs when entering master state > >>Bug #1469. > >> > >> 3. Commit b44c398e7363e9c9605e9ee1d5893f872ef41feb > >>Invalidate routing cache when entering master state > >>Bug #1508 > >> > >> 4. Commit 22da81f8cd432195f6c78cfe5f508f04b081aef7 > >>Fix full topology dump in ftree routing. > >>Topology dump was missing all the leaf switches > >>Bug #1509 > >> > >> 5. Commit c07d245651035cc7ba3b89ac0e81d54bff829f4d > >>Don't complain about invalid QoS options when its > >>default values are used. > >>Bug #1451. > >> > >> 6. Commit 72a2fa241dffacc2eea3c2b0c131f8bcb4792162 > >>Dump SA MAD before sending it, not after. > >>Dumping of the SA MAD was done after the MAD was sent > >>and returned to the pool, resulting in garbage in > >>the OpenSM log. > >>Bug #1510. > >> > >> > > > > Sasha > > Please open the branch and include the above pathces. > > We also wish the new bug fixed (#1515) > > In order to minimize amount of changes which should go to dot > release I would suggest to review the list above - 4-6 are > minor IMHO, 1 is rear (although the fix is safe), 3 is > limited by cache use. > > Sasha > ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: What is the branch that should be used for management packagefor OFED 1.4.1?
Hi Sasha, Below is the list of the OpenSM commits that should go into OFED 1.4.1: 1. Commit aa25fcba61e75ac94af2b950c200cdde433f110c Don't clear sw->need_update if port 0 is active. In a single switch subnet, after a fast switch reset, OpenSM doesn't configure LFT of the switch and the routing is lost. Bug #1507. 2. Commit 595f2e30026f9ec85674e6d70661d26de6f77a6b Update LFTs when entering master state Bug #1469. 3. Commit b44c398e7363e9c9605e9ee1d5893f872ef41feb Invalidate routing cache when entering master state Bug #1508 4. Commit 22da81f8cd432195f6c78cfe5f508f04b081aef7 Fix full topology dump in ftree routing. Topology dump was missing all the leaf switches Bug #1509 5. Commit c07d245651035cc7ba3b89ac0e81d54bff829f4d Don't complain about invalid QoS options when its default values are used. Bug #1451. 6. Commit 72a2fa241dffacc2eea3c2b0c131f8bcb4792162 Dump SA MAD before sending it, not after. Dumping of the SA MAD was done after the MAD was sent and returned to the pool, resulting in garbage in the OpenSM log. Bug #1510. Anything I missed? Regards, Yevgeny Kliteynik Mellanox Technologies LTD Tel: +972-4-909-7200 ext: 394 Fax: +972-4-959-3245 P.O. Box 586 Yokneam 20692 ISRAEL > -Original Message- > From: Sasha Khapyorsky [mailto:sas...@voltaire.com] > Sent: Sunday, February 08, 2009 18:19 > To: Tziporet Koren > Cc: ewg@lists.openfabrics.org; Yevgeny Kliteynik > Subject: Re: What is the branch that should be used for > management packagefor OFED 1.4.1? > > Hi Tziporet, > > On 17:51 Sun 08 Feb , Tziporet Koren wrote: > > As you know we are going for OFED 1.4.1 release. > > What should be the branch to use for this release. > > This branch should start from the sources in 1.4 and include only > > critical bug fixes. > > opensm-3.2 > > > Also - what is the list of bugs that you think should be > included in > > the management package in 1.4.1 > > If there are no major complains about OpenSM in OFED-1.4 then > we probably could not care. > > Sasha > ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] RE: OFED meeting agenda for today (Oct 22)
Or, > -Original Message- > From: Tziporet Koren [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 26, 2008 14:31 > To: Or Gerlitz > Cc: Woodruff, Robert J; ewg@lists.openfabrics.org; Yevgeny Kliteynik > Subject: Re: [ewg] RE: OFED meeting agenda for today (Oct 22) > > Or Gerlitz wrote: > > > > slide 11 (1.4 features) says > > > > "RDS - GA with RDMA API" - wrong, RDS patches are now on > hold for 1.4 > > such that 1.4.1 is a must just in that sense > GA with RDMA API is already done over IB RDS patches on hold > are those that supports iWARP. > > > > "Congestion Control in ibutils" - can someone elaborate what is the > > exact feature? > This is part of ibis and work over ConnectX - You can ask > Yevgeny K for details ibis now can send/receive Congestion Control MADs, which allows us to configure and monitor Congestion Control mechanism on the devices that support it (ConnectX and InfiniScale IV) -- Yevgeny > > "VPI support: Eth and IB for ConnectX" - what is VPI and > how it is used? > This was presented already at Sonoma (look at my presentation > on the web), and was part of the plan all the time (look at > http://www.openfabrics.org/txt/woody/roadmap.txt) > The name was Multi-Protocol before and VPI (Virtual Protocol > Interconnect) now > > I understand that the mlx4_en driver was added to the release. > This is the way the MP is implemented, and its just one more > module for the mlx4_core. and Roland is the Linux maintainer. > > Tziporet > ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] Re: [ewg] List of libraries in OFED
Sasha Khapyorsky wrote: Hi Oren, On 13:31 Wed 09 Jul , Oren Kladnitsky wrote: No. Ibutils use opensm libvendor for mad sending interface. Right, it is not used directly. But it is used in LDFLAGS (due to libosmvendor -> libibumad -> libibcommon dependency): Right, but there's no reason to leave it as "public". libibumad is public, libibcommon isn't -- Yevgeny config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" ibis/config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" ibmgtsim/config/osm.m4: OSM_LDFLAGS="$OSM_LDFLAGS -lopensm -losmvendor -losmcomp -libumad -libcommon" Sasha ___ general mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: Please make sure your document is updated for OFED 1.3
The version is inside the opensm_release_notes.txt file: @@ -1,4 +1,4 @@ -OpenSM Release Notes 3.1.9 +OpenSM Release Notes 3.1.10 = Version: OpenFabrics Enterprise Distribution (OFED) 1.3 @@ -11,7 +11,7 @@ Date:February 2008 This document describes the contents of the OpenSM OFED 1.3 release. OpenSM is an InfiniBand compliant Subnet Manager and Administration, and runs on top of OpenIB. The OpenSM version for this release -is openib-3.1.9 +is openib-3.1.10 This document includes the following sections: 1 This Overview section (describing new features and software -- Perhaps it would be a good idea to remove the version from the text? Regards, Yevgeny Kliteynik Mellanox Technologies LTD Tel: +972-4-909-7200 ext: 394 Fax: +972-4-959-3245 P.O. Box 586 Yokneam 20692 ISRAEL -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 3:58 AM To: Yevgeny Kliteynik Cc: Tziporet Koren; ewg@lists.openfabrics.org; Sean Hefty; Davis, Arlin R; Jeremy Brown; Pavel Shamis; Jeff Squyres (jsquyres); Vu Pham; Oren Kladnitsky; Oren Meron; Eli Cohen; Olaf Kirch; Ira Weiny; Moni Shoua; Jim Mott; Ralph Campbell; Jonathan L. Perkins; Johann George; Jack Morgenstein; Vladimir Sokolovsky; Ishai Rabinovitz; Hoang-Nam Nguyen; Glenn Streiff Subject: Re: Please make sure your document is updated for OFED 1.3 On 00:02 Tue 26 Feb , Yevgeny Kliteynik wrote: > > opensm_release_notes.txt - OpenSM version should be 3.1.10. > If you prefer, I can provide a patch. The content is same. Under OFED docs it is w/out version prefix... Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] RE: Please make sure your document is updated for OFED 1.3
Tziporet, opensm_release_notes.txt - OpenSM version should be 3.1.10. If you prefer, I can provide a patch. Regards, Yevgeny Kliteynik Mellanox Technologies LTD Tel: +972-4-909-7200 ext: 394 Fax: +972-4-959-3245 P.O. Box 586 Yokneam 20692 ISRAEL -Original Message- From: Tziporet Koren Sent: Monday, February 25, 2008 6:03 PM To: ewg@lists.openfabrics.org Cc: Sean Hefty; Davis, Arlin R; Jeremy Brown; Sasha Khapyorsky; Pavel Shamis; Jeff Squyres (jsquyres); Vu Pham; Oren Kladnitsky; Oren Meron; Eli Cohen; Olaf Kirch; Ira Weiny; Moni Shoua; Jim Mott; Ralph Campbell; Jonathan L. Perkins; Johann George; Jack Morgenstein; Yevgeny Kliteynik; Vladimir Sokolovsky; Ishai Rabinovitz; Hoang-Nam Nguyen; Glenn Streiff Subject: Please make sure your document is updated for OFED 1.3 Hi Attached all OFED 1.3 documents Each owner - please make sure the component you own is updated I did my best merging all changes I got but mistakes always happened :-( Thanks Tziporet ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Compile error in latest daily build
Hal Rosenstock wrote: On Thu, 2007-10-25 at 12:13 +0200, Yevgeny Kliteynik wrote: Done. Was this fixed in the ibutils git repo too ? Yes, but the current ibutils maintainer is Oren Kladnitsky, so you need to pull ibutils from here: git://staging.openfabrics.org/~orenk/ibutils --Yevgeny -- Hal -- Yevgeny Hal Rosenstock wrote: On Wed, 2007-10-24 at 13:08 -0700, Woodruff, Robert J wrote: I ran into this compile error in today's daily build, not sure who this should be assigned to... Running rpm -iv /root/OFED-1.3-20071024-0645/RPMS/redhat-release-4AS-5.5/sdpnetstat-1.60 -0.1.ofed20070909.x86_64.rpm Build srptools RPM ibis_wrap.c: In function `_wrap_sacClassPortInfo_resp_time_val_set': ibis_wrap.c:22491: error: structure has no member named `resp_time_val' ibis_wrap.c:22491: warning: left-hand operand of comma expression has no effect ibis_wrap.c: In function `_wrap_sacClassPortInfo_resp_time_val_get': ibis_wrap.c:22543: error: structure has no member named `resp_time_val' make[3]: *** [ibis_wrap.lo] Error 1 make[3]: Leaving directory `/var/tmp/OFED_topdir/BUILD/ibutils-1.2/ibis/src' The need to update ibutils was identified by Sasha the other day but I guess this wasn't done yet. I'm not sure whether Eitan is around. Maybe Yevgeny can do this. -- Hal ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Compile error in latest daily build
Done. -- Yevgeny Hal Rosenstock wrote: On Wed, 2007-10-24 at 13:08 -0700, Woodruff, Robert J wrote: I ran into this compile error in today's daily build, not sure who this should be assigned to... Running rpm -iv /root/OFED-1.3-20071024-0645/RPMS/redhat-release-4AS-5.5/sdpnetstat-1.60 -0.1.ofed20070909.x86_64.rpm Build srptools RPM ibis_wrap.c: In function `_wrap_sacClassPortInfo_resp_time_val_set': ibis_wrap.c:22491: error: structure has no member named `resp_time_val' ibis_wrap.c:22491: warning: left-hand operand of comma expression has no effect ibis_wrap.c: In function `_wrap_sacClassPortInfo_resp_time_val_get': ibis_wrap.c:22543: error: structure has no member named `resp_time_val' make[3]: *** [ibis_wrap.lo] Error 1 make[3]: Leaving directory `/var/tmp/OFED_topdir/BUILD/ibutils-1.2/ibis/src' The need to update ibutils was identified by Sasha the other day but I guess this wasn't done yet. I'm not sure whether Eitan is around. Maybe Yevgeny can do this. -- Hal ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] OFED Aug 13 meeting summary
Hi Sasha, I do plan to do it, but it won't be in ofed 1.3. Regards, Yevgeny Kliteynik Mellanox Technologies LTD Tel: +972-4-909-7200 ext: 394 Fax: +972-4-959-3245 P.O. Box 586 Yokneam 20692 ISRAEL -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 7:19 AM To: Yevgeny Kliteynik Cc: Tziporet Koren; EWG Subject: Re: [ewg] OFED Aug 13 meeting summary Hi Yevgeny, On 19:57 Mon 13 Aug , Yevgeny Kliteynik wrote: > Hi Sasha, > > Here's QoS in OpenSM status update: > > Policy file parser: 100% > Adding QoS fields to PathRecord: 100% > Matching PathRecord request to QoS Match Rules: 100% > PathRecord selection according to QoS level: 50% > Adding QoS fields to MultiPathRecord: 40% > Matching MultiPathRecord request to QoS Match Rules: 0% > MultiPathRecord selection according to QoS level: 0% Thanks for the update. Please feel free to post the patches for sub-components which was done up to now, so we will have more time for reviewing. Of course it is up to readiness. Also are you planing to integrate the "policy" db with low level QoS setup (SL2VL, VLArb)? Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
RE: [ewg] OFED Aug 13 meeting summary
Hi Sasha, Here's QoS in OpenSM status update: Policy file parser: 100% Adding QoS fields to PathRecord: 100% Matching PathRecord request to QoS Match Rules: 100% PathRecord selection according to QoS level: 50% Adding QoS fields to MultiPathRecord: 40% Matching MultiPathRecord request to QoS Match Rules: 0% MultiPathRecord selection according to QoS level: 0% Regards, Yevgeny Kliteynik Mellanox Technologies LTD Tel: +972-4-909-7200 ext: 394 Fax: +972-4-959-3245 P.O. Box 586 Yokneam 20692 ISRAEL -Original Message- From: Sasha Khapyorsky [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 7:45 PM To: Tziporet Koren Cc: EWG; Yevgeny Kliteynik Subject: Re: [ewg] OFED Aug 13 meeting summary Hi Tziporet! On 19:37 Mon 13 Aug , Tziporet Koren wrote: > > 3. Status update - from all > Ofed 1.3: > Vnic - going to be ready next week > OSM - performance mgr development should be ready first week of Sep. Could I ask about the status of QoS development works for OpenSM? Sasha ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
