On Thu, Dec 27, 2012 at 3:54 PM, Ben Pfaff <b...@nicira.com> wrote: > 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.
That's probably true. I'm still holding out some hope that we can have a unified way to look at all the packets flowing through the switch and then trace them. However, that's likely more of a logging issue than a tracing issue. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
