On Wed, Dec 17, 2014 at 10:30:42AM -0800, Jarno Rajahalme wrote: > So far the compressed flow data in struct miniflow has been in 32-bit > words with a 63-bit map, allowing for a maximum size of struct flow of > 252 bytes. With the forthcoming Geneve options this is not sufficient > any more. > > This patch solves the problem by changing the miniflow data to 64-bit > words, doubling the flow max size to 504 bytes. Since the word size > is doubled, there is some loss in compression efficiency. To counter > this some of the flow fields have been reordered to keep related > fields together (e.g., the source and destination IP addresses share > the same 64-bit word). > > This change should speed up flow data processing on 64-bit CPUs, which > may help counterbalance the impact of making the struct flow bigger in > the future. > > Classifier lookup stage boundaries are also changed to 64-bit > alignment, as the current algorithm depends on each miniflow word to > not be split between ranges. This has resulted in new padding (part > of the 'mpls_lse' field). > > The 'dp_hash' field is also moved to packet metadata to eliminate > otherwise needed padding there. This allows the L4 to fit into one > 64-bit word, and also makes matches on 'dp_hash' more efficient as > misses can be found already on stage 1. > > Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com> > Summary:
I don't think we have a Summary: tag. This seems mostly straightforward. Are there particular parts you'd like me to look over carefully? I have a suggestion for miniflow_extract(). It is getting more complex over time, and becoming more difficult to understand. I wonder whether a simpler approach would be just as fast and easier to understand. Suppose that, instead of constructing a miniflow initially, we instead construct a regular "struct flow" on the stack. All the zeroing and then later checking for nonzero values is what drove us earlier to move to building a miniflow directly, so we'd want to avoid that. But we can do that by not initializing the flow at all, and just keeping track in a map of the u32s (or u64s) we've initialized, and then copying those fields into a miniflow based on the map we assembled. (I made the same suggestion in November, but I didn't get a reply, so I think that you must have missed it in all the email that you get.) _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
