netdev - Re: [PATCH v2 2/2] virtio-net: add default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150819140836-mutt-send-email-victork@redhat.com>
Date:	Wed, 19 Aug 2015 14:31:59 +0300
From:	Victor Kaplansky <victork@...hat.com>
To:	Jason Wang <jasowang@...hat.com>
Cc:	virtio-dev@...ts.oasis-open.org, mst@...hat.com,
	netdev@...r.kernel.org, virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v2 2/2] virtio-net: add default_mtu configuration field

On Mon, Aug 17, 2015 at 11:07:15AM +0800, Jason Wang wrote:
> 
> 
> On 08/16/2015 09:42 PM, Victor Kaplansky wrote:
> > @@ -3128,6 +3134,7 @@ struct virtio_net_config {
> >          u8 mac[6];
> >          le16 status;
> >          le16 max_virtqueue_pairs;
> > +        le16 default_mtu;
> 
> Looks like "mtu" is ok, consider we use "mac" instead of "default_mac".

Good point. I'll change the name in the next version of the patch.

> 
> >  };
> >  \end{lstlisting}
> >  
> > @@ -3158,6 +3165,15 @@ by the driver after negotiation.
> >      \field{max_virtqueue_pairs} is valid only if VIRTIO_NET_F_MQ is
> >      set and can be read by the driver.
> >  
> > +\item [\field{default_mtu}] is a hint to the driver set by the
> > +    device. It is valid during feature negotiation only if
> > +    VIRTIO_NET_F_DEFAULT_MTU is offered and holds the initial value
> > +    of MTU to be used by the driver. If VIRTIO_NET_F_DEFAULT_MTU is
> > +    negotiated, the driver uses the \field{default_mtu} as an initial
> > +    value, and also reports MTU changes to the device by writes to
> > +    \field{default_mtu}.  Such reporting can be used for debugging,
> > +    or it can be used for tunning MTU along the network.
> > +
> 
> I vaguely remember that config is read only in some arch or transport
> and that's why we introduce another vq cmd to confirm the announcement.
> Probably we should do same for this?

If so, we need to add one more feature bit to confirm the ability
of the driver to report MTU, or we can weaken the requirement in
conformance statement and write "the driver may report the MTU".
What do you say?

-- Victor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html