Ah... I didn't realize upon first reading it would let you alloc your own custom one. However it requires making an entire proprietary transport. It would be much nicer if I could push them through the standard transports, and just get a destroy callback when the transport completes or gives up, upon where I return it to the HugeTLB pool. Making a whole new transport just to tweak zero-copy behavior is very heavy handed then I'd add all my own bugs to my custom transport that didn't exist in the original nanomsg code. Matthew. -- Sent from my mobile device. On September 15, 2014 12:46:00 AM PDT, "Jason E. Aten" <j.e.aten@xxxxxxxxx> wrote: >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.