On Jan 5, 2015, at 2:39 PM, Ben Pfaff <b...@nicira.com> wrote: > On Mon, Jan 05, 2015 at 02:15:13PM -0800, Ben Pfaff wrote: >> On Mon, Jan 05, 2015 at 02:08:41PM -0800, Jarno Rajahalme wrote: >>> >>> On Dec 29, 2014, at 2:27 PM, Ben Pfaff <b...@nicira.com> wrote: >>> >>>> 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> >>> >>>> This seems mostly straightforward. Are there particular parts you'd >>>> like me to look over carefully? >>>> >>> >>> Maybe the changes to the miniflow push macros, which get a bit more >>> complicated... >> >> OK, I'll do that in a bit. > > I read them through them. I didn't spot any bugs, although they're > somewhat tricky.
Is this an Acked-by then? Jarno _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
