[ovs-dev] [PATCH 1/6] ofproto-dpif: New function ofproto_receive().

[Ethan Jackson]

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 <jesse at nicira.com> wrote:

> On Thu, Dec 27, 2012 at 2:37 PM, Ethan Jackson <ethan at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20121227/73f3851b/attachment-0003.html>