[ovs-dev] Customized match options => miniflow_extract()

Raul Suarez Marin raul.suarez.marin at gmail.com
Mon Mar 16 10:25:30 UTC 2015


Hello Ben,

Thank you for your time and effort. Last week I went through a lot of
debugging and I understood how it works. miniflow looks like "the same
structure" as flow, but embedded in an array of uint32_t and followed by a
map that allows you to know which fields are set. Debugging miniflow
allowed me to realize why the match was not going well, so "I am happy"
that I did not understand it and had to go through debugging.

Kind regards,
Raúl



2015-03-14 20:58 GMT+01:00 Ben Pfaff <blp at nicira.com>:

> On Thu, Mar 05, 2015 at 11:59:40PM +0100, Raul Suarez Marin wrote:
> > I need new match options for my openvswitch. I have already sorted out
> the
> > flow_mod message handling and everything. Now, I need to find where the
> > match is performed, but I cannot find it. Through debugging, I found that
> > the matching is performed (or part of it) at miniflow_extract() at
> > lib\flow.c
> >
> > However, as described in flow.h
> >
> > /*
> >  * The fields are organized in four segments to facilitate staged lookup,
> > where
> >  * lower layer fields are first used to determine if the later fields
> need
> > to
> >  * be looked at.  This enables better wildcarding for datapath flows.
> >  *
> >  * NOTE: Order of the fields is significant, any change in the order
> must be
> >  * reflected in miniflow_extract()!
> >  */
> > struct flow {
> > blablabla
> > }
> >
> > What I did, is to take advantage of a padding field in flow structure,
> and
> > use it. This is now what miniflow_extract() assumes to be true (tcp_flags
> > and new field are 16-bit size).
> >
> > BUILD_ASSERT_DECL(offsetof(struct flow, tcp_flags) + 2
> >                   == offsetof(struct flow, new_field) &&
> >                   offsetof(struct flow, tcp_flags) / 4
> >                   == offsetof(struct flow, new_field) / 4);
> >
> > Then, in miniflow_extract(), I use the miniflow_push_be16(mf,
> > new_field, new_field); sentence (I do not know if this is correct).
> >
> > Here is my question: where I have to take into account the order of the
> > fields, as stated in flow.h comment before definition of "struct flow"?
> Am
> > I missing/misunderstanding something?
>
> Fields have to be added to a miniflow in order of their definition in
> struct flow.
>
> > I also do not understand how "miniflow structure" works, I know it is an
> > optimization of flow structure, but I do not know how it is formed or how
> > to read one.
>
> I kind of despair when people give this kind of feedback, because we
> went to a lot of trouble to explain in the code how a miniflow works.
> If you don't understand the comment, which I reproduce below, then
> please ask specific questions, because that's actionable feedback,
> instead of just saying "I don't understand", because there's no way we
> can know what to say when we've already worked so hard to explain.
>
> /* A sparse representation of a "struct flow".
>  *
>  * A "struct flow" is fairly large and tends to be mostly zeros.  Sparse
>  * representation has two advantages.  First, it saves memory.  Second, it
>  * saves time when the goal is to iterate over only the nonzero parts of
> the
>  * struct.
>  *
>  * The 'map' member holds one bit for each uint64_t in a "struct flow".
> Each
>  * 0-bit indicates that the corresponding uint64_t is zero, each 1-bit
> that it
>  * *may* be nonzero (see below how this applies to minimasks).
>  *
>  * The 'values_inline' boolean member indicates that the values are at
>  * 'inline_values'.  If 'values_inline' is zero, then the values are
>  * offline at 'offline_values'.  In either case, values is an array that
> has
>  * one element for each 1-bit in 'map'.  The least-numbered 1-bit is in
>  * the first element of the values array, the next 1-bit is in the next
> array
>  * element, and so on.
>  *
>  * MINI_N_INLINE is the default number of inline words.  When a miniflow is
>  * dynamically allocated the actual amount of inline storage may be
> different.
>  * In that case 'inline_values' contains storage at least for the number
>  * of words indicated by 'map' (one uint64_t for each 1-bit in the map).
>  *
>  * Elements in values array are allowed to be zero.  This is useful for
> "struct
>  * minimatch", for which ensuring that the miniflow and minimask members
> have
>  * same 'map' allows optimization.  This allowance applies only to a
> miniflow
>  * that is not a mask.  That is, a minimask may NOT have zero elements in
>  * its 'values'.
>  */
>



More information about the dev mailing list