On Thu, Dec 27, 2012 at 03:35:27PM -0500, Jesse Gross wrote: > On Thu, Dec 27, 2012 at 3:30 PM, Ben Pfaff <b...@nicira.com> wrote: > > On Thu, Dec 27, 2012 at 11:37:31AM -0800, Ethan Jackson 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? > > > > We have to be able to deal with flows that have no in_port to support > > OpenFlow "ofp_packet_out", which allows no in_port to be specified. > > But that's different from "trace" because ofp_packet_out doesn't do a > > flow table lookup (it includes its own list of actions). I'm not sure > > that it's really necessary to support "no input port" here. > > > > Jesse, comments? > > The one thing that I would add is that if you have a packet out to > TABLE then it is possible to do a flow lookup with no input port and > it's very useful to be able to trace these.
I agree. I think a parallel feature for tracing packet-outs might be easier and cleaner than lumping it into the current trace command, which is already too overloaded. TABLE and resubmits (which follow the same internal path) don't go through Ethan's new helper, which means that it wouldn't have the same problem. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
