Alex Williamson wrote:
> They don't, but they do need to know whether a filter they previously
> applied successfully is no longer in place. If they don't know this,
> they have to assume the filter on the other side of the vlan is
> transient and always double check it with their own filtering, which
> seems like a waste of cache and cycles.
Double checking is not a waste of cycles if the host filtering is good
but not guaranteed, as it still means fewer packets cross the host
kernel/user boundary.
How reliable are the host filter interfaces anyway?
- Are they 100% reliable? For example, I remember at one time on
Linux, when application A listened for broadcast IP packets, you
wouldn't receive any which has a unicast MAC address for a
different host, except for the times when tcpdump was run in
parallel. That's an example of when the app sees the host filtering
behave differently depending on other apps run at the same time.
Multicast hash filtering is similar, but also depends on the host NIC.
- When updated, do the host filters take effect from the instant
the host syscall returned, or can there be already queued
packets which bypass the new filter?
> - 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.
> 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,
If there are two vlan clients, you don't necessarily need them to use
their own filters, if they are both the same, or compatible in some way.
How about this:
- On any change, notify all clients by walking the list twice.
- Phase 1. For each client:
- The client requests a filter.
- Phase 2. For each client:
- The client enquires whether its filter is in place.
If yes, it relies on it. If no or unreliable, it filters itself.
During this procedure, don't do any packet I/O.
During phase 1, don't send a request to the host kernel until just one
at the end (if the filter has changed), otherwise there will be a
brief time window with no host filter which could leak packets despite
no real change wanted and no packet I/O performed.
The same procedure is done for any configuration change, and together
with that change. Actually: Stop packet I/O, then phase 1, then
update host kernel taps if they've changed, then phase 2, then restart
packet I/O.
-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
