On 04/16/2015 08:07 PM, Steve Wise wrote:
-Original Message-
From: Jason Gunthorpe [mailto:jguntho...@obsidianresearch.com]
Sent: Thursday, April 16, 2015 11:43 AM
To: Michael Wang
Cc: Roland Dreier; Sean Hefty; Hal Rosenstock; linux-rdma@vger.kernel.org;
Hi, Roland
Thanks for the comment :-)
On 04/16/2015 07:02 PM, Roland Dreier wrote:
On Thu, Apr 16, 2015 at 9:44 AM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
We can give client-add() callback a return value and make
ib_register_device() return -ENOMEM when it failed, just
On 04/16/2015 07:05 PM, Weiny, Ira wrote:
On Wed, Apr 15, 2015 at 09:58:18AM +0200, Michael Wang wrote:
We can give client-add() callback a return value and make
ib_register_device() return -ENOMEM when it failed, just wondering why
we don't do this at first, any special reason?
No idea,
On 04/16/2015 07:30 PM, Hefty, Sean wrote:
To be confirmed:
PORT ASSIGNED
rdma_init_qp_attr Y
rdma_destroy_id unknown
cma_listen_on_dev N
cma_bind_loopback N
Bind loopback will attach to a port, but the id does not
On 04/16/2015 05:58 PM, Jason Gunthorpe wrote:
On Thu, Apr 16, 2015 at 10:08:10AM +0200, Michael Wang wrote:
Use raw management helpers to reform cm related part in IB-core cma/ucm.
These checks focus on the device cm type rather than the port capability,
directly pass port 1 works
On 04/16/2015 07:21 PM, Tom Talpey wrote:
On 4/16/2015 11:22 AM, Michael Wang wrote:
On 04/16/2015 04:31 PM, Hefty, Sean wrote:
This is equivalent to today where the checks are per node rather than
per port.
Should all checks here be port 1 based or only certain ones like listen
? For
- get_dma_mr() was using ~0UL which is should be ~0ULL. This causes the
DMA MR to get setup incorrectly in hardware.
- wr_log_show() needed a 64b divide function div64_u64() instead of
doing
division directly.
- fixed warnings about recasting a pointer to a u64
Signed-off-by: Steve Wise
For T5, we must not use the kdb/kgts registers, in order avoid db drops
under extreme loads.
Signed-off-by: Steve Wise sw...@opengridcomputing.com
Signed-off-by: Hariprasad Shenai haripra...@chelsio.com
---
drivers/infiniband/hw/cxgb4/cq.c | 15 +++
drivers/infiniband/hw/cxgb4/t4.h |
Currently the iw_cxgb4 implementation requires the qp and cq qid densities
to match as well as the qp and cq id ranges. So fail a device open if
the device configuration doesn't meet the requirements.
The reason for these restictions has to do with the fact that IQ qid X
has a UGTS register in
Hi,
This patch series changes a macro definition to be consistent with other
register macro defines. Fixes for 32b platform, use BAR2 register for kernel
mode CQ's and enforces qp/cq id requirements.
The patches series is created against github for-4.1 branch.
And includes patches on iw_cxgb4
Cleanup macros and register defines for consistency
Signed-off-by: Hariprasad Shenai haripra...@chelsio.com
---
drivers/infiniband/hw/cxgb4/cm.c | 4 ++--
drivers/infiniband/hw/cxgb4/t4fw_ri_api.h | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git
On 04/16/2015 06:43 PM, Jason Gunthorpe wrote:
On Tue, Apr 14, 2015 at 11:13:03AM +0200, Michael Wang wrote:
I would be very happy to see a patch that adds cap_ib_smi to the
current tree and states 'This patch is tested to have no change on the
binary compilation results'
There are too
On Fri, Apr 17, 2015 at 1:03 AM, Doug Ledford dledf...@redhat.com wrote:
On Thu, 2015-04-16 at 15:37 -0600, Jason Gunthorpe wrote:
On Fri, Apr 17, 2015 at 12:26:47AM +0300, Or Gerlitz wrote:
On Thu, Apr 16, 2015 at 11:13 PM, Jason Gunthorpe
jguntho...@obsidianresearch.com wrote:
On Wed,
On Thu, 16 Apr 2015, Or Gerlitz wrote:
I still didn't hear clear response from Roland confirming that he's gonna send
pull request with these bits.
Roland, please confirm that you are taking this and if not, Dave can you help
us here? copied linux-rdma.
Or, I think the best way forwards is
On Fri, Apr 17, 2015 at 8:03 PM, Roland Dreier rol...@kernel.org wrote:
On Fri, Apr 17, 2015 at 4:15 AM, Or Gerlitz gerlitz...@gmail.com wrote:
Seems like Roland isn't around to carry the rdma pull request for 4.1 ...
Why do you ignore my emails (I see no reply to
On Apr 11, 2015 12:28 PM, Or Gerlitz gerlitz...@gmail.com wrote:
If taking off the maintainer hat would get you some free/spare cycles,
maybe you could resume posting in the digitalvampire blog and/or
participate in the upstreamming of soft-RoCE driver? some folks here
are working on this, so
On Fri, 2015-04-17 at 20:35 +0530, Hariprasad Shenai wrote:
- get_dma_mr() was using ~0UL which is should be ~0ULL. This causes the
DMA MR to get setup incorrectly in hardware.
- wr_log_show() needed a 64b divide function div64_u64() instead of
doing
division directly.
- fixed
On Fri, Apr 17, 2015 at 4:15 AM, Or Gerlitz gerlitz...@gmail.com wrote:
Seems like Roland isn't around to carry the rdma pull request for 4.1 ...
Why do you ignore my emails (I see no reply to
http://www.spinics.net/lists/linux-rdma/msg24194.html) and jump to
this conclusion?
I will send a pull
From: Erez Shitrit ere...@mellanox.com
Date: Thu, 16 Apr 2015 16:34:34 +0300
Currently, iflink of the parent interface was always accessed, even
when interface didn't have a parent and hence we crashed there.
Handle the interface types properly: for a child interface, return
the ifindex of
This patch series was first submitted for inclusion upstream on 10/13/14, but
it seems to have slipped through the cracks.
Add functionality to allow the port mapper to provide to its client
the actual (non-mapped) ip/tcp address information of the remote connecting peer
1) Adding
From: Steve Wise sw...@opengridcomputing.com
When iWARP port mapping is being done, the passive side of a connection
only knows the mapped address/port of the peer. So now query the IWPM
to get the actual address/port of the peer.
Also setup the passive side endpoint to correctly display the
Get the actual (non-mapped) ip/tcp address of the remote connecting peer
from the port mapper and report the address info to the user space application
at the time of connection establishment
Signed-off-by: Tatyana Nikolova tatyana.e.nikol...@intel.com
---
drivers/infiniband/hw/nes/nes.c|
22 matches
Mail list logo
