[Myrinet] Re:Re: [Myrinet] A problem with GM/MCP event-driven me

"geoge_zhang" <[email protected]> Thu, 31 Jan 2002 19:53:21 +0800 (CST)
Newsgroups	gmane.network.myrinet.general
Message-ID	<3C593031.000020.26656@mta5>
Y2hhbmlzbSE=?=
X-Priority: 3
X-Originating-IP: [166.111.165.224]
X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001
Content-Type: Multipart/Alternative; boundary="Boundary-=_rxTexbuBOPYjcTsPpVHrXHGvFQbF"

--Boundary-=_rxTexbuBOPYjcTsPpVHrXHGvFQbF
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi,Vijay :
   Thanks very much for your help, it does help me:-).

>
>> 1.If the SDMA engine enqueues a send for the SEND engine, The L_send__start_sending_chunk_0/1
>>   runs continuesly using the following code:
>>     smp = gm.send_chunk[LZERO].smp;
>>     #if GM_ENABLE_CRC32
>>     smh = gm.send_chunk[LZERO].smh;
>>     #endif
>>     sml = gm.send_chunk[LZERO].smlt;
>>     It seems that the SDMA just stores the send mesg in send_chunk[0]/[1] and sets the 
>>   smp/smlt,but it doesn't clear the gm.send_chunk[LZERO].smp/smlt. Then the mesg stored 
>>   in send_chunk[0]/[1] are send each time L_send__start_sending_chunk called (that is,the sml  
>>   is set) ? It seems impossible, but what's the problem ?
>> 
>
>Take a look at the way part of the gm_event_index table is set up. 
>
>      /* send events */
>      if (i & SEND_INT_BIT && i & SENDING)
>        {
>          GM_SET_EVENT_INDEX_FOR_STATE (FINISH_SEND_EVENT, i);
>          continue;
>        }
>
>This would mean that after the L_send__start_sending_chunk event is 
>called, the corresponding L_send__finish_sending_chunk event is 
>called. And in L_send__finish_sending_chunk(), the two line of code 
>
>    NOTICE_NOT (SENDING); 
>    NOTICE (FREE_SEND_CHUNK); 
>
>ensure that  L_send__start_sending_chunk_0/1() is NOT called without 
>the send chunk's smp/smlt being initialized properly. 
>

   YES,I've seen these codes. Actually, this question should be after the next question. we've traced continuous call of L_send_finish_sending_chunk, so we propose the above question. 
   Then we can focus on the following question.

>
>> 2. It's said that when the GM_STATE is set using NOTICE_NO(SEND_PENDING), the START_SEND_EVENT
>>    cann't happen, and so the L_send__start_sending_chunk_0/1 couldn't be called. 
>>    But in our program, after the GM_STATE is set using NOTICE_NO(SEND_PENDING) when the ACK 
>>    mesg is received, the START_SEND_EVENT still happens and L_send__start_sending_chunk_0/1 
>>    still called. Then what's the problem ?
>> 
>   Have you traced the various events that are called after the 
>NOTICE_NO(SEND_PENDING) is executed? I believe there might a event 
>being called which toggles back the SEND_PENDING bit with 
> 
>    TOGGLE_STATE (gm_free_send_chunk_cnt * SEND_PENDING);

  There is a error in my above words, sorry:-). There is no NOTICE_NO(SEND_PENDING)
when the ACK mesg is received at all.
  As you said, I've traced the events for a single mesg (1024bytes) transfer on the sending side. After the SDMA enqueues the mesg for SEND transfer, there are following status set:
  //in gmcp.c, gm.free_send_chunk_cnt is set to 2.
  1. MARK_LABEL (L_sdma__finish_sdma,)  -> 
     NOTICE (SEND_PENDING);
     gm.free_send_chunk_cnt -- ;
  2. MARK_LABEL (L_send__finish_sending_chunk,) ->
     NOTICE_NOT (SENDING);
     NOTICE (FREE_SEND_CHUNK);
     TOGGLE_STATE (gm_free_send_chunk_cnt * SEND_PENDING); 
     //since there is one mesg transfer, it is stored in gm.send_chunk[0],
       and the gm_free_send_chunk_cnt == 1, so the TOGGLE_STATE clears
       SEND_PENDING. 
    Then the L_send__start_sending_chunk shouldn't be called continuously.
  But when we trace the event list, the L_send__start_sending_chunk does 
  called continuously. And I've inserted a
   if (NOTICED(SEND_PENDING)) *** in the MARK_LABEL(L_send__start_sending_chunk,),
  it shows even SEND_PENDING is not set, the L_send__start_sending_chunk is still
  called, could anyone give any more information?  

    It really confused us, and any help would be greatly appreciated!

Best regards
Geoge
  
  
       
       

>
>hope that helps, 
>Vijay 
>--
>Architecture & Real-time Systems (ARTS) Lab,
>310 Knowles Engineering Bldg,
>UMass Amherst 01003
>Tel: (413)-545-0715 (O)
>Fax: (413)-545-1993
>
>
>_______________________________________________
>Myrinet mailing list
>[email protected]
>http://email.osc.edu/mailman/listinfo/myrinet
>




__________________________________________
È«³¡ÌØ¼Û£ºÊýÂëÏà»ú¡¢ÕÆÉÏµçÄÔ¡¢MP3 http://shopping.263.net/category21.htm
ÌìÓ®³´¹É,ÌìÉúÎÒÓ®! http://stock19.263.net/download/borntowin.htm

