From: "Michael S. Tsirkin" <mst@redhat.com>
To: Amos Kong <akong@redhat.com>
Cc: Vlad Yasevich <vyasevic@redhat.com>,
sf@sfritsch.de, qemu-devel@nongnu.org,
Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] virtio-net: add a field to indicate if vlan table is used
Date: Tue, 25 Mar 2014 12:21:08 +0200 [thread overview]
Message-ID: <20140325102108.GC25131@redhat.com> (raw)
In-Reply-To: <20140303054634.GA20193@amosk.info>
On Mon, Mar 03, 2014 at 01:46:34PM +0800, Amos Kong wrote:
> On Fri, Feb 28, 2014 at 01:29:59PM -0500, Luiz Capitulino wrote:
> > 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?
>
> NAK my patch, it's unnecessary.
I don't agree.
libvirt does not yet look at the filter info, so let's do the
job properly.
https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg02604.html
> > > [1] [PATCH] virtio-net: Do not filter VLANs without F_CTRL_VLAN
> > >
> > > Thanks, Amos
next prev parent reply other threads:[~2014-03-25 10:21 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
2014-03-03 5:46 ` Amos Kong
2014-03-25 10:21 ` Michael S. Tsirkin [this message]
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=20140325102108.GC25131@redhat.com \
--to=mst@redhat.com \
--cc=akong@redhat.com \
--cc=lcapitulino@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.