node: topologymgr: Address SIG node reviewers' review comments

Signed-off-by: Swati Sehgal <[email protected]>

Author: swatisehgal

keps/sig-node/693-topology-manager/README.md

@@ -683,7 +683,6 @@ Device Manager and Device plugin node e2e tests:
 - N installs
 - More rigorous forms of testing.
 - Allowing time for user feedback.
-- Add support for device-specific topology constraints beyond NUMA.
 - Support hugepages alignment.
 
 #### Deprecation
@@ -862,11 +861,18 @@ No.
 
 ###### Will enabling / using this feature result in increasing time taken by any operations covered by existing SLIs/SLOs?
 
-No.
+Yes
+
+This feature would impact the pod startup latency as it is measured from the time pod object is created and the resource alignment logic is executed
+at pod admission time. The check at admission is to determine if the pod is suitable to be admitted on the node based on the configured policy.
+If considered suitable, the pod is deemed suitable to be admitted on a node followed by the pod startup where resources are allocated to it based
+on the NUMA node identified suitable to allocate resource.
+Since Topology Manager supports a maximum of 8 NUMA nodes, pod startup latency has an upper bound for the additional latency introduced by the
+Topology Manager admission check.
 
 This feature is not impacted by the scale of the cluster (number of nodes in the cluster) as that is not relevant and is not factored into the alignment algorithm. It is the scheduler that has to deal with the scalability aspect and determine nodes that can fulfill the resources requested by the pod. If this feature is turned off, the scheduler would still have to perform the same computation as it would if this feature was enabled. Hence, this feature is not impacted by scale or impacts the scalability of a cluster.
 
-Also, the resource alignment logic is executed at pod admission time which is prior to pod startup so there shouldn't be any impact on pod startup latency. The check at admission is to determine if the pod is suitable to be admitted on the node based on the configured policy. If considered suitable, the pod proceeds to startup (following which the pod startup latency is measured).
+
 
 ###### Will enabling / using this feature result in non-negligible increase of resource usage (CPU, RAM, disk, IO, ...) in any components?