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

Reply via email to