I dropped this patch for the moment, it'll be easier to take a fresh look once the bulk of the changes are in.
On 30 September 2014 16:21, Joe Stringer <joestrin...@nicira.com> wrote: > On 30 September 2014 10:27, Ben Pfaff <b...@nicira.com> wrote: > >> On Fri, Sep 26, 2014 at 09:28:18PM +1200, Joe Stringer wrote: >> > Previously we stored the netlink-formatted version of a flow key and >> > mask in 'struct udpif_key'. This patch stores the original key,mask >> > in the 'struct match' format, which reduces the size of a ukey from 1216 >> > bytes to 560. Furthermore, this reduces netlink conversions required and >> > simplifies mask comparison in revalidate_ukey(). >> > >> > Signed-off-by: Joe Stringer <joestrin...@nicira.com> >> > --- >> > For reference, prior to this patchset the size of a udpif_key is 656, >> but the >> > actions are not cached on master. This patch allows the entire patchset >> to have >> > a negligible impact on the memory footprint while boosting performance. >> Some >> > cases may even see an improvement in memory usage. >> > >> > v6: First post. >> >> I understand that we can make this change if the datapath supports >> UIDs, but in the case where it doesn't I don't see how we can do that, >> because we have to be able to reproduce the exact key that the >> datapath originally gave us. Quickly skimming the patch, I don't see >> that the logic is conditional on UIDs. Is it? >> > > I think I see what you're getting at. During upcall or a flow_delete > during dump, we have access to the original flow key so the dpif ops can > re-use that copy[although we don't for flow_del at the moment], however > corner cases like the flow_del in revalidator_sweep__() do not have access > to the original flow key, so is not guaranteed to be able to delete a flow > successfully. Darn. > > I could rework this patch to store the mask in the 'struct flow' format, > then use a union for the 'struct flow' (used when UID support is available) > and an nlattr buf like the current one (for when UID is not available). It > won't be down to smaller than master, but should at least be more compact > than currently. And we should be able to get away with doing this in a > reasonably clean manner. > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
