> On 6 Mar 2018, at 20:13, Michael S. Tsirkin <m...@redhat.com> wrote: > > On Tue, Mar 06, 2018 at 01:02:06PM -0500, Jason Baron wrote: >> >> >> On 03/04/2018 08:05 AM, Yan Vugenfirer wrote: >>> >>> >>>> On 2 Mar 2018, at 22:19, Michael S. Tsirkin <m...@redhat.com >>>> <mailto:m...@redhat.com>> wrote: >>>> >>>> On Fri, Mar 02, 2018 at 03:14:01PM +0800, Jason Wang wrote: >>>>> >>>>> >>>>> On 2018年03月02日 11:46, Jason Baron wrote: >>>>>> Although linkspeed and duplex can be set in a linux guest via >>>>>> 'ethtool -s', >>>>>> this requires custom ethtool commands for virtio-net by default. >>>>>> >>>>>> 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'. >>>>>> >>>>>> Linkspeed and duplex settings can be set as: >>>>>> '-device virtio-net,speed=10000,duplex=full' >>>>> >>>>> I was thinking whether or not it's better to decide the duplex by the >>>>> type >>>>> of backends. >>>>> >>>>> E.g userspace and vhost-kernel implement a in fact half duplex. But dpdk >>>>> implement a full duplex. >>>>> >>>>> Thanks >>>> >>>> OTOH it's a priority for some people to be able to support migration >>>> between different backend types. Breaking that won't be nice. >>> >>> I think that in this case we need a way to update the settings of link >>> speed and link duplex (maybe add QMP command). Migration between >>> different backend types should cause link down\link up events. And this >>> is a time for a driver to re-read the settings and update the OS. >>> >>> Best regards, >>> Yan. >>> >> >> So the virtio_net driver in linux will re-read these settings on link up >> events. So I could add a qmp command to set these (in addition to the >> command-line) interface, if desired. Is there a consensus that we need >> to add a qmp command here? Or can that be treated as a future item, if >> somebody wants it? >> >> Thanks, >> >> -Jason > > We already have ability to take link down and up. > I'd say it's a future item. I agree.
Yan. > > -- > MST