Re: What's with the qmf::org::apache::qpid namespaces?

[Ted Ross <tr...@redhat.com>]

Alan Conway wrote:
> They're very un-C++ and inconsistent with all our other use of
> namespaces. Is there some compelling reason for imposing this nasty
> Java-esque namespace on C++ code? In particular it means we are using
> names in the global namespace rather than one, which is ugly.
>
> Cheers,
> Alan.
>
>   
Alan,

We now have five extension packages in the management framework and more 
on the way.  They are being developed by diverse and unrelated groups.  
We need a namespace structure for the management schemas to ensure that 
there are no collisions in the global set.  Furthermore, some of these 
packages are used in qpidd plug-ins which means they need to work within 
the C++ namespace because they are linked into the broker.

What we were doing before the change was to put all generated management 
code in qpid::management.  This did not scale and we already had a name 
collision.  To fix the problem, I matched the C++ namespaces to the 
management package namespaces and also matched the directory structure.

I chose the "Javaesque" namespace because it really does solve the 
multi-domain, multi-enterprise naming problem which we have in the 
management framework.

Would it have been better to have chosen qpid::qmf::... rather than ::qmf?

If there are things that need to be fixed, let's do it now so as to 
minimize the impact on our development user community.

-Ted

Re: What's with the qmf::org::apache::qpid namespaces?

[Andrew Stitcher <as...@redhat.com>]

Thinking some more on this issue ...

On Thu, 2008-09-25 at 08:57 -0400, Ted Ross wrote:
> Alan Conway wrote:
> > They're very un-C++ and inconsistent with all our other use of
> > namespaces. Is there some compelling reason for imposing this nasty
> > Java-esque namespace on C++ code? In particular it means we are using
> > names in the global namespace rather than one, which is ugly.
> >
> > Cheers,
> > Alan.
> >
> >   
> Alan,
> 
> We now have five extension packages in the management framework and more 
> on the way.  They are being developed by diverse and unrelated groups.  
> We need a namespace structure for the management schemas to ensure that 
> there are no collisions in the global set.  Furthermore, some of these 
> packages are used in qpidd plug-ins which means they need to work within 
> the C++ namespace because they are linked into the broker.
> 
> What we were doing before the change was to put all generated management 
> code in qpid::management.  This did not scale and we already had a name 
> collision.  To fix the problem, I matched the C++ namespaces to the 
> management package namespaces and also matched the directory structure.

I think what you are saying here is that you've changed the internal
code structure of the qpid c++ code because of a *schema* naming
problem.

I assume this is because of some simple minded assumptions in the code
generated to marshal the schema data structures. Why not change the
generated code that sits inside qpidd so that it fits better with the
existing namespace use whilst maintaining the necessary schema
namespace.

/me ducks and goes back to rdma performance work

Andrew

Re: What's with the qmf::org::apache::qpid namespaces?

[Alan Conway <ac...@redhat.com>]

On Thu, 2008-09-25 at 09:06 -0400, Carl Trieloff wrote:
> >
> >
> > Would it have been better to have chosen qpid::qmf::... rather than 
> > ::qmf?
> >
> > I
> 
> I would think that would be cleaner
> Carl.

Or qpid::management::... , the 'q' in qmf is redundant after qpid::

Cheers,
Alan.

Re: What are Qpid's plans for RDMA?

[Andrew Stitcher <as...@redhat.com>]

On Thu, 2008-09-25 at 20:20 -0400, gregory james marsh wrote:
> 
> Hello,
> 
> I'm with the Network-Based Computing Lab at Ohio State University.  Our
> lab primarily does research with the Message Passing Interface (MPI) over
> interconnects like InfiniBand and RDMA.  Recently we have started
> evaluating/testing Qpid with the TCP adaptations to InfiniBand (Sockets
> Direct Protocol [SDP] and IP over InfiniBand [IPoIB]).
> 
> We would like to know more about where the Qpid project plans to go with
> RDMA.  Could anyone give me a brief overview and anticipated timeline of
> the planned functionality?

As of svn revision 697101 The RDMA support in trunk qpid is pretty
stable so if you are using a trunk version more recent than that you
have RDMA support.

The more recent changes have been performance/scalability related.

RDMA is implemented as 2 protocol plugins one for the broker side
(rdma.so) and one for the client side (rdmaconnector.so). In an
installed broker/client library the modules will be found/loaded
automatically. If compiling from scratch the GNU defaults are used and
the modules end up in /usr/local/lib/qpid/daemon
& /usr/local/lib/qpid/client.

However if you are running from within the development tree you'll need
--load-module <path to rdma.so> added to your broker command line. And
you'll need something like:

export QPID_LOAD_MODULE=<path to rdmaconnector.so>

before you run your client code to enable the client library to find the
rdma module.

