On Wed, May 10, 2017 at 2:30 PM, Joe Stringer <j...@ovn.org> wrote: > 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.
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? _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
