[ovs-dev] [PATCH v2] ofp-util: Convert flow_metadata to match structure.

Jesse Gross jesse at nicira.com
Tue Jun 2 15:25:14 UTC 2015


On Tue, Jun 2, 2015 at 8:03 AM, Ben Pfaff <blp at nicira.com> wrote:
> On Tue, Jun 02, 2015 at 07:58:48AM -0700, Ben Pfaff wrote:
>> On Mon, Jun 01, 2015 at 03:35:23PM -0700, Jesse Gross wrote:
>> > On Mon, Jun 1, 2015 at 2:55 PM, Ben Pfaff <blp at nicira.com> wrote:
>> > > On Mon, Jun 01, 2015 at 01:49:30PM -0700, Jesse Gross wrote:
>> > >> We have a special flow_metadata structure to represent the parts
>> > >> of a packet that aren't carried in the payload itself. This is
>> > >> used in the case where we need to send the packet as a Packet In
>> > >> to an OpenFlow controller. This is a subset of the more general
>> > >> struct flow.
>> > >>
>> > >> In practice, almost all operations we do on this structure involve
>> > >> converting it to or from a match or have code that is the same as
>> > >> a match. Serialization to NXM and back is done as a match. There
>> > >> is special flow_metadata formatting code that is almost identical
>> > >> to match formatting.
>> > >>
>> > >> The uses for struct flow_metadata aren't performance critical
>> > >> when it comes to memory, so we can save quite a bit of code by
>> > >> just using a match structure directly instead. In addition, as
>> > >> metadata increases and becomes more complex (Geneve options require
>> > >> some special handling beyond just additional fields), using the
>> > >> match structure means we only have to do this work in one place.
>> > >>
>> > >> Signed-off-by: Jesse Gross <jesse at nicira.com>
>> > >
>> > > Most of this rationale makes sense to me, except that I'm surprised
>> > > that struct flow_metadata (which doesn't have masks) gets converted to
>> > > struct match (which does).  Maybe I should just dig into the code, but
>> > > is there some big reason why this is the case?
>> >
>> > The main reason is just that struct match is the more general superset
>> > and the encode/decoding/formatting code operates on that to be able to
>> > handle everything so it's cleaner to just use a match even if it is
>> > slightly less memory efficient.
>>
>> It just seems conceptually wrong to me to have masks around in cases
>> where there's no concept of one, where the masks just take up space and
>> get ignored.  I'm trying to figure out how much that bothers me.
>
> So, I guess, the summary of my thoughts about this right now is that for
> me it's a no-brainer to switch from a specialized structure to struct
> flow, but struct match is a little harder for me conceptually.

I guess I should have been more clear: we actually are using the
wildcards to indicate which fields are significant. Effectively the
purpose of the conversion code between struct flow_metadata and struct
match is to synthesize these wildcards. There would be little benefit
to switching to struct flow instead because we would still need to do
the same operation.



More information about the dev mailing list