home *** CD-ROM | disk | FTP | other *** search
/ ftp.parl.clemson.edu / 2015-02-07.ftp.parl.clemson.edu.tar / ftp.parl.clemson.edu / pub / pvfs2 / orangefs-2.8.3-20110323.tar.gz / orangefs-2.8.3-20110323.tar / orangefs / src / io / bmi / TODO < prev   
Text File  |  2004-04-29  |  5KB  |  148 lines
  1. General (critical)
  2. -----------------------
  3.  
  4. add hints to allow reference counting on bmi addresses so that we know when
  5. they can be safely discarded
  6.  
  7. General (portability)
  8. -----------------------
  9.  
  10. Get rid of dynamic array declarations that are all over the BMI
  11. code!  This is a stupid hack that only gcc allows.
  12.  
  13. Replace void* type for memory regions with PVFS_byte or BMI_byte
  14. types.  Audit code to make sure that buffers are indexed like
  15. this: (type)((BMI_byte)buffer + offset)
  16.  
  17. General (non critical)
  18. -----------------------
  19.  
  20. implement a mechanism to occasionally (or maybe if resources get low) scan
  21. addresses with a reference count of 0 to see if any of them can be discarded
  22.  
  23. reimplement reference-list.c using a hash table instead of linked
  24. list, to cut down on search time during addr lookups (maybe use
  25. multiple hash tables to search on sepeate keys)
  26.  
  27. consider changing the way the testXXX functions are implemented in
  28. both modules, so that they do not do work with timeout > 0 if the
  29. desired operation is already completed.  Right now both could
  30. potentially stall before grabbing a completed operation...
  31.  
  32. do a better implementation of the testsome and testunexpected
  33. functions, so that they are more clever about multiplexing between
  34. multiple modules and splitting up the max_idle_time (right now
  35. each module is called once with 1/n idle time)
  36.  
  37. we can probably redo op_list_search as a simpler function - I'm not sure
  38. we need so much flexibility any more, so maybe we can skip passing
  39. a whole key into search.
  40.  
  41. Consider adding _optional_ argument checking code, in particular look
  42. for stuff like sum of size_list == size in list calls, size >
  43. expected size, etc.
  44.  
  45. Document what stuff in the method_op structure must be filled in by
  46. methods for correct BMI operation, and what is just there for convenience
  47.  
  48. Implement a mechanism for throttling the amount of eager or unexpected
  49. messages that a method is allowed to receive at a time.  Right now one
  50. could stream a huge number of such messages to use up memory buffers
  51. on a system if the receiver was not posting receives or checking for
  52. unexpected messages fast enough.
  53.  
  54. do I need to clean up things in the completion_array[] at finalize
  55. time?  applies to both GM and TCP modules, maybe to flow and job stuff
  56. as well - actually, should probably just call close_context from
  57. upper level before shutting down modules
  58.  
  59. TCP module:
  60. -----------------------
  61.  
  62. optimize locking
  63.  
  64. do a better job of cleaning out address structures that are no longer in use
  65. (may need a hint to say when this can be done)
  66.  
  67. turn off sigpipe (we will just catch errors at system call time)
  68.  
  69. Do something better than the "enqueue_operation" function - it's
  70. list of arguments has gotten out of hand, I think...
  71.  
  72. also clean up use of tcp_msg_header structure- this is also cluttering the
  73. code, especially when considering what needs to be done to support 
  74. network encoding of the header.
  75.  
  76. There are more oportunities for immediate completion on receives
  77. (specifically, look at the end of tcp_post_recv_rend() when we add to the
  78. completion queue, and the bottom of tcp_post_recv_eager()).
  79. We should try to immediately complete towards the end of
  80. post_recv_rend also (see TODO in comments).
  81.  
  82. Redo tcp_do_work_recv().  It is huge.
  83.  
  84. The data reception portions of tcp_post_recv_eager and
  85. tcp_post_recv_rend could be shared (maybe a separate function also used
  86. within poll?).
  87.  
  88. Implement better fd management in the TCP module.  It should detect when
  89. we are running out of sockets and make efforts to free some up as
  90. needed.  We already have the means to reconnect if needed- we could scan
  91. after operations are taken out of the completion queue to look for
  92. sockets to close without too much difficulty now.  It would rely on a
  93. hint (see ideas at top of this file) from the caller, however, to know
  94. when it is safe to kill sockets.
  95. (look at code from pvfs1:)
  96.  
  97.     if (getrlimit(RLIMIT_NOFILE, &lim) < 0) {
  98.         /* not something to die over */
  99.         LOG("notice: could not discover maximum # of fds.  continuing.\n");
  100.         my_nofile = -1;
  101.     }
  102.     else {
  103.         my_nofile = lim.rlim_cur;
  104.         LOG1("open file limit is %d\n", my_nofile);
  105.     }
  106.  
  107. GM module:
  108. -----------------------
  109.  
  110. optimize locking
  111.  
  112. implement cancel
  113.  
  114. make sure all control messages are network encoded somehow
  115. to work across different architectures
  116.  
  117. clean up use of qlist (in particular, make use of
  118. qlist_for_each_safe() when appropriate)
  119.  
  120. Make sure that GM can handle 0 byte messages; the flow code may trigger
  121. these occasionally.
  122.  
  123. Look into possibility of using lookaside list for method_op
  124. allocation.
  125.  
  126. Consider doing a malloc() followed by register as opposed to
  127. dma_malloc() for control buffers- this would be more space efficient and
  128. would only slow down initialization, not communication (see GM
  129. FAQ).
  130.  
  131. Look at mpich-gm (gmpriv.c) and the way that send callbacks are used.
  132. It looks like (in some cases) that sends are considered completed after
  133. posting, rather than waiting for callback.  This would explain some of
  134. the mpi gm client bandwidth (for small messages).
  135.  
  136. Look into the following projects on top of GM: via, sockets, and opiom
  137.  
  138. Need to handle erroneous messages in recv cycle (what if not peer, for
  139. example?).
  140.  
  141. note that only the ENABLE_GM_BUFPOOL memory buffering method supports
  142. list operations!
  143.  
  144. follow up on gm_blocking_receive() bug- it appears to still
  145. consume 99% cpu when alarms are used, despite report that bug was
  146. fixed.  For now still using XXX_no_spin() version.
  147.  
  148.