Hello, Roland.
I'm not sure if you received email about new QP type that I have sent to
linux-rdma list so I'm sending to you a links to related threads in mailing
list. It would be great if you give some comments about it.
Actually, it important to know if is the proposed name is accepted and
Acked-by: Steve Wise
David Rientjes wrote:
The alloc_skb() in various allocations are failable, so remove
__GFP_NOFAIL from their masks.
Cc: Roland Dreier
Signed-off-by: David Rientjes
---
drivers/infiniband/hw/cxgb4/cq.c |4 ++--
drivers/infiniband/hw/cxgb4/mem.c |2 +-
drivers/in
The alloc_skb() in various allocations are failable, so remove
__GFP_NOFAIL from their masks.
Cc: Roland Dreier
Signed-off-by: David Rientjes
---
drivers/infiniband/hw/cxgb4/cq.c |4 ++--
drivers/infiniband/hw/cxgb4/mem.c |2 +-
drivers/infiniband/hw/cxgb4/qp.c |6 +++---
3 files
My kernel selections are limited to which versions I can get a panfs
module for. The most recent kernel I see support for is a 2.6.31
variant from FC12. I could ask them for a custom port for a newer
mainline kernel but the turn-around will likely be several weeks.
I'll go ahead and ask for one I
Steve Wise wrote:
Jason Gunthorpe wrote:
On Tue, Jul 20, 2010 at 03:50:05PM -0500, Steve Wise wrote:
I think if RDMACM manages the dst and lets the devices access it then
all the existing netdev infrastructure for poking at a dst should be
available to the device?
Yes. But I'm not su
Jason Gunthorpe wrote:
On Tue, Jul 20, 2010 at 03:50:05PM -0500, Steve Wise wrote:
I think if RDMACM manages the dst and lets the devices access it then
all the existing netdev infrastructure for poking at a dst should be
available to the device?
Yes. But I'm not sure exactly how the
On Tue, Jul 20, 2010 at 03:50:05PM -0500, Steve Wise wrote:
>> I think if RDMACM manages the dst and lets the devices access it then
>> all the existing netdev infrastructure for poking at a dst should be
>> available to the device?
>
> Yes. But I'm not sure exactly how the logic I described previ
> I'm experimenting with an rdma_cm application to push data around
> between nodes on an ~1000 node cluster (CentOS-5.3 with 2.6.18-128.el5
> and OFED-1.4.2). Under heavy load, I'm seeing several nodes per day
> kernel panic due to a NULL pointer dereference. It may be that the
> in-kernel
> > Small correction needed regarding the multicast forwarding.
> > Since we are talking about IPv6 multicast groups, which
> translate to > 33:33:xx:xx:xx:xx MAC address, the router
> listener notification protocol > is going to be MLD and not
> IGMP. Still there are switches which support
Jason Gunthorpe wrote:
On Tue, Jul 20, 2010 at 02:20:21PM -0500, Steve Wise wrote:
I guess it should be using the oif from the cm_id?
Not sure exactly what is best here :|
So, looks like there is a larger cleanup here, if the RDMACM holds the
dst and has functions to freshen it/t
On Tue, Jul 20, 2010 at 02:20:21PM -0500, Steve Wise wrote:
> I guess it should be using the oif from the cm_id?
Not sure exactly what is best here :|
>> So, looks like there is a larger cleanup here, if the RDMACM holds the
>> dst and has functions to freshen it/track it then the iwarp driver
>
Do you think upgrading to OFED-1.5.1 would help at all?
-JE
On Mon, Jul 19, 2010 at 11:40 PM, Or Gerlitz wrote:
> Josh England wrote:
>>
>> It may be that the in-kernel field cm_id_priv has a NULL ->alt_av.port ,
>> causing the Oops, but I don't know for sure. Any ideas on how to debug
>> this?
Jason Gunthorpe wrote:
On Tue, Jul 20, 2010 at 01:12:17PM -0500, Steve Wise wrote:
The cxgb* drivers actually reference the neigh and dst structs until the
offload connection is gone. Also if the the offloaded connection has
problems transmitting (due to a L2 address change, for example)
On Tue, Jul 20, 2010 at 01:12:17PM -0500, Steve Wise wrote:
> The cxgb* drivers actually reference the neigh and dst structs until the
> offload connection is gone. Also if the the offloaded connection has
> problems transmitting (due to a L2 address change, for example), then
> the driver
Acked-by: Steve Wise
Or Gerlitz wrote:
fixed the following drivers/infiniband sparse pointed issues
CHECK drivers/infiniband/hw/cxgb3/iwch_cm.c
iwch_cm.c:140:5: warning: symbol 'iwch_l2t_send' was not declared. Should it be
static?
CHECK drivers/infiniband/hw/nes/nes_verbs.c
nes_verbs
Or Gerlitz wrote:
Jason Gunthorpe wrote:
It is a bit wider problem than just ND entries, changes in routing can
also alter the L2 address, so that needs to be tracked as well.
sure, when we did the address change work, see commit dd5bdff "RDMA/cma: Add RDMA_CM_EVENT_ADDR_CHANGE event"
On Tue, Jul 20, 2010 at 10:25:52AM +0300, Or Gerlitz wrote:
> > So.. I think to tackle this you need to start looking at how the
> > dst_entry structure works in netdev and apply the same idea to RDMA-CM
> > and reflect the changes in AH back to the QP owner.
>
> I can take a look (pointer would
On Mon, Jul 19, 2010 at 10:28:24PM -0700, Paul Grun wrote:
> This is incorrect. The intent of the text is that a verbs consumer deals
> ONLY in layer 3 addresses (GIDs). It doesn't make any sense to restrict the
> interpretation to mean 'LIDs', since LIDs are a NOP for RoCE.
>
> CA16-17: When
On Tue, 13 Jul 2010, Ralph Campbell wrote:
> Acked-by: Ralph Campbell
>
> On Mon, 2010-07-12 at 13:50 -0700, Joe Perches wrote:
> > Signed-off-by: Joe Perches
> > ---
> > drivers/infiniband/hw/ipath/ipath_file_ops.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff
> Subject: [PATCH for-2.6.36] ib: fix some sparse warnings
>
> fixed the following drivers/infiniband sparse pointed issues
>
> nes_verbs.c:1944:45: warning: Using plain integer as NULL pointer
> nes_verbs.c:1944:48: warning: Using plain integer as NULL pointer
> CHECK drivers/infiniband/hw/
fixed the following drivers/infiniband sparse pointed issues
CHECK drivers/infiniband/hw/cxgb3/iwch_cm.c
iwch_cm.c:140:5: warning: symbol 'iwch_l2t_send' was not declared. Should it be
static?
CHECK drivers/infiniband/hw/nes/nes_verbs.c
nes_verbs.c:1944:45: warning: Using plain integer as
Works!
[r...@dodly0 OMB-3.1.1]# mpiexec -ppn 1 -n 2 -env I_MPI_FABRICS dapl:dapl -env
I_MPI_DEBUG 5 -env I_MPI_CHECK_DAPL_PROVIDER_MISMATCH none -env DAPL_DBG_TYPE
0x -env DAPL_IB_PKEY 0x0280 -env DAPL_IB_SL 4 /tmp/osu_long
dodly0:5bc3: dapl_init: dbg_type=0x,dbg_dest=0x1
dodly0:5bc3: o
Jason Gunthorpe wrote:
> It is a bit wider problem than just ND entries, changes in routing can
> also alter the L2 address, so that needs to be tracked as well.
sure, when we did the address change work, see commit dd5bdff "RDMA/cma: Add
RDMA_CM_EVENT_ADDR_CHANGE event", the problem I wanted to
23 matches
Mail list logo
