Actually it wasn't just tunnel ports. Anything that didn't have an ifIndex was mapping to the same sFlow datasource. Even if it was on another bridge.
Besides, sFlow wouldn't want to model every tunnel as a separate datasource either -- even if they did have ifIndex numbers. There might be thousands. The idea is to have a small number of fairly-persistent datasources and report on tunnels by annotating individual packet samples (see below). I think the original thinking (years ago) was that we might ignore all samples that did not ingress on an ifindex-interface, but that's not what is happening, and it's not what we want to happen now anyway. Now it's quite common to see ingress-sampled packets that we really want to report on where that ingress port doesn't have an ifIndex (GRE tunnels being just the most obvious example). So if we drop the per-interface-sampler representation and adopt one that more accurately represents what is going on below then it falls out correctly, and still conforms to the sFlow v5 standard. So looking at the code, the hash-table that the ofproto-sflow module maintains to look up odp_port -> struct of_port becomes just a cache of the ifindex ports. It is still needed so that the counter-push data-sources can retrieve the latest stats from the netdev, and so that the packet samples can have their ingress ifindex filled in where applicable. However if an ingress sample comes in for some other port and there is no lookup in the table then it's no longer a show-stopper. It just means that the packet sample goes out with inputPort = 0 (meaning "ifindex unknown "). Ideally, we would want to know the original ifIndex of the physical port where that tunnel first entered the hypervisor, but that seems hard to know. Looking ahead, it would be good to know the details of the tunnel too, so we could annotate the packet-sample with another structure: http://sflow.org/sflow_tunnels.txt but that might be part of a broader discussion where we look at ways to expose more state to the ofproto-sflow module. For example, I am currently looking at how the bundle information might be exposed so that we can also fill in these structures: http://www.sflow.org/sflow_lag.txt And sFlow has standard structures for reporting on MPLS too: http://www.sflow.org/SFLOW-STRUCTS5.txt It seems like there is choice between (1) pushing the information down to ofproto-sflow on a state-change (as we do with that odp_port -> of_port lookup) or (2) providing callback hooks that allow ofproto-dpif-sflow to ask ofproto-dpif questions about tunnels, bundles and more. Right now it looks to me like the latter would be better, because it allows ofproto-dpif to completely control what is exposed and keep a tight grip on all it's internal pointers. But maybe there are other architectural considerations? Neil On Apr 24, 2013, at 11:09 AM, Jesse Gross wrote: > On Wed, Apr 24, 2013 at 10:46 AM, Neil Mckee <neil.mc...@inmon.com> wrote: >> Adjust sFlow packet samplers to better reflect the underlying per-bridge >> sampling that is really happening, rather than modeling it as per-interface >> sampling. This fixes an aliasing issue: tunnel traffic sampled on different >> bridges was all being reported against the same sFlow datasource. >> >> The sFlow counter samples remain unchanged, reporting only on interfaces >> that have valid ifIndex numbers. >> >> See definition of SFlowDataSource in http://sflow.org/sflow_version_5.txt. >> >> Signed-off-by: Neil McKee <neil.mc...@inmon.com> > > It actually is possible to disambiguate between tunnel ports in order > to continue reporting on a per-port basis, have you considered doing > that? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
