Personally I'm happy enough with that.
On Thu, Dec 27, 2012 at 03:07:37PM -0800, Ethan Jackson wrote: > All of this makes sense. However I think it's out of the scope of the > original intention of this patch which was simply to refactor some common > code. The patch as is, maintains the current (admittedly broken) behavior > of trace. I propose we merge it without changing the semantics of trace > for now. In a (near) future series we can embark upon the project of > figuring out exactly how this stuff should work with the new single > datapath model. > > Thoughts? > Ethan > > On Thu, Dec 27, 2012 at 12:29 PM, Jesse Gross <je...@nicira.com> 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. > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
