I'm fine with that too.
On Thu, Dec 27, 2012 at 6:09 PM, Ben Pfaff <b...@nicira.com> wrote: > 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
