On Sun, Sep 14, 2014 at 11:31 PM, Matthew Hall <mhall@xxxxxxxxxxxxxxx> wrote: > I got hosed by the current zero-copy support because it doesn't allow me > to get a callback to custom dealloc my user-supplied buffer after the async > transmit is done, and also doesn't allow me to do zero-copy with my user > supplied buffer that's specially allocated in HugeTLB VM pages by the > user-mode stack. You can only do zero copy using nanomsg's buffer and > that's already an unwanted copy of a faster more efficient buffer from the > stack itself. > Hi Matthew, That's interesting. Do I understand you to say that you defined your own transport (per nn_allocmsg doc) and yet you still couldn't use your own HugeTLB VM pages? NAME ---- nn_allocmsg - allocate a message SYNOPSIS -------- *#include <nanomsg/nn.h>* *void *nn_allocmsg (size_t 'size', int 'type');* DESCRIPTION ----------- Allocate a message of the specified 'size' to be sent in zero-copy fashion. The content of the message is undefined after allocation and it should be filled in by the user. While linknanomsg:nn_send[3] and linknanomsg:nn_sendmsg[3] allow to send arbitrary buffers, buffers allocated using _nn_allocmsg()_ can be more efficient for large messages as they allow for using zero-copy techniques. 'type' parameter specifies type of allocation mechanism to use. Zero is the default one, however, individual transport mechanisms may define their own allocation mechanisms, such as allocating in shared memory or allocating a memory block pinned down to a physical memory address. Such allocation, when used with the transport that defines them, should be more efficient than the default allocation mechanism.