On 1/2/2012 7:34 PM, Hefty, Sean wrote:
this field is a -- union -- how would that work if more than one
extension is to be applied for a structure?
The fields at the end of the structure should only be accessed if the structure
is of the correct type. In this case, ext.xrc_recv is only
I'd like to better understand the allocated by the caller ... are more
difficult to deal with part of your response - for ibv_send_wr - if
the caller have set a new IBV_WR_NEW_FEATURE value for the wr type, they
surely aware to the new fields and actually the size of the structure
can change
1. for libibverbs some structures extended field is added at their end
saying Following fields only available if device supports extensionse.g
@@ -590,6 +634,13 @@ struct ibv_qp {
pthread_mutex_t mutex;
pthread_cond_t cond;
uint32_t
On Thu, Dec 29, 2011 at 3:43 PM, Or Gerlitz ogerl...@mellanox.com wrote:
5. what happens if we just want to enhance an -- existing -- function -
suppose we want to enhance ibv_post_send / ibv_poll_cq to support features
like LSO, checksum offload, masked atomic operations, fast memory remote
or call an existing function with some new enum value
5. what happens if we just want to enhance an -- existing -- function
- suppose we want to enhance ibv_post_send / ibv_poll_cq to support
features like LSO, checksum offload, masked atomic operations, fast
memory remote invalidate,
On Tuesday 02 August 2011 08:38, Jason Gunthorpe wrote:
The hope is once the infrastructure is in libibverbs there will not
be as much need to change libibverbs, just the apps and the drivers.
If I understand correctly, the various additions which would normally be made
to libibverbs
would
If I understand correctly, the various additions which would normally be made
to libibverbs
would then be made by third-party libraries which extend libibverbs to support
their additions.
It may help to read about extensions in opengl:
http://www.opengl.org/registry/doc/rules.html
Additions
On Tue, Aug 02, 2011 at 10:53:05AM +0300, Jack Morgenstein wrote:
These additions would include the new ibv_cmd_xxx functions
(the core functions reside in src/cmd.c), and new, additional, enum values of
the form IBV_USER_VERBS_CMD_, of which the core enum is in file
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 were
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.
I
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
11 matches
Mail list logo
