Comment 3 for bug 1677419

As we increase vr_flow_entries support with a higher value the problem becomes that we are not able to fit the Mirroring metadata table in without re-writing the mechanism of accessing the entries and controlling to a maximum TBD value of entries. Presently Mirroring metadata is referenced via the flow id so tables are 1 for 1.

Option 1:
Settings:

    Set flow stats entries on NFP to 4096K + 800K (4896K) total.
    Leave Mirroring metatdata at 615K entries.
    Leave flow stats update rate same frequency.

Limitations:

    Mirroring would only be functional with vr_flow_entries set > 512K.
    Flow timeout for 4096K vr_flow_entries would increase to 8 seconds minimum vs 1 second.
    Possible collision issues with our internal flow hash when number of entries > 1024K

Option 2:
Settings:

    Set flow stats entries on NFP to 1024K + 200K (1224K) total.
    Set Mirroring metatdata at 1224K entries.
    Leave flow stats update rate same frequency.
    Lower NFP internal flow hash table size from 4M to 3M.

Limitations:

    If vr_flow_entries > 1024K would result in premature flow timeouts.
    Mirroring would only be functional with vr_flow_entries set > 1024K.
    Flow timeout for 1024K vr_flow_entries would increase to 4 seconds minimum vs 1 second.
    Possibility of more NFP flow hash collisions cause by decreasing from 4M to 3M. We had sized to 4M to match a 1024K vr_flow_entry setting on host.

Option 3:

    Set flow stats entries on NFP to 4096K + 800K (4896K) total.
    Redo the Mirroring metatdata access and put a TBD maximum number supported.

Limitations:

    Mirroring entries supported would be TBD value and not tied to flow entries.
    Possible collision issues with our internal flow hash when number of entries > 1024K

NOTE: the Mirroring portion of this is only for "flow" mirroring. Port mirroring does not have an issue because it does not use the Mirroring metadata.