qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: Heads up re Rdma IO state transitions [Was: AsynchIO state transition]
Date Thu, 14 Oct 2010 13:28:51 GMT
On Wed, 2010-10-13 at 21:59 -0700, Aaron Fabbri wrote:
> On Tue, Oct 12, 2010 at 10:22 AM, Andrew Stitcher <astitcher@redhat.com> wrote:
> > For those interested in the Rdma implementation:
> >
> > I've been doing a lot of stability work, stressing the rdma code in odd
> > corner cases (unexpected disconnects mostly). While on this trail I
> > reailised I could simplify the Rdma::AsynchIO state machine drastically
> > by ensuring that all callbacks generated by this layer happen in the
> > "thread context" of the connection.
> Thanks for the heads up.  I'm taking a quick look at the diffs.  By
> "thread context of the connection", do you mean always having these
> callbacks happen from the poller threads?


> Can you give some hints on how this simplified things?

Look at the code, and you will see ;-)

In a little more detail - the Rdma::AsynchIO code is a lot easier to
understand IMO. being sure that all the callbacks happens from an IO
thread with the connection properly serialised makes it easier to not
screw up changes too.

> >
> > After an iteration to improve the performance which added a simple
> > version of the state machine back, we have a version that has very
> > similar throughput, but a little better latency as measured by me on my
> > development boxes.
> What sort of latency improvement are you seeing?

Irrelevant I think given I did no real tuning and this seems to be
important to get good and reliable results. I was only testing in order
to be sure there was no obvious regression.

In other words in my testing the minimum latencies returned by latency
test were not very dissimilar, but the max and avg latencies were


Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message