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 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).