As I said before this is really what we should do so thanks, however, see below.
On Tue, 26 Mar 2013 11:31:15 -0700 Boris Chiu <[email protected]> wrote: > From 493e8ed95e32f9c3e337f758a979120392c9e412 Mon Sep 17 00:00:00 2001 > From: Brendan Doyle <[email protected]> > Date: Tue, 12 Mar 2013 19:38:52 +0000 > Subject: [PATCH] libibmad: To reserve upper 8 bits of tid used by solaris > SRIOV driver > > Signed-off-by: Brendan Doyle <[email protected]> > --- > src/mad.c | 8 ++++++++ > src/rpc.c | 2 +- > 2 files changed, 9 insertions(+), 1 deletion(-) > > diff --git a/src/mad.c b/src/mad.c > index 70a69dd..fe1305d 100644 > --- a/src/mad.c > +++ b/src/mad.c > @@ -50,6 +50,13 @@ > #undef DEBUG > #define DEBUG if (ibdebug) IBWARN > > +#define GET_IB_USERLAND_TID(tid) (tid & 0x00000000ffffffff) > +/* > + * Generate the 64 bit MAD transaction ID. The upper 32 bits are reserved for > + * use by the kernel. We clear the upper 32 bits here, but MADs received from > + * the kernel may contain kernel specific data in these bits, consequently > + * userland TID matching should only be done on the lower 32 bits. > + */ > uint64_t mad_trid(void) > { > static uint64_t base; > @@ -62,6 +69,7 @@ uint64_t mad_trid(void) > trid = random(); > } > next = ++trid | (base << 32); > + next = GET_IB_USERLAND_TID(next); Sorry, I guess I should have specified that we don't need "base" any longer. I am going to combine the removal of base with your patch and accept this. Thanks, Ira > return next; > } > > diff --git a/src/rpc.c b/src/rpc.c > index 5cb13f1..7d93180 100644 > --- a/src/rpc.c > +++ b/src/rpc.c > @@ -129,7 +129,7 @@ static int > _do_madrpc(int port_id, void *sndbuf, void *rcvbuf, int agentid, int len, > int timeout, int max_retries, int *p_error) > { > - uint32_t trid; /* only low 32 bits */ > + uint32_t trid; /* only low 32 bits - see mad_trid() */ > int retries; > int length, status; > > -- > 1.7.9.2 > -- Ira Weiny <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
