netdev - Re: [PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex settings from the hypervisor

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: <20180103154824-mutt-send-email-mst@kernel.org>
Date:   Wed, 3 Jan 2018 15:49:21 +0200
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Jason Baron <jbaron@...mai.com>
Cc:     David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        virtualization@...ts.linux-foundation.org, qemu-devel@...gnu.org,
        jasowang@...hat.com
Subject: Re: [PATCH net-next v2 1/3] virtio_net: propagate linkspeed/duplex
 settings from the hypervisor

On Thu, Dec 28, 2017 at 10:53:54AM -0500, Jason Baron wrote:
> 
> 
> On 12/27/2017 04:43 PM, David Miller wrote:
> > From: Jason Baron <jbaron@...mai.com>
> > Date: Fri, 22 Dec 2017 16:54:01 -0500
> > 
> >> The ability to set speed and duplex for virtio_net in useful in various
> >> scenarios as described here:
> >>
> >> 16032be virtio_net: add ethtool support for set and get of settings
> >>
> >> However, it would be nice to be able to set this from the hypervisor,
> >> such that virtio_net doesn't require custom guest ethtool commands.
> >>
> >> Introduce a new feature flag, VIRTIO_NET_F_SPEED_DUPLEX, which allows
> >> the hypervisor to export a linkspeed and duplex setting. The user can
> >> subsequently overwrite it later if desired via: 'ethtool -s'.
> >>
> >> Signed-off-by: Jason Baron <jbaron@...mai.com>
> >> Cc: "Michael S. Tsirkin" <mst@...hat.com>
> >> Cc: Jason Wang <jasowang@...hat.com>
> > 
> > Looks mostly fine to me but need some virtio_net reviewers on this one.
> > 
> >> @@ -57,6 +57,8 @@
> >>  					 * Steering */
> >>  #define VIRTIO_NET_F_CTRL_MAC_ADDR 23	/* Set MAC address */
> >>  
> >> +#define VIRTIO_NET_F_SPEED_DUPLEX 63	/* Host set linkspeed and duplex */
> >> +
> > 
> > Why use a value so far away from the largest existing one?
> > 
> > Just curious.
> > 
> 
> So that came from a discussion with Michael about which bit to use for
> this, and he suggested using 63:
> 
> "
> Transports started from bit 24 and are growing up.
> So I would say devices should start from bit 63 and grow down.
> "
> 
> https://patchwork.ozlabs.org/patch/848814/#1826669
> 
> I will add a comment to explain it.

Maybe in the commit log. I don't think we need it in the header.

> Thanks,
> 
> -Jason