[ovs-dev] [PATCH v5] tunneling: Avoid recirculation on datapath by computing the recirculate actions at translate time.

[Joe Stringer]

On 10 May 2017 at 12:59, Andy Zhou <azhou at ovn.org> wrote:
> On Wed, May 10, 2017 at 7:56 AM, William Tu <u9012063 at gmail.com> wrote:
>>> It may be cleaner if we add a new trunc action for the datapath, say
>>> trunc2  that applies
>>> to all outputs within the clone.
>>>
>>> So the translation will look like: clone(trunc2, native tunnel
>>> translation). Would this
>>> approach work?
>>>
>>
>> Or how about we apply actual packet truncation when clone action
>> follows truncate action?
>> Now we apply actual packet truncation when:
>> actions=trunc, output
>> actions=trunc, tunnel_push
>> actions=trunc, sample
>
>>
>> If we add clone as another truncate target, then
>> actions = trunc(100), clone(tnl(...)),  actionX,
>> Inside clone will see packet of size 100, and actionX sees original
>> size. Then I think we don't need to introduce trunc2?
>
> This is a reasonable approach. Thanks for the suggestion.
>
> Picking up the topic of trunc on patch port.
>
> Instead of banning trunc output to a patch port, any down side of
> translating that
> to trunc, clone(<patch port translation>)? After all, native tunneling
> looks a lot like patch port conceptually.

How does clone() interact with trunc() in the datapath?

As I understand, before clone() existed in datapath (at least linux
side), the trunc() would only apply to the next output().
Conceptually, if trunc(),clone(...) applies the truncation for the
duration of the clone() then that sounds fine. I'm a little concerned
that a really small truncate value should actually affect parsing of
packet headers for subsequent tables/lookups though. All of this is a
lot simpler if it's tied directly to the output, but now that we're
looking at handling the translation over another bridge without
re-extracting the packet it gets more complex.