All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Capitulino <lcapitulino@redhat.com>
To: Amos Kong <akong@redhat.com>
Cc: Vlad Yasevich <vyasevic@redhat.com>,
	sf@sfritsch.de, qemu-devel@nongnu.org, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] virtio-net: add a field to indicate if vlan table is used
Date: Fri, 28 Feb 2014 13:29:59 -0500	[thread overview]
Message-ID: <20140228132959.3d3637fa@redhat.com> (raw)
In-Reply-To: <20140221100140.GA1679@amosk.info>

On Fri, 21 Feb 2014 18:01:40 +0800
Amos Kong <akong@redhat.com> wrote:

> On Thu, Feb 20, 2014 at 12:46:14PM -0500, Vlad Yasevich wrote:
> > 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.
> 
> In Stefan's patch [1], qemu fills all vlan ids to 1, then all the
> packets will come to guest.
> 
> For the host device, it also should not filter out any vlan-tagged
> packets when VIRTIO_NET_F_CTRL_VLAN is not negotiated. We should also
> fill vlan ids of host device to 1, then vlan-filter of host device
> will not perform.
> 
> If so, we don't need my patch, just pass [0,1,2,...4095] to management
> as past. The new field in RxFilterInfo isn't necessary.

What's the conclusion here?

> 
> [1] [PATCH] virtio-net: Do not filter VLANs without F_CTRL_VLAN 
> 
> Thanks, Amos
>  
> > > -    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
> > > 
> 

  reply	other threads:[~2014-02-28 18:30 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
2014-02-21 10:01   ` Amos Kong
2014-02-28 18:29     ` Luiz Capitulino [this message]
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=20140228132959.3d3637fa@redhat.com \
    --to=lcapitulino@redhat.com \
    --cc=akong@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sf@sfritsch.de \
    --cc=vyasevic@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.