ICSC ITWG Meeting Minutes, 2. Nov. 2004 Taking minutes: IBM (fn) Time: 10:00 am - 12:00 am PDT Participant code: 356608 US Dialin: 1 866 874 0872 Intl Dialin: +44 1452 562 905 UK Dialin: 0845 146 2019 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 10/05 + + - - m-2 10/19 + + - - m-1 10/26 + + - - m-0 11/02 + + - - Present: jim hamrick (jh) [HP] fredy neeser (fn) [IBM] jay rosser (jr) [HP] Agenda bashing: Minutes to approve: Email from Jay Rosser, subject "ICSC ITWG draft minutes 10/19/04", sent 10/19/04 2:29PM PT. - Minutes approved. Action item review: AI – MM group to create text to describe potential hazard of use of stale STags with fast re-registration use model. fn: Closed last time (text was added to it_lmr_link man page.) AI – fn/jr – Can an RMR or LMR be linked or unlinked via an Endpoint in the unconnected state on InfiniBand? jh: For IB RC service, one can only post WRs if QP is in RTS state. See Chapter 10, p. 433/434 for what you can do in various states. Cannot post any WR to the Send Queue if QP is not in RTS state. jr: Declares AI as closed. AI – MM group – determine if a QP can be destroyed or reset if MWs are associated with it (for IB, IBVE, and iWARP). jr: For IBVE, if a QP has a Type 2A MW associated with it, destroy QP will fail. Also for iWARP, if QP has a Narrow MW associated with it, destroy QP will fail. AI closed. AI - jr - emit proposal on how to deal with turning off IOH for DAT compatibility. jr: DAT compatibility. Two possibilities. P1 is to drop private data and IOH from the TII. P2 to add private data to the TDI. fn: Expresses preference for publishing IOH as a separate standard document. jh: RDDP WG is unlikely to change MPA REQ/REP based on the differences between IB and iWARP. RDDP seems to have a preference to leave IRD/ORD negotiation to ULP. Preference for P1 (turning off IOH). jr: DAT 1.2 now has a statement regarding IRD/ORD and suggest to convey IRD/ORD through private data. For compatibility with DAT, IRD/ORD must be negotiated through private data. jh: on the passive side, should be able to specify when creating a listen point that IOH should be turned off. Consumer knows that listen point will only be able to communicate with DAT applications on the active side. jh: Don’t expect a heterogeneous API environment for IPC. Would be surprised to find the IT-API on the server side in a SAN. jr: Non-IT-API client not able to communicate to an IT-API server app using the TII, unless we provide the capability to turn off the IOH on the passive side. jr: Will add capability in proposal to turn off IOH for both active and passive side. iWARP CM issues: Discussion on interoperability and RDMAP/DDP version number problem: jr: IOH could request version number and the peer could accept or reject. Support for downgrading version number requires the per-QP capability that is currently being discussed in the RNIC-PI WG to enable RDMAC compatibility. jr: Currently, we say that the TII requires markers. If markers are negotiated, helps to increase set of devices supported by the TII by allowing the TII not to use markers. jr: TII consumer using a device not having any marker capabilities. No need to expose this to the consumer. fn: Valid idea to support more devices. jh: Will not help for interoperability with other APIs. jr: For IT-API, not to difficult to add this capability to IOH. jr: AI for jr to send concrete proposal to allow TII to negotiate version number as well as the marker setting. fn: AI for fn – If there are no news regarding RDMAC-IETF interoperability and the version number problem after the next RNIC-PI meeting, ask John Carrier for an update regarding RDMAC status. Additional items brought up for discussion: fn: Discusses different approaches for handling remotely detected errors. One example is handling of remote access violation in iWARP and IB. Another example is handling an invalid STag in a “Send and Invalidate” message. all: Agreed that transport-dependent error handling cannot be hidden by API and should be explained in the Extended Description. fn: Mentions that RNIC-PI WG is interested in additional requirements we might have for them, e.g., for MM. fn: Thinks that this will be mostly the extensions for handling multiple PBL types. Need to finialize and vote MM requirements first. [jh leaves the call] Discussion on purpose of remote access flag: fn: remote access flag is a MR attribute that is persistent across MR invalidations/fast-registrations. Current plan is to turn the flag on always and to not expose it to IT-API consumers. So far, no objections heard. jr: Offers to ask iWARP architects regarding sensible use of MR remote access flag – AI for jr. fn: Mentions that DDP/RDMAP do not check STag validity in zero-length RDMA requests – if that is the case, RTR state is indeed useful. AI for fn to send note on “Zero-length RDMA Write/Read and use of RTR state”. Meeting adjourns 15 minutes late.