ICSC ITWG Meeting Minutes, 1. Feb. 2005 Taking minutes: IBM (FN) Meeting attendance diagram (if you have more than 1 minus within the last four ITWG meetings, you are not eligible to vote): mtg date hp ibm netapp sun --- ------- -- --- ------ --- m-3 + + - - m-2 + + - - m-1 + + - - m-0 1. Feb. + + - - Present: Jim Hamrick (JH) [HP] Fredy Neeser (FN) [IBM] Jay Rosser (JR) [HP] Agenda bashing - See TODOs according to FN’s email “MM man pages for IT-API v2.0” sent on Feb 1, 2005. Minutes to approve Email from Fred Worley, subject "ICSC ITWG draft minutes for 1/18/05", sent 1/18/05 4:52PM PT: Approved. Action item review AI (FN): Get rid of MM-16.4.D2.1 and MM-16.4.D2.2. Status: Pending. AI (FN): Document that an unlink operation that fails remotely will not directly manifest as an error locally. Also add text to Implementers guide that they need to absorb the Async Error and not manifest it via the IT API. Status: Pending. AI (JR) Generate a proposal for a mapping service to generate a PBL (with bus addresses) given a virtual address range and a virtual address space ID virtual addresses). Status: Pending. AI (JR): Lead further discussion to complete: Produce requirements for RDDP WG informational draft to support IOH functionality. Status: Pending. AI (JH): Update create_srq man page to include more detailed discussion of protection zone issues. Status: Closed. Text was added to man page by JH. AI (FN): Document stronger ordering rules for RMDA DTOs related to overlapping buffers. Status: Closed. Done for all DTOs. AI (JR): Add macro for rdma_read_incoming / rdma_read_outgoing field names to support IRD / ORD as alternate (additional) names; determine where this changes should be documented (includes msg_events page). Status: We decided to handle this as a global edit. AI (FN): Generate functional change list for MM calls as an example for review. Status: Closed. Editorial issues Email thread started by Jim Hamrick, subject "Proposed division of editorial responsibility", sent 1/19/05 2:02PM PT JR: Anything left to be done? FN: Need to review introductory chapters. AI: FN to review Introduction for editorial changes. JR to review Preface and Global Behavior for additional editorial changes. AI: JR to figure out how to reassemble man pages. (JH joined the conference.) AI: All – Figure out which man pages need text indicating that a call may be blocking, waiting for a remotely generated event. AI: FN to generate standard text for such man pages. Email thread started by Fredy Neeser, subject "AI: List of functional changes for v2.0 API calls", sent 1/21/05 7:49AM PT: All: Agreement on scope/level of detail of list of functional changes. Email thread started by Fredy Neeser, subject "References to external documents", sent 1/24/05 11:19AM PT AI: JR to create global References page with list of agreed-on tags. Email thread started by Jim Hamrick, subject "Which man pages should have an APPLICABILITY section?", sent 1/25/05 11:39AM PT: All: Agreed on in separate email. Email thread started by Jim Hamrick, subject "RETURN VALUE on data structure man pages", sent 1/25/05 1:44PM PT: All: Agreed to expunge the corresponding man page sections. Email from Jay Rosser, subject "Unresolved errata", sent 1/28/05 1:57PM PT: All: Agreement on process of resolving errata per separate email. AI: All to include any resolved Errata in Functional_Changes document which can be used later on to update the Errata spreadsheet. AI: JR to add list of Errata as an Appendix. List Errata Numbers (global and company) and description of original problem. (Errata were not discussed in detail) S-RQ issues FN: Regarding it_post_recv, should we say more about sequential vs. arrival ordering for S-RQs? JH: Not clear how it affects Consumers. FN: Depending on the S-RQ Implementation, an application may have to dimension an S-RQ differently, in order to deal with out-or-order arrival of Send messages (which is classified as a DoS attack). FN: Mentions that he added a sentence to it_post_recv alluding to this Implementation option. Perhaps information on this Implementation option could help Consumers to dimension their S-RQs appropriately. CM issues Email thread started by Jay Rosser, subject "Minor change needed for it_socket_convert", sent 1/25/05 11:51AM PT JH: Prefers not to add a transport-specific interface for handling the keep-alive socket option since there is an alternate path. Caveat: Need to document what exactly can be done with the socket handle. If anything else is done with socket handles except manipulating the keep-alive socket option, undefined behavior will result. JR: SDP over IB uses zero-length RDMA Writes. Would have been nicer to use the same mechanism for SDP over iWARP. Implementing keep-alive using zero-length RDMA Writes is functionally equivalent to using the TCP keep-alive feature. JR: Concerned that keeping around socket descriptors for the lifetime of a converted connection may be too resource consuming. AI: JR and FN to check if keeping around socket descriptors for the lifetime of a converted connection is too resource consuming. Email thread started by Fredy Neeser, subject "Graceful closes during MPA Startup (RDMAC vs. Non-Permissive IETF RNIC)", sent 12/15/04 9:18AM PT: JR: This was resolved through text and additional ladder diagrams in iWARP Implementor’r Guide. (JR had to leave meeting at regular meeting end time 12 pm PDT) MM issues FN: While the lists of reasons for a particular IT-API DTO status are reasonably complete, I feel that too many different transport completion codes are mapped to the same DTO status. Changing this may break applications. FN: Example IT_DTO_ERR_LOCAL_PROTECTION. Many transport error codes are mapped to same DTO status. Not particularly helpful for debugging. JH: Favors a solution that doesn’t break existing applications by eliminating an existing error code. JH & FN: Better to try and add a “detailed status code” to completion events for work requests. With this solution, it_dto_status_t just divides completions into broad categories; the detailed status code can be inspected to determine the status more accurately. AI: FN to evaluate “detailed status code” idea. (Meeting adjourned at 12:15 pm PDT)