> In fact, I'm not sure if it will fail loading because of unresolved
> references). Indeed, I am not sure that the app can run at all due
> to unresolved references.
The dlopen of mlx4 should fail due to unresolved references, so the
net effect will be that no apps cannot open the RDMA device in
From: Jay Sternberg
Add an example program to test XRC. The sample is derived from the SRQ example,
but greatly modified. To test xrc domains, the example allows multiple clients
running on a single system to connect to a server. The server creates one set
of
send/recv xrc qp's for every clie
The iw_cxgb4 module crashes at init time if the T4 card does not
support RDMA. So clean up the init logic to correctly deal with
non-RDMA cards.
- If any RDMA resources are not available, then fail the initializtion
logging an info message.
- Clean up properly on initialization failures.
Signed
RFC3270 mandates that iSCSI PDUs are padded to the closest integer
number of four byte words. Enhance the iser code to support that
on both the TX/RX flows.
Signed-off-by: Or Gerlitz
---
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index 8db00
The code that prepares the SG associated with SCSI command for FMR was
buggy for systems with DMA addresses that don't fit in unsigned long,
e.g under the 32-bit based XenServer dom0 sizeof(dma_addr_t) is eight.
Fix that by casting to unsigned long long a masking constant used by
the code. This re
> In fact, I'm not sure if it will fail loading because of unresolved
> references).
> Indeed, I am not sure that the app can run at all due to unresolved
> references.
I'm not sure what exactly we can do in the situation you described. I would
expect the app to see an unresolved reference.
>
> We do have unregister on finalization. But this code doesn't introduce any
> synchronization across processes on the same node, since kernel manages the
> receive qp. If the reference counter will be moved to app responsibility, it
> will enforce the app to mange the reference counter on app leve
On 08:36 Fri 29 Jul , Hal Rosenstock wrote:
>
> for proper comparison and selector operation
>
> Rate enum was never is ascending order of actual underlying rates
> but even worse with newly added extended link speeds.
>
> Signed-off-by: Hal Rosenstock
> ---
> Changes since v1:
> In find_or
>> Actually I think it is really not so good idea manage reference counter
>> across OOB communication.
>
> But this is exactly what the current API *requires* that users of XRC do!!!
> And I agree, it's not a good idea. :)
We do have unregister on finalization. But this code doesn't introduce
> Actually I think it is really not so good idea manage reference counter
> across OOB communication.
But this is exactly what the current API *requires* that users of XRC do!!!
And I agree, it's not a good idea. :)
> IMHO, I don't see a good reason to redefine existing API.
> I afraid, that su
On Thursday 16 June 2011 22:27, Hefty, Sean wrote:
> > Basically, I wasn't referring to such new verbs as vendor extensions,
> > but rather as new verbs we want to add at this and/or future points of
> > time which didn't exist at the time the IB stack and specifically its
> > kernel/user ABIs/APIs
11 matches
Mail list logo
