On Mon, Mar 29, 2021 at 6:21 PM Ben Pfaff <[email protected]> wrote: > > On Mon, Mar 29, 2021 at 05:26:34PM -0500, Ansis Atteka wrote: > > Under high load I observed that Netlink buffer constantly > > fills up for daemons querying Conntrack Table that has a > > lot of entries in it: > > > > netlink_notifier|WARN|netlink receive buffer overflowed > > > > This patch mitigates the problem by increasing socket > > receive buffer size. Ideally we should try to calculate > > buffer size required, but it would be more sophisticated > > solution than simply increasing buffer size. > > > > Signed-off-by: Ansis Atteka <[email protected]> > > VMware-BZ: #2724821 > > Are you sure that it's queries that cause overflows? Queries retrieve > individual records, which would not overflow the 1 MB receive buffer > that was used before. Dumps can retrieve large numbers of records, but > the kernel works in a way such that the records aren't all written in > one go but gradually as userspace reads them. > > Usually, the cause of an overflow is because there's a Netlink socket > that's subscribed to receive updates from some particular subsystem > (I guess that's conntrack in this case). Those do arrive asynchronously > and can overflow if they arrive faster than userspace can retrieve and > process them. > > I can believe that that is the problem here. Is it? If so then > probably the solution is right, but the description of the problem is > slightly wrong.
Thanks, Ben. Would this amendment to commit message better describe situation: Under high load I observed that Netlink socket buffer constantly fills up for daemons listening for Conntrack Table notifications: _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
