I'm not sure I agree that ZMQ_AFFINITY should be modified at all. I think that it would be most beneficial if you could still use ZMQ_AFFINITY so that a socket is on a particular I/O thread that has already been pinned to a specific CPU.
On Wed, Feb 8, 2012 at 9:30 PM, Pieter Hintjens <[email protected]> wrote: > zmq_setctxopt, perhaps. Search the list for several previous proposals for > this... > On Feb 9, 2012 8:50 AM, "john skaller" <[email protected]> > wrote: > >> >> On 09/02/2012, at 5:56 AM, Chuck Remes wrote: >> >> > A user on irc (calvin) may post here (or on this thread) later. He >> popped into the channel asking about pinning a socket to a specific CPU. I >> pointed him at ZMQ_AFFINITY which is available through zmq_setsockopt(). >> However, as he pointed out, that only controls socket affinity with I/O >> threads which may still be scheduled on any CPU. >> > >> > After a little back-and-forth, here's a proposal for an addition to the >> C API. >> > >> > void *zmq_init_with_affinity (int io_threads, char* >> cpu_bitmask_buffer, size_t bitmask_len); >> >> And, either ZMQ_AFFINITY should be modified to support the arbitrary >> length >> bitmask OR a new tag be invented such as >> >> ZMQ_LONG_AFFINITY >> >> Also, since this API would exclude thread_safety as it too is an >> additional context >> construction option, it may be right to start thinking about >> >> zmq_setcontextopt >> >> function that looks like >> >> zmq_setsokopt >> >> [The interface in C is ugly in the extreme .. ] >> >> > >> > Such a change would allow a programmer to create a context and specify >> which specific CPUs should have I/O threads pinned to them. We need to use >> a byte buffer to contain the bitmask and pass a length since systems with >> more than 64 CPUs and/or cores are already available. >> > >> > This addition would not break existing code. Furthermore, we could >> implement zmq_init() internally with a call to zmq_init_with_affinity(). >> >> Not directly, my modification to the style guide prohibits this. You'd do >> it with >> an inner function all the public interfaces called. Same effect though. >> >> -- >> john skaller >> [email protected] >> >> >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
