While working on the non-const entries proposal, I realized that the technique of "leaving gaps" between numeric priority values of table entries, e.g. inserting entries with priority 100, 90, 80, ... instead of 10, 9, 8, ..., to make it easier to insert entries at arbitrary places later, is kind of annoying. It also doesn't work in general, since there is no gap large enough that guarantees future arbitrary insertions and deletions won't need to change those priorities eventually, to "make room in the priority space".
This led me to the realization that it seems like it would be fairly straightforward to introduce mechanisms between controller and network device where the controller says things like "for table foo, and entries with priority values in the range [X,Y], renumber all of their priorities to be in the range [M,N]". Note that if such a change request happened to satisfy the condition that the new priority values and the old priority values do not reorder the relative priority of any 2 entries in the table, then in many hardware implementations, the hardware state would not need to be changed at all. Only the in-memory state of the runtime priority values would need to be updated.
For example, suppose you inserted 10 entries with priorities 10 down to 1, inclusive.
Later the controller decided it wanted to add 100 entries after the current entry with priority 6, before the current entry with priority 5.
The controller sends a runtime request that says "renumber entries [6,10] as [200,204]". No hardware changes would be required on many target devices, only runtime state.
Then the controller can add new entries with priority values in the range [6,199], and know that they will be in the desired relative priority order with the previously existing entries that still remain in the device.
While working on the non-const entries proposal, I realized that the technique of "leaving gaps" between numeric priority values of table entries, e.g. inserting entries with priority 100, 90, 80, ... instead of 10, 9, 8, ..., to make it easier to insert entries at arbitrary places later, is kind of annoying. It also doesn't work in general, since there is no gap large enough that guarantees future arbitrary insertions and deletions won't need to change those priorities eventually, to "make room in the priority space".
This led me to the realization that it seems like it would be fairly straightforward to introduce mechanisms between controller and network device where the controller says things like "for table foo, and entries with priority values in the range [X,Y], renumber all of their priorities to be in the range [M,N]". Note that if such a change request happened to satisfy the condition that the new priority values and the old priority values do not reorder the relative priority of any 2 entries in the table, then in many hardware implementations, the hardware state would not need to be changed at all. Only the in-memory state of the runtime priority values would need to be updated.
For example, suppose you inserted 10 entries with priorities 10 down to 1, inclusive.
Later the controller decided it wanted to add 100 entries after the current entry with priority 6, before the current entry with priority 5.
The controller sends a runtime request that says "renumber entries [6,10] as [200,204]". No hardware changes would be required on many target devices, only runtime state.
Then the controller can add new entries with priority values in the range [6,199], and know that they will be in the desired relative priority order with the previously existing entries that still remain in the device.
Thoughts?