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

Hal Rosenstock halr at voltaire.com
Fri May 6 05:53:16 PDT 2005


On Thu, 2005-05-05 at 13:10, Sean Hefty wrote: 
> > 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.

I wasn't saying otherwise :-> Just trying to describe the scenario.

>   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.

Right now, OpenSM registers the SA MAD agent with all methods set in the
method mask (overkill) so I'm not sure what is not happening correctly
yet.

> Can you describe in more detail what the exact failure that you're seeing is 
> and what you were expecting?

When the ACK is sent, I do not get a send failure. This is expected
based on what you said at the SA side. I think it (TID matching) would
only happen in the MAD layer automatically on the SA client side so you
would get a send failure if the ACK didn't come back in the other
direction.

> Thanks for looking into this more.

So it seems that something above the MAD layer needs to implement the
matching of ACKs, etc. on the SA side :-(

If we extended response_mad to handle RMPP non data packets, this might
not be the case but I haven't thought about it enough. Just a thought as
a possible way around the issue on the SA side with this.

-- Hal




More information about the general mailing list