9/21/04 Meeting agenda (Taking minutes: HP - JR) y HP Jim Hamrick (JH) Y HP Jay Rosser (JR) Y HP Fred Worley (FW) Y IBM Fredy Neeser (FN) Y NetApp Arkady Kanevksy (AK) (after 30 minutes) 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: + Email from Jim Hamrick, subject "Draft 3 of 9/7/2004 ITWG meeting minutes", sent 9/14/2004 1:38PM PT # Approved + Minutes from 8/31/04 (HP) and 9/14/04 (Sun) yet to be sent to reflector # FW notes that 8/31/04 minutes sent just before today's meeting * Action item review o FN - create additional text for Global Behaviors section to clarify what an asynchronous call is in the IT-API + Pending o FN - Propose use of compile time flag to yield source compatibility with two different bindings of MM calls. + Closed as follows: + FN covers proposal to offer version 1.0 backwards compatibility in version 2.0 # Extra lines in header file * Turned on via compile time define makes it_ia_create bind to version 1.0 binding * Turned off via compile time flag, makes it_ia_create bind to version 2.0 binding # Desired behavior is default binding is version 1.0 binding, so legacy applications will bind with library correctly. * User of version 2.0 must explicitly set for 2.0 behavior. * AI - FN to revise proposal so that version 2.0 Consumers will need explicitly to cause the 2.0 behavior to be manifested and version 1.0 consumers need do nothing. # FN asks if any objection to inlining with default arguments to generate the legacy binding * None heard # FW - proposes "ITAPI_ENABLE_V2_BINDINGS" as the flag to be defined. * FN - no objection * RNIC-PI document o FN - JR and FN have exchanged revisions and are attempting to generate a draft for sharing with RNIC-PI workgroup + AI - JR to send revised version in PDF to reflector by Wednesday for ITWG to comment upon with intent to generate version to share with RNIC-PI WG ASAP * MM requirements o Email thread started by Caitlin Bestlesr subject "LMR Unlinking", sent 8/24/04 10:27AM PT + FN - thinks that MM's response to CB answered her concerns + FN - brief summary of issue # CB's concern is that unlinking an LMR could interfere with a pending DTO # MM had said that if programmer is careless and unlinks LMR before DTO is completed, you will get a protection error * MM thought that API should not block a careless programmer from unlinking LMRs since it would be an expensive operation to do so # MM had said that API must put onus on programmer to generate correct applications and the issue was present even on InfiniBand in IT-API 1.0 # Question of when a DTO that references an unlinked LMR should fail. * If LMR unlink in progress and unlink has not yet completed, indeterminate when pending DTO will fail * Once LMR unlink complete, then pending DTOs will fail # Stale STag issue: * If you link and unlink LMRs rapidly, you can end up re-using same STag after 256 ops * Some care still required by consumers * JR - notes that even with STag key under direct consumer control (voted out of IT API 2.0), problem still exists o FN - agrees + FN - thinks CB's concern is covered by MM's response + (AK - joins) + FN - summarizes for AK's benefit: # Consumer has to ensure DTOs complete before unlinking LMRs # Stale STag issue * Since only 256 key values, Consumers should be warned to use another mechanism + AI - MM group to create text describe potential hazard of use of stale STags with fast re-registration use model. * Discussion on Fast-Registration MR o FN - see email subject "Discussion on Fast-Register MR", sent 9/21/04 9:58AM PT + FN - summarizes that the PDF attached in email covers a portion of the requirements o FN - he and MM had a great deal of discussion of fast registration + local invalidation was an easier subject o FN - recommends discussion of fast registration first since it and local invalidate are a pair o FN - want to describe fast register and local invalidate via "it_lmr_link" and "it_lmr_unlink" concepts + FN - describes use of "link" concept rather than "invalid" concept since "invalid" exists as a term meaning something else in the existing API o FN - MM-4.0 + JR asks what "elt_length" field refers to # FN - "element length" + JR asks FN if PBL as defined in IB VE has differing element sizes and if we need or want to support such # AI - JR - find out if this is the case (IB VE vs iWARP Verbs) and look at the need or not of such support + FN - mentions that addrbase field allows PBLs to be 0-based or VA-based o FN - looks at MM.4.0.D3 + Details completion errors possible from it_lmr_link(): + MM-4.0.D3.2 refers to STag of 0 which cannot be "linked" since it is a "physical address". + MM-4.0.D3.5 # FN - if Consumer posts LMR_Link to work queue, hardware should check this and return an completion error * Badly written app or malicious apps must be prevented from issuing this command # FN - thinks that this should be handled via a "privileged" QP * iWARP Verbs define an attribute of a QP passed in on create that enables use of fast register, etc., and such an attribute is only allowed for privileged consumers. + MM-4.0.D3.8 # FN - first byte offset (fbo) must be strictly less than the element length * FW - what about elements of length 0? * FN - unsupported element length + MM-4.0.D3.9 # FN - fbo and addr must be consistent (only necessary where addr is non-zero). o FN - MM.0.D4 + MM.4.0.D4.1 # Applies to standard InfiniBand (IBTA v1.1) (no lmr_link is supported) # AK - wonders if there are multiple ways to return this error and if this is both the attribute of an LMR and an attribute of the implementation # FN - AK's concern was that an LMR has a state that defines whether it may be linked or not * Attempting wrong action here will generate a completion error (i.e. unlink an LMR that is not linked) * Attempting to call it_lmr_link where provider does not support it will return an immediate error and this seems not confusing nor in disagreement with above. + FN - MM.0.D4.2 # FN - should the addresses in list be checked? # JR - notes that card H/W should do so * JR - If additional checking desired, it could be done in a debugging library * JH - suggests vendor-specific error codes could be implemented by vendors outside API if such capability is desired. # FW - suggests not making any such check normative, but instead, leave it to the implementation. * FN - suggests some language that recognizes the potential overhead to such checking * FW - notes that checks at post time probably would not be sufficient since addresses "could" potentially change later o E.g. memory gets physically removed * FW - summarizes that language should specifically at most state that Consumer must not rely on any checks done by implementation # JH - notes that if there is no immediate error, then application will have to code to handle then errors as completion errors only. * JH - If we allow the immediate error, application needs code in both places. # General agreement that no immediate error for detection of bad PBLs should be in API + FN - MM-0.D4.3 # FN - Consistency error suggested where 0 is a valid virtual address # JH - notes that architectures exist (gives an example) that allow 0 as a valid virtual address # AI - FN eliminate MM-0.D4.3 * Consumer must do their own checks for invalid virtual addresses + FN - MM-0.D4.4 # Makes no sense to allow non-zero value for addr where IT_ADDRBASE_ZERO # No disagreement + FN - MM-0.D4.5 # No disagreement + FN - MM-0.D4.6 # AI - FN check if this is accurate - currently MM-4.0.D1.1 has no type * JR - subtle differences of Block vs Page mode need investigation. + FN - page 5, discussion of lmr_unlink called by unprivileged consumers # JR - wonders about the scenario of unprivileged consumer interfering with privileged LMRs - presumes PD will protect against this * Any other business o JR - mentions work on man pages for CM + Intent to generate pages for company review by end of September o FN - will raise priority of work on narrow window binding man pages o JH - will errata be incorporated in stage 1 of phase 2 draft release? + JR - recognizes that resources are so tight at the moment that new functionality may be all that can be achieved by end September o JR mentions need to look at prioritization of stage 2 of phase 2 + JH - thinks errata incorporation would have to be raised in priority. Meeting adjourns at the 120-minute mark Content-Disposition: form-data; name="link1"