[nanomsg] Re: Language binding vs custom network protocol implementation

  • From: Matthew Hall <mhall@xxxxxxxxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx,"Jason E. Aten" <j.e.aten@xxxxxxxxx>
  • Date: Mon, 15 Sep 2014 01:05:44 -0700

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.

Other related posts: