Add documentation for except support in ipBlock

[Dyanngg]

Documentation for #6658

[Dyanngg]

/skip-all

[antoninbas]

Did we want to include a note about the possible impact of having too many rules with too many excepts? I know this can lead to a rule explosion, but I am not sure it matters too much as there is no constraining cap on the number of flows with the same priority? I don't think there is a significant impact on datapath performance. More flows would increase memory usage.

[antoninbas]

ipBlock -> ipBlock

I don't think you applied Jiajun's suggestion BTW?

[Dyanngg]

I did, just forgot to paste it to the other place...

[Dyanngg]

Did we want to include a note about the possible impact of having too many rules with too many excepts? I know this can lead to a rule explosion, but I am not sure it matters too much as there is no constraining cap on the number of flows with the same priority? I don't think there is a significant impact on datapath performance. More flows would increase memory usage.

Added a short note, let me know if it is good from your perspective

[antoninbas]

LGTM

[antoninbas]

It's fine by me. @tnqn do you know if a high number of flows can also impact latency / throughput. I imagine that it is possible with a large number of diverse connections.

[tnqn]

According to my understanding on how the flow classfication runs, the cost is relative to the number of different mask lengths, instead of the number of flows. For example, in the worst case, there could be 31 mask lengths and OVS may have to calculate the masked IP 31 times to see if it matches flows in this table. Even a single policy rule can cause this if well-designed. On the other hand, if a large number of policy rules have the same mask length for their except ipBlocks, they shouldn't really cause much negative impacts. So the cost is kind of consistent regardless of the number of flows.

For the memory usage, I feel it may be not worth emphasizing its memory impact. An IPBlock with an except ipBlock can result in 31 IPNets in the worst case, but a podSelector can result in tens or hundreds of IPs either.
And the implementation of except in Antrea policy is not different from it in K8s policy.

[antoninbas]

An IPBlock with an except ipBlock can result in 31 IPNets in the worst case

technically, I can have multiple except cidrs and generate many more IPNets than that

but yes, I agree with the overall statement

[tnqn]

According to my understanding on how the flow classfication runs, the cost is relative to the number of different mask lengths, instead of the number of flows. For example, in the worst case, there could be 31 mask lengths and OVS may have to calculate the masked IP 31 times to see if it matches flows in this table. Even a single policy rule can cause this if well-designed. On the other hand, if a large number of policy rules have the same mask length for their except ipBlocks, they shouldn't really cause much negative impacts. So the cost is kind of consistent regardless of the number of flows.

For the memory usage, I feel it may be not worth emphasizing its memory impact. An IPBlock with an except ipBlock can result in 31 IPNets in the worst case, but a podSelector can result in tens or hundreds of IPs either.
And the implementation of except in Antrea policy is not different from it in K8s policy.

[Dyanngg]

/skip-all