On Fri, Nov 16, 2012 at 10:46:57AM -0800, Justin Pettit wrote: > > On Nov 16, 2012, at 10:18 AM, Ben Pfaff <b...@nicira.com> wrote: > > > On Fri, Nov 16, 2012 at 12:03:05AM -0800, Justin Pettit wrote: > >> Commit acf608 (ofproto-dpif: Use a single underlying datapath across > >> multiple bridges.) causes datapath flows from deleted ports to not be > >> removed. The issue is that the code that bulk deletes old flows doesn't > >> know the datapath port number that makes up the datapath flow > >> definition. This commit keeps track of the datapath port in the facet > >> for use when the datapath flow eventually needs to be removed. > >> > >> Signed-off-by: Justin Pettit <jpet...@nicira.com> > > > > This seems OK, but I wonder whether odp_in_port is more naturally a > > member of struct subfacet, since that is tied more closely to kernel > > flows than struct facet? (I almost claimed that we could recover the > > ODP in_port from the subfacet's ->key nlattrs without adding a new > > member, but we discard that information in the common case.) > > I thought about putting it with the subfacet, but I figured it would > always be the same in both, but there are potentially more subfacets > than facets, so it seems like it used less memory. Are there cases > where the in_port would look different from subfacet to subfacet in > the same facet?
I doubt there's a case where subfacets within a facet could have different in_ports. VLAN splinters are the only case where something odd is going on with ports, but that wouldn't change the in_port within a single facet. I don't think memory issues are a real consideration here. The common case is exactly one subfacet per facet. So I would do whichever you think makes more logical sense. I think the subfacet is logically a better location, but I can live with the facet too. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
