On Sun, Jan 24, 2016 at 10:42:24AM +0200, Yan Vugenfirer wrote:
On 21 Jan 2016, at 07:27, Michael S. Tsirkin <mst@redhat.com> wrote:
On Wed, Jan 20, 2016 at 12:42:45PM -0500, Aaron Conole wrote:
"Michael S. Tsirkin" <mst@redhat.com> writes:
On Fri, Jan 15, 2016 at 04:28:30PM -0500, Aaron Conole wrote:
Sometimes it is essential for libvirt to be able to configure
MTU
on guest's NICs to a value different from 1500.
The change adds a new field to configuration area of network
devices. It will be used to pass initial MTU from the device to
the driver, and to pass modified MTU from driver to the device
or from device to driver for both host-guest and guest-host
interaction.
In addition, in order to support backward and forward
compatibility, we introduce a new feature bit called
VIRTIO_NET_F_DEFAULT_MTU.
Signed-off-by: Aaron Conole <aconole@redhat.com>
Cc: Victor Kaplansky <victork@redhat.com>
Since apparently windows guests can't support
such mtu negotiation in the driver, we'd have
to implement this in a guest agent for these
guests.
I think that was due to a previous patch which did not include a
mechanism for reporting the guest->host changes. This includes such a
feedback mechanism. However, I may have misunderstood Yan's previous
email.
What I meant to say is that in Windows we cannot dynamically change MTU from
the device driver. We can set MTU on driver initialisation. Also
This part?
We don’t have the way to support host report of MTU change to the guest
on Windows.
Actually I have a question about this, too.
MTU changes can't be reported to guest, ok.
But let's assume MTU is static.
Can this MTU be discovered during install?
If it is static, it can be discovered during driver load with some
restrictions.
Are the restrictions on value or on how it's accessed then?
By restriction I meant that the driver is not fully initialised yet. So we will have to use control queue in poll mode. Initial value restrictions are in the registry, but I think we can ignore them in this case.
I see this:
NetKVM/wlh/ParaNdis6-Driver.c:
miniportAttributes.GeneralAttributes.MtuSize =
pContext->MaxPacketSize.nMaxDataSize;
This is an initialisation of the miniport driver. We could access virtio device
at this point (most probably without interrupts) and get MTU.
Currently we get the value from registry - pContext->MaxPacketSize.nMaxDataSize
= pConfiguration->MTU.ulValue;
Yan?
Please advise, Yan.
It thus seems advantageous to always have it in
a guest agent, so that libvirt can change it
for all guests in the same way, consistently.
Do you agree to the above? If yes, why do we need
a new device field?
I am not very familiar with qemu-ga. If Yan says the new proposal
will not work, then I will investigate that more thoroughly.
---
v1:
This is an attempt at continuing the work done by Victor
Kaplansky on
mtu negiotiation for virtio-net devices. It attempts to pick up
from
https://lists.oasis-open.org/archives/virtio-dev/201508/
msg00007.html
and is just a minor blurb from the first patch along with the
2nd patch
from the series, and some of the feedback integrated.
v2:
Rephrase and provide a mechanism for guest->host and host->
guest
communication through a driver read-only and driver write-only
field.
content.tex | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/content.tex b/content.tex
index d989d98..b855691 100644
--- a/content.tex
+++ b/content.tex
@@ -3078,6 +3078,11 @@ features.
\item[VIRTIO_NET_F_CTRL_MAC_ADDR(23)] Set MAC address through
control
channel.
+
+\item[VIRTIO_NET_F_MTU(24)] Negotiated MTU is supported. If
+ offered by the device, device advises driver about initial
+ MTU to be used. If negotiated, the driver uses \field{mtu}
as
+ an initial value.
\end{description}
\subsubsection{Feature bit requirements}\label{sec:Device Types
/ Network Device / Feature bits / Feature bit requirements}
@@ -3132,11 +3137,21 @@ of each of transmit and receive
virtqueues (receiveq1\ldots receiveqN
and transmitq1\ldots transmitqN respectively) that can be
configured once VIRTIO_NET_F_MQ
is negotiated.
+The following driver-read-only field, \field{mtu} only exists
if
+VIRTIO_NET_F_MTU is set. This field specifies the MTU that the
device expects
+the driver to honor.
+
+The following driver-write-only field, \field{mtu_requested}
only exists if
+VIRTIO_NET_F_MTU is set. This field will be written by the
driver when it wants
+to request an MTU change from the device.
+
\begin{lstlisting}
struct virtio_net_config {
u8 mac[6];
le16 status;
le16 max_virtqueue_pairs;
+ le16 mtu;
+ le16 mtu_requested;
};
\end{lstlisting}
@@ -3145,6 +3160,18 @@ struct virtio_net_config {
The device MUST set \field{max_virtqueue_pairs} to between 1
and 0x8000 inclusive,
if it offers VIRTIO_NET_F_MQ.
+\devicenormative{\subsubsection}{Device configuration layout}
{Device Types / Network Device / Device configuration layout}
+
+The device MUST set \field{mtu} to between 68 and 65535
inclusive,
+if it offers VIRTIO_NET_F_MTU.
+
+Any time the device modifies \field{mtu}, it MUST send a
configuration change
+notification.
+
+The driver MAY set \field{mtu_requested} to between 68 and
65535 inclusive,
+if the device offers VIRTIO_NET_F_MTU. Any time the driver
modifies
+\field{mtu_requested}, it MUST also send a configuration
change notification.
+
\drivernormative{\subsubsection}{Device configuration layout}
{Device Types / Network Device / Device configuration layout}
A driver SHOULD negotiate VIRTIO_NET_F_MAC if the device offers
it.
@@ -3157,6 +3184,10 @@ If the driver does not negotiate the
VIRTIO_NET_F_STATUS feature, it SHOULD
assume the link is active, otherwise it SHOULD read the link
status from
the bottom bit of \field{status}.
+A driver SHOULD negotiate VIRTIO_NET_F_MTU if the device
offers it. If the
+driver negotiates the VIRTIO_NET_F_MTU feature, the driver
MUST use \field{mtu}
+as the value for MTU.
+
\subsubsection{Legacy Interface: Device configuration layout}\
label{sec:Device Types / Network Device / Device configuration
layout / Legacy Interface: Device configuration layout}
\label{sec:Device Types / Block Device / Feature bits / Device
configuration layout / Legacy Interface: Device configuration
layout}
When using the legacy interface, transitional devices and
drivers
--
2.5.0
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
virtio-dev-help@lists.oasis-open.org
---------------------------------------------------------------------To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.orgFor additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
|