On 3 Oct 2022, at 6:02, Peng He wrote:
> The userspace datapath mananges all the magaflows by a cmap. The cmap > data structrue will grow/shrink during the datapath processing and it > will re-position megaflows. This might result in two revalidator threads > might process a same megaflow during one dump stage. > > Consider a situation that, revalidator 1 processes a megaflow A, and > decides to delete it from the datapath, at the mean time, this megaflow > A is also queued in the process batch of revalidator 2. Normally it's ok > for revalidators to process the same megaflow multiple times, as the > dump_seq shows it's already dumped and the stats will not be contributed > twice. > > Assume that right after A is deleted, a PMD thread generates again > a new megaflow B which has the same match and action of A. The ukey > of megaflow B will replace the one of megaflow A. Now the ukey B is > new to the revalidator system and its dump seq is 0. > > Now since the dump seq of ukey B is 0, when processing megaflow A, > the revalidator 2 will not identify this megaflow A has already been > dumped by revalidator 1 and will contribute the old megaflow A's stats > again, this results in an inconsistent stats between ukeys and megaflows. > > To fix this, the newly generated the ukey B should take the dump_seq > of the replaced ukey A to avoid a same megaflow being revalidated > twice in one dump stage. > > We observe in the production environment, the OpenFlow rules' stats > sometimes are amplified compared to the actual value. > > Signed-off-by: Peng He <[email protected]> > --- Change looks good to me, run basic tests, and did not try to replicate this exact issue (seems to be too hard, as it’s timing based). Acked-by: Eelco Chaudron <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
