Repository navigation
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
@stapelberg @nickgarlis, could you review this connection option? It allows tuning receive buffers for large nftables dumps. It depends on #358, which should use netlink v1.11.2 since v1.11.1 is retracted. |
|
Not sure whether this is something that should be configurable by the caller. The nft CLI more or less hard-codes this to the maximum expected size in a system. Here is an example of how I use it with nftables when initializing the connection: https://github.com/nickgarlis/nftnl/blob/main/conn.go#L31 IMO, this is something that should always be on since it makes a big difference in performance especially when listing large sets. I am happy to update #358 with the latest netlink version and perhaps Go 1.26. |
|
If you think that's reasonable default then I agree with that. Update the implementation to always use max expected size of the system |
This PR exposes netlink's MessageBufferSize through a connection option, leaving the default unchanged. The reason is so users can introduce their own MessageBufferSize. Motivation: 32KiB buffer is recommended for most efficient handling of dumps, such as GetSetElements()
It depends on the dependency update in #358 as MessageBufferSize was introduced in netlink v1.10.0, so I wish we can merge #358 first. Btw newer version of netlink was already shipped and maybe #358 should be updated before merge