All of lore.kernel.org
 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 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.