[ovs-dev] [PATCH] netlink: make Netlink socket receive buffer 4x larger

Ansis ansisatteka at gmail.com
Tue Mar 30 16:31:35 UTC 2021


On Mon, Mar 29, 2021 at 6:21 PM Ben Pfaff <blp at ovn.org> 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 <aatteka at ovn.org>
> > 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:


More information about the dev mailing list