netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
Cc: netdev@vger.kernel.org, Herbert Xu <herbert@gondor.hengli.com.au>,
	Ben Hutchings <bhutchings@solarflare.com>,
	Shan Wei <shanwei@cn.fujitsu.com>
Subject: Re: [PATCH] net: tuntap: Fix tun_net_fix_features()
Date: Tue, 17 May 2011 18:11:56 +0300	[thread overview]
Message-ID: <20110517151155.GA2062@redhat.com> (raw)
In-Reply-To: <20110517150029.GA23179@rere.qmqm.pl>

On Tue, May 17, 2011 at 05:00:29PM +0200, Michał Mirosław wrote:
> On Tue, May 17, 2011 at 05:54:28PM +0300, Michael S. Tsirkin wrote:
> > On Tue, May 17, 2011 at 04:46:35PM +0200, Michał Mirosław wrote:
> > > On Tue, May 17, 2011 at 05:29:43PM +0300, Michael S. Tsirkin wrote:
> > > > On Tue, May 17, 2011 at 10:19:54AM +0200, Michał Mirosław wrote:
> > > > > tun->set_features are meant to limit not force the features.
> [...]
> > > > One thing that this will do though: previously, if
> > > > ethtool disables offloads, then an application enables
> > > > them, the application will have the last say.
> > > > With this patch, the most conservative approach wins.
> > > > Right?
> > > 
> > > Exactly.
> > > 
> > > On device creation, wanted_features default to all offloads
> > > enabled, so unless an admin changes the flags, the application controls
> > > what is enabled. This matters only when using persistent tun/tap and
> > > admin and user are two different people. If the admin is using queues
> > > and doesn't want to handle e.g. TSO packets (I'm not sure if they are
> > > properly accounted in all queuing disciplines), then the feature should
> > > not be enabled by user.
> [...]
> > Yes, with virtualization admin and the app are two different people
> > usually.  The device doesn't have to be persistent though I think -
> > what limits this to persistent devices?
> 
> Hmm. Nothing really. I just forgot about the virtualization case. You
> usually will change the offloads just after device creation unless you're
> testing or debugging something.

That's true. kvm invokes a user script after creating device
but just before configuring it, if there might be a problem
it's likely only because of something such a script might do
(which used to be harmless). My gut feeling is this
is unlikely.

> > I agree this behaviour seems more consistent, I just hope this change
> > does not break any setups.
> 
> The only effect would be some performance drop on cases, where admin turned
> off the offloads and they stay like that regardless of what user part does.
> 
> Best Regards,
> Michał Mirosław

The performance drop is actually quite drastic :), but yes it
will keep going, which is a good thing.

-- 
MST

  reply	other threads:[~2011-05-17 15:11 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-04 18:18 tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG Michael S. Tsirkin
2011-05-04 22:34 ` Herbert Xu
2011-05-04 23:28   ` Michał Mirosław
2011-05-05  0:19     ` Herbert Xu
2011-05-05  8:44     ` Michael S. Tsirkin
2011-05-05  9:34       ` Shan Wei
2011-05-05 10:05         ` Herbert Xu
2011-05-16  7:32           ` Michael S. Tsirkin
2011-05-16  8:07             ` Herbert Xu
2011-05-16  8:18               ` Michael S. Tsirkin
2011-05-16  9:38                 ` Herbert Xu
2011-05-16  9:48                   ` Michael S. Tsirkin
2011-05-16 10:43                     ` Herbert Xu
2011-05-16 11:21                       ` Michael S. Tsirkin
2011-05-16 12:18                         ` Herbert Xu
2011-05-16 12:24                           ` Michał Mirosław
2011-05-16 22:46                             ` Herbert Xu
2011-05-16 23:06                               ` David Miller
2011-05-16 23:45                                 ` Herbert Xu
2011-05-17  5:18                                   ` Michael S. Tsirkin
2011-05-17  5:24                                     ` Herbert Xu
2011-05-17  5:48                                       ` Michael S. Tsirkin
2011-05-17  6:25                                         ` Herbert Xu
2011-05-17  8:08                               ` Michał Mirosław
2011-05-17  8:15                                 ` Michał Mirosław
2011-05-17  8:19                               ` [PATCH] net: tuntap: Fix tun_net_fix_features() Michał Mirosław
2011-05-17 14:29                                 ` Michael S. Tsirkin
2011-05-17 14:46                                   ` Michał Mirosław
2011-05-17 14:54                                     ` Michael S. Tsirkin
2011-05-17 15:00                                       ` Michał Mirosław
2011-05-17 15:11                                         ` Michael S. Tsirkin [this message]
2011-06-01  9:25                                 ` Michael S. Tsirkin
2011-06-20 19:14                                 ` [RESENT PATCH] " Michał Mirosław
2011-06-20 19:25                                   ` Ben Hutchings
2011-06-20 19:44                                     ` Michał Mirosław
2011-05-16 10:53                     ` tap/bridge: Dropping NETIF_F_GSO/NETIF_F_SG Michał Mirosław
2011-05-16  8:28               ` Michael S. Tsirkin
2011-05-05 15:26 ` Michał Mirosław
2011-05-14  6:54   ` Shan Wei
2011-05-16  7:28   ` Michael S. Tsirkin

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=20110517151155.GA2062@redhat.com \
    --to=mst@redhat.com \
    --cc=bhutchings@solarflare.com \
    --cc=herbert@gondor.hengli.com.au \
    --cc=mirq-linux@rere.qmqm.pl \
    --cc=netdev@vger.kernel.org \
    --cc=shanwei@cn.fujitsu.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 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).