[ovs-dev] [PATCH v2] Simplify kernel sFlow implementation
pshelar at nicira.com
Wed Aug 17 16:34:04 PDT 2011
On Wed, Aug 17, 2011 at 3:04 PM, Neil McKee <neil.mckee at inmon.com> wrote:
> On Aug 17, 2011, at 2:30 PM, Ben Pfaff wrote:
>> On Wed, Aug 17, 2011 at 02:18:52PM -0700, Neil McKee wrote:
>>> On Aug 17, 2011, at 12:25 PM, Ben Pfaff wrote:
>>>> On Wed, Aug 17, 2011 at 11:51:05AM -0700, Pravin Shelar wrote:
>>>>> On Tue, Aug 16, 2011 at 11:17 PM, Jesse Gross <jesse at nicira.com> wrote:
>>>>>> 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.
>>>> I was proposing two steps. In the first step, userspace would set a
>>>> cookie that directly encodes information needed for sflow output.
>>> And you have to do that every time, regardless of whether any
>>> packets from that flow end up being sampled?
>> It's very cheap, so that's hardly worth worrying about.
>>>> the second step, userspace would set a cookie that uniquely identifies
>>>> a version of a flow. The second step is harder because userspace has
>>>> to keep around old versions of a flow for a while (the hardest part is
>>>> figuring out when they can be discarded, I think).
>>>> A checksum ties the set of actions to a flow. That's all we need for
>>>> sflow, although it means that we either need to keep around old
>>>> versions of a flow, as in the second step above, or just discard
>>>> sampled packets for old versions (I think that your patch does the
>>> Better to send the sample out with "unknown" egress port/vlan than
>>> to just drop it. Otherwise you are likely to systematically drop
>>> samples from flows that are short-lived, and the results will be
>>> biased. (You do still know the ingress-port, right?)
>> Thanks for the advice. I had not realized that sending a sample with
>> unknown egress data was an option. Yes, we still know the ingress
>> Our flows only expire through timeout (after about 5 seconds of
>> inactivity), so I don't think that this would systematically bias
>> against such flows.
>>>> It is not as general a solution as a unique identifier,
>>>> because when a flow's actions change from A to B and then back to A
>>>> there is no way to distinguish whether a sampled packet corresponds to
>>>> the first or second time that A was set. (That doesn't matter for
>>>> sflow.) That's a corner case; I don't know if it's important. And,
>>>> of course, the IP checksum only probabilistically tells us whether
>>>> there was a change.
>>> This may be stating the obvious, but it's important that you never
>>> send out a sample with the *wrong* egress port/vlan. That could
>>> break all kinds of things (topology discovery, end-host location,
>>> policy violations etc.)
>> Yes, I understand.
>>> Perhaps we could know more about what you are trying to achieve by
>>> changing this? Every suggestion seems to involve more complexity,
>>> more overhead or less accuracy. What's the upside?
>> We're trying to minimize the amount of code and complexity in the
> In the datapath directory I can see a total of about 30 lines of code that is related to sampling. The code to include the actions in the upcall seems to be just this:
> upcall.actions = acts->actions;
> upcall.actions_len = acts->actions_len;
> how many lines of user-space code are you willing to write to reduce this? I must be missing something. What am I missing?
Final goal is generalizing sampling action. so that we can assign
probability to any action.
so sampling would be userspace action with a probability. thats why we
need to decided generic interface.
More information about the dev