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
