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
next prev parent 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$(echo .)com \
--cc=bhutchings@solarflare$(echo .)com \
--cc=herbert@gondor$(echo .)hengli.com.au \
--cc=mirq-linux@rere$(echo .)qmqm.pl \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shanwei@cn$(echo .)fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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