-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prioritize L7NP flows over TrafficControl #5768
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That looks fine to me, but that may not be sufficient for @tushartathgur's L7Visibility implementation. I think ideally we want a way to ensure that priority(L7NP) > priority(user-defined TC) > priority(L7Visibility)
. Some extra work may be needed to ensure the second >
relationship.
You are right, some extra work should be done to ensure the second |
b6f5eb9
to
25c4721
Compare
@antoninbas Done as you said. I have added an extra parameter to |
5986a79
to
13d9482
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fine by me again, but @tnqn and @tushartathgur should take a look
I'll defer to Quan for approval
pkg/agent/openflow/client.go
Outdated
const ( | ||
TrafficControlFlowPriorityHigh = "high" | ||
TrafficControlFlowPriorityMedium = "medium" | ||
TrafficControlFlowPriorityLow = "low" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you could define a dedicated type for this:
type TrafficControlFlowPriority string
const (
TrafficControlFlowPriorityHigh TrafficControlFlowPriority = "high"
TrafficControlFlowPriorityMedium TrafficControlFlowPriority = "medium"
TrafficControlFlowPriorityLow TrafficControlFlowPriority = "low"
)
func (p TrafficControlFlowPriority) toOFPriority() uint16 {
switch p {
case TrafficControlFlowPriorityHigh:
return priorityHigh
case TrafficControlFlowPriorityMedium:
return priorityNormal
case TrafficControlFlowPriorityLow:
return priorityLow
default:
return 0
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! Thanks
13d9482
to
41c5d4a
Compare
@tnqn @tushartathgur Could you help verify this? Thanks a lot. |
41c5d4a
to
4cf6423
Compare
pkg/agent/openflow/client.go
Outdated
TrafficControlFlowPriorityHigh types.TrafficControlFlowPriority = "high" | ||
TrafficControlFlowPriorityMedium types.TrafficControlFlowPriority = "medium" | ||
TrafficControlFlowPriorityLow types.TrafficControlFlowPriority = "low" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why aren't they defined in the same file as the type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid cycled-import in test code, I only moved the definition to another file. It's okay to move these definitions to the where TrafficControlFlowPriority
is defined.
e7eab89
to
1586f4a
Compare
pkg/agent/openflow/network_policy.go
Outdated
@@ -2239,7 +2239,7 @@ func (f *featureNetworkPolicy) l7NPTrafficControlFlows() []binding.Flow { | |||
Done(), | |||
// This generates the flow to forward the returned packets (with FromTCReturnRegMark) to stageOutput directly | |||
// after loading output port number to reg1 in L2ForwardingCalcTable. | |||
TrafficControlTable.ofTable.BuildFlow(priorityHigh). | |||
TrafficControlTable.ofTable.BuildFlow(priorityHigh+1). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's this change for? The flow has the same match and condition as the one in trafficControlCommonFlows
, changing priority shouldn't change anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a necessary change. As you mentioned, this is the same flow with the one in trafficControlCommonFlows
. When both L7NP and TrafficControl are enabled, the same flows will be added and it is a little weird, so I changed the priority. I think it is also okay to revert the change since we can handle duplicated flows when syncing flows to OVS.
pkg/agent/types/trafficcontrol.go
Outdated
TrafficControlFlowPriorityHigh TrafficControlFlowPriority = "high" | ||
TrafficControlFlowPriorityMedium TrafficControlFlowPriority = "medium" | ||
TrafficControlFlowPriorityLow TrafficControlFlowPriority = "low" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to comment which kind of flows should which priority.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
1586f4a
to
2943136
Compare
When applying an L7NP to a Pod, there's a potential issue where creating a TrafficControl CR with a redirect action to the same Pod could bypass the L7 engine. This is due to the fact that both the ct mark `L7NPRedirectCTMark` for identifying L7NP packets and the reg mark `TrafficControlRedirectRegMark` for identifying TrafficControl redirect packets can be set together. In `OutputTable`, the priorities of flows to match the ct mark and the reg mark are the same. Without an additional condition to distinguish between them, packets with both the reg mark and ct mark may be matched by either flow with an equal chance. To rectify this and ensure proper L7NP enforcement, it is crucial to assign a higher priority to the flow that matches the ct mark L7NPRedirectCTMark. This patch also adds an extra parameter `priority` to InstallTrafficControlMarkFlows, which is used to set the priority of the related flows. Signed-off-by: Hongliang Liu <lhongliang@vmware.com>
2943136
to
45c091a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/test-all |
/test-e2e |
1 similar comment
/test-e2e |
When applying an L7NP to a Pod, there's a potential issue where creating a TrafficControl CR with a redirect action to the same Pod could bypass the L7 engine. This is due to the fact that both the ct mark
L7NPRedirectCTMark
for identifying L7NP packets and the reg markTrafficControlRedirectRegMark
for identifying TrafficControl redirect packets can be set together. InOutputTable
, the priorities of flows to match the ct mark and the reg mark are the same. Without an additional condition to distinguish between them, packets with both the reg mark and ct mark may be matched by either flow with an equal chance. To rectify this and ensure proper L7NP enforcement, it is crucial to assign a higher priority to the flow that matches the ct mark L7NPRedirectCTMark.This patch also adds an extra parameter
priority
to InstallTrafficControlMarkFlows, which isused to set the priority of the related flows.