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

Andy Zhou azhou at ovn.org
Thu May 11 17:48:44 UTC 2017


On Thu, May 11, 2017 at 7:57 AM, William Tu <u9012063 at gmail.com> wrote:
> [snip]
>>>> 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.
>>
>> That's the proposal on the table. Conceptually, we just treat clone
>> as another output.
>>
>> I'm a little concerned
>>> that a really small truncate value should actually affect parsing of
>>> packet headers for subsequent tables/lookups though.
>>
>> Isn't this the inherent problem with trunc? trunc causes a packet
>> to become a partial packet, that may cause subsequent actions
>> to fail.
>>
>>  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.
>>
>> What is the additional complexity over handling patch ports
>> over that of native tunneling?
>
> Before the tunneling: Avoid recirculation on datapath (commit
> f1dac51), handling truncate and native tunneling is simple. The native
> tunneling applies the tunnel metadata and output to the tunnel port,
> and truncation applies at before the outputting tunnel port. And
> because we will recirculate and re-parse, the flow key and stats are
> also correct after re-parsing and matching on the truncated packet.
>
> IMO, handling truncate and patch port is way more complex. It means
> translation over another bridge without re-parsing, and the packet
> could match to do anything including native tunneling.
>
> If the only use case of truncate is to sample/mirror, then what if we
> allow trunc and patch port, and applies actual packet truncation
> before sending to the patch port? Like Joe mentioned, another bridge
> might match fields truncated, or actions might fail, but its inherent
> issue of truncate and users should know about it.

This approach makes sense to me.
>
> Regards,
> William


More information about the dev mailing list