Messages in this thread |  | | Date | Sat, 13 Jun 2020 12:28:59 -0700 | From | Stephen Hemminger <> | Subject | Re: [RFC,net-next, 2/5] vrf: track associations between VRF devices and tables |
| |
On Fri, 12 Jun 2020 18:49:34 +0200 Andrea Mayer <andrea.mayer@uniroma2.it> wrote:
> + /* shared_tables: > + * count how many distinct tables does not comply with the > + * strict mode requirement. > + * shared_table value must be 0 in order to switch to strict mode. > + * > + * example of evolution of shared_table: > + * | time > + * add vrf0 --> table 100 shared_tables = 0 | t0 > + * add vrf1 --> table 101 shared_tables = 0 | t1 > + * add vrf2 --> table 100 shared_tables = 1 | t2 > + * add vrf3 --> table 100 shared_tables = 1 | t3 > + * add vrf4 --> table 101 shared_tables = 2 v t4 > + * > + * shared_tables is a "step function" (or "staircase function") > + * and is increased by one when the second vrf is associated to a table > + * > + * at t2, vrf0 and vrf2 are bound to table 100: shared_table = 1. > + * > + * at t3, another dev (vrf3) is bound to the same table 100 but the > + * shared_table counters is still 1. > + * This means that no matter how many new vrfs will register on the > + * table 100, the shared_table will not increase (considering only > + * table 100). > + * > + * at t4, vrf4 is bound to table 101, and shared_table = 2. > + * > + * Looking at the value of shared_tables we can immediately know if > + * the strict_mode can or cannot be enforced. Indeed, strict_mode > + * can be enforced iff shared_table = 0. > + * > + * Conversely, shared_table is decreased when a vrf is de-associated > + * from a table with exactly two associated vrfs. > + */ > + int shared_tables;
Should this be unsigned? Should it be a fixed size?
|  |