Some additional comments related to changes in the receive processing are below.
> static void ib_mad_recv_done_handler(struct ib_mad_port_private *port_priv,
> struct ib_wc *wc)
> {
> @@ -797,17 +876,10 @@
> - recv->header.recv_wc.mad_len = sizeof(struct ib_mad); /* Should this be based
> on wc->byte_len ? Also, RMPP !!! */
> + recv->header.recv_wc.mad_len = sizeof(struct ib_mad);
I believe that this is correct, to avoid including the GRH size. For RMPP, I expect
that the RMPP code will need to update the recv_wc.mad_len once all segments have been
assembled.
> - if (wc->wc_flags & IB_WC_GRH) {
> - recv->header.recv_buf.grh = &recv->grh;
> - } else {
> - recv->header.recv_buf.grh = NULL;
> - }
> + recv->header.recv_buf.grh = &recv->grh;
The API is defined such that the grh pointer is always valid; it's the data that may
or may not be. I think this will make it easier for clients to repost receive buffers
on redirected QPs.
_______________________________________________
openib-general mailing list
[EMAIL PROTECTED]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
