mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yan Vugenfirer <yvugenfi@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Baron <jbaron@akamai.com>,
	jasowang@redhat.com, qemu-devel@nongnu.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH 2/2] qemu: add linkspeed and duplex setting to virtio-net
Date: Wed, 20 Dec 2017 16:33:28 +0200	[thread overview]
Message-ID: <F096C867-C75B-4756-B4F6-9774DDF2FC8B@redhat.com> (raw)
In-Reply-To: <20171220162927-mutt-send-email-mst@kernel.org>


> On 20 Dec 2017, at 16:31, Michael S. Tsirkin <mst@redhat.com> wrote:
> 
> On Tue, Dec 19, 2017 at 11:52:39AM -0500, Jason Baron wrote:
>> 
>> 
>> On 12/19/2017 04:19 AM, Yan Vugenfirer wrote:
>>> 
>>>> On 18 Dec 2017, at 18:04, Jason Baron via Qemu-devel
>>>> <qemu-devel@nongnu.org <mailto:qemu-devel@nongnu.org>> wrote:
>>>> 
>>>> 
>>>> 
>>>> On 12/18/2017 06:34 AM, Yan Vugenfirer wrote:
>>>>> 
>>>>>> On 14 Dec 2017, at 21:33, Jason Baron via Qemu-devel
>>>>>> <qemu-devel@nongnu.org <mailto:qemu-devel@nongnu.org>> wrote:
>>>>>> 
>>>>>> Although they can be currently set in linux via 'ethtool -s', this
>>>>>> requires
>>>>>> guest changes, and thus it would be nice to extend this
>>>>>> functionality such
>>>>>> that it can be configured automatically from the host (as other network
>>>>>> do).
>>>>>> 
>>>>>> Linkspeed and duplex settings can be set as:
>>>>>> '-device virtio-net,speed=10000,duplex=full'
>>>>>> 
>>>>>> where speed is [-1...INT_MAX], and duplex is ["half"|"full"].
>>>>>> 
>>>>>> Signed-off-by: Jason Baron <jbaron@akamai.com
>>>>>> <mailto:jbaron@akamai.com>>
>>>>>> Cc: "Michael S. Tsirkin" <mst@redhat.com <mailto:mst@redhat.com>>
>>>>>> Cc: Jason Wang <jasowang@redhat.com <mailto:jasowang@redhat.com>>
>>>>>> ---
>>>>>> hw/net/virtio-net.c                         | 29
>>>>>> +++++++++++++++++++++++++++++
>>>>>> include/hw/virtio/virtio-net.h              |  3 +++
>>>>>> include/standard-headers/linux/virtio_net.h |  4 ++++
>>>>>> 3 files changed, 36 insertions(+)
>>>>>> 
>>>>>> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
>>>>>> index 38674b0..d63e790 100644
>>>>>> --- a/hw/net/virtio-net.c
>>>>>> +++ b/hw/net/virtio-net.c
>>>>>> @@ -40,6 +40,12 @@
>>>>>> #define VIRTIO_NET_RX_QUEUE_MIN_SIZE VIRTIO_NET_RX_QUEUE_DEFAULT_SIZE
>>>>>> #define VIRTIO_NET_TX_QUEUE_MIN_SIZE VIRTIO_NET_TX_QUEUE_DEFAULT_SIZE
>>>>>> 
>>>>>> +/* duplex and speed defines */
>>>>>> +#define DUPLEX_UNKNOWN          0xff
>>>>>> +#define DUPLEX_HALF             0x00
>>>>>> +#define DUPLEX_FULL             0x01
>>>>>> +#define SPEED_UNKNOWN           -1
>>>>>> +
>>>>>> /*
>>>>>> * Calculate the number of bytes up to and including the given 'field' of
>>>>>> * 'container'.
>>>>>> @@ -61,6 +67,8 @@ static VirtIOFeature feature_sizes[] = {
>>>>>>     .end = endof(struct virtio_net_config, max_virtqueue_pairs)},
>>>>>>    {.flags = 1 << VIRTIO_NET_F_MTU,
>>>>>>     .end = endof(struct virtio_net_config, mtu)},
>>>>>> +    {.flags = 1 << VIRTIO_NET_F_SPEED_DUPLEX,
>>>>>> +     .end = endof(struct virtio_net_config, duplex)},
>>>>>>    {}
>>>>>> };
>>>>>> 
>>>>>> @@ -88,6 +96,8 @@ static void virtio_net_get_config(VirtIODevice
>>>>>> *vdev, uint8_t *config)
>>>>>>    virtio_stw_p(vdev, &netcfg.status, n->status);
>>>>>>    virtio_stw_p(vdev, &netcfg.max_virtqueue_pairs, n->max_queues);
>>>>>>    virtio_stw_p(vdev, &netcfg.mtu, n->net_conf.mtu);
>>>>>> +    virtio_stl_p(vdev, &netcfg.speed, n->net_conf.speed);
>>>>>> +    netcfg.duplex = n->net_conf.duplex;
>>>>>>    memcpy(netcfg.mac, n->mac, ETH_ALEN);
>>>>>>    memcpy(config, &netcfg, n->config_size);
>>>>>> }
>>>>>> @@ -1941,6 +1951,23 @@ static void
>>>>>> virtio_net_device_realize(DeviceState *dev, Error **errp)
>>>>>>        n->host_features |= (0x1 << VIRTIO_NET_F_MTU);
>>>>>>    }
>>>>>> 
>>>>>> +    n->host_features |= (0x1 << VIRTIO_NET_F_SPEED_DUPLEX);
>>>>>> +    if (n->net_conf.duplex_str) {
>>>>>> +        if (strncmp(n->net_conf.duplex_str, "half", 5) == 0) {
>>>>>> +            n->net_conf.duplex = DUPLEX_HALF;
>>>>>> +        } else if (strncmp(n->net_conf.duplex_str, "full", 5) == 0) {
>>>>>> +            n->net_conf.duplex = DUPLEX_FULL;
>>>>>> +        } else {
>>>>>> +            error_setg(errp, "'duplex' must be 'half' or 'full'");
>>>>>> +        }
>>>>>> +    } else {
>>>>>> +        n->net_conf.duplex = DUPLEX_UNKNOWN;
>>>>>> +    }
>>>>>> +    if (n->net_conf.speed < SPEED_UNKNOWN) {
>>>>>> +            error_setg(errp, "'speed' must be between -1
>>>>>> (SPEED_UNKOWN) and "
>>>>>> +                       "INT_MAX");
>>>>>> +    }
>>>>>> +
>>>>>>    virtio_net_set_config_size(n, n->host_features);
>>>>>>    virtio_init(vdev, "virtio-net", VIRTIO_ID_NET, n->config_size);
>>>>>> 
>>>>>> @@ -2160,6 +2187,8 @@ static Property virtio_net_properties[] = {
>>>>>>    DEFINE_PROP_UINT16("host_mtu", VirtIONet, net_conf.mtu, 0),
>>>>>>    DEFINE_PROP_BOOL("x-mtu-bypass-backend", VirtIONet,
>>>>>> mtu_bypass_backend,
>>>>>>                     true),
>>>>>> +    DEFINE_PROP_INT32("speed", VirtIONet, net_conf.speed,
>>>>>> SPEED_UNKNOWN),
>>>>> 
>>>>> From Windows guest perspective I prefer to have some reasonable
>>>>> default (10G for example). 
>>>> 
>>>> 
>>>> hmmm, I didn't want to change/set the default here in case it broke
>>>> something, but I'm ok setting it to some 'reasonable' value - (10G and
>>>> duplex?), if the consensus is that that would be safe.
>>> 
>>> OK from my side.
>>> Thanks.
>> 
>> I presume your speaking for windows - i'm wondering if under linux the
>> virtio device suddenly start showing up as duplex, 10Gbps, will that
>> break anything? I can speak for the use-cases we have here and that
>> would certainly be fine for us, but i'm really not sure if that is ok
>> more generally.
>> 
>> Thanks,
>> 
>> -Jason
> 
> How about not enabling the flag unless the user specified the speed?
> This way we also do not need an "unknown" value.

This is even better.

> 
>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> -Jason
>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Yan.
>>>>> 
>>>>>> +    DEFINE_PROP_STRING("duplex", VirtIONet, net_conf.duplex_str),
>>>>>>    DEFINE_PROP_END_OF_LIST(),
>>>>>> };
>>>>>> 
>>>>>> diff --git a/include/hw/virtio/virtio-net.h
>>>>>> b/include/hw/virtio/virtio-net.h
>>>>>> index b81b6a4..af74a94 100644
>>>>>> --- a/include/hw/virtio/virtio-net.h
>>>>>> +++ b/include/hw/virtio/virtio-net.h
>>>>>> @@ -38,6 +38,9 @@ typedef struct virtio_net_conf
>>>>>>    uint16_t rx_queue_size;
>>>>>>    uint16_t tx_queue_size;
>>>>>>    uint16_t mtu;
>>>>>> +    int32_t speed;
>>>>>> +    char *duplex_str;
>>>>>> +    uint8_t duplex;
>>>>>> } virtio_net_conf;
>>>>>> 
>>>>>> /* Maximum packet size we can receive from tap device: header + 64k */
>>>>>> diff --git a/include/standard-headers/linux/virtio_net.h
>>>>>> b/include/standard-headers/linux/virtio_net.h
>>>>>> index 30ff249..0ff1447 100644
>>>>>> --- a/include/standard-headers/linux/virtio_net.h
>>>>>> +++ b/include/standard-headers/linux/virtio_net.h
>>>>>> @@ -36,6 +36,7 @@
>>>>>> #define VIRTIO_NET_F_GUEST_CSUM1/* Guest handles pkts w/ partial csum */
>>>>>> #define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Dynamic offload
>>>>>> configuration. */
>>>>>> #define VIRTIO_NET_F_MTU3/* Initial MTU advice */
>>>>>> +#define VIRTIO_NET_F_SPEED_DUPLEX 4/* Host set linkspeed and duplex */
>>>>>> #define VIRTIO_NET_F_MAC5/* Host has given MAC address. */
>>>>>> #define VIRTIO_NET_F_GUEST_TSO47/* Guest can handle TSOv4 in. */
>>>>>> #define VIRTIO_NET_F_GUEST_TSO68/* Guest can handle TSOv6 in. */
>>>>>> @@ -76,6 +77,9 @@ struct virtio_net_config {
>>>>>> uint16_t max_virtqueue_pairs;
>>>>>> /* Default maximum transmit unit advice */
>>>>>> uint16_t mtu;
>>>>>> +/* Host exported linkspeed and duplex */
>>>>>> +uint32_t speed;
>>>>>> +uint8_t duplex;
>>>>>> } QEMU_PACKED;
>>>>>> 
>>>>>> /*
>>>>>> -- 
>>>>>> 2.6.1

  reply	other threads:[~2017-12-20 14:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-14 19:33 [PATCH 0/2] virtio_net: allow hypervisor to indicate linkspeed and duplex setting Jason Baron
2017-12-14 19:33 ` [PATCH 2/2] qemu: add linkspeed and duplex setting to virtio-net Jason Baron
2017-12-18 11:34   ` [Qemu-devel] " Yan Vugenfirer
2017-12-18 16:04     ` Jason Baron
     [not found]       ` <21A64922-D22E-4AE1-8B4C-B0D85357240C@redhat.com>
2017-12-19 16:52         ` Jason Baron
2017-12-20 14:31           ` Michael S. Tsirkin
2017-12-20 14:33             ` Yan Vugenfirer [this message]
2017-12-21 19:42               ` Jason Baron
2017-12-21 20:40                 ` Michael S. Tsirkin
2017-12-14 19:33 ` [PATCH net-next 1/2] virtio_net: allow hypervisor to indicate linkspeed and duplex setting Jason Baron
2017-12-14 20:02   ` Michael S. Tsirkin
2017-12-20 14:57   ` Michael S. Tsirkin
2017-12-20 17:07     ` Jason Baron
2017-12-20 17:52       ` Michael S. Tsirkin
2017-12-20 21:32         ` Jason Baron
2017-12-21  0:10           ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F096C867-C75B-4756-B4F6-9774DDF2FC8B@redhat.com \
    --to=yvugenfi@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=jbaron@akamai.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®