On Thu, May 21, 2015 at 07:52:36AM -0600, Wan, Kaike wrote: > > The general format of the request and response will be the same: > > ------------------ > | netlink header | > ------------------ > | Data header | > ------------------ > | Data | > ------------------ > > The data header contains information about the type of request/response, the status (for response), > the type (format) of the data, the total length of the data header + data, and a flags field about > the request/response or data. > > Based on the type of the data, the data section may be in different format: a string about the host > name to resolve, an IP4/IP6 address, a pathrecord, a user pathrecord (struct ib_user_path_rec), > or simply a MAD (like our posted patches), etc. I think given the new plans this is not really necessary. > > Essentially it can be of any format based on the > data type. The key is to document the format so that the kernel and user space can communicate > correctly. > > The details are described below: > > #define IB_NL_VERSION 0x01 Change all "IB" to "RDMA" > > #define IB_NL_OP_MASK 0x0F > #define IB_NL_OP_RESOLVE 0x01 > #define IB_NL_OP_QUERY_PATH 0x02 > #define IB_NL_OP_SET_TIMEOUT 0x03 > #define IB_NL_OP_ACK 0x80 > > #define IB_NL_STATUS_SUCCESS 0x0000 > #define IB_NL_STATUS_ENODATA 0x0001 If we do what Doug suggested should we just make OP 16bits with the high bit ACK/NACK? Then use the other u8 as a detailed status if needed. > > #define IB_NL_DATA_TYPE_INVALID 0x0000 > #define IB_NL_DATA_TYPE_NAME 0x0001 > #define IB_NL_DATA_TYPE_ADDRESS_IP 0x0002 > #define IB_NL_DATA_TYPE_ADDRESS_IP6 0x0003 > #define IB_NL_DATA_TYPE_PATH_RECORD 0x0004 > #define IB_NL_DATA_TYPE_USER_PATH_REC 0x0005 Do we need both PATH_RECORD and USER_PATH_REC? I'm having trouble determining when the OP == QUERY_PATH and the DATA_TYPE != PATH_RECORD. Why don't we remove "QUERY_PATH" above and allow OP == RESOLVE and DATA_TYPE == PATH_RECORD be a "query for path record"? > #define IB_NL_DATA_TYPE_MAD 0x0006 I would drop this for now. > > #define IB_NL_FLAGS_PATH_GMP 1 > #define IB_NL_FLAGS_PATH_PRIMARY (1<<1) > #define IB_NL_FLAGS_PATH_ALTERNATE (1<<2) > #define IB_NL_FLAGS_PATH_OUTBOUND (1<<3) > #define IB_NL_FLAGS_PATH_INBOUND (1<<4) > #define IB_NL_FLAGS_PATH_INBOUND_REVERSE (1<<5) > #define IB_NL_FLAGS_PATH_BIDIRECTIONAL (IB_PATH_OUTBOUND | IB_PATH_INBOUND_REVERSE) > #define IB_NL_FLAGS_QUERY_SA (1<<31) > #define IB_NL_FLAGS_NODELAY (1<<30) > > struct ib_nl_data_hdr { > __u8 version; > __u8 opcode; > __u16 status; > __u16 type; > __u16 reserved; > __u32 flags; > __u32 length; The overall message length is in the netlink header. So keeping in mind Jasons comments regarding returning multiple data records. I think this should be the length of individual records with a "num records" also specified. I would much prefer this over the yucky IBTA RMPP method of implicit record sizes needing to be divided into the overall message size. > }; Should we have a "class" value in the header somewhere? With multiple user space listeners it could be easier to mux messages with such a value. The class/seq would then differentiate the message. > > struct ib_nl_data { > struct ib_nl_data_hdr hdr; > __u8 data[0]; > }; > > > These defines and structures can be added to file include/upai/rdma/rdma_netlink.h (replace with > RDMA_NL prefix) or contained in a seperate file (include/upai/rdma/ib_netlink.h ???). This is not as important as getting the protocol down. Ira -- 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