Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

netlink: add a version of Conn.Receive that doesn't allocate its own buffers #178

Open
mdlayher opened this issue Jan 24, 2021 · 0 comments
Open

netlink: add a version of Conn.Receive that doesn't allocate its own buffers #178

mdlayher opened this issue Jan 24, 2021 · 0 comments

Comments

@mdlayher
Copy link
Owner

This could speed things up significantly for big payloads, and then we can also get rid of the peek/loop/allocate logic and rely on the caller to provide a big enough buffer to read out all the available messages.
@mdlayher mdlayher mentioned this issue Apr 26, 2022
Closed
@turekt turekt mentioned this issue Sep 30, 2022
Open
wenjianhn added a commit to wenjianhn/netlink that referenced this issue Oct 11, 2023
@wenjianhn
Ensure a minimum of 32KB for the buffer used in recvmsg()
9de88ae 
See iproute2 commit bb5ae621d0c7 ("lib/libnetlink: ensure a minimum of
32KB for the buffer used in rtnl_recvmsg()").
iproute2/iproute2@bb5ae621d0c7

Linux v4.9 and newer contains the two commits mentioned in the above
commit message:
"See kernel commits 9063e21fb026 ("netlink: autosize skb lengthes") and
d35c99ff77ec ("netlink: do not enter direct reclaim from netlink_dump()")
for more details."

Also, use unix.MSG_TRUNC to peek without copying the actual payload.

Related to issues mdlayher#178.
@wenjianhn wenjianhn mentioned this issue Oct 11, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mdlayher