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 <je...@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.
>
>>> In
>>> 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
>>> latter).
>>
>> 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
> port.
>
> 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
> kernel.
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?
Neil
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
