On Mon, 2018-07-16 at 23:03 +-0300, Yuval Shaia wrote: +AD4- RDMA MAD kernel module (ibcm) disallow more than one MAD-agent for a +AD4- given MAD class. +AD4- This does not go hand-by-hand with qemu pvrdma device's requirements +AD4- where each VM is MAD agent. +AD4- Fix it by adding implementation of RDMA MAD multiplexer service which on +AD4- one hand register as a sole MAD agent with the kernel module and on the +AD4- other hand gives service to more than one VM. +AD4- +AD4- Design Overview: +AD4- ---------------- +AD4- A server process is registered to UMAD framework (for this to work the +AD4- rdma+AF8-cm kernel module needs to be unloaded) and creates a unix socket to +AD4- listen to incoming request from clients. +AD4- A client process (such as QEMU) connects to this unix socket and +AD4- registers with its own GID. +AD4- +AD4- TX: +AD4- --- +AD4- When client needs to send rdma+AF8-cm MAD message it construct it the same +AD4- way as without this multiplexer, i.e. creates a umad packet but this +AD4- time it writes its content to the socket instead of calling umad+AF8-send(). +AD4- The server, upon receiving such a message fetch local+AF8-comm+AF8-id from it so +AD4- a context for this session can be maintain and relay the message to UMAD +AD4- layer by calling umad+AF8-send(). +AD4- +AD4- RX: +AD4- --- +AD4- The server creates a worker thread to process incoming rdma+AF8-cm MAD +AD4- messages. When an incoming message arrived (umad+AF8-recv()) the server, +AD4- depending on the message type (attr+AF8-id) looks for target client by +AD4- either searching in gid-+AD4-fd table or in local+AF8-comm+AF8-id-+AD4-fd table. With +AD4- the extracted fd the server relays to incoming message to the client. Has this been tested with the SRP protocol? I'm wondering whether this makes it possible to run the ib+AF8-srpt driver and/or the srp+AF8-daemon software in a KVM virtual machine. Thanks, Bart. -- 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
