On Tue, Jun 2, 2015 at 8:03 AM, Ben Pfaff <[email protected]> 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 <[email protected]> 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 <[email protected]> >> > > >> > > 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. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
