From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Ahern <dsahern@gmail.com>,
Solio Sarabia <solio.sarabia@intel.com>,
netdev@vger.kernel.org, davem@daveloft.net,
stephen@networkplumber.org
Cc: kys@microsoft.com, shiny.sebastian@intel.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] net-sysfs: export gso_max_size attribute
Date: Fri, 24 Nov 2017 10:52:44 -0800 [thread overview]
Message-ID: <1511549564.16595.6.camel@gmail.com> (raw)
In-Reply-To: <786ae327-f709-d09c-ceae-5f4789d537a1@gmail.com>
On Fri, 2017-11-24 at 11:43 -0700, David Ahern wrote:
> On 11/24/17 11:32 AM, Eric Dumazet wrote:
> > On Fri, 2017-11-24 at 10:14 -0700, David Ahern wrote:
> > > On 11/22/17 5:30 PM, Solio Sarabia 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>
> > > > ---
> > >
> > > This should be added to rtnetlink rather than sysfs.
> >
> > This is already exposed by rtnetlink [1]
>
> It currently is read-only. This patch wants to control setting it.
>
> >
> > Please lets not add yet another net-sysfs knob.
>
> Which is my main point - no more sysfs files.
>
I was not objecting to your point, sorry if this was not obvious.
I usually hit reply on the latest email, not the first one in the
thread.
Proper support for changing these attributes is more complex than that
trivial change. Bonding and team devices, and tunnels comes to mind.
next prev parent reply other threads:[~2017-11-24 18:52 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
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 [this message]
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=1511549564.16595.6.camel@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=davem@daveloft.net \
--cc=dsahern@gmail.com \
--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 \
--cc=stephen@networkplumber.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).