about scif support

[cque7]

Hi, SCIF is a group of fast communication APIs for Intel's XEON PHI, does zeromq have plans to support SCIF?

Thanks.

[bluca]

Hi, do you have any pointer for documentation/summary of this feature?

In general, we are happy to accept contributions that add support for new transports (see for example VMCI and TIPC), but we need volunteers to implement them :-)

[cque7]

Thanks for the reply. Following is an introduction of SCIF: http://www.intel.com/content/dam/www/public/us/en/documents/pdf/true-scale-xeon-phi-coprocessor-overview.pdf

Where can I find documents on how to add support for new transports? The example code or patch of VMCI and TIPC should be good enough. I am thinking to use zmq in XEON PHI and I'd like to add some code in ZMQ to support XEON PHI.

[bluca]

That looks very interesting!

Not sure we have proper documentation for this, but for the VMCI and TIPC examples you can look at the corresponding files in src:

https://github.com/zeromq/libzmq/tree/master/src

Check for the files: tipc.cpp/hpp and vmci.cpp/hpp In short, you'll have to create subclasses to deal with the endpoint address (scif_address.cpp/hpp), the serverish socket (scif_listener.cpp/hpp) and the clientish socket (scif_connecter.cpp/hpp), and then the glue code to call the new classes and functions in the socket_base and other places (see other PRs, or maybe grep for ZMQ_HAVE_TIPC).

Plus the autotools and CMake stuff in configure.ac, Makefile.am and CMakeLists.txt to check if the feature is available at build time. The convention is to add a new ZMQHAVE* constant, so something like ZMQ_HAVE_SCIF if it's available.

You can check most of the places you have to add the glue code in the VMCI and TIPC pull requests:

https://github.com/zeromq/libzmq/pull/1654 https://github.com/zeromq/libzmq/pull/730

And please add unit tests too :-)

As for the contribution process it's up to you if you want to wait to implement the whole thing before sending a PR that is fine. But you can also send small incremental PRs, by starting from the build system bits, so that you can add your feature without risking to break the build, and then sending for example the endpoint parsing login with its unit test first, and then the client socket, and so on. Or any other way you like. As long as the non-scif build is not broken, we can merge stuff.

Something that might be very useful for you, if you are not familiar with it already, is setting up the Travis and Appveyor CI systems for your fork. Fork libzmq, and then head to: https://travis-ci.org/profile and https://ci.appveyor.com/projects/new and login with your github account, and then enable libzmq. Then, every time you push something to github, Travis will run the Linux and OSX tests, and Appveyor will run the Windows one (which are currently broken btw).

We don't require waiting for the CI to pass before merging, but we do require that a breakage is either fixed or reverted if it impacts other users.