Roland> I guess the problem with calling smi_handle_dr_smp_recv() Roland> twice on the same packet is that the function may alter Roland> the packet.
Hal> No, the second call to smi_handle_dr_smp_recv() was on the Hal> outgoing response and not the incoming request. The thought Hal> was that a packet coming from process_mad is much like an Hal> incoming received packet and hence the call to Hal> smi_handle_dr_smp_recv. The routine validates the packet but Hal> also can do some fixups depending on which case it falls Hal> into. Guess it's only dangerous to validate this and wrong to Hal> fix it up. Maybe I'm misreading the code, but my patch deleted the call to smi_handle_dr_smp_recv() before the call to agent_send. agent_send() eventually ends up in ib_post_send_mad(), which calls handle_outgoing_smp() for directed route MADs, which ends up calling smi_handle_dr_smp_recv() again. Since smi_handle_dr_smp_recv() can change the packet, calling it twice on the same packet seems to break things. However I don't think it's a good idea to think of responses generated by process_mad as an incoming received packet. I think they should be thought of as returning DR SMPs being passed to the SMI for sending (as in section 14.2.2 of the IB spec). Hal> The key to me is the following: The split of responsibility Hal> on the DR header formation is a little unclear to me. In the Hal> case of the SM, are the DR headers fully formed before Hal> handing it to the MAD layer or is some DR fixup needed ? My suggestion would be to follow the IB spec, and assume that the SM follows the SMP initialization in 14.2.2.1 and have the MAD layer just implement the SMI processing in 14.2.2.2. (And I believe things should work similarly for responses generated by the SMA -- the MAD layer should just do SMI processing). - R. _______________________________________________ openib-general mailing list [EMAIL PROTECTED] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general