[openib-general] [PATCH] TODO list for access layer

Sean Hefty mshefty at ichips.intel.com
Tue Aug 10 10:42:48 PDT 2004


Added a TODO list for the access layer.  Removed TODO statements.  One minor update to ib_rmpp_hdr based on feedback from Hal.

Index: ib_verbs.h
===================================================================
--- ib_verbs.h	(revision 620)
+++ ib_verbs.h	(working copy)
@@ -787,7 +787,6 @@
 	return fmr->device->map_phys_fmr(fmr, phys_buf_array, num_phys_buf);
 }
 
-/* Need to discuss this... */
 static inline int ib_unmap_fmr(struct ib_fmr **fmr_array,
 			       int fmr_cnt)
 {
Index: ib_mad.h
===================================================================
--- ib_mad.h	(revision 620)
+++ ib_mad.h	(working copy)
@@ -53,7 +53,7 @@
 struct ib_rmpp_hdr {
 	u8	rmpp_version;
 	u8	rmpp_type;
-	u8	rmpp_flags;
+	u8	rmpp_rtime_flags;
 	u8	rmpp_status;
 	u32	seg_num;
 	u32	paylen_newwin;
@@ -134,11 +134,6 @@
  * @remote_qkey - Specifies the qkey used by remote QP.
  * @pkey_index - Pkey index to use.  Required when sending on QP1 only.
  */
-/* XXX See about using ib_send_wr directly, e.g.:
-	context -> wr_id
-	mad_flags -> send_flags
-	add new timeout_ms field or double use of imm_data
-*/
 struct ib_mad_send_wr {
 	struct list_head	list;
 	void			*context;
@@ -184,7 +179,6 @@
  *
  * An RMPP receive will be coalesced into a single data buffer.
  */
-/* XXX revisit possibility of zero-copy receive */
 struct ib_mad_recv_wc {
 	void			*context;
 	struct ib_grh		*grh;
@@ -209,9 +203,6 @@
  * @method_mask - The caller will receive unsolicited MADs for any method
  *   where @method_mask = 1.
  */
-/* XXX Need to extend to support snooping - perhaps registration type
-   with masks for the class, version, methods if type is 'view-only'?
-*/
 struct ib_mad_reg_req {
 	u8	mgmt_class;
 	u8	mgmt_class_version;
@@ -260,7 +251,6 @@
  * @mad_agent - Specifies the associated registration to post the send to.
  * @mad_send_wr - Specifies the information needed to send the MAD.
  */
-/* XXX Need to define queuing model - above or below API? */
 int ib_mad_post_send(struct ib_mad_agent *mad_agent,
 		     struct ib_mad_send_wr *mad_send_wr);
 
@@ -280,7 +270,6 @@
  * on user-owned QPs.  After calling this routine, users may send
  * MADs on the specified QP by calling ib_mad_post_send.
  */
-/* XXX Need to define provided features for requestor-side redirecting */
 struct ib_mad_agent *ib_mad_qp_redir(struct ib_qp *qp,
 				     u8 rmpp_version,
 				     ib_mad_send_handler send_handler,
Index: TODO
===================================================================
--- TODO	(revision 0)
+++ TODO	(revision 0)
@@ -0,0 +1,31 @@
+Verbs TODOs:
+
+	- Ensure ib_mod_qp can change all QP parameters - check resize.
+	- Determine proper value for static_rate - match CM or inter-packet
+	  delay.  Can an abstracted value be easier to use?
+	- Need to define struct ib_mw_bind.
+	- Optional calls need checks before invoking device driver.
+	- Migrate non-speed path routines into .c file.
+	- Add comments for API.
+	- Should ib_unmap_fmr take fmr_array as input, or just fmr?
+	  What should the restriction on the fmr_array be?  All from same
+	  device?
+
+MAD TODOs:
+	- Need to define queuing model for ib_mad_post_send.
+	  Should queuing be above or below access layer? 
+	  Does this affected starvation?
+	- Should RMPP sends post one or multiple work requests.
+	- See about combining ib_mad_send_wr with ib_send_wr.
+	  context is wr_id.
+	  mad_flags can combine with send_flags - useful for redirected QPs.
+	  timeout_ms does not map - could use imm_data or add new field.
+	- Examine methods to support zero-copy for received RMPP MADs.
+	- Need to extend ib_mad_reg_req to support snooping.
+	  could use masks for class, version, methods to snoop all.
+	  could add a registration type - receive MADs vs. view MADs.
+	  registration for view MADs would need to apply to sends as well.
+	- Need to define features provided by access layer for requestor
+	  side redirection.
+	- Should clients have ability to reserve QP entries (or at least one)?
+



More information about the general mailing list