On 10 May 2017 at 12:59, Andy Zhou <az...@ovn.org> wrote: > On Wed, May 10, 2017 at 7:56 AM, William Tu <u9012...@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. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev