On Aug 18, 2011, at 4:21 AM, Jesse Gross wrote: > On Aug 18, 2011 2:51 AM, "Pravin Shelar" <pshe...@nicira.com> wrote: > > > > On Tue, Aug 16, 2011 at 11:17 PM, Jesse Gross <je...@nicira.com> wrote: > > > On Mon, Aug 15, 2011 at 8:34 PM, pravin shelar <pshe...@nicira.com> wrote: > > >> This patch makes sampling support more generic/simple by adding > > >> Datapath SAMPLING action. When sampling is turned on, a SAMPLING > > >> action is added to all flows for given bridge. > > >> This patch cleanup sampling upcall by striping it down to minimum > > >> essential that userspace can not figure out for itself. Now sample > > >> packet is sent along with actions checksum. So that sflow module can > > >> make sure it has consistent actions. > > > > > > I'm not sure that this does much to simplify or genericize sampling. > > > For the sample action itself, I was expecting something that could be > > > used to execute any set of actions with a given probability but this > > > is still tied towards sending packets to userspace with a fixed > > > probability across the datapath. This would truly be generic and the > > > word "sFlow" would not appear in the kernel at all but could be > > > implemented entirely in userspace based on these primitives. Does > > > this make sense to you? > > > > I think patch is first step toward that. > > > > My idea is to have sampling action with arguments like probability(P) > > and action(A). When probability(P) is hit, passed action (A) could be > > executed on that packet. But i dont like to generalize when there is > > only one use case at present where we need to assign probability. it > > just keeps things simple. > > I mentioned this on the phone but just for everybody else's benefit: > > My main goal here is to come up with an interface that is as close to final > as we can get it. While in general I agree with incremental work, in this > case I think we need to go the full way in regards to the interface. > >
Yes. It would a shame to only get half way and risk breaking the current solution without quite nailing the more generic API either. So can we enumerate some of the use cases? Sampled-RSPAN? Random-forwarding for load-balancing? If you have multiple consumers for samples, all with different sampling-probabilities, then obviously it's important that they can operate efficiently and independently without treading on each others toes. For example, you might only have to generate a random number once, but then several different actions might test it against different probability thresholds. Would "generate-a-random-number" now become an action too? (gosh, the actions-list is starting to look like a FORTH program - not that there's anything wrong with that!). You would also have to be prepared for the same packet to get sampled by different actions and copied onto multiple channels to user-space. You might want some of those channels to be higher priority than others. But I'm sure you've already thought of all these ramifications. I'm still not persuaded that there's anything wrong with copying the actions to user-space as you do now. It can continue to be an annotation that always goes along with any sampled packets that are going there. Stuffing that other 64-bit field into every rule -- just for sFlow -- seems counter to the spirit of this streamlining effort. Neil > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
