On Mon, Jun 08, 2015 at 11:23:50AM -0700, Jarno Rajahalme wrote:
>
> > On Jun 8, 2015, at 9:36 AM, Ben Pfaff <b...@nicira.com> wrote:
> >
> > +/* miniflow_builder */
> > +
> > +void
> > +miniflow_builder_init(struct miniflow_builder *b)
> > +{
> > + b->map = 0;
> > +}
> > +
> > +void
> > +miniflow_builder_to_miniflow(struct miniflow_builder *b,
> > + struct miniflow *miniflow)
> > +{
> > + miniflow->map = 0;
> > +
> > + int max = count_1bits(b->map);
> > + miniflow->values_inline = max <= MINI_N_INLINE;
> > + if (!miniflow->values_inline) {
> > + miniflow->offline_values = xmalloc(max
> > + * sizeof
> > *miniflow->offline_values);
>
> In the current implementation the callers always reserve enough buffer
> space so that manifold_extract always extracts to inline buffer.
Good point. That's easy to fix; I just didn't notice and didn't take
advantage of the full-sized provided buffer. I'll post a v2.
> The caller of miniflow_extract() would supply this from it’s
> stack. The flow is transformed to a miniflow in-place, so the miniflow
> data is always inline. The number of accessed cache lines is still
> more than in the current case, but strictly less than in your current
> proposal. And this avoids the malloc/free.
When I drop the malloc() and free, the "extra" cache lines that the
proposal accesses are on the stack, so they are probably in cache in any
case.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
