Caitlin Bestler wrote:
The overbloated union also works, but it has its own pains.
I have no problem changing it back to the union approach on
either the forward and/or reverse path, if that is the consensus.
Personally, I think using a different style for forware and
reverse would be more confusing, that using a cast in response
to an opcode is no more inherently suspect than selecting a
union sub-variant in response to an opcode and that many or
most applications will need to support multiple work completion
sub-types anyway.
(Note that I'm just using rdma_poll_cq() as an example. I didn't go into
the other calls in as much detail.)
I'm not suggesting the use of unions everywhere. I think that there's a
problem defining a 256 byte structure that is likely to be declared on the
stack so an application can call poll_cq in a transport independent fashion.
Reading a field in a structure and then casting the structure to a parent
structure does not require any specific field layout. Taking an input
parameter to a function and casting it to a parent structure does. For
example, redefine struct ib_wc and move the common field to the end of the
structure.
I don't have an issue with how post_send/post_recv would work; just pointing
out that type checking is lost, which can lead to accessing invalid memory.
For example, an application cannot just define struct rdma_wc and then
call rdma_poll_cq() and have it work. This would result in stack
corruption, yet matches the defined API.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
