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
next prev 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.