Interconnect Software Consorium Socket API Extensions Working Group. -------------------------------------------------------------------- Meeting: Thursday 14th 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 -------------------------------- Present: Bob Teisler, Compaq Jack McCann, Compaq Masanori Itoh, Fujitsu Satya Sharma, IBM Jeff Messing, IBM Vishwanath Subramanian, HP David Edmondson, Sun Jeremy Harris, Sun Annie Foong, Intel John Kasperski, IBM Juliana Hsu, IBM Louis Laborde, HP -------------------------------- Agenda: 1. Agenda bashing. None. 2. Review action items. See below. 3. Areas of interest discussions. Walk through the current requirements list, based on Jeff's excellent kqueue summary. 3. Requirements from the kqueue spec and others point by point 1P : Memory copies across the kernel boundary. Jeff - clarified that this was refering to the meta data not the user's IO data. 2P : Stateless API's scale poorly Bob - stateless APIs are a traditional in unix cmds and this may be moving away from that Jeff - the socket in a socket interface, is a stateful object. Also async solutions inherently have state associated with them. 3P : duplication of work between application and kernel space - No Comments 4P : Inflexible design - Biggest discussion of the call. The debate is between the scale of the calls. Do they cover netio, netio & fileio, or netio, fileio & other waitable events. Bob - want to be able to wait on different things (semaphores, ipc ...) Jeff - want to cover both sync and async data status (select replacement) Jeremy - fileio and netio consolidation at a minimum Bob - do we want to limit ourselves to just these? John - only netio might be good, from a performance tuning standpoint (and charter) dme - from app experience, specialized interfaces are lost in many multi-platform apps, in generalized wrapper routines - Juliana agreed Annie - What about RDMA issues dme - User level program, the FD is insufficient to convey the state information between processes Masanori - need a transport end-to-end way to pass this kind of info dme - new scheme has to work with common OS functions - We do not want to purposely break non-unix versions, but not in our charter to make this work beyond unix Louis - We would need new, complex libraries to support these. Juliana/Satya - up shot of conversation is to keep fileio and netio requirments and keep other events in mind as an expansion of this interface. John - How do you use sendto or recvfrom with fileio? Satya - Only make this requirement in regards to completion status and routines that have obvious overlays (read, write ...) 5P : Scaling - No comments 6P : Limited information returned from user Jeremy - We want to return not only that there is data, but how much and where it was put Satya - Need to balance this with working for sync commands also. 7P : Large Multilevel structures in APIs - No Comments 8P : Current socket API doesn't support upcoming protocols (SCTP) dme - doesn't understand Mike K's perspective that this isn't an API issue Satya - include requirments from existing new protocols (SCTP) Bob - not from SCTP specifically, but its generalized capabilities need to be covered (i.e. transport level fault tolerance ...) - extract its requirements and meet these Annie - agreed 9P : User lvel transport implementation dme - need a write up on what this problem is exactly. Vish - consolidation of events across applications and kernel, implemention dependent not API. 4. AOB. Apologies from dme for not giving out the full details for the conference call, and for being late in arriving. -------------------------------- Outstanding Actions: 2002-03-07/01 (dme) Talk to Martin Kirk about document formatting. Martin: final API specifications will need to be in troff (to match SUS). A web-based collaboration tool is available for comment tracking, etc. dme: stick with ascii for the requirements spec. for now. DONE: 2002-03-11 2002-03-07/02 (Jeff) Produce a summary of requirements extracted from the kqueue paper and send it to the list. Done: 2002-03-13 2002-03-07/03 (dme) Product a summary of requirements extracted from experience with /dev/poll. dme: Aiming for next week. 2002-03-07/04 (dme) Send a pointer to the Linux AIO notes paper to the list. DONE: 2002-03-07 2002-03-07/05 (Satya) Open a dialogue with the Interconnect Transport API working group about buffer management. Satya: conversation with the working group chair has taken place. Agreement that we should examine working together, perhaps including creation of a small sub-team with members from both groups. Wait a couple of weeks to let both groups requirements settle. Done: 2002-03-14 2002-03-11/01 (Martin Kirk) Prepare a sample document to allow the group to experiment with the online comment tracking system. Done: 2002-03-14 2002-03-14/01 (dme) Agenda item for next week: discuss AIO interfaces specifically, including how they relate to POSIX. -------------------------------- Next Meeting: Thursday 21st 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 -------------------------------- Contact Details: email: icsc-socketwg@opengroup.org web: http://www.opengroup.org/icsc/sockets/