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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