If you are using the test client in the qpid source tree you can add -P
rdma (or --protocol rdma) to tell them to use rdma instead of tcp. As we
use rdmacm for connection management Infiniband connections need to be
running IPoIB with an assigned IP address as this is used by rdmacm.

>   I've noticed some RDMA-related code submissions to the C++ trunk
> this month by Andrew Stitcher.  I've been able to run the C++ broker
> listening for RDMA via the RdmaIOPlugin class (at least according to the
> broker log).  However, how does the client side work?  Does the
> RdmaConnector class integrate with the client's Connection class?  Also in
> src/tests I've noticed that "rdma" is an option for the ConnectionOptions
> class.  How will this class fit into the scheme of things?

In your own client code you can set ConnectionOptions.protocol to "rdma"
and provide it to Connection.open to get an rdma connection.

I hope this gives you the info you need.

Andrew

Re: What are Qpid's plans for RDMA?

[Carl Trieloff <cc...@redhat.com>]

The client loads the RDMA plug in via a module loader. To try it out use 
perftest or latencytest

use the option:  -P [ --protocol ] tcp|rdma

on the broker, use --load-module to load the RMDA module.

these are both single file clients, so you can look what is needed to 
update any qpid C++ client for
RDMA by looking at these clients.

The RDMA support is native OFED, broker can listen on more than one 
transport at the same time.

RDMA will be included in the M4 release, code freeze Oct 22 I believe is 
the date M4 close down. release
then after that once committers are happy with it.

Carl.
 
> Hello,
>
> I'm with the Network-Based Computing Lab at Ohio State University.  Our
> lab primarily does research with the Message Passing Interface (MPI) over
> interconnects like InfiniBand and RDMA.  Recently we have started
> evaluating/testing Qpid with the TCP adaptations to InfiniBand (Sockets
> Direct Protocol [SDP] and IP over InfiniBand [IPoIB]).
>
> We would like to know more about where the Qpid project plans to go with
> RDMA.  Could anyone give me a brief overview and anticipated timeline of
> the planned functionality?  I've noticed some RDMA-related code submissions to the C++ trunk
> this month by Andrew Stitcher.  I've been able to run the C++ broker
> listening for RDMA via the RdmaIOPlugin class (at least according to the
> broker log).  However, how does the client side work?  Does the
> RdmaConnector class integrate with the client's Connection class?  Also in
> src/tests I've noticed that "rdma" is an option for the ConnectionOptions
> class.  How will this class fit into the scheme of things?
>
> Thanks in advance for any info,
>
> Greg Marsh
> Network-Based Computing Lab
> Ohio State University
> marshgr@cse.ohio-state.edu
> http://nowlab.cse.ohio-state.edu/
>
>
>
>
>   

What are Qpid's plans for RDMA?

[gregory james marsh <ma...@cse.ohio-state.edu>]

Hello,

I'm with the Network-Based Computing Lab at Ohio State University.  Our
lab primarily does research with the Message Passing Interface (MPI) over
interconnects like InfiniBand and RDMA.  Recently we have started
evaluating/testing Qpid with the TCP adaptations to InfiniBand (Sockets
Direct Protocol [SDP] and IP over InfiniBand [IPoIB]).

We would like to know more about where the Qpid project plans to go with
RDMA.  Could anyone give me a brief overview and anticipated timeline of
the planned functionality?  I've noticed some RDMA-related code submissions to the C++ trunk
this month by Andrew Stitcher.  I've been able to run the C++ broker
listening for RDMA via the RdmaIOPlugin class (at least according to the
broker log).  However, how does the client side work?  Does the
RdmaConnector class integrate with the client's Connection class?  Also in
src/tests I've noticed that "rdma" is an option for the ConnectionOptions
class.  How will this class fit into the scheme of things?

Thanks in advance for any info,

Greg Marsh
Network-Based Computing Lab
Ohio State University
marshgr@cse.ohio-state.edu
http://nowlab.cse.ohio-state.edu/

Re: What's with the qmf::org::apache::qpid namespaces?

[Andrew Stitcher <as...@redhat.com>]

On Thu, 2008-09-25 at 09:06 -0400, Carl Trieloff wrote:
> >
> >
> > Would it have been better to have chosen qpid::qmf::... rather than 
> > ::qmf?
> >
> > I
> 
> I would think that would be cleaner

Just to pile in on the "bike shed painting" discussion:

I think that qpid::management would actually be a better top level
namespace! The f in qmf is framework which is dispensable, but q - qpid,
m = managenent.

Andrew

Re: What's with the qmf::org::apache::qpid namespaces?

[Carl Trieloff <cc...@redhat.com>]

>
>
> Would it have been better to have chosen qpid::qmf::... rather than 
> ::qmf?
>
> I

I would think that would be cleaner
Carl.