vrouter: Extend the flow hold count per-cpu statistics to 128 cpus

[Anand H. Krishnan]

vRouter keeps a per-cpu flow hold count statistic. This statistic is exported to user space processes to aid in debugging. While this statistic is maintained for all the cpus, vRouter exports statistics only for the first 64 cpus. The main reason why we limit the export to only 64 cpus is that the messaging infrastructure within vRouter has a notion of how much to allocate for each message based on the structure name. This calculation is not dynamic since for most structures the calculation remains the same and till now we have not felt the need. For flow, we allocate only for 64 cpus.

While making this calculation dynamic is a larger effort, for now we will extend the memory allocated to accommodate 128 cpus (which is reasonable). Also, split the regular flow request and the flow table information requests so that we allocate only what we need.

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/10826
Submitter: Anand H. Krishnan (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/10827
Submitter: Anand H. Krishnan (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/10890
Submitter: Anand H. Krishnan (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/10891
Submitter: Anand H. Krishnan (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/10892
Submitter: Anand H. Krishnan (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/10826
Committed: http://github.org/Juniper/contrail-vrouter/commit/64c880e36a32e2c8c3cd9f116a0bf7cfa86dcbae
Submitter: Zuul
Branch: R2.20

commit 64c880e36a32e2c8c3cd9f116a0bf7cfa86dcbae
Author: Anand H. Krishnan <email address hidden>
Date: Tue May 26 15:08:24 2015 +0530

Extend the flow hold count per-cpu statistics to 128 cpus

vRouter keeps a per-cpu flow hold count statistic. This statistic is
exported to user space processes to aid in debugging. While this
statistic is maintained for all the cpus, vRouter exports statistics
only for the first 64 cpus. The main reason why we limit the export to
only 64 cpus is that the messaging infrastructure within vRouter has a
notion of how much to allocate for each message based on the structure
name. This calculation is not dynamic since for most structures the
calculation remains the same. For flow, we allocate only for 64 cpus.

While making this calculation dynamic is a larger effort, for now we
will extend the memory allocated to accommodate 128 cpus (which is
reasonable). Also, split the regular flow request and the flow table
information requests so that we allocate only what we need.

Part of this commit also fixes the problem where vRouter was setting
the sandesh list size to the size of the memory rather than the number
of elements in the list, which resulted in sandesh encode failures in
the case of a large cpu count.

Change-Id: I3be31c10c86f52457199e5015d85ac2c7d76f5cf
Closes-BUG: #1458795

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/10890
Committed: http://github.org/Juniper/contrail-vrouter/commit/b9c25b65036f2ca80dbbec45a7798ec6e03c17bf
Submitter: Zuul
Branch: master

commit b9c25b65036f2ca80dbbec45a7798ec6e03c17bf
Author: Anand H. Krishnan <email address hidden>
Date: Tue May 26 15:08:24 2015 +0530

Extend the flow hold count per-cpu statistics to 128 cpus

vRouter keeps a per-cpu flow hold count statistic. This statistic is
exported to user space processes to aid in debugging. While this
statistic is maintained for all the cpus, vRouter exports statistics
only for the first 64 cpus. The main reason why we limit the export to
only 64 cpus is that the messaging infrastructure within vRouter has a
notion of how much to allocate for each message based on the structure
name. This calculation is not dynamic since for most structures the
calculation remains the same. For flow, we allocate only for 64 cpus.

While making this calculation dynamic is a larger effort, for now we
will extend the memory allocated to accommodate 128 cpus (which is
reasonable). Also, split the regular flow request and the flow table
information requests so that we allocate only what we need.

Part of this commit also fixes the problem where vRouter was setting
the sandesh list size to the size of the memory rather than the number
of elements in the list, which resulted in sandesh encode failures in
the case of a large cpu count.

Change-Id: I3be31c10c86f52457199e5015d85ac2c7d76f5cf
Closes-BUG: #1458795

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/10892
Committed: http://github.org/Juniper/contrail-vrouter/commit/859cc82ec565c0d5099e5c818aa97cf933147470
Submitter: Zuul
Branch: R1.10

commit 859cc82ec565c0d5099e5c818aa97cf933147470
Author: Anand H. Krishnan <email address hidden>
Date: Tue May 26 15:08:24 2015 +0530

Extend the flow hold count per-cpu statistics to 128 cpus

vRouter keeps a per-cpu flow hold count statistic. This statistic is
exported to user space processes to aid in debugging. While this
statistic is maintained for all the cpus, vRouter exports statistics
only for the first 64 cpus. The main reason why we limit the export to
only 64 cpus is that the messaging infrastructure within vRouter has a
notion of how much to allocate for each message based on the structure
name. This calculation is not dynamic since for most structures the
calculation remains the same. For flow, we allocate only for 64 cpus.

While making this calculation dynamic is a larger effort, for now we
will extend the memory allocated to accommodate 128 cpus (which is
reasonable). Also, split the regular flow request and the flow table
information requests so that we allocate only what we need.

Part of this commit also fixes the problem where vRouter was setting
the sandesh list size to the size of the memory rather than the number
of elements in the list, which resulted in sandesh encode failures in
the case of a large cpu count.

Change-Id: I3be31c10c86f52457199e5015d85ac2c7d76f5cf
Closes-BUG: #1458795

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/10891
Committed: http://github.org/Juniper/contrail-vrouter/commit/d8581cb074d61efd4312c0e6947325009979c4cc
Submitter: Zuul
Branch: R2.1

commit d8581cb074d61efd4312c0e6947325009979c4cc
Author: Anand H. Krishnan <email address hidden>
Date: Tue May 26 15:08:24 2015 +0530

Extend the flow hold count per-cpu statistics to 128 cpus

vRouter keeps a per-cpu flow hold count statistic. This statistic is
exported to user space processes to aid in debugging. While this
statistic is maintained for all the cpus, vRouter exports statistics
only for the first 64 cpus. The main reason why we limit the export to
only 64 cpus is that the messaging infrastructure within vRouter has a
notion of how much to allocate for each message based on the structure
name. This calculation is not dynamic since for most structures the
calculation remains the same. For flow, we allocate only for 64 cpus.

While making this calculation dynamic is a larger effort, for now we
will extend the memory allocated to accommodate 128 cpus (which is
reasonable). Also, split the regular flow request and the flow table
information requests so that we allocate only what we need.

Part of this commit also fixes the problem where vRouter was setting
the sandesh list size to the size of the memory rather than the number
of elements in the list, which resulted in sandesh encode failures in
the case of a large cpu count.

Change-Id: I3be31c10c86f52457199e5015d85ac2c7d76f5cf
Closes-BUG: #1458795

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/10827
Committed: http://github.org/Juniper/contrail-vrouter/commit/7a5ad8a55558369335a50ea2696c523529b5ff1b
Submitter: Zuul
Branch: R2.0

commit 7a5ad8a55558369335a50ea2696c523529b5ff1b
Author: Anand H. Krishnan <email address hidden>
Date: Tue May 26 15:08:24 2015 +0530

Extend the flow hold count per-cpu statistics to 128 cpus

vRouter keeps a per-cpu flow hold count statistic. This statistic is
exported to user space processes to aid in debugging. While this
statistic is maintained for all the cpus, vRouter exports statistics
only for the first 64 cpus. The main reason why we limit the export to
only 64 cpus is that the messaging infrastructure within vRouter has a
notion of how much to allocate for each message based on the structure
name. This calculation is not dynamic since for most structures the
calculation remains the same. For flow, we allocate only for 64 cpus.

While making this calculation dynamic is a larger effort, for now we
will extend the memory allocated to accommodate 128 cpus (which is
reasonable). Also, split the regular flow request and the flow table
information requests so that we allocate only what we need.

Part of this commit also fixes the problem where vRouter was setting
the sandesh list size to the size of the memory rather than the number
of elements in the list, which resulted in sandesh encode failures in
the case of a large cpu count.

Change-Id: I3be31c10c86f52457199e5015d85ac2c7d76f5cf
Closes-BUG: #1458795