From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Daniel P. Berrange" <berrange@redhat.com>
Cc: Amos Kong <akong@redhat.com>,
qemu-devel@nongnu.org, stefanha@redhat.com,
lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [PATCH v5] net: add support of mac-programming over macvtap in QEMU side
Date: Wed, 5 Jun 2013 14:02:06 +0300 [thread overview]
Message-ID: <20130605110206.GI31830@redhat.com> (raw)
In-Reply-To: <20130605104922.GF17576@redhat.com>
On Wed, Jun 05, 2013 at 11:49:22AM +0100, Daniel P. Berrange wrote:
> On Wed, Jun 05, 2013 at 06:42:13PM +0800, Amos Kong wrote:
> > Currently macvtap based macvlan device is working in promiscuous
> > mode, we want to implement mac-programming over macvtap through
> > Libvirt for better performance.
> >
> > Design:
> > QEMU notifies Libvirt when rx-filter config is changed in guest,
> > then Libvirt query the rx-filter information by a monitor command,
> > and sync the change to macvtap device. Related rx-filter config
> > of the nic contains main mac, rx-mode items and vlan table.
> >
> > This patch adds a QMP event to notify management of rx-filter change,
> > and adds a monitor command for management to query rx-filter
> > information.
> >
> > For reducing length of output, we just return the entries of vlan
> > filter table that have active vlan.
> >
> > Event_throttle API can avoid the events to flood QMP client, but it
> > could cause an unexpected delay. So a flag for each nic is used to
> > avoid events flooding, if management doesn't query rx-filter after
> > it receives one event, new events won't be emitted to QMP monitor.
> >
> > There maybe exist an uncontrollable delay if we let Libvirt do the
> > real change, guests normally expect rx-filter updates immediately.
> > But it's another separate issue, we can investigate it when the
> > work in Libvirt side is done.
>
> What work is libvirt expected to do in response to these events ?
> It this just about updating the ebtables rules to allow packets
> with the newly configured MAC addr to be sent/received on the
> tap backend ?
>
> Daniel
For tap yes, but it depends on the backend.
For the macvtap backend, it needs to update the macvtap device mac(s)
and rx mode.
It also needs to be policy driven - some admins might want
to prevent the ability to change MAC for (some) guests.
> --
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2013-06-05 11:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 10:42 [Qemu-devel] [PATCH v5] net: add support of mac-programming over macvtap in QEMU side Amos Kong
2013-06-05 10:49 ` Daniel P. Berrange
2013-06-05 11:02 ` Michael S. Tsirkin [this message]
2013-06-06 7:00 ` Jason Wang
2013-06-14 5:55 ` Amos Kong
2013-06-07 13:46 ` Luiz Capitulino
2013-06-14 6:05 ` Amos Kong
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=20130605110206.GI31830@redhat.com \
--to=mst@redhat.com \
--cc=akong@redhat.com \
--cc=berrange@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@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).