--Boundary-=_rxTexbuBOPYjcTsPpVHrXHGvFQbF
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: 8bit

Hi,Vijay :<br>   Thanks very much for your help, it does help me:-).<br><br>><br>>> 1.If the SDMA engine enqueues a send for the SEND engine, The L_send__start_sending_chunk_0/1<br>>>   runs continuesly using the following code:<br>>>     smp = gm.send_chunk[LZERO].smp;<br>>>     #if GM_ENABLE_CRC32<br>>>     smh = gm.send_chunk[LZERO].smh;<br>>>     #endif<br>>>     sml = gm.send_chunk[LZERO].smlt;<br>>>     It seems that the SDMA just stores the send mesg in send_chunk[0]/[1] and sets the <br>>>   smp/smlt,but it doesn't clear the gm.send_chunk[LZERO].smp/smlt. Then the mesg stored <br>>>   in send_chunk[0]/[1] are send each time L_send__start_sending_chunk called (that is,the sml  <br>>>   is set) ? It seems impossible, but what's the problem ?<br>>> <br>><br>>Take a look at the way part of the gm_event_index table is set up. <br>><br>>      /* send events */<br>>      if (i & SEND_INT_BIT && i & SENDING)<br>>        {<br>>          GM_SET_EVENT_INDEX_FOR_STATE (FINISH_SEN
 D_EVENT, i);<br>>          continue;<br>>        }<br>><br>>This would mean that after the L_send__start_sending_chunk event is <br>>called, the corresponding L_send__finish_sending_chunk event is <br>>called. And in L_send__finish_sending_chunk(), the two line of code <br>><br>>    NOTICE_NOT (SENDING); <br>>    NOTICE (FREE_SEND_CHUNK); <br>><br>>ensure that  L_send__start_sending_chunk_0/1() is NOT called without <br>>the send chunk's smp/smlt being initialized properly. <br>><br><br>   YES,I've seen these codes. Actually, this question should be after the next question. we've traced continuous call of L_send_finish_sending_chunk, so we propose the above question. <br>   Then we can focus on the following question.<br><br>><br>>> 2. It's said that when the GM_STATE is set using NOTICE_NO(SEND_PENDING), the START_SEND_EVENT<br>>>    cann't happen, and so the L_send__start_sending_chunk_0/1 couldn't be called. <br>>>    But in our program, after the GM_STATE is set using N
 OTICE_NO(SEND_PENDING) when the ACK <br>>>    mesg is received, the START_SEND_EVENT still happens and L_send__start_sending_chunk_0/1 <br>>>    still called. Then what's the problem ?<br>>> <br>>   Have you traced the various events that are called after the <br>>NOTICE_NO(SEND_PENDING) is executed? I believe there might a event <br>>being called which toggles back the SEND_PENDING bit with <br>> <br>>    TOGGLE_STATE (gm_free_send_chunk_cnt * SEND_PENDING);<br><br>  There is a error in my above words, sorry:-). There is no NOTICE_NO(SEND_PENDING)<br>when the ACK mesg is received at all.<br>  As you said, I've traced the events for a single mesg (1024bytes) transfer on the sending side. After the SDMA enqueues the mesg for SEND transfer, there are following status set:<br>  //in gmcp.c, gm.free_send_chunk_cnt is set to 2.<br>  1. MARK_LABEL (L_sdma__finish_sdma,)  -> <br>     NOTICE (SEND_PENDING);<br>     gm.free_send_chunk_cnt -- ;<br>  2. MARK_LABEL (L_send__finish_send
 ing_chunk,) -><br>     NOTICE_NOT (SENDING);<br>     NOTICE (FREE_SEND_CHUNK);<br>     TOGGLE_STATE (gm_free_send_chunk_cnt * SEND_PENDING); <br>     //since there is one mesg transfer, it is stored in gm.send_chunk[0],<br>       and the gm_free_send_chunk_cnt == 1, so the TOGGLE_STATE clears<br>       SEND_PENDING. <br>    Then the L_send__start_sending_chunk shouldn't be called continuously.<br>  But when we trace the event list, the L_send__start_sending_chunk does <br>  called continuously. And I've inserted a<br>   if (NOTICED(SEND_PENDING)) *** in the MARK_LABEL(L_send__start_sending_chunk,),<br>  it shows even SEND_PENDING is not set, the L_send__start_sending_chunk is still<br>  called, could anyone give any more information?  <br><br>    It really confused us, and any help would be greatly appreciated!<br><br>Best regards<br>Geoge<br>  <br>  <br>       <br>       <br><br>><br>>hope that helps, <br>>Vijay <br>>--<br>>Architecture & Real-time Systems (ARTS) Lab,<br>>
 310 Knowles Engineering Bldg,<br>>UMass Amherst 01003<br>>Tel: (413)-545-0715 (O)<br>>Fax: (413)-545-1993<br>><br>><br>>_______________________________________________<br>>Myrinet mailing list<br>>[email protected]<br>>http://email.osc.edu/mailman/listinfo/myrinet<br>><br><br><br><br><br>__________________________________________<br><br>È«³¡ÌØ¼Û£ºÊýÂëÏà»ú¡¢ÕÆÉÏµçÄÔ¡¢MP3 http://shopping.263.net/category21.htm<br>ÌìÓ®³´¹É,ÌìÉúÎÒÓ®! http://stock19.263.net/download/borntowin.htm<br>
--Boundary-=_rxTexbuBOPYjcTsPpVHrXHGvFQbF--