|
From: | Maxime Coquelin |
Subject: | Re: [Qemu-devel] [PATCH v4 0/3] virtio-net: Add support to MTU feature |
Date: | Mon, 12 Dec 2016 11:12:56 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
Hi Daniel, On 12/12/2016 11:02 AM, Daniel P. Berrange wrote:
On Sat, Dec 10, 2016 at 04:30:35PM +0100, Maxime Coquelin wrote:Thanks for the reviews, This series implements Virtio spec update from Aaron Conole which defines a way for the host to expose its max MTU to the guest. "host_mtu" parameter is added to provide QEMU with the MTU value, and the backend, if supported, gets notified of the MTU value when the MTU feature neogotiation succeeds. Only user backend currently supports MTU notification. A new protocol feature has been implemented for sending MTU value to the backend. For kernel backend, it is expected the management tool also configures the tap/macvtap interface with same MTU value. Daniel, I would be interrested about your feedback on this implementation from management tool point of view.I can't give real feedback yet, as I'm not seeing clear information on what problem this series is designed to solve....
Right, I agree it is missing a bit of context here, I'll add more about the background in next revision. The goal of this series is to address two things: 1. Providing a way for the guests to use the same MTU as the host, in order to have a consistent MTU value across the infrastructure. 2. Improve Rx performance for small packets, as if all parties agrees on a MTU value for which packets fit into a single descriptor, then Rx mergeable buffers feature can be disabled (saving one cache-miss on guest side by not accessing the virtio header, when offloading has not been negotiated). Thanks, Maxime
[Prev in Thread] | Current Thread | [Next in Thread] |