(Taking minutes: HP - JR) Y HP Jim Hamrick (JH) (after 15 minutes) Y HP Jay Rosser (JR) N HP Fred Worley (FW) Y IBM Fredy Neeser (FN) N NetApp Arkady Kanevksy (AK) N Sun Matt Pearson (MP) cascading ascii art attendance diagram. (if you have more than 1 minus visible, you are not eligible to vote.) hp ibm netapp sun ---- ----- ------ --- m-3 + + + - m-2 + + - - m-1 + + - - m-0 + + - - * Agenda bashing, approve minutes o Minutes to approve: + Minutes from 9/28/04 yet to be sent to reflector * Action item review o AI - JR to find the text required to identify new requirements (as proposed by Dick) and send to FN/FW so they can issue new proposed requirement. + FN - recommends replacing the tag "REQ2+" with two tags: "Phase 2 - REQ" and "Phase 3 - REQ" + JH/JR - no objection. + Closed + AI - FN - Emit new requirement using above syntax that captures notion of an API where applications could be requested to return memory to the O/S (or invalidate STags). Should be a phase 3 requirement. o AI - FN - request Global Behavior section from editor and update as above ("above" to be found in AI review from 10/5/04 minutes) + FN - add text for asynch behavior? + JR - yes. + FN - still have to do some cleanup of text but do have draft. + Still pending o AI - MM group to create text describe potential hazard of use of stale STags with fast re-registration use model. + Still pending o AI - FN - determine what PBL type checking needs to be done depending on pbl_types_supported IA attribute. See, MM-4.0.D4.4 and MM-8.3.D1 + See email from FN subject "PBL types" sent 10/19/04 10:09AM PT + FN - discusses content of Word document in email attachment + FN - supported PBL types are to be identified by a set of flags "pbl_types_supported". # Four cases described in MM-8.3.D1 (pg 3) # Tricky case is Case 4 - a proprietary extension to iWARP and IB VE verbs to allow support of both PBL types in a given IA * MM - was concerned that the checking errors due to page list hint should not be done synchronously (i.e. burden should not be on IT API implementation) * FN - goal is to provide normal semantics of checking done (i.e. asynch detection of page misalignments done by H/W or RI) where both PBL types supported simultaneously. + FN - discusses request by Consumer for pbl_type support desired. # it_ia_create2() will take a new argument that indicates the variety of PBL types Consumer wishes to use. # MM- 8.3.D4.1 * FN - IA may have larger set of PBL types supported than Consumer requests but it will not be less. * FN - it is a special case where PBL types of BLOCK and PAGE are both simultaneously supported by IA (i.e. for IA's that can support Case 4) o In this case, the PBL type "hint" must be used by Consumer. o IA will report both BLOCK and PAGE PBLs supported only if the Consumer requests both.<> o <>IA will report that only one of BLOCK or PAGE is supported otherwise. + FN - discusses combinations including variable page size support # Conclusion - if vendor wants to support variable size page lists, they must also support either of non-variable sized page lists or block lists. Mandatory to include a discriminator of the PBL type in the device verbs to support this feature. * JR - does the RNIC-PI need to include this? * FN - optionally, yes. + FN - wonders about the IT API behavior when Consumer passes in a PBL type that is not supported by the IA # JR - immediate error seems the correct behavior. # FN - agreed. + Closed. o AI - FN to give a deeper explanation of this next time (refers to MM-10.0.1.D1.3.5) + FN - discusses that the behavior for InfiniBand is implementation-dependent (since a verbs provider could own translation and pinning and offer no ability for the IT API to modify the state of a registration via unlinking). + Closed. o AI - JH to determine if this flag is truly necessary or can be handled with existing flags (refers to "REMOTE ACCESS FLAG" - MM-D1.1.2) + JH - has had no chance to look at this. + FN - has looked into this # At LMR create time, the mode of the LMR is preserved across fast register and invalidation actions. * If Consumer attempts to fast register with wrong access permissions, it will be caught by the implementation * JH - wonders if this is necessary to support - we could simply always enable remote access on LMR create and rely on the fast register to impose the access rights correctly. * FN - not sure and will check with MP * JH - will look into this more. + Still open o AI - Everyone - FN suggests we all think about this issue (refers to MM-10.3.1 and 10.3.2 "wart" issue) + FN - describes the use of a state variable for LMRs that indicates whether or not Consumer has the possibility to unlink the LMR. # FN - notes that this leads to a complex programming model but he and MP see no alternative. + Closed. o AI - FN will add text stating why the restriction is necessary (refers to use of single scatter element from RDMA read restriction) + Pending. + FN - Note that this restriction is requirement MM-10.4.D3.6.2 and the restriction applies only to RDMA read with invalidate. o AI - FN/JR - Can an RMR or LMR be linked or unlinked via an Endpoint in the unconnected state on InfiniBand? Current IT API pages deny this - see if InfiniBand verbs allow it. + Pending. o AI - MM group - determine if QP can be destroyed or reset if MWs associated with it (for IB, IB VE, and iWARP). + Pending. * iWARP CM issues o Email thread started by Caitlin Bestler, subject "Connection Establishment Protocol", sent 9/30/04 6:33AM PT + JR - DAT 1.1 specification left to consumer the requirement to negotiate IRD and ORD on their own in private data (DAT 1.1 page 112 (122 of PDF) lines 7-12). + JR - since we mandate the IOH header and it appears at a specific offset in the private data, we cannot interoperate with such DAT implementations. + JR - can we consider adding a flag to the TII to support the disabling of the IOH protocol? # FN - notes that this is a transport-dependent wart on the TII + FN/JH/JR - agree that this is probably the least turbulent approach + AI - JR - emit proposal on how to deal with turning off IOH for DAT compatibility. o Email thread started by Jay Rosser, subject "[Fwd: First draft of CM man pages]", sent 9/28/04 3:10PM PT + FN - suggests postponing discussion of CM issues until has had an opportunity to review. o Email thread started by Fredy Neeser, subject "Re: First draft of CM man pages", sent 9/29/04 8:08AM PT + Same as above o Email thread started by Jay Rosser, subject "[Fwd: CM review call with Fredy 9/29/04", sent 10/4/04 9:03AM PT + Same as above o Email from Jay Rosser, subject "Second draft of CM man pages", sent 10/14/04 11:34AM PT + Same as above o JR - Describes JH's suggestion of revising RNIC-PI requirements document content to show information from the perspective of the Consumer as well as Implementor. + FN - asks that JR share proposal and we discuss how to lay out the information * MM requirements discussion? o Covered by action items. * Next steps o Focus on man page generation, occupy spare time in telecons with errata review, next round of detailed requirements to be prioritized. * Any other business o MM man pages need review o Next draft of CM pages needs review o FN asks if PBL types strategy seems okay with JR/JH? + JH/JR think it is okay + JH points out that CB had a comment on the PBL types document (sent during telecon) # FN - will look at it Meeting adjourns at the 2hr 5min mark. -----------------------------187803128313750 Content-Disposition: form-data; name="link1"