> One more thought: it's pretty easy to get rid of flow_wildcards later > if we don't want it; it's harder to reintroduce it.
Yep Yep, don't care that much either way, just wondered if you thought about it. You obviously have, so lets leave it for now. Ethan > > On Tue, Aug 07, 2012 at 01:45:04PM -0700, Ethan Jackson wrote: >> Sounds reasonable. >> >> Ethan >> >> On Tue, Aug 7, 2012 at 1:41 PM, Ben Pfaff <b...@nicira.com> wrote: >> > On Mon, Jul 30, 2012 at 06:10:22PM -0700, Ethan Jackson wrote: >> >> In flow_wildcards_init_catchall() and flow_wildcards_init_exact() why >> >> not just memset? Perhaps the appropriate time to make that change >> >> would have been when in_port was changed to a mask come to think of >> >> it. It's fine to leave it if you're going to resolve it in a future >> >> patch of the series. >> > >> > That (and other simplifications) happen in patch 21/28, so I guess >> > I'll leave them there. >> > >> >> The indentation isn't quite right in flow_wildcards_combine(). It was >> >> incorrect before this patch as well, but this may be a good time to >> >> clean it up. >> > >> > OK, fixed. >> > >> >> I suspect you're going to switch flow_wildcards_equal() to using >> >> memcmp() in a future patch? >> > >> > Yes. >> > >> >> Do we still need "struct flow_wildcards" at all? We could just use >> >> struct flow directly. Again, perhaps this will make more sense once >> >> I've seen the future patches. >> > >> > We don't need flow_wildcards. I kept it on the notion that it was >> > useful to readers of code to be able to distinguish a flow from a set >> > of wildcards for a flow, and useful from a type system perspective for >> > the same reason. I may be wrong; I don't know. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
