From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3506AC43381 for ; Thu, 14 Feb 2019 17:47:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 11616222DA for ; Thu, 14 Feb 2019 17:47:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388832AbfBNRrL (ORCPT ); Thu, 14 Feb 2019 12:47:11 -0500 Received: from orbyte.nwl.cc ([151.80.46.58]:37662 "EHLO orbyte.nwl.cc" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725991AbfBNRrL (ORCPT ); Thu, 14 Feb 2019 12:47:11 -0500 Received: from n0-1 by orbyte.nwl.cc with local (Exim 4.91) (envelope-from ) id 1guL6K-0006Hu-QQ; Thu, 14 Feb 2019 18:47:08 +0100 Date: Thu, 14 Feb 2019 18:47:08 +0100 From: Phil Sutter To: David Ahern Cc: Michal Kubecek , netdev@vger.kernel.org, Eric Dumazet , Stephen Hemminger , Eric Dumazet , Hangbin Liu Subject: Re: [PATCH iproute2] lib/libnetlink: ensure a minimum of 32KB for the buffer used in rtnl_recvmsg() Message-ID: <20190214174708.GV26388@orbyte.nwl.cc> Mail-Followup-To: Phil Sutter , David Ahern , Michal Kubecek , netdev@vger.kernel.org, Eric Dumazet , Stephen Hemminger , Eric Dumazet , Hangbin Liu References: <20190213015841.140383-1-edumazet@google.com> <20190214134945.GJ25518@unicorn.suse.cz> <310f4861-1a65-cdcd-515c-b1f6da04b7d7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <310f4861-1a65-cdcd-515c-b1f6da04b7d7@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Thu, Feb 14, 2019 at 10:34:06AM -0700, David Ahern wrote: > On 2/14/19 6:49 AM, Michal Kubecek wrote: > > On Tue, Feb 12, 2019 at 07:04:17PM -0700, David Ahern wrote: > >> > >> Do we know of any single message sizes > 32k? 2d34851cd341 cites > >> increasing VF's but at some point there is a limit. If not, the whole > >> PEEK thing should go away and we just malloc 32k (or 64k) buffers for > >> each recvmsg. > > > > IFLA_VF_LIST is by far the biggest thing I have seen so far. I don't > > remember exact numbers but the issue with 32KB buffer (for the whole > > RTM_NELINK message) was encountered by some of our customers with NICs > > having 120 or 128 VFs. > > > > There is a bigger issue with IFLA_VFINFO_LIST, though, as it's an > > attribute so that netlink limits its size to 64 KB. IIRC with current > > size of IFLA_VF_INFO this would be reached with 270-280 VFs (I'm sure > > the number was higer than 256 but not too much higher.) Using netdevsim, 'ip link show' becomes unusable after enabling more than 244 VFs. I guess it depends on how much info per VF is available. > > This would mean unless we let something else grow too much, the whole > > message shouldn't get much bigger than 64 KB. And if we can find some > > other solution (e.g. passing VF information in separate messages if > > client declares support), even 32 KB would be more than enough. > > That's what I was asking, thanks. So 32kB today is sufficient, 64kB has > future buffer. So this whole PEEK and allocate the message size is > overkill. It could just as easily been bumped from 32kB to 64kB in the > original patch and been good for a while. Yes, I think the real problem is how VF-related messages are structured currently. Cheers, Phil