> +++ b/SRC.txt
> @@ -0,0 +1,138 @@
> +Here's some documentation on Scalable Reliable Connections.
I think this would be more useful in the man page for
ibv_open_src_domain() (which needs to be written ;).
You know, reading over the patch, it strikes me that "src" is a very
confusing acronym, since it really looks like an abbreviation for
"source." I don't know what would be better off the top of my head
but ideas would be appreciated.
> --- a/src/libibverbs.map
> +++ b/src/libibverbs.map
> @@ -24,6 +24,7 @@ IBVERBS_1.0 {
> ibv_get_cq_event;
> ibv_ack_cq_events;
> ibv_create_srq;
> + ibv_create_src_srq;
> ibv_modify_srq;
> ibv_query_srq;
> ibv_destroy_srq;
> @@ -35,6 +36,8 @@ IBVERBS_1.0 {
> ibv_destroy_ah;
> ibv_attach_mcast;
> ibv_detach_mcast;
> + ibv_open_src_domain;
> + ibv_close_src_domain;
> ibv_cmd_get_context;
> ibv_cmd_query_device;
> ibv_cmd_query_port;
These new symbols definitely don't belong in the IBVERBS_1.0 ABI. In
fact since this all changes structure layout I think we need to create
an IBVERBS_1.2 ABI and create compat-1_1.c to deal with it.
Also, if we're going to change the signature of the create_srq method:
> struct ibv_srq * (*create_srq)(struct ibv_pd *pd,
> + struct ibv_src_domain *src_domain,
> + struct ibv_cq *src_cq,
> struct ibv_srq_init_attr
> *srq_init_attr);
then I think we need something like
#define IBV_CREATE_SRQ_METHOD_HAS_SRC_PARAMS
so that driver libraries can still work with both old and new
libibverbs. I'm not sure the gain of avoiding a new entry point is
worth forcing every driver library (even the ones that don't do SRC)
to change -- it might be better to mimic the consumer API and just
have a new create_srq_srq method. That way driver libraries that
don't do SRC would stay source compatible (I think).
- R.
_______________________________________________
general mailing list
general@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
