From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: 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 12:40:20 +0000 [thread overview]
Message-ID: <200902131240.21150.paul@codesourcery.com> (raw)
In-Reply-To: <1234462898.25178.277.camel@bling>
> - A device requests a filter and is told if the request is successful
> - On success the device may skip it's own filtering
> - If another vlan client is added, the following _must_ occur:
> - The "filterer" must clear (remove) the filter
> - The "filteree" must revert to using their own filtering
> - If a vlan client is removed, the following _may_ occur:
> - vlan clients are notified that they may retry their filter
>..
> The added()/removed() interface feels like the right solution to this.
I think your analysis is fundamentally flawed. Firstly I'm not sure the above
holds when going between 1 and 2 clients on a vlan. Even ignoring that, you
are making implicit assumptions about when a filter will succeed. If these
assumptions are broken (which seems likely if we ever implement filtering
with more than 2 devices on a vlan) they you'll get subtle breakage in every
single user of the API.
> We could use a changed() function, but it would need to know the
> direction of the change, which leads back to the same mechanics. If
> there's a better way, please suggest it. Thanks,
I still don't see why the device needs to know what's changed. The response
should always be the same: Request a filter, and see if it works.
Paul
next prev parent reply other threads:[~2009-02-13 12:40 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 21:28 [PATCH 0/4] qemu: TAP filtering support Alex Williamson
2009-02-10 21:28 ` [PATCH 1/4] qemu:net: Add infrastructure for setting an RX filter through the vlan Alex Williamson
2009-02-10 21:28 ` [PATCH 2/4] qemu:net: Add TAP support for RX filtering on Linux Alex Williamson
2009-02-10 21:28 ` [PATCH 3/4] qemu:virtio-net: Add support for qemu_vlan_rxfilter Alex Williamson
2009-02-12 16:26 ` [Qemu-devel] " 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 [this message]
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
2009-02-15 16:25 ` Paul Brook
2009-02-10 21:29 ` [PATCH 4/4] qemu:e1000: " Alex Williamson
2009-02-11 15:11 ` Alex Williamson
2009-02-11 17:11 ` Alex Williamson
2009-02-11 19:31 ` [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 ` [Qemu-devel] " 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=200902131240.21150.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=alex.williamson@hp.com \
--cc=kvm@vger.kernel.org \
--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 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.