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 B3F97C43381 for ; Fri, 15 Feb 2019 22:47:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7B5CD222D0 for ; Fri, 15 Feb 2019 22:47:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="SIPdefQ+" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404579AbfBOWrE (ORCPT ); Fri, 15 Feb 2019 17:47:04 -0500 Received: from mail-yw1-f52.google.com ([209.85.161.52]:40612 "EHLO mail-yw1-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404037AbfBOWrE (ORCPT ); Fri, 15 Feb 2019 17:47:04 -0500 Received: by mail-yw1-f52.google.com with SMTP id c67so4323717ywa.7 for ; Fri, 15 Feb 2019 14:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BFz9XutkXH2+nmCNZg8tNiyuqc6e+THi4QOQ3vSQK10=; b=SIPdefQ+x9cFRxo04qCnbhLUVzYlXPmN1njzRxCKSxX+MN51xya0uYh9b+B0J6E3Pr 24D8EZdR7bW+KBWkL8L3/3vG5WlH3vM+yCjXVGk3lFFOM3fsOEJ4opfcKHzi83kSBUOb A9wLMf3vd+D2vOWRnMfmlxtAgOWSVqxybgvNquvGgpO6VeVKSyZC56iDmN/K0VKqYAGW kfsX6786AEt92OsFpzZDSqYwjwJnEo6tmXYKjYEFckoy8N4zdkZ0M8WmgpDeQ8X1kOGz KdMKC+mEuCrkkaUOeaLbNyzhJE+LLHtIdTN6pYWvRoBVln3LvFgwLNBsKdP137+5FN2d 3UGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BFz9XutkXH2+nmCNZg8tNiyuqc6e+THi4QOQ3vSQK10=; b=YKssgn40tWXKsYxQoSJZrFTGnbLnZaGGtXEwFXVB6rh0fPN2Ji0usp26szthKvBptK ioFZLNIXT0DNhMooNbyEqWLvB9UdYtY2LBcjjVroo5zxWlH6x1/N1gu5vrgVFP/LthaN XRg5vLi8YYvFXq9alFUVTK+SKyPRaGGY+Rbury52K0vJ7EpCevzqJhf1xpeY4kq0V7fH W4Y6ab8fGcB+OsWbs8TAAPIFYsUFmk9J2qW39yUyrDnKscNl8jcf++I3bL1XA0xMyLRB S6CkXAzN0pSkq/Ipemkcg8kB2+ZJqK4oQmweP5wns62C7xn5stzLO33uAMtfn/i9nruF nXSw== X-Gm-Message-State: AHQUAuZXPdiycuYP2qN6MrXDjZQ3hu96mZcFO2JoF6clBEx6ljSspFTN N6v69usWdJT4l98fVBXH9akXK4cE X-Google-Smtp-Source: AHgI3IYX3LTydkhjvX+MS9uhig07GnqQHkzS++pXrfLbXR+Knqb4TKohIhRbfAz5FX5SoNCXApRobg== X-Received: by 2002:a81:7a50:: with SMTP id v77mr9903037ywc.223.1550270822241; Fri, 15 Feb 2019 14:47:02 -0800 (PST) Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com. [209.85.219.182]) by smtp.gmail.com with ESMTPSA id b188sm2590574ywa.58.2019.02.15.14.47.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Feb 2019 14:47:01 -0800 (PST) Received: by mail-yb1-f182.google.com with SMTP id x9so4421831ybj.5 for ; Fri, 15 Feb 2019 14:47:00 -0800 (PST) X-Received: by 2002:a25:b988:: with SMTP id r8mr10140405ybg.464.1550270820017; Fri, 15 Feb 2019 14:47:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Willem de Bruijn Date: Fri, 15 Feb 2019 17:46:23 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Three questions about busy poll To: Cong Wang Cc: Alexander Duyck , Eric Dumazet , sridhar.samudrala@intel.com, Linux Kernel Network Developers Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > > 2. Why there is no socket option for sysctl.net.busy_poll? Clearly > > > sysctl_net_busy_poll is global and SO_BUSY_POLL only works for > > > sysctl.net.busy_read. > > > > I guess because of how sock_poll works. In that case it is not needed. > > The poll duration applies more to the pollset than any of the > > individual sockets, too. > > > Good point, it's probably like struct eventpoll vs. struct epitem. > > The reason why I am looking for a per-socket tuning is to minimize > the impact of setting busy_poll. I don't know if it is possible to somehow > make this per-socket via epoll interfaces, perhaps fundamentally > it is impossible? I think it may be possible. The way busy_read and busy_poll work in sock_poll is that the sum of all (per socket tunable) busy_read durations on the sockets in the pollset is ~bound by (global) busy_poll. The epoll implementation is restricted in the sense that it polls only on one napi_id at a time. Alongside setting ep->napi_id in ep_set_busy_poll_napi_id, we could also set a new ep field takes the min of the global busy_poll and sk->sk_ll_usec. Though I guess you want to be able to poll on a given pollset without setting the global sysctl_net_busy_poll at all? That would be a useful feature both for epoll and poll/select. But definitely requires refining net_busy_loop_on() to optionally take some state derived from the sockets in the (e)pollset.