[ovs-dev] [PATCH v2] Simplify kernel sFlow implementation

Pravin Shelar pshelar at nicira.com
Wed Aug 17 18:51:05 UTC 2011


On Tue, Aug 16, 2011 at 11:17 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Mon, Aug 15, 2011 at 8:34 PM, pravin shelar <pshelar at 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.



More information about the dev mailing list