On 10 May 2017 at 17:08, Andy Zhou <[email protected]> wrote: > On Wed, May 10, 2017 at 2:30 PM, Joe Stringer <[email protected]> wrote: >> On 10 May 2017 at 12:59, Andy Zhou <[email protected]> wrote: >>> On Wed, May 10, 2017 at 7:56 AM, William Tu <[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. >> >> 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.
True. However.. > 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? So far, you could not install rules that output+truncate to a patch port. Translation could be simpler, because it didn't need to apply this truncation and determine what the behaviour is going to be after truncation. The packet is truncated and it egresses OVS. If that packet happened to come back into OVS, then it would be a completely fresh parsing of the packet, matching is based on the fields available, etc. So the additional complexity is that the translation layer never got an implementation for truncate, output to patch, and continue processing. One thing we could consider is if we can figure out how many bytes are required by OVS to do the full extraction, and if the truncation size is larger than this, then we know we can translate directly. If truncation size is less than the 'full ovs parse header length', then we could just recirculate and let the datapath perform truncation. We probably don't need to optimize that path at this stage. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
