On Thu, May 11, 2017 at 9:12 AM, Joe Stringer <[email protected]> wrote: > 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.
Thanks for explaining. Some difficult part of this series is about simulating the re-parsing of the packet. It probably make more sense to discuss this after this series has landed. > > 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. This is an interesting idea. Each packet may have a different size, I am not sure we can determine this at the translation time. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
