On Wed, Mar 23, 2016 at 07:40:08AM -0600, Ryan Moats wrote: > Ben Pfaff <b...@ovn.org> wrote on 03/22/2016 04:54:16 PM: > > There's a number of instances of code similar to this, but I really > > haven't got a clue what it really does or where the number 4 comes from: > > > + // this offset is to protect the hard coded rules in > physical.c > > > + ins_seqno += 4; > > > As to the += 4 offset, this comes from the fact that when _TRACKED returns > a deleted row, you can't trust what is in the returned row as the memory > has already been freed). Therefore, all you have is the seqnos to go by. > Fortunately, the insert seqno is unique and constant, so we can use this > as a key for looking up the flow(s) that need to be removed - this is the > reason for all of the extra "seqno" hashmaps and related lookups. However, > there are four OF flows added in physical.c that aren't driven by any ovnsb > rows (I refer to them as "hard-coded"). To avoid collisions, I assigned > these flows to insert seqno's 1, 2, 3, and 4 and then offset each row's > insert seqno received for a row by 4 to avoid collisions.
This sort of magic really needs in-code documentation. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
