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? > 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?) > 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.) 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? 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
