[openib-general] cma header - change some things according to the list feedback
James Lentini
jlentini at netapp.com
Thu Aug 25 11:15:01 PDT 2005
Hi Guy,
Looks good. A few small comments below:
On Thu, 25 Aug 2005, Guy German wrote:
> This is the header file, embedding some of the feedbacks received from the list
>
> According to this suggestion - the qp is modified to init/rtr/rts in the
> cm abstraction.
>
> The connection is done with a synchronous call to get a device for qp
> creation. I think it can also be done the way Roland suggested, but I still
> believe this is simpler for consumers (especially for the iwarp oriented ones).
>
> There are still unresolved issues discussed now on the list, but those are mainly
> on the implementation side.
>
> I would like to hear the list opinion on the API, because I'm sure there are
> untied ends on the API side as well.
>
> If someone has a totally different suggestion - can he post it to the list
> for review ?
>
> Thanks,
> Guy
>
>
> /*
> * Copyright (c) 2005 Voltaire Inc. All rights reserved.
> *
> * This Software is licensed under one of the following licenses:
> *
> * 1) under the terms of the "Common Public License 1.0" a copy of which is
> * available from the Open Source Initiative, see
> * http://www.opensource.org/licenses/cpl.php.
> *
> * 2) under the terms of the "The BSD License" a copy of which is
> * available from the Open Source Initiative, see
> * http://www.opensource.org/licenses/bsd-license.php.
> *
> * 3) under the terms of the "GNU General Public License (GPL) Version 2" a
> * copy of which is available from the Open Source Initiative, see
> * http://www.opensource.org/licenses/gpl-license.php.
> *
> * Licensee has the right to choose one of the above licenses.
> *
> * Redistributions of source code must retain the above copyright
> * notice and one of the license notices.
> *
> * Redistributions in binary form must reproduce both the above copyright
> * notice, one of the license notices in the documentation
> * and/or other materials provided with the distribution.
> *
> */
>
> /*
> * This header file as a preliminary proposition for a connection manager
> * abstraction layer (cma) for IB and iwarp
> * - there is an assumption that iwarp uses the same openib qp terminology in
> * the rest of the verbs, and the only place needs abstraction is the cm.
> * - This proposition assumes that the address translation is done in the cma
> * layer.
> * - The cma also modifies the qp states to init/rtr/rts and error as needed.
> * - for calling accept/reject or disconnect on the passive side you need to
> * use the cma handle accepted in ib_cma_listen cb.
> * - cma_id is created when calling connect or listen and destroyed when
> * accepting disconnected/rejected/unreachable events on either active
> * side (connect cb) or passive side (accept cb)
> */
>
> #ifndef IB_CMA_H
> #define IB_CMA_H
>
> #include <linux/socket.h>
>
> enum ib_cma_event {
> IB_CMA_EVENT_ESTABLISHED,
> IB_CMA_EVENT_REJECTED,
> IB_CMA_EVENT_NON_PEER_REJECTED,
> IB_CMA_EVENT_DISCONNECTED,
> IB_CMA_EVENT_UNREACHABLE
> };
>
> enum ib_qos {
> IB_QOS_BEST_EFFORT = 0,
> IB_QOS_HIGH_THROUGHPUT = (1 << 0),
> IB_QOS_LOW_LATENCY = (1 << 1),
> IB_QOS_ECONOMY = (1 << 2),
> IB_QOS_PREMIUM = (1 << 3)
> };
>
> enum ib_connect_flags {
> IB_CONNECT_DEFAULT_FLAG = 0x00,
> IB_CONNECT_MULTIPATH_FLAG = 0x01
> };
>
> /*
> * for ib_cma_get_src_ip - ib_cma_id will have to include
> * the path data received in the request handler
> */
> union ib_cma_id{
> struct ib_cm_id *cm_id;
> u32 iwarp_id;
> };
>
> typedef void (*ib_cma_rarp_handler)(struct sockaddr *src_ip, void *context);
How about ib_cma_addr_handler? By using the string rarp, you imply
that RARP is being used.
> typedef void (*ib_cma_ac_handler)(enum ib_cma_event event, void *context);
> typedef void (*ib_cma_event_handler)(enum ib_cma_event event, void *context,
> void *private_data);
Would ib_cma_conn_handler be more appropriate?
> typedef void (*ib_cma_listen_handler)(union ib_cma_id *cma_id,
> struct ib_device *device,
> void *private_data, void *context);
>
> struct ib_cma_conn {
> struct ib_qp *qp;
> struct ib_qp_attr *qp_attr;
> struct sockaddr *dst_ip;
> __be64 service_id;
> struct ib_recv_wr *recv_wr,
> u32 num_recv_wr,
> void *context;
> ib_cma_event_handler cma_event_handler;
> const void *private_data;
> u8 private_data_len;
> u32 timeout;
> enum ib_qos qos;
> enum ib_connect_flags connect_flags;
> };
>
>
> /**
> * ib_cma_get_device - Returns the device to be used according to
> * the destination ip address (this can be detemined according
> * to the local routing table). Call this function before
> * creating the qp. If using link-local IPv6 addresses
> * there is no need to call this function.
> * @remote_address: The destination address for connection
> * @device: The device to use (returned by the function)
> */
> int ib_cma_get_device(struct sockaddr *remote_address,
> enum ib_qos qos, struct ib_device **device);
>
>
> /**
> * ib_cma_connect - this is the connect request function, called by
> * the active side. The consumer registers an upcall that will be
> * initiated by the cma with an appropriate connection event
> * notification (established/rejected/disconnected etc)
> * @cma_conn: This structure contains the following connection parameters:
> * @qp: qp for establishing the connection
> * @qp_attr: only relevant attributes are used
> * @dst_ip: destination ip address
> * @service_id: destination service id (port)
> * @recv_wr: An array of work requests to post on the receive queue.before
> * sending the RTU
> * @num_recv_wr: recv_wr array length - number of buffers to post recv
> * @context: context to be returned in the callback
> * @cma_event_handler: the upcall function for the active side
> * @private_data: private data to be received at the listener upcall
> * @private_data_len: private data length (max 255)
> * @timeout:
> * @qos: Quality os service for the rc
> * @connect_flags: default or multipath connection
> * @cma_id: This returned handle is a union (different in ib and iwarp)
> * in ib - it is the cm_id.
> */
> int ib_cma_connect(struct ib_cma_conn *cma_conn,
> union ib_cma_id *cma_id);
>
Should there be a way to cancel an ib_cma_connect() call?
>
> /**
> * ib_cma_disconnect - this function disconnects the rc. It can be
> * called, by either the passive or active side
> * @qp: the connected qp to disconnect
> * @cma_id: On the active side- this handle is the one returned
> * when ib_cma_connect was called.
> * On the passive side- this handle was accepted in cma_listen callback
> */
> int ib_cma_disconnect(struct ib_qp *qp, union ib_cma_id *cma_id);
>
>
> /**
> * ib_cma_sid_listen - this function is called by the passive side. It is
> * listening on a the specified port (ib service id) for incomming
> * connection requests
> * @device:
> * @address:
> * @service_id: service id (port) to listen on
> * @context: user context to be returned in the callback
> * @cm_listen_handler: the listen callback
> * @cma_id: cma handle for the passive side
> */
> int ib_cma_sid_listen(struct ib_device *device, struct sockaddr *address,
> __be64 service_id, void *context,
> ib_cma_listen_handler cm_listen_handler,
> union ib_cma_id *cma_id);
Given the new sockaddr parameter, I think you should rename this
function ib_cma_listen().
>
>
> /**
> * ib_cma_sid_destroy - this functionis is called on the passive side, to
> * stop listenning on a certain sevice id
> * @cma_id: the same cma handle received when ib_cma_sid_listen was called
> */
> int ib_cma_sid_destroy(union ib_cma_id *cma_id);
I'd also change this to ib_cma_destroy().
> /**
> * ib_cma_accept - call on the passive side to accept a connection request
> * @cma_id: this handle was accepted in cma_listen callback
> * @qp: the connection's qp
> * @private_data: private data to send back to the initiator
> * @private_data_len: private data length
> * @recv_wr: An array of work requests to post on the receive queue.before
> * sending the REP
> * @num_recv_wr: recv_wr array length - number of buffers to post recv
> * @context: user context to be returned in the callback
> * @cm_accept_handler: the cma accept callback - triggered when RTU ack
> * received
> */
> int ib_cma_accept(union ib_cma_id *cma_id, struct ib_qp *qp,
> const void *private_data, u8 private_data_len,
> struct ib_recv_wr *recv_wr, u32 num_recv_wr,
> void *context, ib_cma_ac_handler cm_accept_handler);
>
> /**
> * ib_cma_reject - call on the passive side to reject a connection request.
> * This call destroys the cma_id, hence when the active side accepts
> * the reject the cma_id is already destroyed.
> * @cma_id: this handle was accepted in cma_listen callback
> * @private_data: private data to send back to the initiator
> * @private_data_len: private data length
> */
> int ib_cma_reject(union ib_cma_id *cma_id, const void *private_data,
> u8 private_data_len);
>
>
> /**
> * ib_cma_get_src_ip - this function performs "rarp", asynchronicly
> * from cma_id to src ip
> * @cma_id: the cma_id will have to include the path data received
> * in the request handler
> * @src_ip: source ip of the initiator
> */
> int ib_cma_get_src_ip(union ib_cma_id *cma_id,
> ib_cma_rarp_handler rarp_handler,
> void *context);
>
> #endif /* IB_CMA_H */
>
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
More information about the general
mailing list