> On May 10, 2017, at 12:59 PM, Andy Zhou <[email protected]> wrote: > > On Wed, May 10, 2017 at 7:56 AM, William Tu <[email protected] > <mailto:[email protected]>> 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. >
Right, why should truncated OUTPUT to a patch port behave any different from any other OUTPUT port? Jarno > >> >> 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 > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
