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