From: Jamie Lokier <jamie@shareable.org>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org, Alex Williamson <alex.williamson@hp.com>,
kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter
Date: Fri, 13 Feb 2009 20:38:19 +0000 [thread overview]
Message-ID: <20090213203819.GC20328@shareable.org> (raw)
In-Reply-To: <200902131704.49809.paul@codesourcery.com>
Paul Brook wrote:
> > > A simple "Something changed, please try your filter again" callback
> > > automatically covers all these cases.
> >
> > It doesn't, if tap has no memory of how many clients require a filter.
>
> I'm talking about a callback for devices requesting an inbound
> filter. Devices implementing outgoing (device->vlan) filters just do
> as they're told.
So am I.
> > If tap just answers "YES and installs the kernel filter" or "NO and
> > doesn't install the kernel filter" and doesn't remember how many
> > clients need a filter, then:
> >...
> > In other words, tap needs to distinguish three states:
> >
> > "1 filter requested and installed in the kernel"
> > ">1 filter requested, none installed in the kernel"
> > "0 filters requested, none installed in the kernel"
>
> Absolutely not. This is the reason we have separate the "request an incoming
> filter" API from the "provide an outgoing filter" callback. It allows the
> vlan code to arbitrate in the middle.
I'm guessing that "vlan code to arbitrate in the middle" is exactly
what I've suggested.
Maybe the description was messed up. Substitute something else for
"tap" in the above: "The _vlan arbitration code which talks to the tap
device_ needs to distinguish three states...".
> A vlan is a bus network, not a set of point-point connections.
Yes, this is what I've assumed.
The callback you suggest for devices requesting an inbound filter will
infinite-loop when there's two such devices on the same vlan bus,
because each time the callback is called, that device will re-issue
its filter request which triggers the callback on the other similar
device. Back and forth.
To avoid the infinite loop, the vlan code in the middle (if that's
where you want it, and I agree) has to distinguish between no inbound
filters requested by attached devices, and multiple incompatible
inbound filters requested by attached devices.
-- Jamie
next prev parent reply other threads:[~2009-02-13 20:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 21:28 [Qemu-devel] [PATCH 0/4] qemu: TAP filtering support Alex Williamson
2009-02-10 21:28 ` [Qemu-devel] [PATCH 1/4] qemu:net: Add infrastructure for setting an RX filter through the vlan Alex Williamson
2009-02-10 21:28 ` [Qemu-devel] [PATCH 2/4] qemu:net: Add TAP support for RX filtering on Linux Alex Williamson
2009-02-10 21:28 ` [Qemu-devel] [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter Alex Williamson
2009-02-12 16:26 ` Paul Brook
2009-02-12 16:36 ` Alex Williamson
2009-02-12 17:05 ` Paul Brook
2009-02-12 18:21 ` Alex Williamson
2009-02-12 20:26 ` Jamie Lokier
2009-02-13 12:40 ` Paul Brook
2009-02-13 16:00 ` Jamie Lokier
2009-02-13 16:17 ` Paul Brook
2009-02-13 16:46 ` Jamie Lokier
2009-02-13 17:04 ` Paul Brook
2009-02-13 20:38 ` Jamie Lokier [this message]
2009-02-15 16:25 ` Paul Brook
2009-02-10 21:29 ` [Qemu-devel] [PATCH 4/4] qemu:e1000: " Alex Williamson
2009-02-11 15:11 ` [Qemu-devel] " Alex Williamson
2009-02-11 17:11 ` [Qemu-devel] " Alex Williamson
2009-02-11 19:31 ` [Qemu-devel] Re: [PATCH 0/4] qemu: TAP filtering support Mark McLoughlin
2009-02-11 19:43 ` Anthony Liguori
2009-02-11 19:51 ` Alex Williamson
2009-02-11 20:19 ` Mark McLoughlin
2009-02-11 20:37 ` Alex Williamson
2009-02-12 19:57 ` Jamie Lokier
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=20090213203819.GC20328@shareable.org \
--to=jamie@shareable.org \
--cc=alex.williamson@hp.com \
--cc=kvm@vger.kernel.org \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/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).