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=-1.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS 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 F0D0AC43381 for ; Thu, 14 Feb 2019 17:34:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BAD38222DA for ; Thu, 14 Feb 2019 17:34:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MhB47fFx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389527AbfBNReJ (ORCPT ); Thu, 14 Feb 2019 12:34:09 -0500 Received: from mail-pl1-f196.google.com ([209.85.214.196]:45393 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729595AbfBNReJ (ORCPT ); Thu, 14 Feb 2019 12:34:09 -0500 Received: by mail-pl1-f196.google.com with SMTP id r14so3483759pls.12 for ; Thu, 14 Feb 2019 09:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BGmkiQ6v86e8KXr+6wWlKGlW1to1pvN/ksUx0xQtRnA=; b=MhB47fFxFOHOBjAJF7wc7mfW93kpeJy84oYPzN4W/TfZnnn/xOFt5NVRI5tEJcVaWq y4jBWXuTZEvxjzlgsTlT8sb8+gYmrOlqL5SfIf+pscbeYhrz4RkFNDlzVTLYipu4dNv6 SLZJ3R0TxWfrpplHzvMrQCiPfAa2/jjoafxFNUEAEXGkaVmjEEYXMxeVo5UlEkwUED4b luHr9LADTO/Grv4It2yTToRA24ojTmSBSC81mPXOaz6EjBejLgJzbYDRmZaK5wvYD+5/ sFYp5zs8ZGbckmvUY0QsenwCj4KL2Ab5tYNc8NbpWK8JJGMPqKUjWMxiyi3us1yxlh6d vQMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BGmkiQ6v86e8KXr+6wWlKGlW1to1pvN/ksUx0xQtRnA=; b=Z4rJw/14QAhppL1gvOmU9snwQFdRqvdAbeZ+r6rF9/wape9QlG8UX5FWJBAGYeefAB S+EjBHAJ+WdOGZu7b2/SdOeu9OmMyzsMC359W4Vzwd6fem8wWRi1/eHdPDqkPF66oA1B 8pcyqEMqUbQ252Q7mYI7+JpC8B+7O4UtxNBH9phsPMwSHeDquHshUsvVuC8zSEiy14a9 Kda/7CsP7hRuD5nFlHBS/Vz379+d7XT2bzlXcSdlm71PQisn9HMUM0a0yaM1i7VQElFs lXQLttY/DGO2GLP88cpvc89W5C89InSbT+0IAuE5IEBf+BV0VsEpDc6NqYRaHKkcAqQo MNPA== X-Gm-Message-State: AHQUAuYygoltAO6QDvnE60C3MOXCUNF1ipotyKtCcH9sGzm9WSHLOJ6J Vb6GZ2PfqRxlK4t81fRb50M= X-Google-Smtp-Source: AHgI3IZLlzfEjdaJAijqIMhBwvThU+6TVn8HgkVuePPtjbiceS6c4fLomoC2+bfRU6x4QDVt+BWpZw== X-Received: by 2002:a17:902:bd86:: with SMTP id q6mr5271129pls.16.1550165648835; Thu, 14 Feb 2019 09:34:08 -0800 (PST) Received: from ?IPv6:2601:282:800:fd80:fcca:3d2d:5c58:2370? ([2601:282:800:fd80:fcca:3d2d:5c58:2370]) by smtp.googlemail.com with ESMTPSA id 186sm11427835pga.36.2019.02.14.09.34.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 09:34:07 -0800 (PST) Subject: Re: [PATCH iproute2] lib/libnetlink: ensure a minimum of 32KB for the buffer used in rtnl_recvmsg() To: Michal Kubecek , netdev@vger.kernel.org Cc: Eric Dumazet , Stephen Hemminger , Eric Dumazet , Hangbin Liu , Phil Sutter References: <20190213015841.140383-1-edumazet@google.com> <20190214134945.GJ25518@unicorn.suse.cz> From: David Ahern Message-ID: <310f4861-1a65-cdcd-515c-b1f6da04b7d7@gmail.com> Date: Thu, 14 Feb 2019 10:34:06 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190214134945.GJ25518@unicorn.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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.) > > 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.