-
Notifications
You must be signed in to change notification settings - Fork 176
feat: Introduce pluggable intra-flow dispatch policy framework #1139
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
feat: Introduce pluggable intra-flow dispatch policy framework #1139
Conversation
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Hi @LukeAVanDrie. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
1a35b17
to
7c25ce0
Compare
/ok-to-test |
For other viewers: I notice a lot of overlap of files between this & #1138 Focusing on the |
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.
Small comment! I do think we should put a hold on this until the subset PR merges
} | ||
|
||
// fcfs (First-Come, First-Served) implements the `framework.IntraFlowDispatchPolicy` interface. | ||
type fcfs struct { |
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.
Do fcfs & listqueue have a high amount of functional overlap?
Motivation: Intraflow feature completeness is not a primary objective for initial implementation, so wondering if we can reuse code for now until we reach the point that there is functional drift
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.
ListQueue
abstracts the request storage.
FCFS
abstracts the the request ordering.
We could absorb ListQueue
into FCFS
(or vice versa) but that will establish patterns that will be messy to undo later when we want to add support for intra-flow dispatch policies. The current design adds minimal boilerplate but sets us up much better for future changes.
/hold As this PR is a superset of #1138 holding until that one merges |
7c25ce0
to
5740f8e
Compare
This commit introduces the `IntraFlowDispatchPolicy` framework, the second major component of the new pluggable flow control system. This framework decouples the logic for selecting a request from within a single flow's queue (temporal scheduling) from the underlying queue data structure. Key components include: - `framework.IntraFlowDispatchPolicy`: The core interface that defines the contract for selecting an item from a flow's queue. - `framework.FlowQueueAccessor`: A read-only interface that provides policies with safe access to queue state. - `RequiredQueueCapabilities`: A mechanism for policies to declare their queue requirements (e.g., FIFO, priority-ordered), which are validated by the registry. - A factory and registration system for discovering and instantiating policy plugins by name. - A comprehensive conformance test suite to validate the contract for all policy plugins. - A foundational `FCFS` (First-Come, First-Served) policy as the first reference implementation. This work builds directly on the `SafeQueue` framework, enabling the development of sophisticated, policy-driven request prioritization and scheduling.
5740f8e
to
a4b94d3
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kfswain, LukeAVanDrie The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This commit introduces the `IntraFlowDispatchPolicy` framework, the second major component of the new pluggable flow control system. This framework decouples the logic for selecting a request from within a single flow's queue (temporal scheduling) from the underlying queue data structure. Key components include: - `framework.IntraFlowDispatchPolicy`: The core interface that defines the contract for selecting an item from a flow's queue. - `framework.FlowQueueAccessor`: A read-only interface that provides policies with safe access to queue state. - `RequiredQueueCapabilities`: A mechanism for policies to declare their queue requirements (e.g., FIFO, priority-ordered), which are validated by the registry. - A factory and registration system for discovering and instantiating policy plugins by name. - A comprehensive conformance test suite to validate the contract for all policy plugins. - A foundational `FCFS` (First-Come, First-Served) policy as the first reference implementation. This work builds directly on the `SafeQueue` framework, enabling the development of sophisticated, policy-driven request prioritization and scheduling.
This PR is part of a stack.
Incremental diff against #1138: LukeAVanDrie/gateway-api-inference-extension@feat/flow-control-framework-plugins-queue...feat/flow-control-frameowrk-plugins-intra-flow-dispatch
This work tracks #674
This PR introduces the second major component of the new pluggable flow control system: the Intra-Flow Dispatch Policy framework.
While the previous PR introduced the
SafeQueue
framework for managing the storage of requests, this PR introduces theIntraFlowDispatchPolicy
framework for managing the logic of request selection. It is responsible for temporal scheduling: determining the order in which requests are selected for dispatch from within a single flow's queue.Key Contributions
IntraFlowDispatchPolicy
Interface: Defines a clear contract for implementing tactical dispatch logic (e.g., FCFS, SLO-aware).CapabilityFIFO
), and the framework will ensure they are paired with a compatibleSafeQueue
implementation.dispatch.MustRegisterPolicy
) allows new policies to be easily added and instantiated by name.FCFS
Reference Implementation: Includes a simple, robust "First-Come, First-Served" policy as the first concrete implementation and a reference for future plugins.Architectural Impact
This change establishes the first tier of our two-tier policy design:
By decoupling the dispatch logic from the data structure, we can now develop and experiment with sophisticated scheduling algorithms without modifying the core flow control engine.