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 <b...@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'.
> */
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
