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. 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). 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
