[ovs-dev] [PATCH] dpif: Refactor flow dumping interface to make better sense for batching.

Joe Stringer joestringer at nicira.com
Tue May 20 22:03:43 UTC 2014


On 21 May 2014 06:40, Ben Pfaff <blp at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140521/4650c641/attachment-0005.html>


More information about the dev mailing list