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. > > Regards, > William > >>> >>> Without the "Avoid recirculation" patch we have two datapath flows, because >>> the >>> packet is recirculated. At the end of the first flow the packet size is >>> changed >>> and the packet with modified size enters the OF pipeline again. >>> >>> What is the reason not to change packet size when truncate action is >>> applied? >>> >> >> One of the reasons could be that we introduced trunc before clone. >> Otherwise, a >> clone(trunc2, output:x) is equivalent to trunc, output:x. Note that >> the trunc datapath >> action is different than other datapath actions, which usually applies >> to all following >> actions. Native tunneling may be the first use case that motivates >> trunc2, which should >> have the normal datapath action behavior. >> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
