[nanomsg] Re: nn_recv with padding
- From: Martin Sustrik <sustrik@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 13 May 2014 07:06:00 +0200
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 13/05/14 02:03, Drew Crawford wrote:
> It had not occurred to me how inproc is implemented. It’s obvious
> in retrospect that no zero-copy implementation can be done in that
> case, but it wasn’t obvious before I had considered what the
> implementation is.
>
> However, I think it is still possible to support custom allocation
> sizes for TCP/UDP transport, which is where sending messages is the
> slowest and performance matters most. Depending on how serious you
> want to be about supporting the same socket API across different
> transports the implementation could either fall back to memcpy in
> the inproc case or else return an error and force the programmer do
> it.
Yes. But that means breaking the zero-copy promise, which is the thing
you wanted to achieve in the first place. Imagine the documentation
for the socket option:
NN_ALLOC_MORE_MEM: Causes nanomsg to allocate additional bytes per
message. Setting this option to a positive value may cause copies of
the message to be done within the stack, invisible to the user.
That being said, I feel there's some logical fallacy in the whole
problem statement. Either you have large messages (>100kB) in which
case adding 16 padding bytes to the message on the sending side is
going to have no performance impact. Or, possibly, you have small
messages (<100kB) where the whole copying thing is going to happen in
CPU cache without accessing physical memory and zero-copy is thus
going to have negligible performance impact.
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTcag4AAoJENTpVjxCNN9Y8ogH/1VQqY5JVVO0IG28qd6guLvE
rLA+TTOvzqm0Z/+EbWXDjjvPIVQAPMfNNkVXF/DPREYdJjSciDk3PK5sSA4cp+cK
3li3yvxnNV3UkBS+VrIXmknFdRB1b+9gRnLnjhXitkAg6PGbf8iQOI4PSh1fIi/m
ANNy7IctBoY63+HyfjQrQl4/W5lo6PlGzyZ+BLc+JwhKDG1VXteyUxZT0LLDR5rZ
najAjHoWs5nXNkkclrlf45gsUjTHaziYQM88DfthU6y3akSw/9m7XtQ6ig1WLKa7
i39VxHezw0XEg/XA2fjobxdhXcE0wkNHpdXmuU4jc4JzIf3Tnrvi+1m9iOHejlU=
=C0pH
-----END PGP SIGNATURE-----
Other related posts:
