AIO contexts and memory reuse about nng HOT 6 CLOSED

So once you send, yes, the function assumes ownership of the message, and will return it back to the pool when done.

It might be possible to build a system where instead of nng_msg_free returning the message to the heap directly, it calls a user-supplied callback which could then reuse it. This would reduce pressure on the heap, although you probably would not achieve precisely what you want with respect to a single memory region.

Other solutions are also possible under the hood, but they would involve more data copies, which is something that I think you're trying to avoid.

from nng.

Sorry for being so late to get back to you.

The best way to do explicitly manage memory is to use nng_msg_alloc() with large messages, and then use those. This will avoid copying data.

For those you can use nng_ctx_send, nng_ctx_recv, or nng_send_aio(), or nng_recv_aio().

What happens is that these utilize the message memory directly. The older NNG_FLAG_ALLOC is a convenience and intended mostly for compatibility with legacy nanomsg. It isn't as efficient as allocating the messages directly.

To allocate the message directly, you can allocate it for as large as you think it will grow. Then you can either truncate it and grow it, or just access the body directly.

You should ignore nng_aio_set_iov... that API is indeed for the underlying byte stream APIs, and not intended for the SP message oriented protocols.

from nng.

Note that if you use nng_msg_append() or something like that, then it definitely is not zero copy. The trick to zero copy is to use the message memory directly.

Also, btw, it isn't truly zero copy. It's less copies. True zero copy requires rather sophisticated memory management and hardware support for direct DMA, etc. Generally what we have done here is usually good enough, but for extreme high performance you'll probably want to investigate RDMA or something like that.

from nng.

And 100K requests per second is not extreme high performance, unless they are very large.

from nng.

Thanks for your reply.

Using nng_msg_alloc() and building the message in place may be a very reasonable solution. On the other hand, I was considering doing one allocation per context, rather than per message. I was hoping to get around The function assumes ownership of the message.

If I could pre-allocate the space for responses too, that would solve the alignment problem.

If it is not possible, would you like to sketch what the implementation would entail? In case anyone finds time to work on it.

from nng.

Note that with respect to responses, the function normally allocates messages with a certain amount of "head room". This ensures that you can inject or change headers if you need to. Again, this isn't exactly what you're asking for, but it may help.

from nng.