qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevic@redhat.com>
To: Amos Kong <akong@redhat.com>, qemu-devel@nongnu.org
Cc: lcapitulino@redhat.com, sf@sfritsch.de, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] virtio-net: add a field to indicate if vlan table is used
Date: Thu, 20 Feb 2014 12:46:14 -0500	[thread overview]
Message-ID: <53063F66.3020805@redhat.com> (raw)
In-Reply-To: <1392914322-27329-1-git-send-email-akong@redhat.com>

On 02/20/2014 11:38 AM, Amos Kong wrote:
> Stefan Fritsch just fixed a virtio-net driver bug [1], virtio-net won't
> filter out VLAN-tagged packets if VIRTIO_NET_F_CTRL_VLAN isn't negotiated.
> 
> This patch added a new field to @RxFilterInfo to indicate if management
> uses the vlan table.
> 
> [1] http://lists.nongnu.org/archive/html/qemu-devel/2014-02/msg02604.html
> 
> Signed-off-by: Amos Kong <akong@redhat.com>
> ---
> V2: don't make vlan-table optional, add a flag to indicate
>     if vlan table is used by management
> ---
>  hw/net/virtio-net.c | 38 +++++++++++++++++++++++++-------------
>  qapi-schema.json    |  3 +++
>  qmp-commands.hx     |  2 ++
>  3 files changed, 30 insertions(+), 13 deletions(-)
> 
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 3626608..f591f4e 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -222,13 +222,33 @@ static char *mac_strdup_printf(const uint8_t *mac)
>                              mac[1], mac[2], mac[3], mac[4], mac[5]);
>  }
>  
> +static intList *get_vlan_table(VirtIONet *n)
> +{
> +    intList *list, *entry;
> +    int i, j;
> +
> +    list = NULL;
> +    for (i = 0; i < MAX_VLAN >> 5; i++) {
> +        for (j = 0; n->vlans[i] && j < 0x1f; j++) {
> +            if (n->vlans[i] & (1U << j)) {
> +                entry = g_malloc0(sizeof(*entry));
> +                entry->value = (i << 5) + j;
> +                entry->next = list;
> +                list = entry;
> +            }
> +        }
> +    }
> +
> +    return list;
> +}
> +
>  static RxFilterInfo *virtio_net_query_rxfilter(NetClientState *nc)
>  {
>      VirtIONet *n = qemu_get_nic_opaque(nc);
> +    VirtIODevice *vdev = VIRTIO_DEVICE(n);
>      RxFilterInfo *info;
>      strList *str_list, *entry;
> -    intList *int_list, *int_entry;
> -    int i, j;
> +    int i;
>  
>      info = g_malloc0(sizeof(*info));
>      info->name = g_strdup(nc->name);
> @@ -273,19 +293,11 @@ static RxFilterInfo *virtio_net_query_rxfilter(NetClientState *nc)
>          str_list = entry;
>      }
>      info->multicast_table = str_list;
> +    info->vlan_table = get_vlan_table(n);
>  
> -    int_list = NULL;
> -    for (i = 0; i < MAX_VLAN >> 5; i++) {
> -        for (j = 0; n->vlans[i] && j < 0x1f; j++) {
> -            if (n->vlans[i] & (1U << j)) {
> -                int_entry = g_malloc0(sizeof(*int_entry));
> -                int_entry->value = (i << 5) + j;
> -                int_entry->next = int_list;
> -                int_list = int_entry;
> -            }
> -        }
> +    if ((1 << VIRTIO_NET_F_CTRL_VLAN) & vdev->guest_features) {
> +        info->vlan = true;
>      }

So, in the case that vlan filtering is not supported in the guest
we get:
             "vlan": false,
             "vlan-table": [
                 0,
                 1,
                 2,
                 ...
                 4095
            ]
since virtio_net now initializes the table to all 1s.
Seems a bit awkward.  We are providing a lot of data that
is simply going to be ignored.

> -    info->vlan_table = int_list;
>  
>      /* enable event notification after query */
>      nc->rxfilter_notify_enabled = 1;
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 7cfb5e5..5b54e94 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -4032,6 +4032,8 @@
>  #
>  # @unicast-overflow: unicast table is overflowed or not
>  #
> +# @vlan: whether management uses the vlan table
> +#

The above description seems a bit confusing to me.  The value
we are returning describes whether or not qemu is performing
vlan filtering.  I am not sure if it has any bearing on what
management may be doing.

I think the idea is that management, in the future, would look at
this value and make some decision about applying provided filter
to the current host configuration.

>  # @main-mac: the main macaddr string
>  #
>  # @vlan-table: a list of active vlan id
> @@ -4052,6 +4054,7 @@
>      'broadcast-allowed':  'bool',
>      'multicast-overflow': 'bool',
>      'unicast-overflow':   'bool',
> +    'vlan':               'bool',

Not terribly descriptive.  May be call it vlan-filter?

Thanks
-vlad
>      'main-mac':           'str',
>      'vlan-table':         ['int'],
>      'unicast-table':      ['str'],
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index cce6b81..b170c79 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -3307,6 +3307,7 @@ Each array entry contains the following:
>  - "broadcast-allowed": allow to receive broadcast (json-bool)
>  - "multicast-overflow": multicast table is overflowed (json-bool)
>  - "unicast-overflow": unicast table is overflowed (json-bool)
> +- "vlan": management uses the vlan table (json-bool)
>  - "main-mac": main macaddr string (json-string)
>  - "vlan-table": a json-array of active vlan id
>  - "unicast-table": a json-array of unicast macaddr string
> @@ -3321,6 +3322,7 @@ Example:
>              "name": "vnet0",
>              "main-mac": "52:54:00:12:34:56",
>              "unicast": "normal",
> +            "vlan": true,
>              "vlan-table": [
>                  4,
>                  0
> 

  parent reply	other threads:[~2014-02-20 18:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-20 16:38 [Qemu-devel] [PATCH v2] virtio-net: add a field to indicate if vlan table is used Amos Kong
2014-02-20 16:47 ` Eric Blake
2014-02-20 17:46 ` Vlad Yasevich [this message]
2014-02-21 10:01   ` Amos Kong
2014-02-28 18:29     ` Luiz Capitulino
2014-03-03  5:46       ` Amos Kong
2014-03-25 10:21         ` Michael S. Tsirkin
2014-03-25 10:18   ` Michael S. Tsirkin
2014-03-25 10:15 ` 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=53063F66.3020805@redhat.com \
    --to=vyasevic@redhat.com \
    --cc=akong@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sf@sfritsch.de \
    /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;
as well as URLs for NNTP newsgroup(s).