On Thu, Dec 27, 2012 at 03:29:18PM -0500, Jesse Gross wrote: > On Thu, Dec 27, 2012 at 2:37 PM, Ethan Jackson <et...@nicira.com> wrote: > > > >> Why shouldn't we give up in trace, as we do in the packet receive > >> path, if the port can't be found? "trace" is supposed to match the > >> packet receive path (otherwise it isn't as useful). I guess the > >> reason is that we don't have to, since the user specified the ofproto > >> name, but I think that we should anyway. > > > > > > There seems to be some contention on this point. Currently, the unit tests > > rely on this behavior. Specifically, you can do a trace without specifying > > an in_port and it will implicitly use OFPP_NONE. In previous rounds of > > review, I had suggested that we remove this option, and require a valid > > in_port to trace. Jesse suggested that this feature is important. I really > > don't care either way. Could you two please make a decision on the point? > > I think the problem is that trace has historically been pretty loose > about whether the data that it is interpreting is userspace level > (i.e. OpenFlow) or kernel level. It wasn't that important before > since they matched up pretty closely but with the single datapath > changes it's important that it's clear. > > * Userspace format: Anything that is logged by the core of userspace, > which will be after ODP/vlan/tunnel translation. This can also > include exact match OpenFlow flows. Here it's important to support > omitting the input port since it is commonly used with packet outs > (this is what I was talking about before). We also shouldn't try to > do any translation and instead will take an ofproto and OpenFlow port. > > * Kernel format: Packets coming up from the kernel or existing flows. > These definitely require translation and shouldn't require an ofproto > since it is implicit. Miss upcalls should always have an input port. > There is one possible case for not having an input port, which is a > packet out that then gets sent to userspace, such as for sFlow. It > probably doesn't make a lot of sense to trace these packets since > they're in the middle of an action list (and sFlow will just throw > them away anyways) so we could just disallow it. > > * Full packet: This one currently confuses the above two formats > since it expects both a userspace flow and kernel metadata like mark > and priority. This will become a problem soon since with IPsec flow > based tunneling the mark can determine the input port. In an ideal > world we would support both of the above modes independently and not > allow cross over. > > If we start making the sematics clear that it will be a lot easier to > determine the right behavior. For example, in the case of the unit > tests we should switch then from kernel style to userspace style.
This sounds like a good analysis. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
