On Thu, May 11, 2017 at 7:57 AM, William Tu <[email protected]> wrote: > [snip] >>>> 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? > > Before the tunneling: Avoid recirculation on datapath (commit > f1dac51), handling truncate and native tunneling is simple. The native > tunneling applies the tunnel metadata and output to the tunnel port, > and truncation applies at before the outputting tunnel port. And > because we will recirculate and re-parse, the flow key and stats are > also correct after re-parsing and matching on the truncated packet. > > IMO, handling truncate and patch port is way more complex. It means > translation over another bridge without re-parsing, and the packet > could match to do anything including native tunneling. > > If the only use case of truncate is to sample/mirror, then what if we > allow trunc and patch port, and applies actual packet truncation > before sending to the patch port? Like Joe mentioned, another bridge > might match fields truncated, or actions might fail, but its inherent > issue of truncate and users should know about it.
This approach makes sense to me. > > Regards, > William _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
