Skip to content

netlink: add MessageBufferSize configuration option#270

Open
nickgarlis wants to merge 1 commit intomdlayher:mainfrom
nickgarlis:add-message-buffer-option
Open

netlink: add MessageBufferSize configuration option#270
nickgarlis wants to merge 1 commit intomdlayher:mainfrom
nickgarlis:add-message-buffer-option

Conversation

@nickgarlis
Copy link
Collaborator

Add a MessageBufferSize config option to let users define the size of the copy buffer used when calling Receive. If the caller knows the maximum expected message size, they can skip the peek/allocate logic, reducing allocations and syscalls. This should improve performance in high-throughput applications.

Since the kernel keeps track of the largest buffer size passed to recvmsg for a socket, MessageBufferSize needs to be set at connection initialization and cannot be changed afterwards.

The truncation error has also been changed to a custom Go error instead of unix.ENOSPC, as the latter is misleading and there is little value in handling it with errors.Is.

Add a MessageBufferSize config option to let users define the size of
the copy buffer used when calling Receive. If the caller knows the
maximum expected message size, they can skip the peek/allocate logic,
reducing allocations and syscalls. This should improve performance in
high-throughput applications.

Since the kernel keeps track of the largest buffer size passed to
recvmsg for a socket, MessageBufferSize needs to be set at connection
initialization and cannot be changed afterwards.

The truncation error has also been changed to a custom Go error instead
of unix.ENOSPC, as the latter is misleading and there is little value in
handling it with errors.Is.

- https://github.com/torvalds/linux/blob/113ae7b4decc6c2d95bdbbe52e615a0137ef7f9f/net/netlink/af_netlink.h#L35
@nickgarlis
Copy link
Collaborator Author

Hmm, this seems to need a bit more work. With this change, message truncation would now be possible if the user gave the wrong input. However, with the way things are now, it's not possible to tip lockedReceiveIter that this error, is not entirely fatal and the remaining multi-part messages also need to be drained.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant