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
