Bug 1351
Summary: | Skip test cases based on testbed capabilities | ||
---|---|---|---|
Product: | DPDK | Reporter: | Juraj Linkeš (juraj.linkes) |
Component: | DTS | Assignee: | Juraj Linkeš (juraj.linkes) |
Status: | IN_PROGRESS --- | ||
Severity: | normal | CC: | admin, juraj.linkes, probb, thomas |
Priority: | High | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All |
Description
Juraj Linkeš
2024-01-10 10:38:21 CET
Another thing to consider is making the TG optiona DTS should test no more than DPDK API. Feature capabilities can be checked via some DPDK API. If there is no capability API for some features which are not supported by a hardware, it should be considered a bug. Please do not build any HW database outside of the drivers. (In reply to Thomas Monjalon from comment #2) > DTS should test no more than DPDK API. > Feature capabilities can be checked via some DPDK API. This is what we want to use. Ideally we won't add anything new, just leverage existing APIs to check/list capabilities. I don't know how exactly this works and my wording reflects that. Is there a place where we could learn more (how to use the APIs, what they are etc.)? > If there is no capability API for some features which are not supported by a > hardware, it should be considered a bug. > > Please do not build any HW database outside of the drivers. Each feature category may have a different API to check capabilities. For instance, for rte_flow, the main idea is to "try" with a "validate" call. Metadata have a function rte_eth_rx_metadata_negotiate(). A lot of ethdev capabilities are returned in struct rte_eth_dev_info. etc, etc... Unfortunately it is not unified. For each feature, you need to look for how the capability can be checked. If you feel it is badly documented or something is missing, then consider it is a bug to report. Thank you |