On Mon, Oct 31, 2011 at 9:38 PM, Roland Dreier rol...@kernel.org wrote:
Sorry for the late review here
Oh yes... BTW this is patch 4/5, I don't see patches 1,2,3 on your for-next
tree/branch @ kernel.org, have you accepted them?
Sorry for the late review here, but does it seem like the best
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
doc/current-routing.txt |2 +-
man/opensm.8.in |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/current-routing.txt b/doc/current-routing.txt
index f97bc3f..ae2c65f 100644
--- a/doc/current-routing.txt
Hi,
packet_life_time is 12 in sm.conf.
I'm debugging the polling process and see that ibv_poll_cq returns
error when mlx4_cqe-owner_sr_opcode gets MLX4_CQE_OPCODE_ERROR value
(in libmlx4, mlx4_poll_one). Where this value came from?
Thanks,
Vlad
On Mon, Oct 31, 2011 at 3:00 PM, Or Gerlitz
On 10/31/2011 4:12 PM, Ira Weiny wrote:
On Thu, 27 Oct 2011 12:41:53 -0700
Hal Rosenstock h...@dev.mellanox.co.il wrote:
On 10/6/2011 8:13 PM, Ira Weiny wrote:
Allow for the pre-creation of these groups on a partition by partition
basis.
This looks good to me and has been needed for
Just to clarify:
On 11/1/2011 9:25 AM, Vlad Weinbaum wrote:
packet_life_time is 12 in sm.conf.
OpenSM packet_life_time setting has nothing to do with this (but is used
for SwitchInfo:LifeTimeValue setting):
# The code of maximal time a packet can live in a switch
# The actual time is 4.096usec
My question is: will the mc-next contain the right value?
(since the compiler may cache the value of mc-next within that function and
not read the updated value from memory,
so if the mc_list will be changed by another thread, we may get bad results
...)
Access to the list is protected by a
On Tue, Nov 01, 2011 at 08:40:12AM +0200, Or Gerlitz wrote:
Today, e.g in some IBoE perf monitoring scripts we wrote, the
distinction is done by if (the ext counter directory exists) then go
and read the counters from there, else read from the non extended
counters directory. With the change
Hi Hal,
On 09:17 Tue 18 Oct , Hal Rosenstock wrote:
Signed-off-by: Yevgeny Kliteynik klit...@dev.mellanox.co.il
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
Hi Hal,
On 09:17 Tue 18 Oct , Hal Rosenstock wrote:
Signed-off-by: Jim Schutt jasc...@sandia.gov
Signed-off-by: Hal Rosenstock h...@mellanox.com
---
Applied, thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
Hi Hal,
On 12:55 Thu 27 Oct , Hal Rosenstock wrote:
Since PortInfo attribute is now IB_SMP_DATA_SIZE (64 bytes),
there is no remaining space at the end of the attribute as
it now fills the entire SMP data size.
Found-by: Leonid Keller leo...@mellanox.co.il
Signed-off-by: Hal
Hi Hal,
On 08:50 Wed 28 Sep , Hal Rosenstock wrote:
In dump_topology_node, FDR10 can be active regardless of whether
PortInfo:CapabilityMask.IsExtendedSpeeds is set or not
Prior to this, FDR10 was only indicated if IsExtendedSpeeds was not set
Signed-off-by: Hal Rosenstock
From: Roland Dreier rol...@kernel.org
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will get the main batch of changes for 3.2. One note: my tree is
based on 3.1-rc9, and I have some changes to drivers/net/mlx4, but in
your
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
Is there any reason to expose the 32 and 64 bit version of the same
counter? That seems needless. Emit the largest version available and
prepend 0's to fill out to the available width so that userspace can
know the counter size.
On Tue, Nov 01, 2011 at 07:23:52PM +0200, Or Gerlitz wrote:
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
Is there any reason to expose the 32 and 64 bit version of the same
counter? That seems needless. Emit the largest version available and
prepend 0's to fill out to the
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
Guys (Roland, Jason), I'm open to any comments, any time, for any
patch, but for a patch which was posted weeks ago it's pretty unfair
to have your comments coming only eight days after the merge window
has been opened, lets try to come
I don't see a problem with having a sysfs counter file being extended
to return a 64 bit number.. I think that is within the purvue of
acceptable changes. Shame the counter wasn't exported as hex though -
makes it harder to signal if it is 32 or 64 bit.
if I understand you right, we
On Mon, Oct 31, 2011 at 10:33 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Fri, 2011-10-21 at 18:57 +0200, Bart Van Assche wrote:
Register transport attributes after the attribute array has been
set up instead of before. The current code is racy because there
is no
On Tue, Nov 1, 2011 at 11:37 AM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
Whats the problem here? If a 64 bit counter is available then export
it as 64 bit otherwise keep exporting something smaller.
I agree zero padding non-hex numbers isn't ideal. Export as hex?
I agree that
On Tue, Nov 1, 2011 at 11:42 PM, Roland Dreier rol...@kernel.org wrote:
The least bad way forward does seem like it is probably
the separate new directory thing.
I agree
Or.
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
I don't mean the 32 bit counters are useless, I mean exposing PMA
counters that saturate and can be randomly reset by external agents
through sysfs is useless. You can't make any kind of data collection
based on such a system.
Ideally
On Tue, Nov 1, 2011 at 11:14 AM, Or Gerlitz or.gerl...@gmail.com wrote:
Guys (Roland, Jason), I'm open to any comments, any time, for any
patch, but for a patch which was posted weeks ago it's pretty unfair
to have your comments coming only eight days after the merge window
has been opened,
On Tue, Nov 01, 2011 at 02:42:33PM -0700, Roland Dreier wrote:
I agree that it definitely is more appealing, if we have a 64-bit
version of a counter, that we should just export that counter
where we used to export the 32-bit version.
I think this falls under the 'undocumented, beware' API
On Tue, Nov 01, 2011 at 11:46:08PM +0200, Or Gerlitz wrote:
In the same vien adding saturating but non-resettable PMA-esque
counters for IBoE seems pretty hackish to me.. Though I agree it is
not terribly relevant for 64 bit counters.
To put things in place, the IB stack PMA counters
On Tue, Nov 01, 2011 at 03:03:58PM -0700, Ira Weiny wrote:
And again, this is a useless interface in IB.
Why do you mean by this?
A counter that is randomly reset by an external IB performance manager
is not useful for collecting local statistical information.
A counter that saturates
On Tue, 1 Nov 2011 15:11:35 -0700
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
On Tue, Nov 01, 2011 at 03:03:58PM -0700, Ira Weiny wrote:
And again, this is a useless interface in IB.
Why do you mean by this?
A counter that is randomly reset by an external IB performance
On Tue, Nov 1, 2011 at 11:49 PM, Roland Dreier rol...@kernel.org wrote:
There's no obligation to merge something just because you posted it before
the merge window, and in fact Linus's complaint at the kernel summit is
always that sub-maintainers don't say no enough.
And let's be honest in
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
Why have a sysfs counter at all when you can just ask the PMA and get exactly
the
same data?
The HW/FW PMA agent isn't supported for IBoE only for IB, the
counters are for both
Or.
--
To unsubscribe from this list: send the line
On Tue, 1 Nov 2011 15:34:46 -0700
Or Gerlitz or.gerl...@gmail.com wrote:
Jason Gunthorpe jguntho...@obsidianresearch.com wrote:
Why have a sysfs counter at all when you can just ask the PMA and get
exactly the
same data?
The HW/FW PMA agent isn't supported for IBoE only for IB, the
Let's not get into fairness here... I'm trying to make progress on my backlog
but there are patches that for better or worse have been around for a year
or more.
Along these lines, is there any news on when patchwork might be available
again? I've been trying to help review some of the
Hi,
There is a new release of infiniband-diags.
Tarball available at:
http://www.openfabrics.org/downloads/management/infiniband-diags-1.5.11.tar.gz
(listed in http://www.openfabrics.org/downloads/management/latest.txt)
md5sum: 815b3550e906fa3452355fa619b073e0 infiniband-diags-1.5.11.tar.gz
30 matches
Mail list logo
