[openib-general] [PATCH] [MAD] changes to ib_create_send_mad

[Hal Rosenstock]

On Thu, 2005-05-05 at 13:10, Sean Hefty wrote:
> I will see if I can reproduce this using the numbers that you gave.  What 
> size did you specify for the sge?  The total number of segments is 
> calculated using the sge sizes.

Isn't that calculated and filled in by ib_create_send_mad ?

buf_size = get_buf_length(hdr_len, data_len)
...
send_buf->sge.length = buf_size;

I pretty sure I leave this along after calling ib_create_send_mad. Is
there something that needs to be done here ?

> The fact that you see the same payload length for both of these makes me 
> think that either the sge size is off, or there's an issue in the RMPP code 
> using it.

Yes, the fact that it was the same seemed weird to me too but wasn't
sure of the origin.

> > Also, I did more investigation of send failures. In terms of send
> > failures upon not receiving ACKs, SA is different from vendor class 2. I
> > think the problem starts (and hopefully ends) with response_mad(). In
> > the case of SA GetTableResp being sent, the non data packets (ACK, etc.)
> > come back as SA GetTable so this is not currently considered a response
> > but I think it needs to be. I'm not sure if there are other issues
> > behind this as I didn't chase it further. Let me know if you want me to
> > do this.
> 
> The RMPP code formats ACKs by inverting the response bit.  This is necessary 
> in order to route the ACK to the correct agent, and meets the SA 
> requirements.  Response MADs are routed to the correct agent using the TID. 
>   Non-response MADs are routed by using the lookup tables.
> 
> E.g. if you look at the SA, the ACK (GetTable) needs to go to the agent 
> using the lookup tables.  The TID carried in the ACK was actually set by the 
> sender of the ACK, and cannot be used to route to the SA's agent.
> 
> Can you describe in more detail what the exact failure that you're seeing is 
> and what you were expecting?

I will answer this separately as this will take more time.

-- Hal