[mvapich-discuss] mvapich layer breaking

[Mike Heffner]

Hi Amith,

I apologize for the late reply.

Yes, I see that you are setting that up in those functions 
(comm_rdma_init and comm_exch_addr) and that there is some other code 
for multicast support in there. My question was that it looks like it 
would be cleaner to put that code in MPID_CommInit() which should exist 
in the MPID layer. There is a call to MPID_CommInit() immediately before 
the RDMA setup code, so there shouldn't be an issue with pushing the 
code into that function and leaving MPIR_Comm_make_coll as stock mpich.

Just an observation while reading through the code that would clean up 
some of the device-specific code in the stock MPIR_ components.


Cheers,

Mike

amith rajith mamidala wrote:
> Hi Mike,
> 
> We have done this for supporting RDMA-based collective operations
> and the associated address exchange to deliver the best
> peformance,
> 
> Thanks,
> Amith
> 
> On Thu, 20 Jul 2006, Mike Heffner wrote:
> 
>> Hi,
>>
>> I have been reading through the mvapich code and I have found that
>> mvapich breaks the ADI abstraction provided by the MPID API. In the file
>> "src/context/comm_util.c" in function MPIR_Comm_make_coll() there are
>> direct calls to device-specific functions such as comm_rdma_init() and
>> comm_exch_addr().
>>
>> What were the technical reasons behind placing these initialization
>> calls at the MPIR layer rather than overloading the MPID_CommInit()
>> function to achieve similar results?
>>
>>
>> Cheers,
>>
>> Mike
>>
>> --
>>
>>    Mike Heffner <mike.heffner at evergrid.com>
>>    EverGrid Software
>>    Blacksburg, VA USA
>>
>>    Voice: (540) 443-3500 #603
>> _______________________________________________
>> mvapich-discuss mailing list
>> mvapich-discuss at mail.cse.ohio-state.edu
>> http://mail.cse.ohio-state.edu/mailman/listinfo/mvapich-discuss
>>
> 
> 



-- 

   Mike Heffner <mike.heffner at evergrid.com>
   EverGrid Software
   Blacksburg, VA USA

   Voice: (540) 443-3500 #603