On Fri, 2022-08-19 at 12:16 -0700, Jakub Kicinski wrote: > On Fri, 19 Aug 2022 10:54:51 -0700 Jakub Kicinski wrote: > > > Ugh, I repressed all those memories ... I don't remember now, I guess > > > I'd have to try it. Also it doesn't just apply to normal stuff but also > > > multicast, and that can be even trickier. > > > > No worries, let me try myself. Annoyingly I have this doc on a different > > branch than my netlink code, that's why I was being lazy :) > > Buffer sizing > ------------- > > Netlink sockets are datagram sockets rather than stream sockets, > meaning that each message must be received in its entirety by a single > recv()/recvmsg() system call. If the buffer provided by the user is too > short, the message will be truncated and the ``MSG_TRUNC`` flag set > in struct msghdr (struct msghdr is the second argument > 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 > I guess technically 8 KiB ;-) > or a page > size of the CPU architecture, whichever is bigger. 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). Seems reasonable, thanks :) Honestly most of our problems came from ever-growing message sizes, and userspace having defaulted to 4k buffers ... annoyingly. Even 8k may not always be enough for future - so for the kernel guide maybe say we should mostly not even have GET operations but have a way to restrict DUMP operations to a certain (set of) object(s), and have the ability to split objects in the middle when they have a lot of properties ... johannes
