On Fri, Mar 6, 2009 at 4:05 PM, Hal Rosenstock <[email protected]> wrote: > - Show quoted text - > On Fri, Mar 6, 2009 at 3:51 PM, Hal Rosenstock <[email protected]> > wrote: >> On Fri, Mar 6, 2009 at 3:41 PM, Sasha Khapyorsky <[email protected]> wrote: >>> On 12:55 Fri 06 Mar , Hal Rosenstock wrote: >>>> >>>> It could be subsequent patch but thought it best to include it. Do you >>>> want this separate ? >>> >>> Without clear usage case I would prefer to not have it at all - finally >>> it is on a fast path. >> >> It's the same as what is done in the kernel for MAD response but I >> removed it because I could see you were against this. >> >>>> >>>> > BR is not used anywhere in OpenSM. >>>> >>>> No, but someone might use ib_types.h to build BM. >>> >>> We cannot know what will be needed then - this someone will need to care >>> anyway. >> >> You could say that about a lot of things accepted which aren't fully >> integrated. >> >>>> > And this function which should process TrapRepress method does nothing, >>>> > right? >>>> >>>> Just some validation; It doesn't need to do anything (just retire the >>>> transaction). >>> >>> Then I don't understand - how is trap 144 repress handled? And why >>> those changes in trap_rcv_process_response() were needed? >> >> Perhaps it's being overly pendantic. I can revise the patch to not >> have the repress get this far. > > I misread your comment.
Maybe I didn't misread. > trap_rcv needs to cause the repress for the trap to be generated. This is already done. I think what you were saying was why does the incoming repress need to get this far into the code, right ? -- Hal > > -- Hal > >> -- Hal >> >>> Sasha >>> >> > _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
