* [PATCH] docs: netlink: Correct buffer sizing info
@ 2026-05-12 10:30 Konstantin Shabanov
2026-05-13 0:27 ` Jakub Kicinski
2026-05-15 23:10 ` patchwork-bot+netdevbpf
0 siblings, 2 replies; 5+ messages in thread
From: Konstantin Shabanov @ 2026-05-12 10:30 UTC (permalink / raw)
To: linux-doc
Cc: Konstantin Shabanov, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, netdev, linux-kernel
Update the docs to match the code (include/linux/netlink.h):
/*
* skb should fit one page. This choice is good for headerless malloc.
* But we should limit to 8K so that userspace does not have to
* use enormous buffer sizes on recvmsg() calls just to avoid
* MSG_TRUNC when PAGE_SIZE is very large.
*/
#if PAGE_SIZE < 8192UL
#define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(PAGE_SIZE)
#else
#define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(8192UL)
#endif
Link: https://lore.kernel.org/all/20220819200221.422801-2-kuba@kernel.org/
Signed-off-by: Konstantin Shabanov <mail@etehtsea.me>
---
Documentation/userspace-api/netlink/intro.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/userspace-api/netlink/intro.rst b/Documentation/userspace-api/netlink/intro.rst
index aacffade8f84..ca60abe94e3d 100644
--- a/Documentation/userspace-api/netlink/intro.rst
+++ b/Documentation/userspace-api/netlink/intro.rst
@@ -526,8 +526,8 @@ of the recvmsg() system call, *not* a Netlink header).
Upon truncation the remaining part of the message is discarded.
-Netlink expects that the user buffer will be at least 8kB or a page
-size of the CPU architecture, whichever is bigger. Particular Netlink
+Netlink expects that the user buffer will be at most 8kB or a page
+size of the CPU architecture, whichever is smaller. Particular Netlink
families may, however, require a larger buffer. 32kB buffer is recommended
for most efficient handling of dumps (larger buffer fits more dumped
objects and therefore fewer recvmsg() calls are needed).
base-commit: 917719c412c48687d4a176965d1fa35320ec457c
--
2.53.0
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] docs: netlink: Correct buffer sizing info
2026-05-12 10:30 [PATCH] docs: netlink: Correct buffer sizing info Konstantin Shabanov
@ 2026-05-13 0:27 ` Jakub Kicinski
2026-05-15 15:57 ` Konstantin Shabanov
2026-05-15 23:10 ` patchwork-bot+netdevbpf
1 sibling, 1 reply; 5+ messages in thread
From: Jakub Kicinski @ 2026-05-13 0:27 UTC (permalink / raw)
To: Konstantin Shabanov
Cc: linux-doc, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, netdev, linux-kernel
On Tue, 12 May 2026 17:30:53 +0700 Konstantin Shabanov wrote:
> Update the docs to match the code (include/linux/netlink.h):
>
> /*
> * skb should fit one page. This choice is good for headerless malloc.
> * But we should limit to 8K so that userspace does not have to
> * use enormous buffer sizes on recvmsg() calls just to avoid
> * MSG_TRUNC when PAGE_SIZE is very large.
> */
> #if PAGE_SIZE < 8192UL
> #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(PAGE_SIZE)
> #else
> #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(8192UL)
> #endif
You should explain what you think the problem is in the commit message.
Maybe if you did you'd realize you're comparing kernel header comment
to user space guidance which are (obviously?) the inverse of each
other..
> Link: https://lore.kernel.org/all/20220819200221.422801-2-kuba@kernel.org/
That's not how we refer to committed code.
--
pw-bot: reject
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] docs: netlink: Correct buffer sizing info
2026-05-13 0:27 ` Jakub Kicinski
@ 2026-05-15 15:57 ` Konstantin Shabanov
2026-05-15 22:51 ` Jakub Kicinski
0 siblings, 1 reply; 5+ messages in thread
From: Konstantin Shabanov @ 2026-05-15 15:57 UTC (permalink / raw)
To: kuba
Cc: corbet, davem, edumazet, horms, linux-doc, linux-kernel, mail,
netdev, pabeni, skhan
On Tue, 12 May 2026 17:27:57 -0700 Jakub Kicinski wrote:
> On Tue, 12 May 2026 17:30:53 +0700 Konstantin Shabanov wrote:
> > Update the docs to match the code (include/linux/netlink.h):
> >
> > /*
> > * skb should fit one page. This choice is good for headerless malloc.
> > * But we should limit to 8K so that userspace does not have to
> > * use enormous buffer sizes on recvmsg() calls just to avoid
> > * MSG_TRUNC when PAGE_SIZE is very large.
> > */
> > #if PAGE_SIZE < 8192UL
> > #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(PAGE_SIZE)
> > #else
> > #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(8192UL)
> > #endif
>
> You should explain what you think the problem is in the commit message.
> Maybe if you did you'd realize you're comparing kernel header comment
> to user space guidance which are (obviously?) the inverse of each
> other..
I thought that the comment is self-explaining:
* But we should limit to 8K so that userspace does not have to
* use enormous buffer sizes on recvmsg() calls just to avoid
* MSG_TRUNC when PAGE_SIZE is very large.
The problem is that according to the comment, kernel isn't going to send
more than 8K in a single reply and the documentation is currently recommends the opposite:
to create _at least_ 8K buffer what looks excessive.
Also, the logic in the comment is aligned with userspace libraries (libmnl [1]
and wireguard-tools [2]).
[1]: https://git.netfilter.org/libmnl/tree/include/libmnl/libmnl.h?id=54dea548d796653534645c6e3c8577eaf7d77411#n20
[2]: https://git.zx2c4.com/wireguard-tools/tree/src/netlink.h?id=a998407747005ea7e4e0258d96f105c97241e1d3#n70
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] docs: netlink: Correct buffer sizing info
2026-05-15 15:57 ` Konstantin Shabanov
@ 2026-05-15 22:51 ` Jakub Kicinski
0 siblings, 0 replies; 5+ messages in thread
From: Jakub Kicinski @ 2026-05-15 22:51 UTC (permalink / raw)
To: Konstantin Shabanov
Cc: corbet, davem, edumazet, horms, linux-doc, linux-kernel, netdev,
pabeni, skhan
On Fri, 15 May 2026 22:57:41 +0700 Konstantin Shabanov wrote:
> The problem is that according to the comment, kernel isn't going to send
> more than 8K in a single reply and the documentation is currently recommends the opposite:
> to create _at least_ 8K buffer what looks excessive.
Got it.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] docs: netlink: Correct buffer sizing info
2026-05-12 10:30 [PATCH] docs: netlink: Correct buffer sizing info Konstantin Shabanov
2026-05-13 0:27 ` Jakub Kicinski
@ 2026-05-15 23:10 ` patchwork-bot+netdevbpf
1 sibling, 0 replies; 5+ messages in thread
From: patchwork-bot+netdevbpf @ 2026-05-15 23:10 UTC (permalink / raw)
To: Konstantin Shabanov
Cc: linux-doc, davem, edumazet, kuba, pabeni, horms, corbet, skhan,
netdev, linux-kernel
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 12 May 2026 17:30:53 +0700 you wrote:
> Update the docs to match the code (include/linux/netlink.h):
>
> /*
> * skb should fit one page. This choice is good for headerless malloc.
> * But we should limit to 8K so that userspace does not have to
> * use enormous buffer sizes on recvmsg() calls just to avoid
> * MSG_TRUNC when PAGE_SIZE is very large.
> */
> #if PAGE_SIZE < 8192UL
> #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(PAGE_SIZE)
> #else
> #define NLMSG_GOODSIZE SKB_WITH_OVERHEAD(8192UL)
> #endif
>
> [...]
Here is the summary with links:
- docs: netlink: Correct buffer sizing info
https://git.kernel.org/netdev/net-next/c/55834f0d7421
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-05-15 23:09 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-12 10:30 [PATCH] docs: netlink: Correct buffer sizing info Konstantin Shabanov
2026-05-13 0:27 ` Jakub Kicinski
2026-05-15 15:57 ` Konstantin Shabanov
2026-05-15 22:51 ` Jakub Kicinski
2026-05-15 23:10 ` patchwork-bot+netdevbpf
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.