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. > > The use of the checksum for actions surprised me a little bit, as it > is semantically equivalent to what we have today but perhaps not as > accurate. Ben made a couple of good suggestions in the previous > thread about how to do this cleanly and generically. Did you run into > problems with those? > AFAIU, Ben was suggesting to have cookie set from userspace. that cookie can be returned on upcall. so that userspace can validate flow used in kernel datapath. Other part was about keeping flows which are deleted and updated. so that sflow can lookup those flows if required. I thought cookie can be generated in kernel using checksum and return it to userspace. In this way we do not need to change user-kernel interface when sflow need extra information as it has exact flow that kernel used. Actually it is mentioned in previous mail thread. About keeping flow in userspace, I had chat with Ben about same and we thought it can increase memory requirement plus userspace needs some support from kernel to purge those flows. So I decided to postpone this part. Thanks, Pravin. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
