All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Solio Sarabia <solio.sarabia@intel.com>
Cc: netdev@vger.kernel.org, davem@daveloft.net, kys@microsoft.com,
	shiny.sebastian@intel.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net-sysfs: export gso_max_size attribute
Date: Thu, 23 Nov 2017 21:18:37 -0800	[thread overview]
Message-ID: <20171123211837.0f5efa8b@xeon-e3> (raw)
In-Reply-To: <1511397041-27994-1-git-send-email-solio.sarabia@intel.com>

On Wed, 22 Nov 2017 16:30:41 -0800
Solio Sarabia <solio.sarabia@intel.com> wrote:

> The netdevice gso_max_size is exposed to allow users fine-control on
> systems with multiple NICs with different GSO buffer sizes, and where
> the virtual devices like bridge and veth, need to be aware of the GSO
> size of the underlying devices.
> 
> In a virtualized environment, setting the right GSO sizes for physical
> and virtual devices makes all TSO work to be on physical NIC, improving
> throughput and reducing CPU util. If virtual devices send buffers
> greater than what NIC supports, it forces host to do TSO for buffers
> exceeding the limit, increasing CPU utilization in host.
> 
> Suggested-by: Shiny Sebastian <shiny.sebastian@intel.com>
> Signed-off-by: Solio Sarabia <solio.sarabia@intel.com>
> ---
> In one test scenario with Hyper-V host, Ubuntu 16.04 VM, with Docker
> inside VM, and NTttcp sending 40 Gbps from one container, setting the
> right gso_max_size values for all network devices in the chain, reduces
> CPU overhead about 3x (for the sender), since all TSO work is done by
> physical NIC.
> 
>  net/core/net-sysfs.c | 30 ++++++++++++++++++++++++++++++
>  1 file changed, 30 insertions(+)


You probably should expose gso_max_segs as well.

  parent reply	other threads:[~2017-11-24  5:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-23  0:30 [PATCH] net-sysfs: export gso_max_size attribute Solio Sarabia
2017-11-23 21:48 ` Solio Sarabia
2017-11-24  5:18 ` Stephen Hemminger [this message]
2017-11-24 17:14 ` David Ahern
2017-11-24 18:32   ` Eric Dumazet
2017-11-24 18:43     ` David Ahern
2017-11-24 18:52       ` Eric Dumazet
2017-11-27 21:47     ` Solio Sarabia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171123211837.0f5efa8b@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=davem@daveloft.net \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shiny.sebastian@intel.com \
    --cc=solio.sarabia@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.