Interconnect Software Consorium Socket API Extensions Working Group. -------------------------------------------------------------------- Meeting: Thursday 28th March 2002 21:00GMT (04:00p EST, 03:00p CST, 01:00p PST, 22:00CET, 06:00JST+) Toll Free (US & Canada): 1-888-742-8686 International: +1-303-928-2600 Conference ID: 3378790 -------------------------------- Attendees: Bob Teisler, Compaq Satya Sharma, IBM Jeff Messing, IBM Vishwanath Subramanian, HP Annie Foong, Intel John Kasperski, IBM Juliana Hsu, IBM Louis Laborde, HP -------------------------------- Agenda: 0. dme is gone on holiday so Satya is going to run the meeting. 1. Agenda bashing. Debate about what we'll be doing in it. - Going through the requirements as specified in the HP document John K. - Please make subject lists in the mailing list debates accurate and tied to the HP document. Vish - Do we have agreement on the broad areas of the document? 1. Async Interfaces 2. Memory Buffer Management APIs 3. Completion Event Queues - Does it work in the sync case? (needs to support both). 2. Going through the HP requirements document point by point. 1. API's needing async versions a. write/read, writev/readv routines. Do we need to support async versions of these? result : Not settled. In general it was thought to be outside the scope of the socket extensions and did not provide needed software functionality. Louis wants fileio to be covered b. a send_file API was brought up. result : I believe we decided that this was not needed. 2. async connect/accept a. connect isn't needed b. accept isn't an API interface, but rather an event for the completion queue. 3. Initiation of multiple calls could be supported. a. Agreed to remove this item. 4. Canceling operations a. Agreed to settle on an API to cancel all outstanding operations. - basically to move all resources for outstanding calls to the completion queue. The user still needs to read these of that queue. Any operations already finished will be untouched on the completion queue. b. No other canceling needed. 5. Status on operations a. Agreed to remove this item. 6. Ordering async tx packets a. Can we guarantee that the API doesn't scramble the order Result : We agreed on the concept, but couldn't on the wording. The problem centered around whether it was sufficient to say the API wouldn't cause a reorder, or to require that the API guarantee the order for the transport layer. 7. Async calls can specify a signal to issue when CQ has data a. even with an event queue it will also need a signal to kick it off. result: Much debate. Centered around whether the signal was needed in the API beyond a thread sitting on the CQ routine waiting for new postings. Nothing decided (ran out of time). 8. Ran out of time on review. Debate about whether we needed a thread on each point in the document. a. Agreed to debate it online. In groups of about 5, till settled then on to the next one. b. Include one thread for what we've already agreed on. Jeff : I do not think this has been started yet. 3. next week we are going to go through a simple send/recv async model to see how it all fits together. -------------------------------- Outstanding Actions: None.. -------------------------------- Next Meeting: Thursday 11th April 2002 21:00GMT (04:00p EST, 03:00p CST, 01:00p PST, 22:00CET, 06:00JST+) Toll Free (US & Canada): 1-888-742-8686 International: +1-303-928-2600 Conference ID: 3378790 -------------------------------- Contact Details: email: icsc-socketwg@opengroup.org web: http://www.opengroup.org/icsc/sockets/