N7K F1 TCAM limitations ("ERROR: Hardware programming failed. Reason: Tcam will be over used, please enable bank chaining and/or turn off atomic update")

Question

Platform/versions:
# sh ver
  kickstart: version 6.2(2)
  system:    version 6.2(2)
# sh mod
Mod  Ports  Module-Type                         Model              Status
1    32     10 Gbps Ethernet Module             N7K-M132XP-12      ok
2    48     1000 Mbps Optical Ethernet Module   N7K-M148GS-11      ok
3    32     1/10 Gbps Ethernet Module           N7K-F132XP-15      ok
4    32     1/10 Gbps Ethernet Module           N7K-F132XP-15      ok
5    0      Supervisor Module-1X                N7K-SUP1           ha-standby
6    0      Supervisor Module-1X                N7K-SUP1           active *
I recently tried to add a couple of "ip dhcp relay address" statements to an SVI and received the following error message:
ERROR: Hardware programming failed. Reason: Tcam will be over used, please enable bank chaining and/or turn off atomic update
Studying this page I was able to determine, that I seemed to be hitting a 50% TCAM utilization limit on the F1 modules, which prevented atomic updates:
# show hardware access-list resource entries module 3
         ACL Hardware Resource Utilization (Module 3)
                          Instance  1, Ingress
TCAM: 530 valid entries   494 free entries
IPv6 TCAM: 8 valid entries   248 free entries
                          Used    Free    Percent
                                          Utilization
TCAM                      530     494     51.75 
I was able to workaround it be disabling atomic updates:
hardware access-list update default-result permit
no hardware access-list update atomic
I understand, that with this config I am theoretically allowing ACL traffic during updates which shouldn't be allowed (alternately I could drop it), but that's not really my primary concern here.
First of all I need to understand why adding DHCP relays are apparently affecting my TCAM entry resources?
Second, I need to understand if there are other implications of disabling atomic updates, such as during ISSU?
Third,  What are my options - if any - for planning the usage of the apparently relatively scarce resources on the F1 modules?

Answer 1

Could be CSCua13121:
Symptom:
Host of certain Vlan will not get IP address from DHCP.
Conditions:
M1/F1 Chassis with Fabric Path Vlan with atomic update enable.
On such system if configured SVI with DHCP is bounced that is if we shut down and bring it up may cause DHCP relay issue.
Workaround:
Disable Atomic update and bounce the Vlan. Disabling Atomic update may cause packet drops .
Except that ought to be fixed in 6.2(2).