Re: [RFC,net-next, 2/5] vrf: track associations between VRF devices and tables

From: Stephen Hemminger
Date: Sat Jun 13 2020 - 15:29:14 EST


On Fri, 12 Jun 2020 18:49:34 +0200
Andrea Mayer <andrea.mayer@xxxxxxxxxxx> 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?