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
