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

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

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: