On Thu, Dec 18, 2014 at 05:13:47PM -0800, Neil McKee wrote: > I want the sFlow module to know when a sampled packet was a cache miss in > the datapath. That way we can include this information with the sFlow > sample feed that is sent out, and applications can analyze the data to see > what mix of traffic is suffering cache misses. Any ideas on how to add > this? > > When a cache miss is upcall'd to userspace (from In > datapath/datapath.c:ovs_dp_process_packet()), then userspace reacts by > pushing down operations to create a new flow and send that packet > (lib/dpif-netlink.c:dpif_operate()). But if that packet is then sampled > and upcall'd to sFlow there does not seem to be a flag we can inspect to > know that it was a cache miss in the first place. > > If the datapath were to include the number of packets seen by the flow so > far when it upcalls a sample (that number is kept in struct sw_flow in the > datapath flow cache) then we could infer it was a cache miss when we see > that number == 1. > > Alternatively, if we could set a bit somewhere when we pass the cache-miss > back down to be sent, so that the bit is preserved and visible if that > same packet is then sampled, then we could do it that way. Trying to > avoid datapath changes I looked to see if there was a way to set a bit in > the skbuff that would survive and come back in a sample, but I'm not sure > how to go about doing that. > > Or maybe there is another way?
Two approaches come to mind. One way is to add a bit to struct user_action_cookie's 'sflow' member that indicates whether the sample was produced by a cache miss. This might be tricky because it would mean that the OVS_PACKET_CMD_EXECUTE and OVS_FLOW_CMD_SET passed to the datapath would need different actions in the sflow case; until now, they have always been the same. The other way is to process sflow sample actions entirely in userspace, without passing them to the datapath at all. I am not sure of the best place to do that; I haven't looked. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
