All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: Rick Jones <rick.jones2@hpe.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -next 2/2] virtio_net: Read the advised MTU
Date: Thu, 02 Jun 2016 13:06:32 -0400	[thread overview]
Message-ID: <f7tmvn3sep3.fsf@redhat.com> (raw)
In-Reply-To: <5750578E.4040406@hpe.com> (Rick Jones's message of "Thu, 2 Jun 2016 08:58:06 -0700")


Hi Rick,

In the future, please don't cut the list.

Rick Jones <rick.jones2@hpe.com> writes:

> On 06/02/2016 08:43 AM, Aaron Conole wrote:
>> This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it
>> exists, read the advised MTU and use it.
>>
>> No proper error handling is provided for the case where a user changes the
>> negotiated MTU. A future commit will add proper error handling. Instead, a
>> warning is emitted if the guest changes the device MTU after previously
>> being given advice.
>
> One of the things I've been doing has been setting-up a cluster
> (OpenStack) with JumboFrames, and then setting MTUs on instance vNICs
> by hand to measure different MTU sizes.  It would be a shame if such a
> thing were not possible in the future.  Keeping a warning if shrinking
> the MTU would be good, leave the error (perhaps) to if an attempt is
> made to go beyond the advised value.

This was cut because it didn't make sense for such a warning to
be issued, but it seems like perhaps you may want such a feature?  I
agree with Michael, after thinking about it, that I don't know what sort
of use the warning would serve.  After all, if you're changing the MTU,
you must have wanted such a change to occur?

-Aaron

> happy benchmarking,
>
> rick jones

  parent reply	other threads:[~2016-06-02 17:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-02 15:43 [PATCH -next 0/2] virtio-net: Advised MTU feature Aaron Conole
2016-06-02 15:43 ` [PATCH -next 1/2] virtio: Start feature MTU support Aaron Conole
2016-06-02 16:17   ` Michael S. Tsirkin
2016-06-02 17:10     ` Aaron Conole
2016-06-02 17:10       ` Aaron Conole
2016-06-02 16:17   ` Michael S. Tsirkin
2016-06-02 15:43 ` [PATCH -next 2/2] virtio_net: Read the advised MTU Aaron Conole
2016-06-02 16:16   ` Michael S. Tsirkin
2016-06-02 16:16     ` Michael S. Tsirkin
2016-06-02 17:10     ` Aaron Conole
2016-06-02 17:10     ` Aaron Conole
     [not found]   ` <5750578E.4040406@hpe.com>
2016-06-02 17:06     ` Aaron Conole
2016-06-02 17:06     ` Aaron Conole [this message]
2016-06-02 18:02       ` Rick Jones
2016-06-02 18:02         ` Rick Jones
2016-06-02 17:25   ` kbuild test robot
2016-06-02 17:25     ` kbuild test robot
2016-06-02 17:48     ` Aaron Conole
2016-06-02 17:48       ` Aaron Conole

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=f7tmvn3sep3.fsf@redhat.com \
    --to=aconole@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rick.jones2@hpe.com \
    --cc=virtualization@lists.linux-foundation.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 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.