* RE: [PATCH v2] net/mlx5: promote private API to stable
From: Bing Zhao @ 2026-06-02 6:07 UTC (permalink / raw)
To: Dariusz Sosnowski, Slava Ovsiienko, Ori Kam, Suanming Mou,
Matan Azrad
Cc: dev@dpdk.org
In-Reply-To: <20260529073255.689808-1-dsosnowski@nvidia.com>
Hi,
Thanks
> -----Original Message-----
> From: Dariusz Sosnowski <dsosnowski@nvidia.com>
> Sent: Friday, May 29, 2026 3:33 PM
> To: Slava Ovsiienko <viacheslavo@nvidia.com>; Bing Zhao
> <bingz@nvidia.com>; Ori Kam <orika@nvidia.com>; Suanming Mou
> <suanmingm@nvidia.com>; Matan Azrad <matan@nvidia.com>
> Cc: dev@dpdk.org
> Subject: [PATCH v2] net/mlx5: promote private API to stable
>
> Following experimental functions are exposed by mlx5 PMD since 25.11
> release:
>
> - rte_pmd_mlx5_driver_event_cb_register
> - rte_pmd_mlx5_driver_event_cb_unregister
> - rte_pmd_mlx5_enable_steering
> - rte_pmd_mlx5_disable_steering
>
> First two are used to register callbacks for driver events (when Rx/Tx
> queues are created or destroyed).
> Other two are used to enable/disable flow steering in mlx5 PMD.
> No changes were made and no changes are planned to these symbols.
>
> These are currently used by NVIDIA DOCA SDK since version 3.3, which
> started depending on upstream DPDK releases [1].
> Purpose of their use is to:
>
> - expose HW identifiers of Rx/Tx mlx5 queues managed by DPDK and
> - allow flow steering to happen outside of DPDK.
>
> Also, some of these symbols will be used by netdev-doca backend in Open
> vSwitch [2].
> Whenever a DOCA netdev would be added/removed in Open vSwitch, it will
> have to disable/enable steering for mlx5 driver.
> Stabilizing these symbols is required by current OVS policy to remove the
> need for ALLOW_EXPERIMENTAL_API [3].
>
> This patch promotes aforementioned symbols to stable.
>
> [1]: https://docs.nvidia.com/doca/sdk/customer-affecting-
> changes/index.html
> [2]:
> https://patchwork.ozlabs.org/project/openvswitch/list/?series=504726&state
> =%2A&archive=both
> [3]: https://mail.openvswitch.org/pipermail/ovs-dev/2026-May/432066.html
>
> Signed-off-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
> ---
> v2:
> - Updated 26.07 release notes.
>
> doc/guides/rel_notes/release_26_07.rst | 9 +++++++++
> drivers/net/mlx5/mlx5_driver_event.c | 4 ++--
> drivers/net/mlx5/mlx5_flow.c | 4 ++--
> drivers/net/mlx5/rte_pmd_mlx5.h | 4 ----
> 4 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_26_07.rst
> b/doc/guides/rel_notes/release_26_07.rst
> index 6eba91a5e9..2af24d40a0 100644
> --- a/doc/guides/rel_notes/release_26_07.rst
> +++ b/doc/guides/rel_notes/release_26_07.rst
> @@ -127,6 +127,15 @@ API Changes
> - ``rte_flow_dynf_metadata_get``
> - ``rte_flow_dynf_metadata_set``
>
> +* **mlx5: promoted driver event and steering management APIs from
> +experimental to stable.**
> +
> + The following mlx5 APIs are no longer marked experimental:
> +
> + - ``rte_pmd_mlx5_driver_event_cb_register``
> + - ``rte_pmd_mlx5_driver_event_cb_unregister``
> + - ``rte_pmd_mlx5_enable_steering``
> + - ``rte_pmd_mlx5_disable_steering``
> +
>
> ABI Changes
> -----------
> diff --git a/drivers/net/mlx5/mlx5_driver_event.c
> b/drivers/net/mlx5/mlx5_driver_event.c
> index 1dc8029ee5..89e49331c8 100644
> --- a/drivers/net/mlx5/mlx5_driver_event.c
> +++ b/drivers/net/mlx5/mlx5_driver_event.c
> @@ -236,7 +236,7 @@
> notify_existing_devices(rte_pmd_mlx5_driver_event_callback_t cb, void
> *opaque)
> notify_existing_queues(port_id, cb, opaque); }
>
> -RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_pmd_mlx5_driver_event_cb_register,
> 25.11)
> +RTE_EXPORT_SYMBOL(rte_pmd_mlx5_driver_event_cb_register)
> int
>
> rte_pmd_mlx5_driver_event_cb_register(rte_pmd_mlx5_driver_event_callback_t
> cb, void *opaque) { @@ -264,7 +264,7 @@
> rte_pmd_mlx5_driver_event_cb_register(rte_pmd_mlx5_driver_event_callback_t
> cb, v
> return 0;
> }
>
> -RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_pmd_mlx5_driver_event_cb_unregister,
> 25.11)
> +RTE_EXPORT_SYMBOL(rte_pmd_mlx5_driver_event_cb_unregister)
> int
>
> rte_pmd_mlx5_driver_event_cb_unregister(rte_pmd_mlx5_driver_event_callback
> _t cb) { diff --git a/drivers/net/mlx5/mlx5_flow.c
> b/drivers/net/mlx5/mlx5_flow.c index 915ea29a5a..a95dd9dc94 100644
> --- a/drivers/net/mlx5/mlx5_flow.c
> +++ b/drivers/net/mlx5/mlx5_flow.c
> @@ -12506,7 +12506,7 @@ flow_disable_steering_run_on_related(struct
> rte_eth_dev *dev,
> }
> }
>
> -RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_pmd_mlx5_disable_steering, 25.11)
> +RTE_EXPORT_SYMBOL(rte_pmd_mlx5_disable_steering)
> void
> rte_pmd_mlx5_disable_steering(void)
> {
> @@ -12532,7 +12532,7 @@ rte_pmd_mlx5_disable_steering(void)
> mlx5_steering_disabled = true;
> }
>
> -RTE_EXPORT_EXPERIMENTAL_SYMBOL(rte_pmd_mlx5_enable_steering, 25.11)
> +RTE_EXPORT_SYMBOL(rte_pmd_mlx5_enable_steering)
> int
> rte_pmd_mlx5_enable_steering(void)
> {
> diff --git a/drivers/net/mlx5/rte_pmd_mlx5.h
> b/drivers/net/mlx5/rte_pmd_mlx5.h index 55a26cb067..f482875434 100644
> --- a/drivers/net/mlx5/rte_pmd_mlx5.h
> +++ b/drivers/net/mlx5/rte_pmd_mlx5.h
> @@ -620,7 +620,6 @@ int rte_pmd_mlx5_external_sq_disable(uint16_t port_id,
> uint32_t sq_num);
> * - (-EEXIST) if @p cb was already registered.
> * - (-ENOMEM) if failed to allocate memory for callback entry.
> */
> -__rte_experimental
> int
>
> rte_pmd_mlx5_driver_event_cb_register(rte_pmd_mlx5_driver_event_callback_t
> cb, void *opaque);
>
> @@ -641,7 +640,6 @@
> rte_pmd_mlx5_driver_event_cb_register(rte_pmd_mlx5_driver_event_callback_t
> cb, v
> * - 0 if callback was successfully unregistered or if no such callback
> was registered.
> * - (-EINVAL) if @p cb is NULL.
> */
> -__rte_experimental
> int
>
> rte_pmd_mlx5_driver_event_cb_unregister(rte_pmd_mlx5_driver_event_callback
> _t cb);
>
> @@ -679,7 +677,6 @@
> rte_pmd_mlx5_driver_event_cb_unregister(rte_pmd_mlx5_driver_event_callback
> _t cb)
> * with other functions from ethdev API used to configure any of the mlx5
> ports.
> * It is the responsibility of the application to enforce this.
> */
> -__rte_experimental
> void
> rte_pmd_mlx5_disable_steering(void);
>
> @@ -697,7 +694,6 @@ rte_pmd_mlx5_disable_steering(void);
> * - 0 - Flow steering was successfully enabled or it flow steering was
> never disabled.
> * - (-EBUSY) - There are mlx5 ports probed and re-enabling steering
> cannot be done safely.
> */
> -__rte_experimental
> int
> rte_pmd_mlx5_enable_steering(void);
>
> --
> 2.47.3
Acked-by: Bing Zhao <bingz@nvidia.com>
^ permalink raw reply
* [PATCH v2] devtools: add Vertex AI to review scripts
From: David Marchand @ 2026-06-02 6:44 UTC (permalink / raw)
To: dev; +Cc: thomas, Stephen Hemminger, Aaron Conole
In-Reply-To: <20260601132402.1125588-1-david.marchand@redhat.com>
Add support for Google Vertex AI authentication as an alternative to
direct API key authentication. All four providers (Anthropic, Google,
OpenAI, xAI) can now use Vertex AI with Application Default Credentials.
This requires a python dependency google-auth but it is left as
optional.
Key features:
- Auto-detection of authentication method based on environment
- Manual override via --auth flag (auto, direct, vertex)
- Automatic model name translation for Vertex format
- Support for both global and regional Vertex endpoints
- Proper error handling for Vertex API responses
Provider-specific implementations:
- Anthropic: Uses /publishers/anthropic/models/{model}:rawPredict
with model name format claude-sonnet-4-5@20250929
- Google: Uses /publishers/google/models/{model}:generateContent
- OpenAI/xAI: Use /endpoints/openapi/chat/completions
with publisher prefix (e.g., openai/gpt-oss-120b-maas)
Authentication detection logic:
- Vertex: Requires google-auth library and ADC configured
- Direct: Falls back to API key from environment variables
Available models on Vertex AI:
- Anthropic: All Claude models
- Google: All Gemini models
- OpenAI: gpt-oss-120b-maas, gpt-oss-20b-maas (open-weight only)
- xAI: grok-4.20-*, grok-4.1-fast-* variants
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Note: I only tested Vertex.
I have no API key to double check the "direct" method is still working.
Changes since v1:
- factorized auth string generation,
- enhanced -l option (offlist comment from Maxime),
- fixed some pylint warnings introduced by changes,
---
devtools/ai/_common.py | 204 +++++++++++++++++++++++++++++++++---
devtools/ai/review-doc.py | 26 ++---
devtools/ai/review-patch.py | 30 +++---
3 files changed, 215 insertions(+), 45 deletions(-)
diff --git a/devtools/ai/_common.py b/devtools/ai/_common.py
index 69982cbda5..3e70f4cd6f 100644
--- a/devtools/ai/_common.py
+++ b/devtools/ai/_common.py
@@ -6,6 +6,7 @@
import argparse
import json
+import os
import subprocess
import sys
from dataclasses import dataclass
@@ -13,6 +14,14 @@
from urllib.error import HTTPError, URLError
from urllib.request import Request, urlopen
+# Optional dependency for Vertex AI
+try:
+ from google.auth import default as google_auth_default
+ from google.auth.transport.requests import Request as GoogleAuthRequest
+ VERTEX_AI_AVAILABLE = True
+except ImportError:
+ VERTEX_AI_AVAILABLE = False
+
# Provider configurations (model defaults; override with --model).
PROVIDERS: dict[str, dict[str, str]] = {
"anthropic": {
@@ -65,10 +74,14 @@ def get_git_config(key: str) -> str | None:
def list_providers() -> NoReturn:
"""Print available providers and exit."""
print("Available AI Providers:\n")
- print(f"{'Provider':<12} {'Default Model':<30} {'API Key Variable'}")
- print(f"{'--------':<12} {'-------------':<30} {'----------------'}")
+ print(f"{'Provider':<12} {'Default Model':<30} {'API Key (Direct Auth)'}")
+ print(f"{'--------':<12} {'-------------':<30} {'---------------------'}")
for name, config in PROVIDERS.items():
print(f"{name:<12} {config['default_model']:<30} {config['env_var']}")
+ if VERTEX_AI_AVAILABLE:
+ print("\nVertex AI authentication is available (use --auth vertex)")
+ else:
+ print("\nVertex AI authentication requires: pip install google-auth")
sys.exit(0)
@@ -128,25 +141,167 @@ def print_token_summary(
print(format_token_summary(usage, provider, model), file=sys.stderr)
+def get_vertex_credentials() -> tuple[str, str]:
+ """Get Google Cloud access token and project for Vertex AI.
+
+ Uses Application Default Credentials (ADC).
+ Requires: gcloud auth application-default login
+
+ Returns: (access_token, project_id)
+ """
+ credentials, project = google_auth_default()
+
+ # Refresh credentials to get access token
+ auth_request = GoogleAuthRequest()
+ credentials.refresh(auth_request)
+
+ if not project:
+ error("Could not detect GCP project. Set GOOGLE_CLOUD_PROJECT environment variable or run: gcloud config set project PROJECT_ID")
+
+ return credentials.token, project
+
+
+def model_to_vertex(model: str, provider: str) -> str:
+ """Convert model name to Vertex AI format.
+
+ Anthropic models use @ for version dates:
+ - API format: claude-sonnet-4-5-20250929
+ - Vertex format: claude-sonnet-4-5@20250929
+
+ OpenAI/xAI models need publisher prefix:
+ - Vertex requires: openai/gpt-oss-120b-maas
+
+ Other providers use the same format for both.
+ """
+ if provider == "anthropic":
+ # Match pattern: ends with -YYYYMMDD (8 digits)
+ if model.count('-') >= 3:
+ parts = model.rsplit('-', 1)
+ if len(parts) == 2 and len(parts[1]) == 8 and parts[1].isdigit():
+ return f"{parts[0]}@{parts[1]}"
+ elif provider in ("openai", "xai"):
+ # Add publisher prefix if not already present
+ if "/" not in model:
+ return f"{provider}/{model}"
+ return model
+
+
+def detect_auth_method(provider: str) -> str:
+ """Detect authentication method for a provider.
+
+ Args:
+ provider: The provider name (e.g., "anthropic", "openai")
+
+ Returns:
+ "direct" or "vertex"
+ """
+ env_var = PROVIDERS[provider]["env_var"]
+ if os.environ.get(env_var):
+ return "direct"
+ if VERTEX_AI_AVAILABLE:
+ try:
+ credentials, project = google_auth_default()
+ if credentials and project:
+ return "vertex"
+ except Exception:
+ pass
+ return "direct"
+
+
+def get_auth_string(auth_choice: str, provider: str) -> str:
+ """Get authentication string for API requests.
+
+ Args:
+ auth_choice: User's auth choice ("auto", "direct", or "vertex")
+ provider: Provider name
+
+ Returns:
+ Authentication string - either "vertex" or "direct:<api_key>"
+ """
+ config = PROVIDERS[provider]
+
+ # Determine actual auth method
+ if auth_choice == "auto":
+ auth_method = detect_auth_method(provider)
+ else:
+ auth_method = auth_choice
+
+ # Build auth string based on method
+ if auth_method == "vertex":
+ if not VERTEX_AI_AVAILABLE:
+ error("Vertex AI support requires 'google-auth' library. Install with: pip install google-auth")
+ return "vertex"
+
+ api_key = os.environ.get(config["env_var"])
+ if not api_key:
+ error(f"{config['env_var']} environment variable not set")
+ return f"direct:{api_key}"
+
+
def _build_request_meta(
- provider: str, api_key: str, model: str
-) -> tuple[str, dict[str, str]]:
- """Return (url, headers) for a provider request."""
+ provider: str, auth: str, model: str, request_data: dict[str, Any]
+) -> tuple[str, dict[str, str], dict[str, Any]]:
+ """Return (url, headers, request_data) for a provider request.
+
+ Args:
+ provider: Provider name
+ auth: Authentication string - either "direct:<api_key>" or "vertex"
+ model: Model identifier
+ request_data: The request payload (may be modified for Vertex)
+
+ Returns:
+ Tuple of (url, headers, modified_request_data)
+ """
config = PROVIDERS[provider]
- if provider == "anthropic":
+
+ if auth.startswith("direct:"):
+ api_key = auth[7:]
+ if provider == "anthropic":
+ request_data["model"] = model
+ return config["endpoint"], {
+ "Content-Type": "application/json",
+ "x-api-key": api_key,
+ "anthropic-version": "2023-06-01",
+ }, request_data
+ if provider == "google":
+ url = f"{config['endpoint']}/{model}:generateContent?key={api_key}"
+ return url, {"Content-Type": "application/json"}, request_data
+ # openai, xai
+ request_data["model"] = model
return config["endpoint"], {
"Content-Type": "application/json",
- "x-api-key": api_key,
- "anthropic-version": "2023-06-01",
- }
- if provider == "google":
- url = f"{config['endpoint']}/{model}:generateContent?key={api_key}"
- return url, {"Content-Type": "application/json"}
- # openai, xai
- return config["endpoint"], {
+ "Authorization": f"Bearer {api_key}",
+ }, request_data
+
+ # Vertex AI authentication
+ if auth != "vertex":
+ error(f"Invalid auth format: {auth}")
+
+ access_token, project_id = get_vertex_credentials()
+ project_id = os.environ.get("GOOGLE_CLOUD_PROJECT") or os.environ.get("GCP_PROJECT") or project_id
+ location = os.environ.get("CLOUD_ML_REGION", "global")
+
+ if location == "global":
+ vertex_base = f"https://aiplatform.googleapis.com/v1/projects/{project_id}/locations/{location}"
+ else:
+ vertex_base = f"https://{location}-aiplatform.googleapis.com/v1/projects/{project_id}/locations/{location}"
+
+ headers = {
"Content-Type": "application/json",
- "Authorization": f"Bearer {api_key}",
+ "Authorization": f"Bearer {access_token}",
}
+ vertex_model = model_to_vertex(model, provider)
+
+ if provider == "anthropic":
+ request_data["anthropic_version"] = "vertex-2023-10-16"
+ url = f"{vertex_base}/publishers/anthropic/models/{vertex_model}:rawPredict"
+ elif provider == "google":
+ url = f"{vertex_base}/publishers/google/models/{vertex_model}:generateContent"
+ else: # openai, xai
+ request_data["model"] = vertex_model
+ url = f"{vertex_base}/endpoints/openapi/chat/completions"
+
+ return url, headers, request_data
def _extract_usage(provider: str, result: dict[str, Any]) -> TokenUsage:
@@ -208,7 +363,7 @@ def _print_verbose_usage(usage: TokenUsage) -> None:
def send_request(
provider: str,
- api_key: str,
+ auth: str,
model: str,
request_data: dict[str, Any],
*,
@@ -220,8 +375,19 @@ def send_request(
The caller assembles the provider-specific request body via its own
build_*_request helpers (the prompts differ per script). This function
handles transport, error reporting, and token-usage extraction.
+
+ Args:
+ provider: Provider name (anthropic, openai, xai, google)
+ auth: Authentication string - either "direct:<api_key>" or "vertex"
+ model: Model identifier
+ request_data: Provider-specific request payload
+ timeout: Request timeout in seconds
+ verbose: Show detailed token usage
+
+ Returns:
+ Tuple of (response_text, token_usage)
"""
- url, headers = _build_request_meta(provider, api_key, model)
+ url, headers, request_data = _build_request_meta(provider, auth, model, request_data)
body = json.dumps(request_data).encode("utf-8")
req = Request(url, data=body, headers=headers)
@@ -232,6 +398,8 @@ def send_request(
error_body = e.read().decode("utf-8")
try:
error_data = json.loads(error_body)
+ if isinstance(error_data, list) and error_data:
+ error_data = error_data[0]
error(f"API error: {error_data.get('error', error_body)}")
except json.JSONDecodeError:
error(f"API error ({e.code}): {error_body}")
@@ -239,6 +407,8 @@ def send_request(
if isinstance(e.reason, TimeoutError):
error(f"Request timed out after {timeout} seconds")
error(f"Connection error: {e.reason}")
+ except TimeoutError:
+ error(f"Request timed out after {timeout} seconds")
usage = _extract_usage(provider, result)
if verbose:
diff --git a/devtools/ai/review-doc.py b/devtools/ai/review-doc.py
index 24e70ae06b..e01be077fe 100755
--- a/devtools/ai/review-doc.py
+++ b/devtools/ai/review-doc.py
@@ -27,6 +27,7 @@
TokenUsage,
add_token_args,
error,
+ get_auth_string,
get_git_config,
list_providers,
print_token_summary,
@@ -259,7 +260,6 @@ def build_user_prompt(
def build_anthropic_request(
- model: str,
max_tokens: int,
agents_content: str,
doc_content: str,
@@ -273,7 +273,6 @@ def build_anthropic_request(
doc_file, commit_prefix, output_format, include_diff_markers
)
return {
- "model": model,
"max_tokens": max_tokens,
"system": [
{"type": "text", "text": SYSTEM_PROMPT},
@@ -293,7 +292,6 @@ def build_anthropic_request(
def build_openai_request(
- model: str,
max_tokens: int,
agents_content: str,
doc_content: str,
@@ -307,7 +305,6 @@ def build_openai_request(
doc_file, commit_prefix, output_format, include_diff_markers
)
return {
- "model": model,
"max_tokens": max_tokens,
"messages": [
{"role": "system", "content": SYSTEM_PROMPT},
@@ -352,7 +349,7 @@ def build_google_request(
def call_api(
provider: str,
- api_key: str,
+ auth: str,
model: str,
max_tokens: int,
agents_content: str,
@@ -367,7 +364,6 @@ def call_api(
"""Build the per-provider request body and dispatch via _common."""
if provider == "anthropic":
request_data = build_anthropic_request(
- model,
max_tokens,
agents_content,
doc_content,
@@ -388,7 +384,6 @@ def call_api(
)
else: # openai, xai
request_data = build_openai_request(
- model,
max_tokens,
agents_content,
doc_content,
@@ -399,7 +394,7 @@ def call_api(
)
return send_request(
provider,
- api_key,
+ auth,
model,
request_data,
timeout=timeout,
@@ -631,6 +626,12 @@ def main() -> None:
help="Show API request details",
)
add_token_args(parser)
+ parser.add_argument(
+ "--auth",
+ choices=["auto", "direct", "vertex"],
+ default="auto",
+ help="Authentication method: auto (default), direct (API key), vertex (Google Cloud)",
+ )
parser.add_argument(
"-q",
"--quiet",
@@ -709,10 +710,8 @@ def main() -> None:
config = PROVIDERS[args.provider]
model = args.model or config["default_model"]
- # Get API key
- api_key = os.environ.get(config["env_var"])
- if not api_key:
- error(f"{config['env_var']} environment variable not set")
+ # Get authentication string
+ auth = get_auth_string(args.auth, args.provider)
# Validate files
agents_path = Path(args.agents)
@@ -783,6 +782,7 @@ def main() -> None:
if args.verbose:
print("=== Request ===", file=sys.stderr)
print(f"Provider: {args.provider}", file=sys.stderr)
+ print(f"Auth method: {'vertex' if auth == 'vertex' else 'direct'}", file=sys.stderr)
print(f"Model: {model}", file=sys.stderr)
print(f"Output format: {args.output_format}", file=sys.stderr)
print(f"AGENTS file: {args.agents}", file=sys.stderr)
@@ -800,7 +800,7 @@ def main() -> None:
# Call API
review_text, call_usage = call_api(
args.provider,
- api_key,
+ auth,
model,
args.tokens,
agents_content,
diff --git a/devtools/ai/review-patch.py b/devtools/ai/review-patch.py
index 52601ac156..9ac227000e 100755
--- a/devtools/ai/review-patch.py
+++ b/devtools/ai/review-patch.py
@@ -25,6 +25,7 @@
TokenUsage,
add_token_args,
error,
+ get_auth_string,
get_git_config,
list_providers,
print_token_summary,
@@ -460,7 +461,6 @@ def build_system_prompt(review_date: str, release: str | None) -> str:
def build_anthropic_request(
- model: str,
max_tokens: int,
system_prompt: str,
agents_content: str,
@@ -474,7 +474,6 @@ def build_anthropic_request(
patch_name=patch_name, format_instruction=format_instruction
)
return {
- "model": model,
"max_tokens": max_tokens,
"system": [
{"type": "text", "text": system_prompt},
@@ -494,7 +493,6 @@ def build_anthropic_request(
def build_openai_request(
- model: str,
max_tokens: int,
system_prompt: str,
agents_content: str,
@@ -508,7 +506,6 @@ def build_openai_request(
patch_name=patch_name, format_instruction=format_instruction
)
return {
- "model": model,
"max_tokens": max_tokens,
"messages": [
{"role": "system", "content": system_prompt},
@@ -553,7 +550,7 @@ def build_google_request(
def call_api(
provider: str,
- api_key: str,
+ auth: str,
model: str,
max_tokens: int,
system_prompt: str,
@@ -567,7 +564,6 @@ def call_api(
"""Build the per-provider request body and dispatch via _common."""
if provider == "anthropic":
request_data = build_anthropic_request(
- model,
max_tokens,
system_prompt,
agents_content,
@@ -586,7 +582,6 @@ def call_api(
)
else: # openai, xai
request_data = build_openai_request(
- model,
max_tokens,
system_prompt,
agents_content,
@@ -596,7 +591,7 @@ def call_api(
)
return send_request(
provider,
- api_key,
+ auth,
model,
request_data,
timeout=timeout,
@@ -813,6 +808,12 @@ def main() -> None:
help="Show API request details",
)
add_token_args(parser)
+ parser.add_argument(
+ "--auth",
+ choices=["auto", "direct", "vertex"],
+ default="auto",
+ help="Authentication method: auto (default), direct (API key), vertex (Google Cloud)",
+ )
parser.add_argument(
"-f",
"--format",
@@ -930,10 +931,8 @@ def main() -> None:
config = PROVIDERS[args.provider]
model = args.model or config["default_model"]
- # Get API key
- api_key = os.environ.get(config["env_var"])
- if not api_key:
- error(f"{config['env_var']} environment variable not set")
+ # Get authentication string
+ auth = get_auth_string(args.auth, args.provider)
# Validate files
agents_path = Path(args.agents)
@@ -1041,7 +1040,7 @@ def main() -> None:
review_text, call_usage = call_api(
args.provider,
- api_key,
+ auth,
model,
args.tokens,
system_prompt,
@@ -1111,7 +1110,7 @@ def main() -> None:
review_text, call_usage = call_api(
args.provider,
- api_key,
+ auth,
model,
args.tokens,
system_prompt,
@@ -1136,6 +1135,7 @@ def main() -> None:
if args.verbose:
print("=== Request ===", file=sys.stderr)
print(f"Provider: {args.provider}", file=sys.stderr)
+ print(f"Auth method: {'vertex' if auth == 'vertex' else 'direct'}", file=sys.stderr)
print(f"Model: {model}", file=sys.stderr)
print(f"Review date: {review_date}", file=sys.stderr)
if args.release:
@@ -1164,7 +1164,7 @@ def main() -> None:
if estimated_tokens > 0: # Not already processed
review_text, call_usage = call_api(
args.provider,
- api_key,
+ auth,
model,
args.tokens,
system_prompt,
--
2.53.0
^ permalink raw reply related
* RE: [PATCH v7] net/idpf: update for new mempool cache algorithm
From: Morten Brørup @ 2026-06-02 6:45 UTC (permalink / raw)
To: dev
In-Reply-To: <20260601183621.252920-1-mb@smartsharesystems.com>
Recheck-request: iol-unit-arm64-testing
CI subsystem log:
[176/407] Compiling C object lib/librte_cmdline.a.p/cmdline_cmdline.c.o
FAILED: lib/librte_cmdline.a.p/cmdline_cmdline.c.o
gcc-10 -Ilib/librte_cmdline.a.p -Ilib -I../lib -Ilib/cmdline -I../lib/cmdline -Ilib/eal/common -I../lib/eal/common -I. -I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/arm/include -I../lib/eal/arm/include -I../kernel/linux -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/log -I../lib/log -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/argparse -I../lib/argparse -Ilib/net -I../lib/net -Ilib/mbuf -I../lib/mbuf -Ilib/mempool -I../lib/mempool -Ilib/ring -I../lib/ring -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O3 -include rte_config.h -Wvla -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wshadow -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned -Wno-missing-field-initializers -D_GN
U_SOURCE -fPIC -march=armv8.2-a+crypto+sve -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API -DRTE_LOG_DEFAULT_LOGTYPE=lib.cmdline -MD -MQ lib/librte_cmdline.a.p/cmdline_cmdline.c.o -MF lib/librte_cmdline.a.p/cmdline_cmdline.c.o.d -o lib/librte_cmdline.a.p/cmdline_cmdline.c.o -c ../lib/cmdline/cmdline.c
gcc-10: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-10/README.Bugs> for instructions.
^ permalink raw reply
* RE: [PATCH v7] mempool/dpaa: update for new mempool cache algorithm
From: Morten Brørup @ 2026-06-02 6:51 UTC (permalink / raw)
To: dev
In-Reply-To: <20260601183621.252920-2-mb@smartsharesystems.com>
Recheck-request: iol-unit-arm64-testing
CI log:
==== Unit test summary for Red Hat Enterprise Linux 9.7 (dpdk_unit_test): ====
[...]
53/145 DPDK:fast-tests / eal_flags_file_prefix_autotest FAIL 0.88s (exit status 255 or signal 127 SIGinvalid)
>>> DPDK_TEST=eal_flags_file_prefix_autotest MALLOC_PERTURB_=192 /home-local/jenkins-local/jenkins-agent/workspace/Generic-Unit-Test-DPDK/dpdk/build/app/dpdk-test --file-prefix=eal_flags_file_prefix_autotest
[...]
Error (line 1407) - failed to run with --file-prefix=memtest1
Test Failed
^ permalink raw reply
* RE: [PATCH v7] mempool/dpaa2: update for new mempool cache algorithm
From: Morten Brørup @ 2026-06-02 6:53 UTC (permalink / raw)
To: dev
In-Reply-To: <20260601183621.252920-3-mb@smartsharesystems.com>
Recheck-request: iol-unit-arm64-testing
CI subsystem log:
==== 20 line log output for Ubuntu 24.04 (lpm_autotest): ====
[...]
[89/406] Compiling C object lib/librte_eal.a.p/eal_linux_eal_timer.c.o
FAILED: lib/librte_eal.a.p/eal_linux_eal_timer.c.o
gcc-10 -Ilib/librte_eal.a.p -Ilib -I../lib -Ilib/eal/common -I../lib/eal/common -I. -I.. -Iconfig -I../config -Ilib/eal/include -I../lib/eal/include -Ilib/eal/linux/include -I../lib/eal/linux/include -Ilib/eal/arm/include -I../lib/eal/arm/include -I../kernel/linux -Ilib/eal -I../lib/eal -Ilib/kvargs -I../lib/kvargs -Ilib/log -I../lib/log -I../lib/metrics -Ilib/telemetry -I../lib/telemetry -Ilib/argparse -I../lib/argparse -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Werror -std=c11 -O3 -include rte_config.h -Wvla -Wcast-qual -Wdeprecated -Wformat -Wformat-nonliteral -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wold-style-definition -Wpointer-arith -Wshadow -Wsign-compare -Wstrict-prototypes -Wundef -Wwrite-strings -Wno-packed-not-aligned -Wno-missing-field-initializers -D_GNU_SOURCE -fPIC -march=armv8.2-a+crypto+sve -DALLOW_EXPERIMENTAL_API -DALLOW_INTERNAL_API '-DABI_VERSION="26.2"' -DRTE_LOG_DEFAULT_LOGTYPE=l
ib.eal -MD -MQ lib/librte_eal.a.p/eal_linux_eal_timer.c.o -MF lib/librte_eal.a.p/eal_linux_eal_timer.c.o.d -o lib/librte_eal.a.p/eal_linux_eal_timer.c.o -c ../lib/eal/linux/eal_timer.c
gcc-10: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-10/README.Bugs> for instructions.
^ permalink raw reply
* RE: [PATCH v2] doc, eal, devtools: discourage new __rte_always_inline
From: Konstantin Ananyev @ 2026-06-02 7:07 UTC (permalink / raw)
To: Stephen Hemminger, dev@dpdk.org; +Cc: Thomas Monjalon
In-Reply-To: <20260601172104.311909-1-stephen@networkplumber.org>
> Modern compilers at -O2 make good inlining decisions for small
> static inline functions; forced inlining via __rte_always_inline
> should be reserved for cases where it is required for correctness
> or for documented measured performance reasons.
>
> Document the policy in the coding style guide and add a
> checkpatches.sh entry that flags when new uses of the attribute
> are introduced. Checkpatches is not an absolute blocker to
> acceptance, only an indicator that more review is needed.
>
> Add additional comments about use of __rte_always_inline,
> __rte_noinline, __rte_hot, and __rte_cold to the rte_common.h
> to aid developers.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> devtools/checkpatches.sh | 8 +++++
> doc/guides/contributing/coding_style.rst | 26 ++++++++++++++++-
> lib/eal/include/rte_common.h | 37 ++++++++++++++++++++++--
> 3 files changed, 68 insertions(+), 3 deletions(-)
>
> diff --git a/devtools/checkpatches.sh b/devtools/checkpatches.sh
> index f5dd77443f..2a3d364178 100755
> --- a/devtools/checkpatches.sh
> +++ b/devtools/checkpatches.sh
> @@ -137,6 +137,14 @@ check_forbidden_additions() { # <patch>
> -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> "$1" || res=1
>
> + # forbid new use of __rte_always_inline
> + awk -v FOLDERS="lib drivers app examples" \
> + -v EXPRESSIONS='\\<__rte_always_inline\\>' \
> + -v RET_ON_FAIL=1 \
> + -v MESSAGE='Adding __rte_always_inline; prefer plain inline' \
> + -f $(dirname $(readlink -f $0))/check-forbidden-tokens.awk \
> + "$1" || res=1
> +
> # refrain from using compiler __rte_atomic_thread_fence()
> # It should be avoided on x86 for SMP case.
> awk -v FOLDERS="lib drivers app examples" \
> diff --git a/doc/guides/contributing/coding_style.rst
> b/doc/guides/contributing/coding_style.rst
> index 243a3c2959..8f9e77d1c1 100644
> --- a/doc/guides/contributing/coding_style.rst
> +++ b/doc/guides/contributing/coding_style.rst
> @@ -747,11 +747,35 @@ Static Variables and Functions
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> * All functions and variables that are local to a file must be declared as ``static``
> because it can often help the compiler to do some optimizations (such as, inlining
> the code).
> -* Functions that should be inlined should to be declared as ``static inline`` and
> can be defined in a .c or a .h file.
> +* Functions that should be inlined should be declared as ``static inline`` and can
> be defined in a .c or a .h file.
>
> .. note::
> Static functions defined in a header file must be declared as ``static
> inline`` in order to prevent compiler warnings about the function being unused.
>
> +Use of ``__rte_always_inline``
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The ``__rte_always_inline`` attribute forces the compiler to inline a function
> regardless of its size or call-graph heuristics.
> +Prefer plain ``inline`` (or no annotation at all for static functions) and let the
> compiler decide.
> +Modern compilers at ``-O2`` make good inlining decisions for small ``static
> inline`` functions in headers,
> +and forced inlining can hurt performance by inflating function bodies, increasing
> register pressure, and overriding profile-guided optimization.
> +
> +``__rte_always_inline`` should only be used when one of the following applies:
> +
> +* The function contains ``__rte_constant()`` checks that gate a constant-folded
> fast path,
> + and the optimization is lost if the function is not inlined into the caller.
> + Examples include byte-order helpers and length-dispatched copy/compare
> routines.
> +
> +* The function wraps inline assembly or a compiler intrinsic whose correctness
> depends on being inlined into the caller's register context (for example, intrinsics
> requiring a compile-time constant argument).
> +
> +* Measurement on a representative workload shows that the annotation is
> required to retain performance, and the reason is documented in the commit
> message that introduces it.
> +
> +Each use must be justified at the point it is introduced. Adding
> ``__rte_always_inline`` because nearby code uses it is not a justification;
> +if the constant or intrinsic that requires inlining is several call levels up the call
> chain,
> +restructure the code rather than annotating the entire chain.
> +
> +The complementary attribute ``__rte_noinline`` is useful for explicitly marking
> cold paths (error handling, initialization, slow-path fallbacks) where outlining the
> function can reduce instruction-cache pressure on the hot path.
> +
> Const Attribute
> ~~~~~~~~~~~~~~~
>
> diff --git a/lib/eal/include/rte_common.h b/lib/eal/include/rte_common.h
> index 71415346cf..e358be7fcf 100644
> --- a/lib/eal/include/rte_common.h
> +++ b/lib/eal/include/rte_common.h
> @@ -482,7 +482,22 @@ static void __attribute__((destructor(RTE_PRIO(prio)),
> used)) func(void)
> #endif
>
> /**
> - * Force a function to be inlined
> + * Force a function to be inlined, regardless of the compiler's size and
> + * call-graph heuristics.
> + *
> + * Prefer plain @c inline (or no annotation on a static function) and let the
> compiler decide.
> + * Modern compilers at -O2 inline small static functions well,
> + * and forcing it can hurt by inflating call sites, raising register pressure,
> + * and overriding profile-guided optimization.
> + *
> + * Reserve this attribute for cases where inlining is required for
> + * correctness, or for a documented and measured performance reason, e.g.
> + * - a constant-folded fast path gated by @c __rte_constant() that is lost
> + * unless the function is inlined into the caller;
> + * - a wrapper around inline asm or an intrinsic that needs a
> + * compile-time-constant argument from the caller's context.
> + *
> + * See the DPDK coding style guide for the full policy.
> */
> #ifdef RTE_TOOLCHAIN_MSVC
> #define __rte_always_inline __forceinline
> @@ -491,7 +506,11 @@ static void __attribute__((destructor(RTE_PRIO(prio)),
> used)) func(void)
> #endif
>
> /**
> - * Force a function to be noinlined
> + * Force a function not to be inlined.
> + *
> + * Useful for explicitly outlining cold paths such as error handling,
> + * initialization, slow-path fallbacks, so they do not bloat the hot path
> + * or add to its instruction-cache footprint.
> */
> #ifdef RTE_TOOLCHAIN_MSVC
> #define __rte_noinline __declspec(noinline)
> @@ -501,6 +520,12 @@ static void __attribute__((destructor(RTE_PRIO(prio)),
> used)) func(void)
>
> /**
> * Hint function in the hot path
> + *
> + * The compiler may optimize the function more aggressively, treat calls
> + * to it as likely for branch prediction, and group it with other hot
> + * functions to improve instruction-cache locality. This affects code
> + * placement and prediction, not inlining; combine with an inline
> + * annotation if both are wanted.
> */
> #ifdef RTE_TOOLCHAIN_MSVC
> #define __rte_hot
> @@ -510,6 +535,14 @@ static void __attribute__((destructor(RTE_PRIO(prio)),
> used)) func(void)
>
> /**
> * Hint function in the cold path
> + *
> + * The compiler optimizes the function for size rather than speed,
> + * marks branches that reach it as unlikely, and may move it to a separate
> + * section to keep it off the hot path and reduce instruction-cache
> + * pressure there.
> + *
> + * Suitable for error handling, logging, and setup/teardown code.
> + * Functions marked @c __rte_noreturn are already treated as cold.
> */
> #ifdef RTE_TOOLCHAIN_MSVC
> #define __rte_cold
> --
Acked-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> 2.53.0
^ permalink raw reply
* RE: [PATCH v2] app/test-pmd: add generic PROG action parser support
From: Konstantin Ananyev @ 2026-06-02 7:35 UTC (permalink / raw)
To: Ajmera, Megha, Stephen Hemminger
Cc: Richardson, Bruce, Dumitrescu, Cristian, Shetty, Praveen,
Singh, Aman Deep, dev@dpdk.org
In-Reply-To: <MW4PR11MB589273F3A331E94D0876900D97152@MW4PR11MB5892.namprd11.prod.outlook.com>
> > For my own curiosity: how user can define his own PROG action?
> > Is it supposed to be programmed and uplodaded to the NIC by some external
> tool
> > (P4 compiler)?
> > Or does it refer to the set of some predefined functions that given firmware
> > supports?
> > Or ... ?
> > Sorry for probably naive questions, but I found is nearly zero information inside
> > DPDK docs about how PROG action supposed to work.
>
> PROG in rte_flow is currently a vendor-defined action interface (name +
> arguments), not a generic DPDK programming model by itself.
>
> So in practice:
>
> 1. DPDK/testpmd does not define or upload user code to NIC on its own.
> 2. testpmd just passes the prog name/argument/payload to the PMD via
> rte_flow.
> 3. What that name/arguments means is NIC/firmware specific.
> 4. Depending on device support, it may map to predefined firmware-exposed
> functions
Ok, so it is predefined by the FW.
Then shouldn't CPFL PG contain a list of supported PROGs and their arguments?
Again, some tests/examples for it with testpmd/DTS.
Or that's all will be the next step (patch-series)?
> 5. If the PMD/firmware does not recognize it, flow validate/create will fail.
^ permalink raw reply
* RE: [PATCH] ring: avoid extra store at move head
From: Konstantin Ananyev @ 2026-06-02 9:02 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev@dpdk.org
In-Reply-To: <20260601152313.1946d438@phoenix.local>
> > C11 __rte_ring_headtail_move_head_mt() uses output
> > parameter: 'uint32_t *old_head' directly within CAS operation.
> > In x86_64 that cause gcc to generate extra instructions to
> > store return value of CAS (eax) within 'old_head' memory location,
> > even when CAS was not successful and another attempt should be
> > performed. In some cases, even extra branch can be observed.
> > To be more specific the code like that is generated:
> > // start of 'do { } while();' loop
> > .L2
> > ...
> > lock cmpxchgl %r8d, (%rdi)
> > jne .L17 //
> > .L1: // <---- successful completion of CAS, finish
> > movl %edx, %eax
> > ret
> > .L17: // <---- unsuccessful completion of CAS, repeat
> > movl %eax, (%r9)
> > jmp .L2
> >
> > In constrast, x86 specific version that uses
> > __sync_bool_compare_and_swap() doesn't exibit such problem,
> > as __sync_bool_compare_and_swap() doesn't update the 'old_head'
> > with new value, and we have to re-read it explicitly on each iteration.
> >
> > Overcome that problem by using local variable 'head' inside the loop,
> > and updaing '*old_head' value only at exit.
> > With such change gcc manages to avoid extra store(/branch).
> >
> > Depends-on: series-38225 ("deprecate rte_atomicNN family")
> >
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
> > ---
>
> I used the standard ring perf tests and ran 10 times via:
> ! /bin/bash
> if [ -z "$1" ]; then
> echo "Usage $0 version"
> exit 1
> fi
>
> VERSION=$1
> for i in $(seq 1 10); do
> sudo DPDK_TEST=ring_perf_autotest \
> ./build/app/dpdk-test -l 2-5 -n 4 --no-pci --file-prefix=run$i \
> > ~/DPDK/ring_perf_results/${VERSION}_run${i}.log 2>&1
> echo "${VERSION} run $i done"
> done
>
>
> Then had Claude compare results:
>
> Key metric (two physical cores legacy MP/MC bulk n=128):
> main: 5.380 cycles/elem
> sync-bool: 5.377 cycles/elem (-0.07%)
> avoid-store: 5.892 cycles/elem (+9.52%) ← regresses
>
>
> Looking at the dissassembly of ring_enqueue_bulk:
>
> The inner loop of main and sync-bool versions is:
> mov 0x80(%rdi),%r11d ; load d->head via displacement
> mov 0x104(%rdi),%ebx ; load s->tail
> add %ecx,%ebx
> sub %r11d,%ebx
> cmp %ebx,%r12d
> jae [exit]
> lea (%r8,%r11,1),%r13d ; new_head = old_head + n
> mov %r11d,%eax ; expected → eax
> lock cmpxchg %r13d,0x80(%rdi) ; ← displacement addressing
> jne [retry] ; ← direct jne, eax preserved
>
> Using atomic_compare_exchange and your patch:
> mov 0x38(%rdi),%r10d
> mov 0x80(%rdi),%eax ; load d->head directly into %eax
> lea 0x80(%rdi),%rcx ; ← MATERIALIZE &d->head into %rcx
> lea -0x1(%r8),%r12d
> mov 0x104(%rdi),%r11d
> add %r10d,%r11d
> sub %eax,%r11d
> cmp %r11d,%r12d
> jae [exit]
> lea (%r8,%rax,1),%r13d ; new_head
> lock cmpxchg %r13d,(%rcx) ; ← INDIRECT addressing via %rcx
> mov %eax,%ebx ; ← EXTRA: save post-CAS %eax to %ebx
> jne [retry]
>
> Bottom line: good idea but still fighting with Gcc optimizer here.
Thanks for trying.
On my box (AMD EPYC 9534) with same test, there is no much difference between all of them:
use-sync-bool: 2.2273
use-c11-current-version: 2.2422
use-c11-patched: 2.2431
Anyway, -10% on some boxes - that's probably good enough reason to keep specific version
for __rte_ring_headtail_move_head_mt().
My ask would be to have some special macro for it, so users can enable/disable it via
'meson setup' at will.
Konstantin
^ permalink raw reply
* RE: [PATCH] app/crypto-perf: support ML DSA
From: Akhil Goyal @ 2026-06-02 9:02 UTC (permalink / raw)
To: Pratik Senapati, dev@dpdk.org
Cc: Anoob Joseph, Gowrishankar Muthukrishnan, kai.ji@intel.com
In-Reply-To: <20260528075853.2206573-2-psenapati@marvell.com>
Please send this patch as a series with ML KEM support so that CI can run successfully.
^ permalink raw reply
* RE: [PATCH] crypto/openssl: fix use-after-free bug and cleanup
From: Akhil Goyal @ 2026-06-02 9:03 UTC (permalink / raw)
To: Pratik Senapati, dev@dpdk.org
Cc: Anoob Joseph, Gowrishankar Muthukrishnan, kai.ji@intel.com,
stable@dpdk.org
In-Reply-To: <20260528075822.2206494-1-psenapati@marvell.com>
> -----Original Message-----
> From: Pratik Senapati <psenapati@marvell.com>
> Sent: Thursday, May 28, 2026 1:28 PM
> To: dev@dpdk.org
> Cc: Akhil Goyal <gakhil@marvell.com>; Anoob Joseph <anoobj@marvell.com>;
> Gowrishankar Muthukrishnan <gmuthukrishn@marvell.com>; kai.ji@intel.com;
> stable@dpdk.org
> Subject: [PATCH] crypto/openssl: fix use-after-free bug and cleanup
>
> params is freed before it is used by
> EVP_PKEY_decapsulate_init() causing a
> use-after-free issue. Pass NULL to
> EVP_PKEY_decapsulate_init() instead of params
> to avoid it.
>
> Add resource cleanup for all error paths in the ML-KEM
> decapsulate handler and consolidate cleanup into
> two goto labels err_pkey and err_decap.
>
> Fixes: 5f761d7b60 ("crypto/openssl: support ML-KEM and ML-DSA")
> Cc: stable@dpdk.org
> Signed-off-by: Pratik Senapati <psenapati@marvell.com>
> ---
Fix compilation.
^ permalink raw reply
* [RFC PATCH 0/3] remove unneeded build options
From: Bruce Richardson @ 2026-06-02 9:08 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
Having unnecessary build options just makes things confusing for
the user, and expands the set of potential builds. This set
makes 3 build options no-ops, and marks them as deprecated for
future removal.
Bruce Richardson (3):
build: deprecate kernel dir option
build: deprecate standalone tests option
build: deprecate HPET build option
app/meson.build | 6 +-----
app/test/test.c | 7 -------
app/test/test_timer.c | 5 +++++
config/meson.build | 2 +-
doc/guides/linux_gsg/enable_func.rst | 2 --
doc/guides/rel_notes/deprecation.rst | 7 +++++++
lib/eal/linux/meson.build | 5 +----
meson_options.txt | 6 +++---
8 files changed, 18 insertions(+), 22 deletions(-)
--
2.53.0
^ permalink raw reply
* [RFC PATCH 1/3] build: deprecate kernel dir option
From: Bruce Richardson @ 2026-06-02 9:08 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
In-Reply-To: <20260602090847.905721-1-bruce.richardson@intel.com>
The kernel_dir option does nothing, so it can be deprecated and removed
in future.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
doc/guides/rel_notes/deprecation.rst | 4 ++++
meson_options.txt | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 17f90a6352..ed1dda6008 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -17,6 +17,10 @@ Other API and ABI deprecation notices are to be posted below.
Deprecation Notices
-------------------
+* build: The following meson build options are deprecated and will be removed in a future release:
+
+ - ``kernel_dir``: option unused as Linux kernel drivers are in a separate ``dpdk-kmods`` repository.
+
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
diff --git a/meson_options.txt b/meson_options.txt
index e28d24054c..7bd5ebc084 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -33,7 +33,7 @@ option('ibverbs_link', type: 'combo', choices : ['static', 'shared', 'dlopen'],
option('include_subdir_arch', type: 'string', value: '', description:
'subdirectory where to install arch-dependent headers')
option('kernel_dir', type: 'string', value: '', description:
- 'Path to the kernel for building kernel modules. Headers must be in $kernel_dir or $kernel_dir/build. Modules will be installed in /lib/modules.')
+ '[Deprecated] Value unused. Previously, path to the kernel for building kernel modules.')
option('machine', type: 'string', value: 'auto', description:
'Alias of cpu_instruction_set.')
option('max_ethports', type: 'integer', value: 32, description:
--
2.53.0
^ permalink raw reply related
* [RFC PATCH 2/3] build: deprecate standalone tests option
From: Bruce Richardson @ 2026-06-02 9:08 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
In-Reply-To: <20260602090847.905721-1-bruce.richardson@intel.com>
The unit tests can be disabled in DPDK in a couple of ways. Firstly,
there is the original "tests" boolean option - when set to false, the
tests are skipped as part of the build. However, the newer
enable_apps/disable_apps options also can be used to disable the tests
[you can disable using the "enable" option by omitting "tests" from the
list to enable].
This duplication of functionality is unnecessary, so let's remove the
standalone tests option.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/meson.build | 6 +-----
doc/guides/rel_notes/deprecation.rst | 1 +
meson_options.txt | 2 +-
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/app/meson.build b/app/meson.build
index 1798db3ae4..52f704ec94 100644
--- a/app/meson.build
+++ b/app/meson.build
@@ -17,6 +17,7 @@ apps = [
'graph',
'pdump',
'proc-info',
+ 'test',
'test-acl',
'test-bbdev',
'test-cmdline',
@@ -35,11 +36,6 @@ apps = [
'test-security-perf',
]
-if get_option('tests')
-# build the auto test app if enabled.
- apps += 'test'
-endif
-
default_cflags = machine_args + ['-DALLOW_EXPERIMENTAL_API']
default_ldflags = []
if get_option('default_library') == 'static' and not is_windows
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index ed1dda6008..15459851d0 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -20,6 +20,7 @@ Deprecation Notices
* build: The following meson build options are deprecated and will be removed in a future release:
- ``kernel_dir``: option unused as Linux kernel drivers are in a separate ``dpdk-kmods`` repository.
+ - ``tests``: disabling tests can be achieved by using the ``enable_apps`` / ``disable_apps`` options instead.
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
diff --git a/meson_options.txt b/meson_options.txt
index 7bd5ebc084..323a3901e1 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -55,6 +55,6 @@ option('enable_stdatomic', type: 'boolean', value: false, description:
option('enable_trace_fp', type: 'boolean', value: false, description:
'enable fast path trace points.')
option('tests', type: 'boolean', value: true, description:
- 'build unit tests')
+ '[Deprecated] Value unused. Add "tests" to disable_apps setting to disable the unit tests')
option('use_hpet', type: 'boolean', value: false, description:
'use HPET timer in EAL')
--
2.53.0
^ permalink raw reply related
* [RFC PATCH 3/3] build: deprecate HPET build option
From: Bruce Richardson @ 2026-06-02 9:08 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
In-Reply-To: <20260602090847.905721-1-bruce.richardson@intel.com>
We can enable the building of the HPET code by default on Linux, since
the timers are not used - or even initialized - by default. Instead an
app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
APIs. Therefore, let's simplify the user experience by deprecating the
option "use_hpet" and make it a no-op.
To avoid issue with the dpdk-test binary which was trying to initialize
the hpet on startup, move the hpet init call to the timer autotest - the
only place where it was used.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test/test.c | 7 -------
app/test/test_timer.c | 5 +++++
config/meson.build | 2 +-
doc/guides/linux_gsg/enable_func.rst | 2 --
doc/guides/rel_notes/deprecation.rst | 2 ++
lib/eal/linux/meson.build | 5 +----
meson_options.txt | 2 +-
7 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/app/test/test.c b/app/test/test.c
index 58ef52f312..99d6e90f8b 100644
--- a/app/test/test.c
+++ b/app/test/test.c
@@ -180,13 +180,6 @@ main(int argc, char **argv)
goto out;
}
-#ifdef RTE_LIBEAL_USE_HPET
- if (rte_eal_hpet_init(1) < 0)
-#endif
- RTE_LOG(INFO, APP,
- "HPET is not enabled, using TSC as default timer\n");
-
-
char *dpdk_test = getenv("DPDK_TEST");
if (dpdk_test && strlen(dpdk_test) > 0)
diff --git a/app/test/test_timer.c b/app/test/test_timer.c
index c936843ddc..dcb26c4395 100644
--- a/app/test/test_timer.c
+++ b/app/test/test_timer.c
@@ -501,6 +501,11 @@ static int
timer_sanity_check(void)
{
#ifdef RTE_LIBEAL_USE_HPET
+ if (rte_eal_hpet_init(1) < 0) {
+ printf("HPET is not enabled, using TSC as default timer\n");
+ return 0;
+ }
+
if (eal_timer_source != EAL_TIMER_HPET) {
printf("Not using HPET, can't sanity check timer sources\n");
return 0;
diff --git a/config/meson.build b/config/meson.build
index 9ba7b9a338..6012a3c243 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -381,7 +381,7 @@ endforeach
# set other values pulled from the build options
dpdk_conf.set('RTE_MAX_ETHPORTS', get_option('max_ethports'))
-dpdk_conf.set('RTE_LIBEAL_USE_HPET', get_option('use_hpet'))
+dpdk_conf.set('RTE_LIBEAL_USE_HPET', is_linux)
dpdk_conf.set('RTE_ENABLE_STDATOMIC', get_option('enable_stdatomic'))
dpdk_conf.set('RTE_ENABLE_TRACE_FP', get_option('enable_trace_fp'))
dpdk_conf.set('RTE_PKTMBUF_HEADROOM', get_option('pkt_mbuf_headroom'))
diff --git a/doc/guides/linux_gsg/enable_func.rst b/doc/guides/linux_gsg/enable_func.rst
index 4e1a939f35..1d5b030172 100644
--- a/doc/guides/linux_gsg/enable_func.rst
+++ b/doc/guides/linux_gsg/enable_func.rst
@@ -176,8 +176,6 @@ To enable HPET support in DPDK:
Note that this may involve doing a kernel rebuild,
as many common linux distributions do *not* have this setting
enabled by default in their kernel builds.
-#. Enable DPDK support for HPET by using the build-time meson option ``use_hpet``,
- for example, ``meson configure -Duse_hpet=true``
For an application to use the ``rte_get_hpet_cycles()`` and ``rte_get_hpet_hz()`` API calls,
and optionally to make the HPET the default time source for the rte_timer library,
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index 15459851d0..42ad118c92 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -21,6 +21,8 @@ Deprecation Notices
- ``kernel_dir``: option unused as Linux kernel drivers are in a separate ``dpdk-kmods`` repository.
- ``tests``: disabling tests can be achieved by using the ``enable_apps`` / ``disable_apps`` options instead.
+ - ``use_hpet``: option unused as HPET is only supported on Linux
+ and is runtime-enabled using ``rte_eal_hpet_init()`` API.
* kvargs: The function ``rte_kvargs_process`` will get a new parameter
for returning key match count. It will ease handling of no-match case.
diff --git a/lib/eal/linux/meson.build b/lib/eal/linux/meson.build
index 29ba313218..8b0519c9a1 100644
--- a/lib/eal/linux/meson.build
+++ b/lib/eal/linux/meson.build
@@ -15,14 +15,11 @@ sources += files(
'eal_memory.c',
'eal_thread.c',
'eal_timer.c',
+ 'eal_timer_hpet.c',
'eal_vfio.c',
'eal_vfio_mp_sync.c',
)
-if dpdk_conf.get('RTE_LIBEAL_USE_HPET')
- sources += files('eal_timer_hpet.c')
-endif
-
deps += ['kvargs', 'telemetry']
if has_libnuma
dpdk_conf.set10('RTE_EAL_NUMA_AWARE_HUGEPAGES', true)
diff --git a/meson_options.txt b/meson_options.txt
index 323a3901e1..242de6681f 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -57,4 +57,4 @@ option('enable_trace_fp', type: 'boolean', value: false, description:
option('tests', type: 'boolean', value: true, description:
'[Deprecated] Value unused. Add "tests" to disable_apps setting to disable the unit tests')
option('use_hpet', type: 'boolean', value: false, description:
- 'use HPET timer in EAL')
+ '[Deprecated] Value unused. HPET can be runtime-enabled on Linux using rte_eal_hpet_init().')
--
2.53.0
^ permalink raw reply related
* RE: [PATCH] ring: avoid extra store at move head
From: Morten Brørup @ 2026-06-02 9:21 UTC (permalink / raw)
To: Konstantin Ananyev, Stephen Hemminger; +Cc: dev
In-Reply-To: <580828b0214b4e1fb22e2f6d4079eadf@huawei.com>
> > Then had Claude compare results:
> >
> > Key metric (two physical cores legacy MP/MC bulk n=128):
> > main: 5.380 cycles/elem
> > sync-bool: 5.377 cycles/elem (-0.07%)
> > avoid-store: 5.892 cycles/elem (+9.52%) ← regresses
> >
> >
> > Looking at the dissassembly of ring_enqueue_bulk:
> >
> > The inner loop of main and sync-bool versions is:
> > mov 0x80(%rdi),%r11d ; load d->head via displacement
> > mov 0x104(%rdi),%ebx ; load s->tail
> > add %ecx,%ebx
> > sub %r11d,%ebx
> > cmp %ebx,%r12d
> > jae [exit]
> > lea (%r8,%r11,1),%r13d ; new_head = old_head + n
> > mov %r11d,%eax ; expected → eax
> > lock cmpxchg %r13d,0x80(%rdi) ; ← displacement addressing
> > jne [retry] ; ← direct jne, eax preserved
> >
> > Using atomic_compare_exchange and your patch:
> > mov 0x38(%rdi),%r10d
> > mov 0x80(%rdi),%eax ; load d->head directly into %eax
> > lea 0x80(%rdi),%rcx ; ← MATERIALIZE &d->head into
> %rcx
> > lea -0x1(%r8),%r12d
> > mov 0x104(%rdi),%r11d
> > add %r10d,%r11d
> > sub %eax,%r11d
> > cmp %r11d,%r12d
> > jae [exit]
> > lea (%r8,%rax,1),%r13d ; new_head
> > lock cmpxchg %r13d,(%rcx) ; ← INDIRECT addressing via %rcx
> > mov %eax,%ebx ; ← EXTRA: save post-CAS %eax to
> %ebx
> > jne [retry]
> >
> > Bottom line: good idea but still fighting with Gcc optimizer here.
>
> Thanks for trying.
> On my box (AMD EPYC 9534) with same test, there is no much difference
> between all of them:
> use-sync-bool: 2.2273
> use-c11-current-version: 2.2422
> use-c11-patched: 2.2431
> Anyway, -10% on some boxes - that's probably good enough reason to keep
> specific version
> for __rte_ring_headtail_move_head_mt().
> My ask would be to have some special macro for it, so users can
> enable/disable it via 'meson setup' at will.
This seems very exotic as a meson command line option.
Either put it in rte_config.h, or make it CPU specific.
^ permalink raw reply
* RE: [RFC PATCH 1/3] build: deprecate kernel dir option
From: Morten Brørup @ 2026-06-02 9:24 UTC (permalink / raw)
To: Bruce Richardson, dev
In-Reply-To: <20260602090847.905721-2-bruce.richardson@intel.com>
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 2 June 2026 11.09
>
> The kernel_dir option does nothing, so it can be deprecated and removed
> in future.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
Good cleanup.
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* RE: [RFC PATCH 2/3] build: deprecate standalone tests option
From: Morten Brørup @ 2026-06-02 9:26 UTC (permalink / raw)
To: Bruce Richardson, dev
In-Reply-To: <20260602090847.905721-3-bruce.richardson@intel.com>
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 2 June 2026 11.09
>
> The unit tests can be disabled in DPDK in a couple of ways. Firstly,
> there is the original "tests" boolean option - when set to false, the
> tests are skipped as part of the build. However, the newer
> enable_apps/disable_apps options also can be used to disable the tests
> [you can disable using the "enable" option by omitting "tests" from the
> list to enable].
>
> This duplication of functionality is unnecessary, so let's remove the
> standalone tests option.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
Good cleanup.
Acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply
* Re: [PATCH] gpu/metax: add new driver for Metax GPU
From: Thomas Monjalon @ 2026-06-02 10:01 UTC (permalink / raw)
To: 许玲燕; +Cc: dev, eagostini
In-Reply-To: <6c18e957-c1c2-4b43-9b2c-b36424c1e9af.lingyan.xu@metax-tech.com>
Hello,
01/06/2026 07:47, 许玲燕:
> I am writing to propose a new driver for the Metax GPU,
How do you access the GPU?
Are you using a specific library or kernel module?
> which I believe will significantly enhance our support
> and performance for this hardware.
> The patch attached includes the initial implementation of the driver,
> with key features such as:
>
> * Basic initialization and configuration
> * Memory management and allocation
> * Core functionality for rendering and compute tasks
I am familiar with connecting compute tasks of a GPU
with DPDK networking, but I'm surprised by the rendering functionality.
Do you mean graphical rendering of data coming from the network?
> Please review the code and let me know if you have any feedback or suggestions.
> I am more than happy to make any necessary adjustments and improvements.
Thank you for working on this.
I recommend following this guide to introduce a new driver:
https://doc.dpdk.org/guides/contributing/new_driver.html
^ permalink raw reply
* RE: [RFC PATCH 3/3] build: deprecate HPET build option
From: Morten Brørup @ 2026-06-02 10:47 UTC (permalink / raw)
To: Bruce Richardson, dev
In-Reply-To: <20260602090847.905721-4-bruce.richardson@intel.com>
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 2 June 2026 11.09
>
> We can enable the building of the HPET code by default on Linux, since
> the timers are not used - or even initialized - by default. Instead an
> app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
> APIs. Therefore, let's simplify the user experience by deprecating the
> option "use_hpet" and make it a no-op.
>
> To avoid issue with the dpdk-test binary which was trying to initialize
> the hpet on startup, move the hpet init call to the timer autotest -
> the
> only place where it was used.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
Careful!
I think this patch has unintended side effects:
On Linux, it unconditionally enables HPET (and sets RTE_LIBEAL_USE_HPET), which was previously disabled by default.
So, if some Linux applications use #ifdef RTE_LIBEAL_USE_HPET, they will now tell DPDK to use that timer instead of the TSC.
We can fix the apps/examples in the DPDK repo, but it will potentially change behavior of DPDK user's applications.
I'm not opposed to unconditionally enabling HPET ability in DPDK itself on Linux.
But I'm worried about side effects of unconditionally enabling #ifdef RTE_LIBEAL_USE_HPET in Linux user applications.
^ permalink raw reply
* Re: [RFC PATCH 3/3] build: deprecate HPET build option
From: David Marchand @ 2026-06-02 11:39 UTC (permalink / raw)
To: Morten Brørup, Bruce Richardson; +Cc: dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F658D8@smartserver.smartshare.dk>
On Tue, 2 Jun 2026 at 12:47, Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Tuesday, 2 June 2026 11.09
> >
> > We can enable the building of the HPET code by default on Linux, since
> > the timers are not used - or even initialized - by default. Instead an
> > app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
> > APIs. Therefore, let's simplify the user experience by deprecating the
> > option "use_hpet" and make it a no-op.
> >
> > To avoid issue with the dpdk-test binary which was trying to initialize
> > the hpet on startup, move the hpet init call to the timer autotest -
> > the
> > only place where it was used.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
>
> Careful!
> I think this patch has unintended side effects:
>
> On Linux, it unconditionally enables HPET (and sets RTE_LIBEAL_USE_HPET), which was previously disabled by default.
>
> So, if some Linux applications use #ifdef RTE_LIBEAL_USE_HPET, they will now tell DPDK to use that timer instead of the TSC.
> We can fix the apps/examples in the DPDK repo, but it will potentially change behavior of DPDK user's applications.
>
> I'm not opposed to unconditionally enabling HPET ability in DPDK itself on Linux.
> But I'm worried about side effects of unconditionally enabling #ifdef RTE_LIBEAL_USE_HPET in Linux user applications.
I don't see a functional impact.
There may be an impact on performance?
But users can switch to rte_get_tsc_cycles() to avoid the added branch.
On the other hand, did you consider dropping HPET altogether?
--
David Marchand
^ permalink raw reply
* RE: [PATCH 1/2] crypto/ipsec_mb: allow aesni_mb and aesni_gcm vdevs on Arm
From: Hemant Agrawal @ 2026-06-02 12:09 UTC (permalink / raw)
To: Wathsala Vithanage, Kai Ji, Pablo de Lara
Cc: dev@dpdk.org, nd@arm.com, Paul.Elliott@arm.com,
Dhruv.Tripathi@arm.com, Shebu.VargheseKuriakose@arm.com
In-Reply-To: <20260529205512.1985844-1-wathsala.vithanage@arm.com>
> -----Original Message-----
> From: Wathsala Vithanage <wathsala.vithanage@arm.com>
> Sent: 30 May 2026 02:25
> To: Kai Ji <kai.ji@intel.com>; Pablo de Lara <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; nd@arm.com; Paul.Elliott@arm.com;
> Dhruv.Tripathi@arm.com; Shebu.VargheseKuriakose@arm.com; Wathsala
> Vithanage <wathsala.vithanage@arm.com>
> Subject: [PATCH 1/2] crypto/ipsec_mb: allow aesni_mb and aesni_gcm vdevs
> on Arm
>
> Extend Arm PMD gating in ipsec_mb_create() to permit
> IPSEC_MB_PMD_TYPE_AESNI_MB and IPSEC_MB_PMD_TYPE_AESNI_GCM in
> addition to existing SNOW3G and ZUC.
>
> This removes -ENOTSUP rejection for crypto_aesni_mb and crypto_aesni_gcm
> on Arm, enabling these vdevs to probe and run when backed by a compatible
> ipsec-mb library.
>
> Signed-off-by: Wathsala Vithanage <wathsala.vithanage@arm.com>
> ---
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
^ permalink raw reply
* RE: [PATCH 2/2] doc: update Arm IPsec-MB references for cryptodev PMDs
From: Hemant Agrawal @ 2026-06-02 12:10 UTC (permalink / raw)
To: Wathsala Vithanage, Kai Ji, Pablo de Lara
Cc: dev@dpdk.org, nd@arm.com, paul.elliott@arm.com,
dhruv.tripathi@arm.com, shebu.vargheseKuriakose@arm.com
In-Reply-To: <20260529210404.1986896-1-wathsala.vithanage@arm.com>
> -----Original Message-----
> From: Wathsala Vithanage <wathsala.vithanage@arm.com>
> Sent: 30 May 2026 02:34
> To: Kai Ji <kai.ji@intel.com>; Pablo de Lara <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; nd@arm.com; paul.elliott@arm.com;
> dhruv.tripathi@arm.com; shebu.vargheseKuriakose@arm.com; Wathsala
> Vithanage <wathsala.vithanage@arm.com>
> Subject: [PATCH 2/2] doc: update Arm IPsec-MB references for cryptodev
> PMDs
>
> Document Arm/ARM64 IPsec-MB source and supported tag level for
> aesni_mb, aesni_gcm, snow3g, and zuc cryptodev guides.
>
> - Add Arm library reference to aesni_mb and aesni_gcm docs.
> - Update snow3g and zuc IPsec-MB library tag to SECLIB-IPSEC-2026.05.30.
>
> Signed-off-by: Wathsala Vithanage <wathsala.vithanage@arm.com>
> ---
> doc/guides/cryptodevs/aesni_gcm.rst | 4 ++++
> doc/guides/cryptodevs/aesni_mb.rst | 4 ++++
> doc/guides/cryptodevs/snow3g.rst | 2 +-
> doc/guides/cryptodevs/zuc.rst | 2 +-
> 4 files changed, 10 insertions(+), 2 deletions(-)
>
Acked-by: Hemant Agrawal <hemant.agrawal@nxp.com>
^ permalink raw reply
* Re: [RFC PATCH 3/3] build: deprecate HPET build option
From: Bruce Richardson @ 2026-06-02 12:27 UTC (permalink / raw)
To: Morten Brørup; +Cc: dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F658D8@smartserver.smartshare.dk>
On Tue, Jun 02, 2026 at 12:47:00PM +0200, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Tuesday, 2 June 2026 11.09
> >
> > We can enable the building of the HPET code by default on Linux, since
> > the timers are not used - or even initialized - by default. Instead an
> > app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
> > APIs. Therefore, let's simplify the user experience by deprecating the
> > option "use_hpet" and make it a no-op.
> >
> > To avoid issue with the dpdk-test binary which was trying to initialize
> > the hpet on startup, move the hpet init call to the timer autotest -
> > the
> > only place where it was used.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
>
> Careful!
> I think this patch has unintended side effects:
>
> On Linux, it unconditionally enables HPET (and sets RTE_LIBEAL_USE_HPET), which was previously disabled by default.
>
> So, if some Linux applications use #ifdef RTE_LIBEAL_USE_HPET, they will now tell DPDK to use that timer instead of the TSC.
> We can fix the apps/examples in the DPDK repo, but it will potentially change behavior of DPDK user's applications.
>
> I'm not opposed to unconditionally enabling HPET ability in DPDK itself on Linux.
> But I'm worried about side effects of unconditionally enabling #ifdef RTE_LIBEAL_USE_HPET in Linux user applications.
>
Good point, I hadn't considered if end applications had code guarded by
USE_HPET.
However, even if HPET support is build-enabled, it still requires apps to
explicitly opt-in a) to use it and then b) to make it the default for timer
operations. That means that if apps have got the code present to use HPET
by default, then they must have a valid reason for doing so and have
explicitly opted in to doing so by adding the hpet API calls. It's not
possible for apps to "accidentally" start using HPET. [I suppose there may
be a risk from old/legacy code in apps, maybe where hpet was used in the
past and forgotten about, but otherwise I can't see there being an issue.]
More review and testing is welcome though, to ensure I'm not actually
missing something here...
/Bruce
^ permalink raw reply
* Re: [RFC PATCH 3/3] build: deprecate HPET build option
From: Bruce Richardson @ 2026-06-02 12:37 UTC (permalink / raw)
To: David Marchand; +Cc: Morten Brørup, dev
In-Reply-To: <CAJFAV8x5_JihAXe_bruriVu01b5wmF4fJ7vD42yFfNwpJQwDtQ@mail.gmail.com>
On Tue, Jun 02, 2026 at 01:39:42PM +0200, David Marchand wrote:
> On Tue, 2 Jun 2026 at 12:47, Morten Brørup <mb@smartsharesystems.com> wrote:
> >
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Tuesday, 2 June 2026 11.09
> > >
> > > We can enable the building of the HPET code by default on Linux, since
> > > the timers are not used - or even initialized - by default. Instead an
> > > app needs to explicitly call rte_eal_hpet_init() to use the HPET timer
> > > APIs. Therefore, let's simplify the user experience by deprecating the
> > > option "use_hpet" and make it a no-op.
> > >
> > > To avoid issue with the dpdk-test binary which was trying to initialize
> > > the hpet on startup, move the hpet init call to the timer autotest -
> > > the
> > > only place where it was used.
> > >
> > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > ---
> >
> > Careful!
> > I think this patch has unintended side effects:
> >
> > On Linux, it unconditionally enables HPET (and sets RTE_LIBEAL_USE_HPET), which was previously disabled by default.
> >
> > So, if some Linux applications use #ifdef RTE_LIBEAL_USE_HPET, they will now tell DPDK to use that timer instead of the TSC.
> > We can fix the apps/examples in the DPDK repo, but it will potentially change behavior of DPDK user's applications.
> >
> > I'm not opposed to unconditionally enabling HPET ability in DPDK itself on Linux.
> > But I'm worried about side effects of unconditionally enabling #ifdef RTE_LIBEAL_USE_HPET in Linux user applications.
>
> I don't see a functional impact.
>
> There may be an impact on performance?
> But users can switch to rte_get_tsc_cycles() to avoid the added branch.
>
I'd be very surprised if there was an impact from that. Any timers we have
already take a measurable number of cycles, so the extra branch is going to
be unnoticable IMHO.
>
> On the other hand, did you consider dropping HPET altogether?
>
I did, but that I considered a bit riskier and harder to do, as we don't
know who might actually be using it. This was a simple way to get rid of
the unnecessary option without impacting apps.
IIRC the main reason we had HPET off by default was that lots of distro
kernels in the past had the necessary MMAP_HPET support disabled by
default, making it awkward to use - the user had to compile the kernel.
However, I was pleasantly surprised to discover that Ubuntu has it enabled
by default so the HPET now works out of the box, and it's interesting to
see the timer_autotest doing TSC and HPET clock comparisons.
/Bruce
^ permalink raw reply
* RE: [RFC PATCH 3/3] build: deprecate HPET build option
From: Morten Brørup @ 2026-06-02 12:41 UTC (permalink / raw)
To: David Marchand, Bruce Richardson; +Cc: dev
In-Reply-To: <CAJFAV8x5_JihAXe_bruriVu01b5wmF4fJ7vD42yFfNwpJQwDtQ@mail.gmail.com>
> On the other hand, did you consider dropping HPET altogether?
Google AI says that - on modern CPUs - the HPET has no advantages over the TSC.
This supports David's idea.
Suggestion:
Rewrite HPET APIs as a shim to TSC, and deprecate the HPET APIs.
-Morten
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox