> On Sep 13, 2016, at 4:44 PM, Ben Pfaff <b...@ovn.org> wrote: > > On Mon, Sep 12, 2016 at 01:52:42PM -0700, Jarno Rajahalme wrote: >> Refactor handle_packet_out() to prepare for bundle support for packet >> outs in a later patch. >> >> Two new callbacks are introduced in ofproto-provider class: >> ->packet_xlate() and ->packet_execute(). ->packet_xlate() translates >> the packet using the flow and actions provided by the caller, but >> defers all OpenFlow-visible side-effects (stats, learn actions, actual >> packet output, etc.) to be explicitly executed with the >> ->packet_execute() call. >> >> Adds a new ofproto_rule_reduce_timeouts__() that must be called with >> 'ofproto_mutex' held. This is used in the next patch. >> >> Signed-off-by: Jarno Rajahalme <ja...@ovn.org> >> --- >> v3: Removed layer violations by making ofproto-dpif initialize and >> manage its private 'aux' member in struct ofproto_packet_out. > > It appears that an xlate_cache always allocates at least 512 bytes of > space. (It's not a change but I hadn't noticed before.) Is that right? > It seems like a lot, since I guess that the ordinary occupancy is much > smaller than that. >
It’s an union, and the size is 40 bytes per entry. Given that each match/miss gets a table entry, each matched rule gets a rule entry, and then the occasional normal, learn, etc., the total size in a complex pipeline could easily be the 512 or more. E.g., pipeline of 15 tables would generate about 30 entries, with total size of 1200 bytes in the ofpbuf. However, since some pipelines are simple, I reduced the initial size to 120 bytes. We can revisit this when the optimizations described below are done. I have though of optimizing this further by making the entires variable sized, much like the ofpacts. We could also add a table number to the XC_RULE entry, and then modify the XC_TABLE to XC_TABLE_MISS. That would effectively halve the number of entries, and also make the average entry size about 16 bytes. Furthermore, entries now using malloc could use the ofpbuf directly, which could save some alloc/free overhead. Finally, we could give the same treatment that I did for XC_NORMAL to XC_BOND and XC_NETFLOW, replacing the full struct flow with just the fields that are needed. > Acked-by: Ben Pfaff <b...@ovn.org <mailto:b...@ovn.org>> Thanks for the review! Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
