> Study of objects: > 'device','port' - Pre-existing and read-only, query_object returns > information like we have today > 'pd','mr','mw','cq','srq','qp','ah' - Basic objects, not all have a > modify/query > 'flow','xrc',etc - extra objects IMO, we should examine what items are objects. E.g. and XRC RQ is treated as a QP, whereas an SRQ is not. It may make more sense to treat each QP type as separate objects. It would definitely make the data structures more efficient and a lot more understandable. > Additional entry points: > poll_cq/req_notify_cq - These are high speed, so simple ioctls, or > driver specific > post recv/send - drivers implement these via call_driver_on_object > attach/detach mcast - Could be 'modify' a qp, or could be new ioctls > async_event - Should be an ioctl > get_fd - Convert the object to a fd (eg async_fd, comp_channel, etc) We could define a generic event_channel/event_queue object to report asynchronous events. The EQ could then be associated with a device, port, CQ, CM objects (e.g. QP), etc. User space could achieve current semantics by limiting which objects are associated with each channel. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
