On 21 May 2014 06:40, Ben Pfaff <b...@nicira.com> wrote: > > > I'm not sure whether you would want it in this in a separate patch, but > it > > appears that we only try to detect "already_dumped" for flows that > haven't > > been used before. Flows which have been used before and are duplicated > will > > execute through to revalidate_ukey(), and potentially revalidate twice > (but > > only if the first revalidation was successful). > > > > I've been looking at replacing 'ukey->mark' with a seq which would > simplify > > detecting already-dumped flows, so I could try to address these concerns > > separately if you like. > > I think that's subtle enough that I'd prefer to address it > separately. This patch is intended to be only a refactoring, without > significant changes to behavior (the insignificant changes should only > be to how batches get formed). >
OK. > > With this patch, it is much easier to tell how many flows are being > handled > > in a batch. Out of curiousity, do you know: > > * How many can we fit inside a buffer of NL_DUMP_BUFSIZE (avg case)? > > Looking at the definition of ODPUTIL_FLOW_KEY_BYTES, I'd guess that > the "average" key, when tunneling is going on, is about 150 bytes. > Triple that (just a guess) to account for the mask, actions, stats, > other overhead, etc., and you get about 450 bytes per flow. The > kernel normally dumps 4096 bytes at a time, and 4096/450 is 9, so I'd > guess about ten or so. Maybe a few more if there are no tunnels and > few actions. > > * How does that compare to REVALIDATE_MAX_BATCH? > > Based on that ballpark estimate, I guess REVALIDATE_MAX_BATCH is > bigger than necessary. 4096/50 would only allow 81 bytes per flow, > which isn't going to happen. Thanks for that summary. This provides useful context for a bunch of pieces I'd seen but not understood. > > * Is it worth counting these for future reference? > > Off-hand, I don't have a good idea for how to use this information. > Do you? > One thought is to look at how much of the flow_dump is actions in a typical case to look at the benefit of removing them. But I think that's a specific enough case, we could just look at it as part of the development.
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
