* Re: [dpdk-dev] [PATCH v1 01/12] mldev: introduce machine learning device library
@ 2023-02-03 20:18 2% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-02-03 20:18 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Shivah Shankar Shankar Narayan Rao, Jerin Jacob Kollanukkaran,
dev, Bruce Richardson, Srikanth Yalavarthi, ferruh.yigit,
ajit.khaparde, aboyer, andrew.rybchenko, beilei.xing, chas3,
chenbo.xia, ciara.loftus, Devendra Singh Rawat, ed.czeck,
evgenys, grive, g.singh, zhouguoyang, haiyue.wang, Harman Kalra,
heinrich.kuhn, hemant.agrawal, hyonkim, igorch, Igor Russkikh,
jgrajcia, jasvinder.singh, jianwang, jiawenwu, jingjing.wu,
johndale, john.miller, linville, keith.wiles,
Kiran Kumar Kokkilagadda, oulijun, Liron Himi, longli, mw,
spinler, matan, matt.peters, maxime.coquelin, mk, humin29,
Pradeep Kumar Nalla, Nithin Kumar Dabilpuram, qiming.yang,
qi.z.zhang, Radha Chintakuntla, rahul.lakkireddy, Rasesh Mody,
rosen.xu, sachin.saxena, Satha Koteswara Rao Kottidi,
Shahed Shaikh, shaibran, shepard.siegel, asomalap, somnath.kotur,
sthemmin, steven.webster, Sunil Kumar Kori, mtetsuyah,
Veerasenareddy Burru, viacheslavo, xiao.w.wang,
cloud.wangxiaoyun, yisen.zhuang, yongwang, xuanziyang2,
Prasun Kapoor, Nadav Haklai, Satananda Burla,
Narayana Prasad Raju Athreya, Akhil Goyal, mdr, dmitry.kozliuk,
anatoly.burakov, cristian.dumitrescu, honnappa.nagarahalli,
mattias.ronnblom, ruifeng.wang, drc, konstantin.ananyev,
olivier.matz, jay.jayatheerthan, Ashwin Sekhar T K,
Pavan Nikhilesh Bhagavatula, eagostini, Derek Chickles,
Parijat Shukla, Anup Prabhu, Prince Takkar, david.marchand
03/02/2023 18:33, Stephen Hemminger:
> On Fri, 03 Feb 2023 09:42:45 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 03/02/2023 01:25, Stephen Hemminger:
> > > On Wed, 1 Feb 2023 13:34:41 +0000
> > > Shivah Shankar Shankar Narayan Rao <sshankarnara@marvell.com> wrote:
> > >
> > > > --- a/lib/eal/include/rte_log.h
> > > > +++ b/lib/eal/include/rte_log.h
> > > > @@ -48,6 +48,7 @@ extern "C" {
> > > > #define RTE_LOGTYPE_EFD 18 /**< Log related to EFD. */
> > > > #define RTE_LOGTYPE_EVENTDEV 19 /**< Log related to eventdev. */
> > > > #define RTE_LOGTYPE_GSO 20 /**< Log related to GSO. */
> > > > +#define RTE_LOGTYPE_MLDEV 21 /**< Log related to mldev. */
> > >
> > > NAK to this part.
> > > No new static logtypes please.
> >
> > Good catch.
> > By the way, we should remove unused RTE_LOGTYPE_*.
>
> Yes, for 23.11 would like to work down the list.
Do we need to wait 23.11?
It is not an ABI breakage.
And most of these defines are already unused.
^ permalink raw reply [relevance 2%]
* Re: [PATCH] eal: introduce atomics abstraction
2023-02-02 20:44 0% ` Morten Brørup
@ 2023-02-03 13:56 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-02-03 13:56 UTC (permalink / raw)
To: Morten Brørup
Cc: Tyler Retzlaff, Honnappa Nagarahalli, thomas, dev,
david.marchand, jerinj, konstantin.ananyev, ferruh.yigit, nd
On Thu, Feb 02, 2023 at 09:44:52PM +0100, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Thursday, 2 February 2023 20.00
> >
> > On Thu, Feb 02, 2023 at 09:43:58AM +0100, Morten Brørup wrote:
> > > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > > Sent: Wednesday, 1 February 2023 22.41
> > > >
> > > > On Wed, Feb 01, 2023 at 01:07:59AM +0000, Honnappa Nagarahalli
> > wrote:
> > > > >
> > > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > > Sent: Tuesday, January 31, 2023 4:42 PM
> > > > > >
> > > > > > Honnappa, please could you give your view on the future of
> > atomics
> > > > in DPDK?
> > > > > Thanks Thomas, apologies it has taken me a while to get to this
> > > > discussion.
> > > > >
> > > > > IMO, we do not need DPDK's own abstractions. APIs from
> > stdatomic.h
> > > > (stdatomics as is called here) already serve the purpose. These
> > APIs
> > > > are well understood and documented.
> > > >
> > > > i agree that whatever atomics APIs we advocate for should align
> > with
> > > > the
> > > > standard C atomics for the reasons you state including implied
> > > > semantics.
> > > >
> > > > >
> > > > > For environments where stdatomics are not supported, we could
> > have a
> > > > stdatomic.h in DPDK implementing the same APIs (we have to support
> > only
> > > > _explicit APIs). This allows the code to use stdatomics APIs and
> > when
> > > > we move to minimum supported standard C11, we just need to get rid
> > of
> > > > the file in DPDK repo.
> > >
> > > Perhaps we can use something already existing, such as this:
> > > https://android.googlesource.com/platform/bionic/+/lollipop-
> > release/libc/include/stdatomic.h
> > >
> > > >
> > > > my concern with this is that if we provide a stdatomic.h or
> > introduce
> > > > names
> > > > from stdatomic.h it's a violation of the C standard.
> > > >
> > > > references:
> > > > * ISO/IEC 9899:2011 sections 7.1.2, 7.1.3.
> > > > * GNU libc manual
> > > > https://www.gnu.org/software/libc/manual/html_node/Reserved-
> > > > Names.html
> > > >
> > > > in effect the header, the names and in some instances namespaces
> > > > introduced
> > > > are reserved by the implementation. there are several reasons in
> > the
> > > > GNU libc
> > > > manual that explain the justification for these reservations and if
> > > > if we think about ODR and ABI compatibility we can conceive of
> > others.
> > >
> > > I we are going to move to C11 soon, I consider the shim interim, and
> > am inclined to ignore these warning factors.
> > >
> > > If we are not moving to C11 soon, I would consider these
> > disadvantages more seriously.
> >
> > I think it's reasonable to assume that we are talking years here.
> >
> > We've had a few discussions about minimum C standard. I think my first
> > mailing list exchanges about C99 was almost 2 years ago. Given that we
> > still aren't on C99 now (though i know Bruce has a series up) indicates
> > that progression to C11 isn't going to happen any time soon and even if
> > it was the baseline we still can't just use it (reasons described
> > later).
> >
> > Also, i'll point out that we seem to have accepted moving to C99 with
> > one of the holdback compilers technically being non-conformant but it
> > isn't blocking us because it provides the subset of C99 features
> > without
> > being conforming that we happen to be using.
> >
> > >
> > > >
> > > > i'll also remark that the inter-mingling of names from the POSIX
> > > > standard implicitly exposed as a part of the EAL public API has
> > been
> > > > problematic for portability.
> > >
> > > This is a very important remark, which should be considered
> > carefully! Tyler has firsthand experience with DPDK portability. If he
> > thinks porting to Windows is going to be a headache if we expose the
> > stdatomic.h API, we must listen! So, what is your gut feeling here,
> > Tyler?
> >
> > I think this is even more of a concern with language standard than it
> > is
> > with a platform standard. Because the language standard is used across
> > platforms.
> >
> > On the surface it looks appealing to just go through all the dpdk code
> > one last time and #include <stdatomic.h> and directly depend on names
> > that "look" standard. In practice though we aren't depending on the
> > toolchain / libc surface we are binding ourselves to the shim and the
> > implementation it provides.
> >
> > This is aside from the mechanics of making it work in the different
> > contexts we now have to care about. Here is a story of how things
> > become tricky.
> >
> > When i #include <stdatomic.h> which one gets used if the implementation
> > provides one? Let's force our stdatomic.h
> >
> > Now i need to force the build system to prefer my shim header? Keeping
> > in mind that the presence of a libc stdatomic.h does not mean that the
> > toolchain in fact supports standard atomics. Okay, that's under our
> > control by editing some meson.build files maybe it isn't so bad but...
> >
> > It seems my application also has to do the same in their build system
> > now because...
> >
> > The type definitions (size, alignment) and code generated from the
> > body of inline functions as seen by the application built translation
> > units may differ from those in the dpdk translation units if they don't
> > use our header. The potential for ABI compat problems is increasing but
> > maybe it is managable? it can be worse...
> >
> > We can't limit our scope to thinking that there is just an
> > application (a single binary) and dpdk. Complex applications will
> > invariably depend on other libraries and if the application needs to
> > interface with those compatibily at the ABI level using standard
> > atomics
> > then we've made it very difficult since the application has to choose
> > to
> > use our conflicting named atomic types which may not be compatible or
> > the real standard atomics. They can of course produce horrible shims
> > of their own to interoperate.
> >
> > We need consistency across the entire binary at runtime and i don't
> > think it's practical to say that anyone who uses dpdk has to compile
> > their whole world with our shim. So dealing with all this complexity
> > for the sake of asthetics "looking" like the standard api seems kind
> > of not worth it. Sure it saves having to deprecate later and one last
> > session of shotgun surgery but that's kind of all we get.
> >
> > Don't think i'm being biased in favor of windows/msvc here. From the
> > perspective of the windows/msvc combination i intend to use only the
> > standard C ABI provided by the implementation. I have no intention of
> > trying to introduce support for the current ABI that doesn't use the
> > standard atomic types. my discouraging of this approach is about
> > avoiding
> > subtle to detect but very painful problems on
> > {linux,unix}/compiler<version>
> > combinations that already have a shipped/stable ABI.
> >
> > > >
> > > > let's discuss this from here. if there's still overwhelming desire
> > to
> > > > go
> > > > this route then we'll just do our best.
> > > >
> > > > ty
> > >
> > > I have a preference for exposing the stdatomic.h API. Tyler listed
> > the disadvantages above. (I also have a preference for moving to C11
> > soon.)
> >
> > I am eager to see this happen, but as explained in my original proposal
> > it doesn't eliminate the need for an abstraction. Unless we are willing
> > to break our compatibility promises and potentially take a performance
> > hit on some platform/compiler combinations which as i understand is not
> > acceptable.
> >
> > >
> > > Exposing a 1:1 similar API with RTE prefixes would also be acceptable
> > for me. The disadvantage is that the names are different than the C11
> > names, which might lead to some confusion. And from an ABI stability
> > perspective, such an important API should not be marked experimental.
> > This means that years will pass before we can get rid of it again, due
> > to ABI stability policies.
> >
> > I think the key to success with rte_ prefixed names is making
> > absolutely
> > sure we mirror the semantics and types in the standard.
> >
> > I will point out one bit of fine print here is that we will not support
> > atomic operations on struct/union types (something the standard
> > supports).
> > With the rte_ namespace i think this becomes less ambiguous, if we
> > present
> > standard C names though what's to avoid the confusion? Aside from it
> > fails
> > to compile with one compiler vs another.
> >
> > I agree that this may be around for years. But how many years depends a
> > lot on how long we have to maintain compatibility for the existing
> > platform/compiler combinations that can't (and aren't enabled) to use
> > the standard.
> >
> > Even if we introduced standard names we still have to undergo some kind
> > of mutant deprecation process to get the world to recompile everything
> > against the actual standard, so it doesn't give us forward
> > compatibility.
> >
> > Let me know what folks would like to do, i guess i'm firmly leaned
> > toward no-shim and just rte_ explicit. But as a community i'll pursue
> > whatever you decide.
> >
> > Thanks!
>
> Tyler is making a very strong case here.
>
> I have changed my mind, and now support Tyler's approach.
>
Having read through the whole thread a second time, I am starting to
realise how complex a problem this could be. From what I read, I would tend
towards the opinion that we shouldn't provide any atomics in DPDK at all,
and just rely on the C standard ones. The main complication in any solution
I suspect is going to be the use of atomics in static inline functions we
have in our header files.
/Bruce
^ permalink raw reply [relevance 0%]
* [PATCH v4 1/2] ethdev: introduce the PHY affinity field in Tx queue API
@ 2023-02-03 13:33 6% ` Jiawei Wang
0 siblings, 0 replies; 200+ results
From: Jiawei Wang @ 2023-02-03 13:33 UTC (permalink / raw)
To: viacheslavo, orika, thomas, andrew.rybchenko, Aman Singh,
Yuying Zhang, Ferruh Yigit
Cc: dev, rasland
When multiple physical ports are connected to a single DPDK port,
(example: kernel bonding, DPDK bonding, failsafe, etc.),
we want to know which physical port is used for Rx and Tx.
This patch maps a DPDK Tx queue with a physical port,
by adding tx_phy_affinity setting in Tx queue.
The affinity number is the physical port ID where packets will be
sent.
Value 0 means no affinity and traffic could be routed to any
connected physical ports, this is the default current behavior.
The number of physical ports is reported with rte_eth_dev_info_get().
The new tx_phy_affinity field is added into the padding hole of
rte_eth_txconf structure, the size of rte_eth_txconf keeps the same.
An ABI check rule needs to be added to avoid false warning.
Add the testpmd command line:
testpmd> port config (port_id) txq (queue_id) phy_affinity (value)
For example, there're two physical ports connected to
a single DPDK port (port id 0), and phy_affinity 1 stood for
the first physical port and phy_affinity 2 stood for the second
physical port.
Use the below commands to config tx phy affinity for per Tx Queue:
port config 0 txq 0 phy_affinity 1
port config 0 txq 1 phy_affinity 1
port config 0 txq 2 phy_affinity 2
port config 0 txq 3 phy_affinity 2
These commands config the Tx Queue index 0 and Tx Queue index 1 with
phy affinity 1, uses Tx Queue 0 or Tx Queue 1 send packets,
these packets will be sent from the first physical port, and similar
with the second physical port if sending packets with Tx Queue 2
or Tx Queue 3.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
---
app/test-pmd/cmdline.c | 100 ++++++++++++++++++++
app/test-pmd/config.c | 1 +
devtools/libabigail.abignore | 5 +
doc/guides/rel_notes/release_23_03.rst | 4 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 +++
lib/ethdev/rte_ethdev.h | 10 ++
6 files changed, 133 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index cb8c174020..f771fcf8ac 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -776,6 +776,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
" Cleanup txq mbufs for a specific Tx queue\n\n"
+
+ "port config (port_id) txq (queue_id) phy_affinity (value)\n"
+ " Set the physical affinity value "
+ "on a specific Tx queue\n\n"
);
}
@@ -12633,6 +12637,101 @@ static cmdline_parse_inst_t cmd_show_port_flow_transfer_proxy = {
}
};
+/* *** configure port txq phy_affinity value *** */
+struct cmd_config_tx_phy_affinity {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t config;
+ portid_t portid;
+ cmdline_fixed_string_t txq;
+ uint16_t qid;
+ cmdline_fixed_string_t phy_affinity;
+ uint8_t value;
+};
+
+static void
+cmd_config_tx_phy_affinity_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_config_tx_phy_affinity *res = parsed_result;
+ struct rte_eth_dev_info dev_info;
+ struct rte_port *port;
+ int ret;
+
+ if (port_id_is_invalid(res->portid, ENABLED_WARN))
+ return;
+
+ if (res->portid == (portid_t)RTE_PORT_ALL) {
+ printf("Invalid port id\n");
+ return;
+ }
+
+ port = &ports[res->portid];
+
+ if (strcmp(res->txq, "txq")) {
+ printf("Unknown parameter\n");
+ return;
+ }
+ if (tx_queue_id_is_invalid(res->qid))
+ return;
+
+ ret = eth_dev_info_get_print_err(res->portid, &dev_info);
+ if (ret != 0)
+ return;
+
+ if (dev_info.nb_phy_ports == 0) {
+ printf("Number of physical ports is 0 which is invalid for PHY Affinity\n");
+ return;
+ }
+ printf("The number of physical ports is %u\n", dev_info.nb_phy_ports);
+ if (dev_info.nb_phy_ports < res->value) {
+ printf("The PHY affinity value %u is Invalid, exceeds the "
+ "number of physical ports\n", res->value);
+ return;
+ }
+ port->txq[res->qid].conf.tx_phy_affinity = res->value;
+
+ cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ port, "port");
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_config =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ config, "config");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_portid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_txq =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_qid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_hwport =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ phy_affinity, "phy_affinity");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_value =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ value, RTE_UINT8);
+
+static cmdline_parse_inst_t cmd_config_tx_phy_affinity = {
+ .f = cmd_config_tx_phy_affinity_parsed,
+ .data = (void *)0,
+ .help_str = "port config <port_id> txq <queue_id> phy_affinity <value>",
+ .tokens = {
+ (void *)&cmd_config_tx_phy_affinity_port,
+ (void *)&cmd_config_tx_phy_affinity_config,
+ (void *)&cmd_config_tx_phy_affinity_portid,
+ (void *)&cmd_config_tx_phy_affinity_txq,
+ (void *)&cmd_config_tx_phy_affinity_qid,
+ (void *)&cmd_config_tx_phy_affinity_hwport,
+ (void *)&cmd_config_tx_phy_affinity_value,
+ NULL,
+ },
+};
+
/* ******************************************************************************** */
/* list of instructions */
@@ -12866,6 +12965,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_show_port_cman_capa,
(cmdline_parse_inst_t *)&cmd_show_port_cman_config,
(cmdline_parse_inst_t *)&cmd_set_port_cman_config,
+ (cmdline_parse_inst_t *)&cmd_config_tx_phy_affinity,
NULL,
};
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index acccb6b035..b83fb17cfa 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -936,6 +936,7 @@ port_infos_display(portid_t port_id)
printf("unknown\n");
break;
}
+ printf("Current number of physical ports: %u\n", dev_info.nb_phy_ports);
}
void
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..ac7d3fb2da 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -34,3 +34,8 @@
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+
+; Ignore fields inserted in padding hole of rte_eth_txconf
+[suppress_type]
+ name = rte_eth_txconf
+ has_data_member_inserted_between = {offset_of(tx_deferred_start), offset_of(offloads)}
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index 73f5d94e14..e99bd2dcb6 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -55,6 +55,10 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added affinity for multiple physical ports connected to a single DPDK port.**
+
+ * Added Tx affinity in queue setup to map a physical port.
+
* **Updated AMD axgbe driver.**
* Added multi-process support.
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 79a1fa9cb7..5c716f7679 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1605,6 +1605,19 @@ Enable or disable a per queue Tx offloading only on a specific Tx queue::
This command should be run when the port is stopped, or else it will fail.
+config per queue Tx physical affinity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Configure a per queue physical affinity value only on a specific Tx queue::
+
+ testpmd> port (port_id) txq (queue_id) phy_affinity (value)
+
+* ``phy_affinity``: physical port to use for sending,
+ when multiple physical ports are connected to
+ a single DPDK port.
+
+This command should be run when the port is stopped, otherwise it fails.
+
Config VXLAN Encap outer layers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index c129ca1eaf..2fd971b7b5 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1138,6 +1138,14 @@ struct rte_eth_txconf {
less free descriptors than this value. */
uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
+ /**
+ * Affinity with one of the multiple physical ports connected to the DPDK port.
+ * Value 0 means no affinity and traffic could be routed to any connected
+ * physical port.
+ * The first physical port is number 1 and so on.
+ * Number of physical ports is reported by nb_phy_ports in rte_eth_dev_info.
+ */
+ uint8_t tx_phy_affinity;
/**
* Per-queue Tx offloads to be set using RTE_ETH_TX_OFFLOAD_* flags.
* Only offloads set on tx_queue_offload_capa or tx_offload_capa
@@ -1744,6 +1752,8 @@ struct rte_eth_dev_info {
/** Device redirection table size, the total number of entries. */
uint16_t reta_size;
uint8_t hash_key_size; /**< Hash key size in bytes */
+ /** Number of physical ports connected with DPDK port. */
+ uint8_t nb_phy_ports;
/** Bit mask of RSS offloads, the bit offset also means flow type */
uint64_t flow_type_rss_offloads;
struct rte_eth_rxconf default_rxconf; /**< Default Rx configuration */
--
2.18.1
^ permalink raw reply [relevance 6%]
* Re: [PATCH] eal: introduce atomics abstraction
2023-02-02 19:00 4% ` Tyler Retzlaff
2023-02-02 20:44 0% ` Morten Brørup
@ 2023-02-03 12:19 0% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-02-03 12:19 UTC (permalink / raw)
To: Tyler Retzlaff
Cc: Morten Brørup, Honnappa Nagarahalli, thomas, dev,
david.marchand, jerinj, konstantin.ananyev, ferruh.yigit, nd
On Thu, Feb 02, 2023 at 11:00:23AM -0800, Tyler Retzlaff wrote:
> On Thu, Feb 02, 2023 at 09:43:58AM +0100, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > Sent: Wednesday, 1 February 2023 22.41
> > >
> > > On Wed, Feb 01, 2023 at 01:07:59AM +0000, Honnappa Nagarahalli wrote:
> > > >
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > Sent: Tuesday, January 31, 2023 4:42 PM
> > > > >
> > > > > Honnappa, please could you give your view on the future of atomics
> > > in DPDK?
> > > > Thanks Thomas, apologies it has taken me a while to get to this
> > > discussion.
> > > >
> > > > IMO, we do not need DPDK's own abstractions. APIs from stdatomic.h
> > > (stdatomics as is called here) already serve the purpose. These APIs
> > > are well understood and documented.
> > >
> > > i agree that whatever atomics APIs we advocate for should align with
> > > the
> > > standard C atomics for the reasons you state including implied
> > > semantics.
> > >
> > > >
> > > > For environments where stdatomics are not supported, we could have a
> > > stdatomic.h in DPDK implementing the same APIs (we have to support only
> > > _explicit APIs). This allows the code to use stdatomics APIs and when
> > > we move to minimum supported standard C11, we just need to get rid of
> > > the file in DPDK repo.
> >
> > Perhaps we can use something already existing, such as this:
> > https://android.googlesource.com/platform/bionic/+/lollipop-release/libc/include/stdatomic.h
> >
> > >
> > > my concern with this is that if we provide a stdatomic.h or introduce
> > > names
> > > from stdatomic.h it's a violation of the C standard.
> > >
> > > references:
> > > * ISO/IEC 9899:2011 sections 7.1.2, 7.1.3.
> > > * GNU libc manual
> > > https://www.gnu.org/software/libc/manual/html_node/Reserved-
> > > Names.html
> > >
> > > in effect the header, the names and in some instances namespaces
> > > introduced
> > > are reserved by the implementation. there are several reasons in the
> > > GNU libc
> > > manual that explain the justification for these reservations and if
> > > if we think about ODR and ABI compatibility we can conceive of others.
> >
> > I we are going to move to C11 soon, I consider the shim interim, and am inclined to ignore these warning factors.
> >
> > If we are not moving to C11 soon, I would consider these disadvantages more seriously.
>
> I think it's reasonable to assume that we are talking years here.
>
> We've had a few discussions about minimum C standard. I think my first
> mailing list exchanges about C99 was almost 2 years ago. Given that we
> still aren't on C99 now (though i know Bruce has a series up) indicates
> that progression to C11 isn't going to happen any time soon and even if
> it was the baseline we still can't just use it (reasons described
> later).
>
> Also, i'll point out that we seem to have accepted moving to C99 with
> one of the holdback compilers technically being non-conformant but it
> isn't blocking us because it provides the subset of C99 features without
> being conforming that we happen to be using.
>
What compiler is this? As far as I know, all our currently support
compilers claim to support C99 fully. All should support C11 also,
except for GCC 4.8 on RHEL/CentOS 7. Once we drop support for Centos 7, I
think we can require at minimum a c11 compiler for building DPDK itself.
I'm still a little uncertain about requiring that users build their own
code with -std=c11, though.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: Sign changes through function signatures
2023-02-02 21:26 3% ` Morten Brørup
@ 2023-02-03 12:05 4% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-02-03 12:05 UTC (permalink / raw)
To: Morten Brørup
Cc: Thomas Monjalon, Ben Magistro, Tyler Retzlaff, Olivier Matz,
ferruh.yigit, andrew.rybchenko, ben.magistro, dev,
Stefan Baranoff, david.marchand, anatoly.burakov
On Thu, Feb 02, 2023 at 10:26:48PM +0100, Morten Brørup wrote:
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Thursday, 2 February 2023 21.45
> >
> > 02/02/2023 21:26, Tyler Retzlaff:
> > > On Thu, Feb 02, 2023 at 02:23:39PM -0500, Ben Magistro wrote:
> > > > Hello,
> > > >
> > > > While making some updates to our code base for 22.11.1 that were
> > missed in
> > > > our first pass through, we hit the numa node change[1]. In the
> > process of
> > > > updating our code, we noticed that a couple functions
> > (rx/tx_queue_setup,
> > > > maybe more that we aren't using) state they accept `SOCKET_ID_ANY`
> > but the
> > > > function signature then asks for an unsigned integer while
> > `SOCKET_ID_ANY`
> > > > is `-1`. Following it through the redirect to the "real" function
> > it also
> > > > asks for an unsigned integer which is then passed on to one or more
> > > > functions asking for an integer. As an example using the the i40e
> > driver
> > > > -- we would call `rte_eth_tx_queue_setup` [2] which ultimately
> > calls
> > > > `i40e_dev_tx_queue_setup`[3] which finally calls
> > `rte_zmalloc_socket`[4]
> > > > and `rte_eth_dma_zone_reserve`[5].
> > > >
> > > > I guess what I am looking for is clarification on if this is
> > intentional or
> > > > if this is additional cleanup that may need to be completed/be
> > desirable so
> > > > that signs are maintained through the call paths and avoid
> > potentially
> > > > producing sign-conversion warnings. From the very quick glance I
> > took at
> > > > the i40e driver, it seems these are just passed through to other
> > functions
> > > > and no direct use/manipulation occurs (at least in the mentioned
> > functions).
> > >
> > > i believe this is just sloppyness with sign in our api surface. i too
> > > find it frustrating that use of these api force either explicit
> > > casts or suffer having to suppress warnings.
> > >
> > > in the past examples of this have been cleaned up without full
> > deprecation
> > > notices but there are a lot of instances. i also feel (unpopular
> > opinion)
> > > that for some integer types like this that have constrained range /
> > number
> > > spaces it would be of value to introduce a typedef that can be used
> > > consistently.
> > >
> > > for now you'll just have to add the casts and hopefully in the future
> > we
> > > will fix the api making them unnecessary. of course feel free to
> > submit
> > > patches too, it would be great to have these cleaned up.
> >
> > I agree it should be cleaned up.
> > Those IDs should accept negative values.
> > Not sure which type we should choose (int, int32_t, or a typedef).
>
> Why would we use a signed socket ID? We don't use signed port IDs. To me, unsigned seems the way to go. (A minor detail: With unsigned we can use the entire range of values minus one (for the magic "any" value), whereas with signed we can only use the positive range of values. This detail is completely irrelevant when using 32 bit for socket ID, but could be relevant if using fewer bits.)
>
> Also, we don't need 32 bit for socket ID. 8 or 16 bit should suffice, like port ID. But reducing from 32 bit would probably cause major ABI breakage.
>
> >
> > Another thing to check is the name of the variable.
> > It should be a socket ID when talking about CPU,
> > and a NUMA node ID when talking about memory.
> >
> > And last but not the least,
> > how can we keep ABI compatibility?
> > I hope we can use function versioning to avoid deprecation and
> > breaking.
> >
> > Trials and suggestions are welcome.
>
> Signedness is not the only problem with the socket ID. The meaning of SOCKET_ID_ANY is excessively overloaded. If we want to clean this up, we should consider the need for another magic value SOCKET_ID_NONE for devices connected to the chipset, as discussed in this other email thread [1]. And as discussed there, there are also size problems, because some device structures use 8 bit to hold the socket ID.
>
> And functions should always return -1, never SOCKET_ID_ANY, to indicate error.
>
> [1]: http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87684@smartserver.smartshare.dk/
>
> I only bring warnings and complications to the discussion here, no solutions. Sorry! :-(
>
Personally, I think if we are going to change things, we should do things
properly, especially/even if we are going to have to break ABI or use ABI
compatibility.
I would suggest rather than a typedef, we should actually wrap the int
value in a struct - for two reasons:
* it means the compiler will actually error out for us if an int or
unsigned int is used instead. This allow easier fixing at compile-time
rather than hoping things are correctly specified in existing code.
* it allows us to do things like explicitly calling out flags, rather than
just using magic values. While still keeping the size 32 bits, we can
have the actual socket value as 16-bits and have flags to indicate:
- ANY socket, NO socket, INVALID value socket. This could end up being
useful in many cases, for example, when allocating memory we could
specify a socket number with the ANY flag, indicating that any socket is
ok, but we'd ideally prefer the number specified.
As for socket id, and numa id, I'm not sure we should have different
names/types for the two. For example, for PCI devices, do they need a third
type or are they associated with cores or with memory? The socket id for
the core only matters in terms of data locality, i.e. what memory or cache
location it is in. Therefore, for me, I'd pick one name and stick with it.
/Bruce
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-02-02 16:12 0% ` Naga Harish K, S V
@ 2023-02-03 9:44 0% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2023-02-03 9:44 UTC (permalink / raw)
To: Naga Harish K, S V
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Thu, Feb 2, 2023 at 9:42 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Monday, January 30, 2023 8:13 PM
> > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> > Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> > Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Mon, Jan 30, 2023 at 3:26 PM Naga Harish K, S V
> > <s.v.naga.harish.k@intel.com> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Saturday, January 28, 2023 4:24 PM
> > > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > > Cc: jerinj@marvell.com; Carrillo, Erik G
> > > > <erik.g.carrillo@intel.com>; Gujjar, Abhinandan S
> > > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > > <jay.jayatheerthan@intel.com>
> > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> > > >
> > > > On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
> > > > <s.v.naga.harish.k@intel.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > >
> > > > > > > > >
> > > > > > > > > > > + */
> > > > > > > > > > > + uint32_t rsvd[15];
> > > > > > > > > > > + /**< Reserved fields for future use */
> > > > > > > > > >
> > > > > > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init()
> > > > > > > > > > to
> > > > > > make
> > > > > > > > > > sure rsvd is zero.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > The reserved fields are not used by the adapter or application.
> > > > > > > > > Not sure Is it necessary to Introduce a new API to clear
> > > > > > > > > reserved
> > > > fields.
> > > > > > > >
> > > > > > > > When adapter starts using new fileds(when we add new fieds
> > > > > > > > in future), the old applicaiton which is not using
> > > > > > > > rte_event_eth_rx_adapter_runtime_params_init() may have
> > junk
> > > > > > > > value and then adapter implementation will behave bad.
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > does it mean, the application doesn't re-compile for the new DPDK?
> > > > > >
> > > > > > Yes. No need recompile if ABI not breaking.
> > > > > >
> > > > > > > When some of the reserved fields are used in the future, the
> > > > > > > application
> > > > > > also may need to be recompiled along with DPDK right?
> > > > > > > As the application also may need to use the newly consumed
> > > > > > > reserved
> > > > > > fields?
> > > > > >
> > > > > > The problematic case is:
> > > > > >
> > > > > > Adapter implementation of 23.07(Assuming there is change params)
> > > > > > field needs to work with application of 23.03.
> > > > > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > > > > >
> > > > >
> > > > > As rte_event_eth_rx_adapter_runtime_params_init() initializes only
> > > > reserved fields to zero, it may not solve the issue in this case.
> > > >
> > > > rte_event_eth_rx_adapter_runtime_params_init() needs to zero all
> > > > fields, not just reserved field.
> > > > The application calling sequence is
> > > >
> > > > struct my_config c;
> > > > rte_event_eth_rx_adapter_runtime_params_init(&c)
> > > > c.interseted_filed_to_be_updated = val;
> > > >
> > > Can it be done like
> > > struct my_config c = {0};
> > > c.interseted_filed_to_be_updated = val; and update Doxygen
> > > comments to recommend above usage to reset all fields?
> > > This way, rte_event_eth_rx_adapter_runtime_params_init() can be
> > avoided.
> >
> > Better to have a function for documentation clarity. Similar scheme already
> > there in DPDK. See rte_eth_cman_config_init()
> >
> >
>
>
> The reference function rte_eth_cman_config_init() is resetting the params struct and initializing the required params with default values in the pmd cb.
No need for PMD cb.
> The proposed rte_event_eth_rx_adapter_runtime_params_init () API just needs to reset the params struct. There are no pmd CBs involved.
> Having an API just to reset the struct seems overkill. What do you think?
It is slow path API. Keeping it as function is better. Also, it helps
the documentations of config parm in
rte_event_eth_rx_adapter_runtime_params_config()
like, This structure must be initialized with
rte_event_eth_rx_adapter_runtime_params_init() or so.
>
> > >
> > > > Let me share an example and you can tell where is the issue
> > > >
> > > > 1)Assume parameter structure is 64B and for 22.03 8B are used.
> > > > 2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
> > > > 3)There is an application written based on 22.03 which using only 8B
> > > > after calling rte_event_eth_rx_adapter_runtime_params_init()
> > > > 4)Assume, in 22.07 another 8B added to structure.
> > > > 5)Now, the application (3) needs to run on 22.07. Since the
> > > > application is calling
> > > > rte_event_eth_rx_adapter_runtime_params_init()
> > > > and 9 to 15B are zero, the implementation will not go bad.
> > > >
> > > > > The old application only tries to set/get previous valid fields
> > > > > and the newly
> > > > used fields may still contain junk value.
> > > > > If the application wants to make use of any the newly used params,
> > > > > the
> > > > application changes are required anyway.
> > > >
> > > > Yes. If application wants to make use of newly added features. No
> > > > need to change if new features are not needed for old application.
^ permalink raw reply [relevance 0%]
* [PATCH v5 2/3] graph: pcap capture for graph nodes
2023-02-03 8:19 4% ` [PATCH v5 1/3] pcapng: comment option support for epb Amit Prakash Shukla
@ 2023-02-03 8:19 2% ` Amit Prakash Shukla
0 siblings, 0 replies; 200+ results
From: Amit Prakash Shukla @ 2023-02-03 8:19 UTC (permalink / raw)
To: Jerin Jacob, Kiran Kumar K, Nithin Dabilpuram, Anatoly Burakov
Cc: dev, Amit Prakash Shukla
Implementation adds support to capture packets at each node with
packet metadata and node name.
Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
---
v2:
- Fixed code style issue
- Fixed CI compilation issue on github-robot
v3:
- Code review suggestion from Stephen
- Fixed potential memory leak
v4:
- Code review suggestion from Jerin
v5:
- Code review suggestion from Jerin
doc/guides/rel_notes/release_23_03.rst | 7 +
lib/graph/graph.c | 17 +-
lib/graph/graph_pcap.c | 216 +++++++++++++++++++++++++
lib/graph/graph_pcap_private.h | 116 +++++++++++++
lib/graph/graph_populate.c | 12 +-
lib/graph/graph_private.h | 5 +
lib/graph/meson.build | 3 +-
lib/graph/rte_graph.h | 5 +
lib/graph/rte_graph_worker.h | 9 ++
9 files changed, 387 insertions(+), 3 deletions(-)
create mode 100644 lib/graph/graph_pcap.c
create mode 100644 lib/graph/graph_pcap_private.h
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index dab62508c4..e709df8b53 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -78,6 +78,10 @@ New Features
``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
required for eth_rx, eth_tx, crypto and timer eventdev adapters.
+* **Added pcap trace support in graph library.**
+
+ * Added support to capture packets at each graph node with packet metadata and
+ node name.
Removed Items
-------------
@@ -110,6 +114,9 @@ API Changes
* Experimental function ``rte_pcapng_copy`` was updated to support comment
section in enhanced packet block in pcapng library.
+* Experimental structures ``struct rte_graph_param``, ``struct rte_graph`` and
+ ``struct graph`` were updated to support pcap trace in graph library.
+
ABI Changes
-----------
diff --git a/lib/graph/graph.c b/lib/graph/graph.c
index 3a617cc369..a839a2803b 100644
--- a/lib/graph/graph.c
+++ b/lib/graph/graph.c
@@ -15,6 +15,7 @@
#include <rte_string_fns.h>
#include "graph_private.h"
+#include "graph_pcap_private.h"
static struct graph_head graph_list = STAILQ_HEAD_INITIALIZER(graph_list);
static rte_spinlock_t graph_lock = RTE_SPINLOCK_INITIALIZER;
@@ -228,7 +229,12 @@ graph_mem_fixup_node_ctx(struct rte_graph *graph)
node_db = node_from_name(name);
if (node_db == NULL)
SET_ERR_JMP(ENOLINK, fail, "Node %s not found", name);
- node->process = node_db->process;
+
+ if (graph->pcap_enable) {
+ node->process = graph_pcap_dispatch;
+ node->original_process = node_db->process;
+ } else
+ node->process = node_db->process;
}
return graph;
@@ -242,6 +248,9 @@ graph_mem_fixup_secondary(struct rte_graph *graph)
if (graph == NULL || rte_eal_process_type() == RTE_PROC_PRIMARY)
return graph;
+ if (graph_pcap_file_open(graph->pcap_filename) || graph_pcap_mp_init())
+ graph_pcap_exit(graph);
+
return graph_mem_fixup_node_ctx(graph);
}
@@ -323,11 +332,17 @@ rte_graph_create(const char *name, struct rte_graph_param *prm)
if (graph_has_isolated_node(graph))
goto graph_cleanup;
+ /* Initialize pcap config. */
+ graph_pcap_enable(prm->pcap_enable);
+
/* Initialize graph object */
graph->socket = prm->socket_id;
graph->src_node_count = src_node_count;
graph->node_count = graph_nodes_count(graph);
graph->id = graph_id;
+ graph->num_pkt_to_capture = prm->num_pkt_to_capture;
+ if (prm->pcap_filename)
+ rte_strscpy(graph->pcap_filename, prm->pcap_filename, RTE_GRAPH_PCAP_FILE_SZ);
/* Allocate the Graph fast path memory and populate the data */
if (graph_fp_mem_create(graph))
diff --git a/lib/graph/graph_pcap.c b/lib/graph/graph_pcap.c
new file mode 100644
index 0000000000..9cbd1b8fdb
--- /dev/null
+++ b/lib/graph/graph_pcap.c
@@ -0,0 +1,216 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell International Ltd.
+ */
+
+#include <errno.h>
+#include <pwd.h>
+#include <stdlib.h>
+#include <unistd.h>
+
+#include <rte_mbuf.h>
+#include <rte_pcapng.h>
+
+#include "rte_graph_worker.h"
+
+#include "graph_pcap_private.h"
+
+#define GRAPH_PCAP_BUF_SZ 128
+#define GRAPH_PCAP_NUM_PACKETS 1024
+#define GRAPH_PCAP_PKT_POOL "graph_pcap_pkt_pool"
+#define GRAPH_PCAP_FILE_NAME "dpdk_graph_pcap_capture_XXXXXX.pcapng"
+
+/* For multi-process, packets are captured in separate files. */
+static rte_pcapng_t *pcapng_fd;
+static bool pcap_enable;
+struct rte_mempool *pkt_mp;
+
+void
+graph_pcap_enable(bool val)
+{
+ pcap_enable = val;
+}
+
+int
+graph_pcap_is_enable(void)
+{
+ return pcap_enable;
+}
+
+void
+graph_pcap_exit(struct rte_graph *graph)
+{
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ if (pkt_mp)
+ rte_mempool_free(pkt_mp);
+
+ if (pcapng_fd) {
+ rte_pcapng_close(pcapng_fd);
+ pcapng_fd = NULL;
+ }
+
+ /* Disable pcap. */
+ graph->pcap_enable = 0;
+ graph_pcap_enable(0);
+}
+
+static int
+graph_pcap_default_path_get(char **dir_path)
+{
+ struct passwd *pwd;
+ char *home_dir;
+
+ /* First check for shell environment variable */
+ home_dir = getenv("HOME");
+ if (home_dir == NULL) {
+ graph_warn("Home env not preset.");
+ /* Fallback to password file entry */
+ pwd = getpwuid(getuid());
+ if (pwd == NULL)
+ return -EINVAL;
+
+ home_dir = pwd->pw_dir;
+ }
+
+ /* Append default pcap file to directory */
+ if (asprintf(dir_path, "%s/%s", home_dir, GRAPH_PCAP_FILE_NAME) == -1)
+ return -ENOMEM;
+
+ return 0;
+}
+
+int
+graph_pcap_file_open(const char *filename)
+{
+ int fd;
+ char file_name[RTE_GRAPH_PCAP_FILE_SZ];
+ char *pcap_dir;
+
+ if (pcapng_fd)
+ goto done;
+
+ if (!filename || filename[0] == '\0') {
+ if (graph_pcap_default_path_get(&pcap_dir) < 0)
+ return -1;
+ snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ, "%s", pcap_dir);
+ free(pcap_dir);
+ } else {
+ snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ, "%s_XXXXXX.pcapng",
+ filename);
+ }
+
+ fd = mkstemps(file_name, strlen(".pcapng"));
+ if (fd < 0) {
+ graph_err("mkstemps() failure");
+ return -1;
+ }
+
+ graph_info("pcap filename: %s", file_name);
+
+ /* Open a capture file */
+ pcapng_fd = rte_pcapng_fdopen(fd, NULL, NULL, "Graph pcap tracer",
+ NULL);
+ if (pcapng_fd == NULL) {
+ graph_err("Graph rte_pcapng_fdopen failed.");
+ close(fd);
+ return -1;
+ }
+
+done:
+ return 0;
+}
+
+int
+graph_pcap_mp_init(void)
+{
+ pkt_mp = rte_mempool_lookup(GRAPH_PCAP_PKT_POOL);
+ if (pkt_mp)
+ goto done;
+
+ /* Make a pool for cloned packets */
+ pkt_mp = rte_pktmbuf_pool_create_by_ops(GRAPH_PCAP_PKT_POOL,
+ IOV_MAX + RTE_GRAPH_BURST_SIZE, 0, 0,
+ rte_pcapng_mbuf_size(RTE_MBUF_DEFAULT_BUF_SIZE),
+ SOCKET_ID_ANY, "ring_mp_mc");
+ if (pkt_mp == NULL) {
+ graph_err("Cannot create mempool for graph pcap capture.");
+ return -1;
+ }
+
+done:
+ return 0;
+}
+
+int
+graph_pcap_init(struct graph *graph)
+{
+ struct rte_graph *graph_data = graph->graph;
+
+ if (graph_pcap_file_open(graph->pcap_filename) < 0)
+ goto error;
+
+ if (graph_pcap_mp_init() < 0)
+ goto error;
+
+ /* User configured number of packets to capture. */
+ if (graph->num_pkt_to_capture)
+ graph_data->nb_pkt_to_capture = graph->num_pkt_to_capture;
+ else
+ graph_data->nb_pkt_to_capture = GRAPH_PCAP_NUM_PACKETS;
+
+ /* All good. Now populate data for secondary process. */
+ rte_strscpy(graph_data->pcap_filename, graph->pcap_filename, RTE_GRAPH_PCAP_FILE_SZ);
+ graph_data->pcap_enable = 1;
+
+ return 0;
+
+error:
+ graph_pcap_exit(graph_data);
+ graph_pcap_enable(0);
+ graph_err("Graph pcap initialization failed. Disabling pcap trace.");
+ return -1;
+}
+
+uint16_t
+graph_pcap_dispatch(struct rte_graph *graph,
+ struct rte_node *node, void **objs,
+ uint16_t nb_objs)
+{
+ struct rte_mbuf *mbuf_clones[RTE_GRAPH_BURST_SIZE];
+ char buffer[GRAPH_PCAP_BUF_SZ];
+ uint64_t i, num_packets;
+ struct rte_mbuf *mbuf;
+ ssize_t len;
+
+ if (!nb_objs || (graph->nb_pkt_captured >= graph->nb_pkt_to_capture))
+ goto done;
+
+ num_packets = graph->nb_pkt_to_capture - graph->nb_pkt_captured;
+ /* nb_objs will never be greater than RTE_GRAPH_BURST_SIZE */
+ if (num_packets > nb_objs)
+ num_packets = nb_objs;
+
+ snprintf(buffer, GRAPH_PCAP_BUF_SZ, "%s: %s", graph->name, node->name);
+
+ for (i = 0; i < num_packets; i++) {
+ struct rte_mbuf *mc;
+ mbuf = (struct rte_mbuf *)objs[i];
+
+ mc = rte_pcapng_copy(mbuf->port, 0, mbuf, pkt_mp, mbuf->pkt_len,
+ rte_get_tsc_cycles(), 0, buffer);
+ if (mc == NULL)
+ break;
+
+ mbuf_clones[i] = mc;
+ }
+
+ /* write it to capture file */
+ len = rte_pcapng_write_packets(pcapng_fd, mbuf_clones, i);
+ rte_pktmbuf_free_bulk(mbuf_clones, i);
+ if (len <= 0)
+ goto done;
+
+ graph->nb_pkt_captured += i;
+
+done:
+ return node->original_process(graph, node, objs, nb_objs);
+}
diff --git a/lib/graph/graph_pcap_private.h b/lib/graph/graph_pcap_private.h
new file mode 100644
index 0000000000..2ec772072c
--- /dev/null
+++ b/lib/graph/graph_pcap_private.h
@@ -0,0 +1,116 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell International Ltd.
+ */
+
+#ifndef _RTE_GRAPH_PCAP_PRIVATE_H_
+#define _RTE_GRAPH_PCAP_PRIVATE_H_
+
+#include <stdint.h>
+#include <sys/types.h>
+
+#include "graph_private.h"
+
+/**
+ * @internal
+ *
+ * Pcap trace enable/disable function.
+ *
+ * The function is called to enable/disable graph pcap trace functionality.
+ *
+ * @param val
+ * Value to be set to enable/disable graph pcap trace.
+ */
+void graph_pcap_enable(bool val);
+
+/**
+ * @internal
+ *
+ * Check graph pcap trace is enable/disable.
+ *
+ * The function is called to check if the graph pcap trace is enabled/disabled.
+ *
+ * @return
+ * - 1: Enable
+ * - 0: Disable
+ */
+int graph_pcap_is_enable(void);
+
+/**
+ * @internal
+ *
+ * Initialise graph pcap trace functionality.
+ *
+ * The function invoked to allocate mempool.
+ *
+ * @return
+ * 0 on success and -1 on failure.
+ */
+int graph_pcap_mp_init(void);
+
+/**
+ * @internal
+ *
+ * Initialise graph pcap trace functionality.
+ *
+ * The function invoked to open pcap file.
+ *
+ * @param filename
+ * Pcap filename.
+ *
+ * @return
+ * 0 on success and -1 on failure.
+ */
+int graph_pcap_file_open(const char *filename);
+
+/**
+ * @internal
+ *
+ * Initialise graph pcap trace functionality.
+ *
+ * The function invoked when the graph pcap trace is enabled. This function
+ * open's pcap file and allocates mempool. Information needed for secondary
+ * process is populated.
+ *
+ * @param graph
+ * Pointer to graph structure.
+ *
+ * @return
+ * 0 on success and -1 on failure.
+ */
+int graph_pcap_init(struct graph *graph);
+
+/**
+ * @internal
+ *
+ * Exit graph pcap trace functionality.
+ *
+ * The function is called to exit graph pcap trace and close open fd's and
+ * free up memory. Pcap trace is also disabled.
+ *
+ * @param graph
+ * Pointer to graph structure.
+ */
+void graph_pcap_exit(struct rte_graph *graph);
+
+/**
+ * @internal
+ *
+ * Capture mbuf metadata and node metadata to a pcap file.
+ *
+ * When graph pcap trace enabled, this function is invoked prior to each node
+ * and mbuf, node metadata is parsed and captured in a pcap file.
+ *
+ * @param graph
+ * Pointer to the graph object.
+ * @param node
+ * Pointer to the node object.
+ * @param objs
+ * Pointer to an array of objects to be processed.
+ * @param nb_objs
+ * Number of objects in the array.
+ */
+uint16_t graph_pcap_dispatch(struct rte_graph *graph,
+ struct rte_node *node, void **objs,
+ uint16_t nb_objs);
+
+#endif /* _RTE_GRAPH_PCAP_PRIVATE_H_ */
diff --git a/lib/graph/graph_populate.c b/lib/graph/graph_populate.c
index 102fd6c29b..2c0844ce92 100644
--- a/lib/graph/graph_populate.c
+++ b/lib/graph/graph_populate.c
@@ -9,6 +9,7 @@
#include <rte_memzone.h>
#include "graph_private.h"
+#include "graph_pcap_private.h"
static size_t
graph_fp_mem_calc_size(struct graph *graph)
@@ -75,7 +76,11 @@ graph_nodes_populate(struct graph *_graph)
memset(node, 0, sizeof(*node));
node->fence = RTE_GRAPH_FENCE;
node->off = off;
- node->process = graph_node->node->process;
+ if (graph_pcap_is_enable()) {
+ node->process = graph_pcap_dispatch;
+ node->original_process = graph_node->node->process;
+ } else
+ node->process = graph_node->node->process;
memcpy(node->name, graph_node->node->name, RTE_GRAPH_NAMESIZE);
pid = graph_node->node->parent_id;
if (pid != RTE_NODE_ID_INVALID) { /* Cloned node */
@@ -183,6 +188,8 @@ graph_fp_mem_populate(struct graph *graph)
int rc;
graph_header_popluate(graph);
+ if (graph_pcap_is_enable())
+ graph_pcap_init(graph);
graph_nodes_populate(graph);
rc = graph_node_nexts_populate(graph);
rc |= graph_src_nodes_populate(graph);
@@ -227,6 +234,9 @@ graph_nodes_mem_destroy(struct rte_graph *graph)
int
graph_fp_mem_destroy(struct graph *graph)
{
+ if (graph_pcap_is_enable())
+ graph_pcap_exit(graph->graph);
+
graph_nodes_mem_destroy(graph->graph);
return rte_memzone_free(graph->mz);
}
diff --git a/lib/graph/graph_private.h b/lib/graph/graph_private.h
index f9a85c8926..7d1b30b8ac 100644
--- a/lib/graph/graph_private.h
+++ b/lib/graph/graph_private.h
@@ -22,6 +22,7 @@ extern int rte_graph_logtype;
__func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__, )))
#define graph_err(...) GRAPH_LOG(ERR, __VA_ARGS__)
+#define graph_warn(...) GRAPH_LOG(WARNING, __VA_ARGS__)
#define graph_info(...) GRAPH_LOG(INFO, __VA_ARGS__)
#define graph_dbg(...) GRAPH_LOG(DEBUG, __VA_ARGS__)
@@ -100,6 +101,10 @@ struct graph {
/**< Memory size of the graph. */
int socket;
/**< Socket identifier where memory is allocated. */
+ uint64_t num_pkt_to_capture;
+ /**< Number of packets to be captured per core. */
+ char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ];
+ /**< pcap file name/path. */
STAILQ_HEAD(gnode_list, graph_node) node_list;
/**< Nodes in a graph. */
};
diff --git a/lib/graph/meson.build b/lib/graph/meson.build
index c7327549e8..3526d1b5d4 100644
--- a/lib/graph/meson.build
+++ b/lib/graph/meson.build
@@ -14,7 +14,8 @@ sources = files(
'graph_debug.c',
'graph_stats.c',
'graph_populate.c',
+ 'graph_pcap.c',
)
headers = files('rte_graph.h', 'rte_graph_worker.h')
-deps += ['eal']
+deps += ['eal', 'pcapng']
diff --git a/lib/graph/rte_graph.h b/lib/graph/rte_graph.h
index b32c4bc217..c9a77297fc 100644
--- a/lib/graph/rte_graph.h
+++ b/lib/graph/rte_graph.h
@@ -35,6 +35,7 @@ extern "C" {
#define RTE_GRAPH_NAMESIZE 64 /**< Max length of graph name. */
#define RTE_NODE_NAMESIZE 64 /**< Max length of node name. */
+#define RTE_GRAPH_PCAP_FILE_SZ 64 /**< Max length of pcap file name. */
#define RTE_GRAPH_OFF_INVALID UINT32_MAX /**< Invalid graph offset. */
#define RTE_NODE_ID_INVALID UINT32_MAX /**< Invalid node id. */
#define RTE_EDGE_ID_INVALID UINT16_MAX /**< Invalid edge id. */
@@ -164,6 +165,10 @@ struct rte_graph_param {
uint16_t nb_node_patterns; /**< Number of node patterns. */
const char **node_patterns;
/**< Array of node patterns based on shell pattern. */
+
+ bool pcap_enable; /**< Pcap enable. */
+ uint64_t num_pkt_to_capture; /**< Number of packets to capture. */
+ char *pcap_filename; /**< Filename in which packets to be captured.*/
};
/**
diff --git a/lib/graph/rte_graph_worker.h b/lib/graph/rte_graph_worker.h
index fc6fee48c8..438595b15c 100644
--- a/lib/graph/rte_graph_worker.h
+++ b/lib/graph/rte_graph_worker.h
@@ -44,6 +44,12 @@ struct rte_graph {
rte_graph_t id; /**< Graph identifier. */
int socket; /**< Socket ID where memory is allocated. */
char name[RTE_GRAPH_NAMESIZE]; /**< Name of the graph. */
+ bool pcap_enable; /**< Pcap trace enabled. */
+ /** Number of packets captured per core. */
+ uint64_t nb_pkt_captured;
+ /** Number of packets to capture per core. */
+ uint64_t nb_pkt_to_capture;
+ char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ]; /**< Pcap filename. */
uint64_t fence; /**< Fence. */
} __rte_cache_aligned;
@@ -64,6 +70,9 @@ struct rte_node {
char parent[RTE_NODE_NAMESIZE]; /**< Parent node name. */
char name[RTE_NODE_NAMESIZE]; /**< Name of the node. */
+ /** Original process function when pcap is enabled. */
+ rte_node_process_t original_process;
+
/* Fast path area */
#define RTE_NODE_CTX_SZ 16
uint8_t ctx[RTE_NODE_CTX_SZ] __rte_cache_aligned; /**< Node Context. */
--
2.25.1
^ permalink raw reply [relevance 2%]
* [PATCH v5 1/3] pcapng: comment option support for epb
2023-01-24 11:21 4% ` [PATCH v4 " Amit Prakash Shukla
2023-01-24 11:21 2% ` [PATCH v4 2/3] graph: pcap capture for graph nodes Amit Prakash Shukla
@ 2023-02-03 8:19 4% ` Amit Prakash Shukla
2023-02-03 8:19 2% ` [PATCH v5 2/3] graph: pcap capture for graph nodes Amit Prakash Shukla
1 sibling, 1 reply; 200+ results
From: Amit Prakash Shukla @ 2023-02-03 8:19 UTC (permalink / raw)
To: Reshma Pattan, Stephen Hemminger; +Cc: dev, jerinj, Amit Prakash Shukla
This change enhances rte_pcapng_copy to have comment in enhanced
packet block.
Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
---
v2:
- Fixed code style issue
- Fixed CI compilation issue on github-robot
v3:
- Code review suggestion from Stephen
- Fixed potential memory leak
v4:
- Code review suggestion from Jerin
v5:
- Code review suggestion from Jerin
app/test/test_pcapng.c | 4 ++--
doc/guides/rel_notes/release_23_03.rst | 2 ++
lib/pcapng/rte_pcapng.c | 10 +++++++++-
lib/pcapng/rte_pcapng.h | 4 +++-
lib/pdump/rte_pdump.c | 2 +-
5 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/app/test/test_pcapng.c b/app/test/test_pcapng.c
index a7acbdc058..303d3d66f9 100644
--- a/app/test/test_pcapng.c
+++ b/app/test/test_pcapng.c
@@ -139,7 +139,7 @@ test_write_packets(void)
struct rte_mbuf *mc;
mc = rte_pcapng_copy(port_id, 0, orig, mp, pkt_len,
- rte_get_tsc_cycles(), 0);
+ rte_get_tsc_cycles(), 0, NULL);
if (mc == NULL) {
fprintf(stderr, "Cannot copy packet\n");
return -1;
@@ -255,7 +255,7 @@ test_write_over_limit_iov_max(void)
struct rte_mbuf *mc;
mc = rte_pcapng_copy(port_id, 0, orig, mp, pkt_len,
- rte_get_tsc_cycles(), 0);
+ rte_get_tsc_cycles(), 0, NULL);
if (mc == NULL) {
fprintf(stderr, "Cannot copy packet\n");
return -1;
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index 73f5d94e14..dab62508c4 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -107,6 +107,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* Experimental function ``rte_pcapng_copy`` was updated to support comment
+ section in enhanced packet block in pcapng library.
ABI Changes
-----------
diff --git a/lib/pcapng/rte_pcapng.c b/lib/pcapng/rte_pcapng.c
index 80d08e1a3b..acb31a9d93 100644
--- a/lib/pcapng/rte_pcapng.c
+++ b/lib/pcapng/rte_pcapng.c
@@ -450,7 +450,8 @@ rte_pcapng_copy(uint16_t port_id, uint32_t queue,
const struct rte_mbuf *md,
struct rte_mempool *mp,
uint32_t length, uint64_t cycles,
- enum rte_pcapng_direction direction)
+ enum rte_pcapng_direction direction,
+ const char *comment)
{
struct pcapng_enhance_packet_block *epb;
uint32_t orig_len, data_len, padding, flags;
@@ -511,6 +512,9 @@ rte_pcapng_copy(uint16_t port_id, uint32_t queue,
if (rss_hash)
optlen += pcapng_optlen(sizeof(uint8_t) + sizeof(uint32_t));
+ if (comment)
+ optlen += pcapng_optlen(strlen(comment));
+
/* reserve trailing options and block length */
opt = (struct pcapng_option *)
rte_pktmbuf_append(mc, optlen + sizeof(uint32_t));
@@ -548,6 +552,10 @@ rte_pcapng_copy(uint16_t port_id, uint32_t queue,
&hash_opt, sizeof(hash_opt));
}
+ if (comment)
+ opt = pcapng_add_option(opt, PCAPNG_OPT_COMMENT, comment,
+ strlen(comment));
+
/* Note: END_OPT necessary here. Wireshark doesn't do it. */
/* Add PCAPNG packet header */
diff --git a/lib/pcapng/rte_pcapng.h b/lib/pcapng/rte_pcapng.h
index 7d2697c647..6d286cda41 100644
--- a/lib/pcapng/rte_pcapng.h
+++ b/lib/pcapng/rte_pcapng.h
@@ -100,6 +100,8 @@ enum rte_pcapng_direction {
* The timestamp in TSC cycles.
* @param direction
* The direction of the packer: receive, transmit or unknown.
+ * @param comment
+ * Packet comment.
*
* @return
* - The pointer to the new mbuf formatted for pcapng_write
@@ -111,7 +113,7 @@ struct rte_mbuf *
rte_pcapng_copy(uint16_t port_id, uint32_t queue,
const struct rte_mbuf *m, struct rte_mempool *mp,
uint32_t length, uint64_t timestamp,
- enum rte_pcapng_direction direction);
+ enum rte_pcapng_direction direction, const char *comment);
/**
diff --git a/lib/pdump/rte_pdump.c b/lib/pdump/rte_pdump.c
index a81544cb57..9bc4bab4f2 100644
--- a/lib/pdump/rte_pdump.c
+++ b/lib/pdump/rte_pdump.c
@@ -122,7 +122,7 @@ pdump_copy(uint16_t port_id, uint16_t queue,
if (cbs->ver == V2)
p = rte_pcapng_copy(port_id, queue,
pkts[i], mp, cbs->snaplen,
- ts, direction);
+ ts, direction, NULL);
else
p = rte_pktmbuf_copy(pkts[i], mp, 0, cbs->snaplen);
--
2.25.1
^ permalink raw reply [relevance 4%]
* RE: [EXT] Re: [PATCH v4 2/3] graph: pcap capture for graph nodes
2023-01-31 8:06 0% ` Jerin Jacob
@ 2023-02-03 8:15 0% ` Amit Prakash Shukla
0 siblings, 0 replies; 200+ results
From: Amit Prakash Shukla @ 2023-02-03 8:15 UTC (permalink / raw)
To: Jerin Jacob
Cc: Jerin Jacob Kollanukkaran, Kiran Kumar Kokkilagadda,
Nithin Kumar Dabilpuram, Anatoly Burakov, dev
Thanks Jerin for the feedback. I will make the changes in next version of the patch.
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Tuesday, January 31, 2023 1:37 PM
> To: Amit Prakash Shukla <amitprakashs@marvell.com>
> Cc: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Kiran Kumar
> Kokkilagadda <kirankumark@marvell.com>; Nithin Kumar Dabilpuram
> <ndabilpuram@marvell.com>; Anatoly Burakov
> <anatoly.burakov@intel.com>; dev@dpdk.org
> Subject: [EXT] Re: [PATCH v4 2/3] graph: pcap capture for graph nodes
>
> External Email
>
> ----------------------------------------------------------------------
> On Tue, Jan 24, 2023 at 4:52 PM Amit Prakash Shukla
> <amitprakashs@marvell.com> wrote:
> >
> > Implementation adds support to capture packets at each node with
> > packet metadata and node name.
> >
> > Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
> > ---
> > v2:
> > - Fixed code style issue
> > - Fixed CI compilation issue on github-robot
> >
> > v3:
> > - Code review suggestion from Stephen
> > - Fixed potential memory leak
> >
> > v4:
> > - Code review suggestion from Jerin
> >
> > app/test/test_graph_perf.c | 2 +-
> > doc/guides/rel_notes/release_23_03.rst | 7 +
> > lib/graph/graph.c | 17 +-
> > lib/graph/graph_pcap.c | 217 +++++++++++++++++++++++++
> > lib/graph/graph_pcap_private.h | 124 ++++++++++++++
> > lib/graph/graph_populate.c | 12 +-
> > lib/graph/graph_private.h | 5 +
> > lib/graph/meson.build | 3 +-
> > lib/graph/rte_graph.h | 5 +
> > lib/graph/rte_graph_worker.h | 9 +
> > 10 files changed, 397 insertions(+), 4 deletions(-) create mode
> > 100644 lib/graph/graph_pcap.c create mode 100644
> > lib/graph/graph_pcap_private.h
> >
> > diff --git a/app/test/test_graph_perf.c b/app/test/test_graph_perf.c
> > index 1d065438a6..c5b463f700 100644
> > --- a/app/test/test_graph_perf.c
> > +++ b/app/test/test_graph_perf.c
> > @@ -324,7 +324,7 @@ graph_init(const char *gname, uint8_t nb_srcs,
> uint8_t nb_sinks,
> > char nname[RTE_NODE_NAMESIZE / 2];
> > struct test_node_data *node_data;
> > char *ename[nodes_per_stage];
> > - struct rte_graph_param gconf;
> > + struct rte_graph_param gconf = {0};
>
> If it is Fix move to seperate patch out this series.
>
>
> > const struct rte_memzone *mz;
> > uint8_t total_percent = 0;
> > rte_node_t *src_nodes;
> > diff --git a/doc/guides/rel_notes/release_23_03.rst
> > b/doc/guides/rel_notes/release_23_03.rst
> > index 8c360b89e4..9ba392fb58 100644
> > --- a/doc/guides/rel_notes/release_23_03.rst
> > +++ b/doc/guides/rel_notes/release_23_03.rst
> > @@ -69,6 +69,10 @@ New Features
> > ``rte_event_dev_config::nb_single_link_event_port_queues``
> parameter
> > required for eth_rx, eth_tx, crypto and timer eventdev adapters.
> >
> > +* **Added pcap trace support in graph library.**
> > +
> > + * Added support to capture packets at each graph node with packet
> metadata and
> > + node name.
> >
> > Removed Items
> > -------------
> > @@ -101,6 +105,9 @@ API Changes
> > * Experimental function ``rte_pcapng_copy`` was updated to support
> comment
> > section in enhanced packet block in pcapng library.
> >
> > +* Experimental structures ``struct rte_graph_param``, ``struct
> > +rte_graph`` and
> > + ``struct graph`` were updated to support pcap trace in graph library.
> > +
> > ABI Changes
> > -----------
> >
> > diff --git a/lib/graph/graph.c b/lib/graph/graph.c index
> > 3a617cc369..a839a2803b 100644
> > --- a/lib/graph/graph.c
> > +++ b/lib/graph/graph.c
> > @@ -15,6 +15,7 @@
> > #include <rte_string_fns.h>
> >
> > #include "graph_private.h"
> > +#include "graph_pcap_private.h"
> >
> > static struct graph_head graph_list =
> > STAILQ_HEAD_INITIALIZER(graph_list);
> > static rte_spinlock_t graph_lock = RTE_SPINLOCK_INITIALIZER; @@
> > -228,7 +229,12 @@ graph_mem_fixup_node_ctx(struct rte_graph *graph)
> > node_db = node_from_name(name);
> > if (node_db == NULL)
> > SET_ERR_JMP(ENOLINK, fail, "Node %s not found", name);
> > - node->process = node_db->process;
> > +
> > + if (graph->pcap_enable) {
> > + node->process = graph_pcap_dispatch;
> > + node->original_process = node_db->process;
> > + } else
> > + node->process = node_db->process;
> > }
> >
> > return graph;
> > @@ -242,6 +248,9 @@ graph_mem_fixup_secondary(struct rte_graph
> *graph)
> > if (graph == NULL || rte_eal_process_type() == RTE_PROC_PRIMARY)
> > return graph;
> >
> > + if (graph_pcap_file_open(graph->pcap_filename) ||
> graph_pcap_mp_init())
> > + graph_pcap_exit(graph);
> > +
> > return graph_mem_fixup_node_ctx(graph); }
> >
> > @@ -323,11 +332,17 @@ rte_graph_create(const char *name, struct
> rte_graph_param *prm)
> > if (graph_has_isolated_node(graph))
> > goto graph_cleanup;
> >
> > + /* Initialize pcap config. */
> > + graph_pcap_enable(prm->pcap_enable);
> > +
> > /* Initialize graph object */
> > graph->socket = prm->socket_id;
> > graph->src_node_count = src_node_count;
> > graph->node_count = graph_nodes_count(graph);
> > graph->id = graph_id;
> > + graph->num_pkt_to_capture = prm->num_pkt_to_capture;
> > + if (prm->pcap_filename)
> > + rte_strscpy(graph->pcap_filename, prm->pcap_filename,
> > + RTE_GRAPH_PCAP_FILE_SZ);
> >
> > /* Allocate the Graph fast path memory and populate the data */
> > if (graph_fp_mem_create(graph)) diff --git
> > a/lib/graph/graph_pcap.c b/lib/graph/graph_pcap.c new file mode 100644
> > index 0000000000..7bd13ed61e
> > --- /dev/null
> > +++ b/lib/graph/graph_pcap.c
> > @@ -0,0 +1,217 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2023 Marvell International Ltd.
> > + */
> > +
> > +#include <errno.h>
> > +#include <unistd.h>
> > +#include <stdlib.h>
> > +#include <pwd.h>
>
> Sort in alphabetical order.
>
>
> > +
> > +#include <rte_mbuf.h>
> > +#include <rte_pcapng.h>
> > +
> > +#include "rte_graph_worker.h"
> > +
> > +#include "graph_pcap_private.h"
> > +
> > +#define GRAPH_PCAP_BUF_SZ 128
> > +#define GRAPH_PCAP_NUM_PACKETS 1024
> > +#define GRAPH_PCAP_PKT_POOL "graph_pcap_pkt_pool"
> > +#define GRAPH_PCAP_FILE_NAME
> "dpdk_graph_pcap_capture_XXXXXX.pcapng"
> > +
> > +/* For multi-process, packets are captured in separate files. */
> > +static rte_pcapng_t *pcapng_fd; static bool pcap_enable; struct
> > +rte_mempool *pkt_mp;
> > +
> > +void
> > +graph_pcap_enable(bool val)
> > +{
> > + pcap_enable = val;
> > +}
> > +
> > +int
> > +graph_pcap_is_enable(void)
> > +{
> > + return pcap_enable;
> > +}
> > +
> > +void
> > +graph_pcap_exit(struct rte_graph *graph) {
> > + if (rte_eal_process_type() == RTE_PROC_PRIMARY)
> > + if (pkt_mp)
> > + rte_mempool_free(pkt_mp);
> > +
> > + if (pcapng_fd) {
> > + rte_pcapng_close(pcapng_fd);
> > + pcapng_fd = NULL;
> > + }
> > +
> > + /* Disable pcap. */
> > + graph->pcap_enable = 0;
> > + graph_pcap_enable(0);
> > +}
> > +
> > +static int
> > +graph_pcap_default_path_get(char **dir_path) {
> > + struct passwd *pwd;
> > + char *home_dir;
> > +
> > + /* First check for shell environment variable */
> > + home_dir = getenv("HOME");
> > + if (home_dir == NULL) {
> > + graph_warn("Home env not preset.");
> > + /* Fallback to password file entry */
> > + pwd = getpwuid(getuid());
> > + if (pwd == NULL)
> > + return -EINVAL;
> > +
> > + home_dir = pwd->pw_dir;
> > + }
> > +
> > + /* Append default pcap file to directory */
> > + if (asprintf(dir_path, "%s/%s", home_dir, GRAPH_PCAP_FILE_NAME)
> == -1)
> > + return -ENOMEM;
> > +
> > + return 0;
> > +}
> > +
> > +int
> > +graph_pcap_file_open(const char *filename) {
> > + int fd;
> > + char file_name[RTE_GRAPH_PCAP_FILE_SZ];
> > + char *pcap_dir;
> > +
> > + if (pcapng_fd)
> > + goto done;
> > +
> > + if (!filename || filename[0] == '\0') {
> > + if (graph_pcap_default_path_get(&pcap_dir) < 0)
> > + return -1;
> > + snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ, "%s", pcap_dir);
> > + free(pcap_dir);
> > + } else {
> > + snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ,
> "%s_XXXXXX.pcapng",
> > + filename);
> > + }
> > +
> > + fd = mkstemps(file_name, strlen(".pcapng"));
> > + if (fd < 0) {
> > + graph_err("mkstemps() failure");
> > + return -1;
> > + }
> > +
> > + graph_info("pcap filename: %s", file_name);
> > +
> > + /* Open a capture file */
> > + pcapng_fd = rte_pcapng_fdopen(fd, NULL, NULL, "Graph pcap tracer",
> > + NULL);
> > + if (pcapng_fd == NULL) {
> > + graph_err("Graph rte_pcapng_fdopen failed.");
> > + close(fd);
> > + return -1;
> > + }
> > +
> > +done:
> > + return 0;
> > +}
> > +
> > +int
> > +graph_pcap_mp_init(void)
> > +{
> > + pkt_mp = rte_mempool_lookup(GRAPH_PCAP_PKT_POOL);
> > + if (pkt_mp)
> > + goto done;
> > +
> > + /* Make a pool for cloned packets */
> > + pkt_mp =
> rte_pktmbuf_pool_create_by_ops(GRAPH_PCAP_PKT_POOL,
> > + IOV_MAX + RTE_GRAPH_BURST_SIZE, 0, 0,
> > + rte_pcapng_mbuf_size(RTE_MBUF_DEFAULT_BUF_SIZE),
> > + SOCKET_ID_ANY, "ring_mp_mc");
> > + if (pkt_mp == NULL) {
> > + graph_err("Cannot create mempool for graph pcap capture.");
> > + return -1;
> > + }
> > +
> > +done:
> > + return 0;
> > +}
> > +
> > +int
> > +graph_pcap_init(struct graph *graph)
> > +{
> > + struct rte_graph *graph_data = graph->graph;
> > +
> > + if (graph_pcap_file_open(graph->pcap_filename) < 0)
> > + goto error;
> > +
> > + if (graph_pcap_mp_init() < 0)
> > + goto error;
> > +
> > + /* User configured number of packets to capture. */
> > + if (graph->num_pkt_to_capture)
> > + graph_data->nb_pkt_to_capture = graph->num_pkt_to_capture;
> > + else
> > + graph_data->nb_pkt_to_capture =
> > + GRAPH_PCAP_NUM_PACKETS;
> > +
> > + /* All good. Now populate data for secondary process. */
>
> No need new line.
>
> > +
> > + rte_strscpy(graph_data->pcap_filename, graph->pcap_filename,
> RTE_GRAPH_PCAP_FILE_SZ);
> > + graph_data->pcap_enable = 1;
> > +
> > + return 0;
> > +
> > +error:
> > + graph_pcap_exit(graph_data);
> > + graph_pcap_enable(0);
> > + graph_err("Graph pcap initialization failed. Disabling pcap trace.");
> > + return -1;
> > +}
> > +
> > +uint16_t
> > +graph_pcap_dispatch(struct rte_graph *graph,
> > + struct rte_node *node, void **objs,
> > + uint16_t nb_objs) {
> > + struct rte_mbuf *mbuf_clones[RTE_GRAPH_BURST_SIZE];
> > + char buffer[GRAPH_PCAP_BUF_SZ];
> > + uint64_t i, num_packets;
> > + struct rte_mbuf *mbuf;
> > + ssize_t len;
> > +
> > + if (!nb_objs || (graph->nb_pkt_captured >= graph-
> >nb_pkt_to_capture))
> > + goto done;
> > +
> > + num_packets = graph->nb_pkt_to_capture - graph-
> >nb_pkt_captured;
> > + /* nb_objs will never be greater than RTE_GRAPH_BURST_SIZE */
> > + if (num_packets > nb_objs)
> > + num_packets = nb_objs;
> > +
> > + snprintf(buffer, GRAPH_PCAP_BUF_SZ, "%s: %s", graph->name,
> > + node->name);
> > +
> > + for (i = 0; i < num_packets; i++) {
> > + struct rte_mbuf *mc;
> > + mbuf = (struct rte_mbuf *)objs[i];
> > +
> > + mc = rte_pcapng_copy(mbuf->port, 0, mbuf, pkt_mp, mbuf-
> >pkt_len,
> > + rte_get_tsc_cycles(), 0, buffer);
> > + if (mc == NULL)
> > + break;
> > +
> > + mbuf_clones[i] = mc;
> > + }
> > +
> > + /* write it to capture file */
> > + len = rte_pcapng_write_packets(pcapng_fd, mbuf_clones, i);
> > + rte_pktmbuf_free_bulk(mbuf_clones, i);
> > + if (len <= 0)
> > + goto done;
> > +
> > + graph->nb_pkt_captured += i;
> > +
> > +done:
> > + return node->original_process(graph, node, objs, nb_objs); }
> > diff --git a/lib/graph/graph_pcap_private.h
> > b/lib/graph/graph_pcap_private.h new file mode 100644 index
> > 0000000000..198add67e2
> > --- /dev/null
> > +++ b/lib/graph/graph_pcap_private.h
> > @@ -0,0 +1,124 @@
> > +/* SPDX-License-Identifier: BSD-3-Clause
> > + * Copyright(C) 2023 Marvell International Ltd.
> > + */
> > +
> > +#ifndef _RTE_GRAPH_PCAP_PRIVATE_H_
> > +#define _RTE_GRAPH_PCAP_PRIVATE_H_
> > +
> > +#include <stdint.h>
> > +#include <sys/types.h>
> > +
> > +#include "graph_private.h"
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
>
> No need this for internal header files
>
>
> > +
> > +/**
> > + * @internal
> > + *
> > + * Pcap trace enable/disable function.
> > + *
> > + * The function is called to enable/disable graph pcap trace functionality.
> > + *
> > + * @param val
> > + * Value to be set to enable/disable graph pcap trace.
> > + */
> > +void graph_pcap_enable(bool val);
> > +
> > +/**
> > + * @internal
> > + *
> > + * Check graph pcap trace is enable/disable.
> > + *
> > + * The function is called to check if the graph pcap trace is
> enabled/disabled.
> > + *
> > + * @return
> > + * - 1: Enable
> > + * - 0: Disable
> > + */
> > +int graph_pcap_is_enable(void);
> > +
> > +/**
> > + * @internal
> > + *
> > + * Initialise graph pcap trace functionality.
> > + *
> > + * The function invoked to allocate mempool.
> > + *
> > + * @return
> > + * 0 on success and -1 on failure.
> > + */
> > +int graph_pcap_mp_init(void);
> > +
> > +/**
> > + * @internal
> > + *
> > + * Initialise graph pcap trace functionality.
> > + *
> > + * The function invoked to open pcap file.
> > + *
> > + * @param filename
> > + * Pcap filename.
> > + *
> > + * @return
> > + * 0 on success and -1 on failure.
> > + */
> > +int graph_pcap_file_open(const char *filename);
> > +
> > +/**
> > + * @internal
> > + *
> > + * Initialise graph pcap trace functionality.
> > + *
> > + * The function invoked when the graph pcap trace is enabled. This
> > +function
> > + * open's pcap file and allocates mempool. Information needed for
> > +secondary
> > + * process is populated.
> > + *
> > + * @param graph
> > + * Pointer to graph structure.
> > + *
> > + * @return
> > + * 0 on success and -1 on failure.
> > + */
> > +int graph_pcap_init(struct graph *graph);
> > +
> > +/**
> > + * @internal
> > + *
> > + * Exit graph pcap trace functionality.
> > + *
> > + * The function is called to exit graph pcap trace and close open
> > +fd's and
> > + * free up memory. Pcap trace is also disabled.
> > + *
> > + * @param graph
> > + * Pointer to graph structure.
> > + */
> > +void graph_pcap_exit(struct rte_graph *graph);
> > +
> > +/**
> > + * @internal
> > + *
> > + * Capture mbuf metadata and node metadata to a pcap file.
> > + *
> > + * When graph pcap trace enabled, this function is invoked prior to
> > +each node
> > + * and mbuf, node metadata is parsed and captured in a pcap file.
> > + *
> > + * @param graph
> > + * Pointer to the graph object.
> > + * @param node
> > + * Pointer to the node object.
> > + * @param objs
> > + * Pointer to an array of objects to be processed.
> > + * @param nb_objs
> > + * Number of objects in the array.
> > + */
> > +uint16_t graph_pcap_dispatch(struct rte_graph *graph,
> > + struct rte_node *node, void **objs,
> > + uint16_t nb_objs);
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +
> > +#endif /* _RTE_GRAPH_PCAP_PRIVATE_H_ */
> > diff --git a/lib/graph/graph_populate.c b/lib/graph/graph_populate.c
> > index 102fd6c29b..2c0844ce92 100644
> > --- a/lib/graph/graph_populate.c
> > +++ b/lib/graph/graph_populate.c
> > @@ -9,6 +9,7 @@
> > #include <rte_memzone.h>
> >
> > #include "graph_private.h"
> > +#include "graph_pcap_private.h"
> >
> > static size_t
> > graph_fp_mem_calc_size(struct graph *graph) @@ -75,7 +76,11 @@
> > graph_nodes_populate(struct graph *_graph)
> > memset(node, 0, sizeof(*node));
> > node->fence = RTE_GRAPH_FENCE;
> > node->off = off;
> > - node->process = graph_node->node->process;
> > + if (graph_pcap_is_enable()) {
> > + node->process = graph_pcap_dispatch;
> > + node->original_process = graph_node->node->process;
> > + } else
> > + node->process = graph_node->node->process;
> > memcpy(node->name, graph_node->node->name,
> RTE_GRAPH_NAMESIZE);
> > pid = graph_node->node->parent_id;
> > if (pid != RTE_NODE_ID_INVALID) { /* Cloned node */ @@
> > -183,6 +188,8 @@ graph_fp_mem_populate(struct graph *graph)
> > int rc;
> >
> > graph_header_popluate(graph);
> > + if (graph_pcap_is_enable())
> > + graph_pcap_init(graph);
> > graph_nodes_populate(graph);
> > rc = graph_node_nexts_populate(graph);
> > rc |= graph_src_nodes_populate(graph); @@ -227,6 +234,9 @@
> > graph_nodes_mem_destroy(struct rte_graph *graph) int
> > graph_fp_mem_destroy(struct graph *graph) {
> > + if (graph_pcap_is_enable())
> > + graph_pcap_exit(graph->graph);
> > +
> > graph_nodes_mem_destroy(graph->graph);
> > return rte_memzone_free(graph->mz); } diff --git
> > a/lib/graph/graph_private.h b/lib/graph/graph_private.h index
> > f9a85c8926..7d1b30b8ac 100644
> > --- a/lib/graph/graph_private.h
> > +++ b/lib/graph/graph_private.h
> > @@ -22,6 +22,7 @@ extern int rte_graph_logtype;
> > __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__,
> > )))
> >
> > #define graph_err(...) GRAPH_LOG(ERR, __VA_ARGS__)
> > +#define graph_warn(...) GRAPH_LOG(WARNING, __VA_ARGS__)
> > #define graph_info(...) GRAPH_LOG(INFO, __VA_ARGS__) #define
> > graph_dbg(...) GRAPH_LOG(DEBUG, __VA_ARGS__)
> >
> > @@ -100,6 +101,10 @@ struct graph {
> > /**< Memory size of the graph. */
> > int socket;
> > /**< Socket identifier where memory is allocated. */
> > + uint64_t num_pkt_to_capture;
> > + /**< Number of packets to be captured per core. */
> > + char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ];
> > + /**< pcap file name/path. */
> > STAILQ_HEAD(gnode_list, graph_node) node_list;
> > /**< Nodes in a graph. */
> > };
> > diff --git a/lib/graph/meson.build b/lib/graph/meson.build index
> > c7327549e8..3526d1b5d4 100644
> > --- a/lib/graph/meson.build
> > +++ b/lib/graph/meson.build
> > @@ -14,7 +14,8 @@ sources = files(
> > 'graph_debug.c',
> > 'graph_stats.c',
> > 'graph_populate.c',
> > + 'graph_pcap.c',
> > )
> > headers = files('rte_graph.h', 'rte_graph_worker.h')
> >
> > -deps += ['eal']
> > +deps += ['eal', 'pcapng']
> > diff --git a/lib/graph/rte_graph.h b/lib/graph/rte_graph.h index
> > b32c4bc217..c9a77297fc 100644
> > --- a/lib/graph/rte_graph.h
> > +++ b/lib/graph/rte_graph.h
> > @@ -35,6 +35,7 @@ extern "C" {
> >
> > #define RTE_GRAPH_NAMESIZE 64 /**< Max length of graph name. */
> > #define RTE_NODE_NAMESIZE 64 /**< Max length of node name. */
> > +#define RTE_GRAPH_PCAP_FILE_SZ 64 /**< Max length of pcap file
> name.
> > +*/
> > #define RTE_GRAPH_OFF_INVALID UINT32_MAX /**< Invalid graph
> offset. */
> > #define RTE_NODE_ID_INVALID UINT32_MAX /**< Invalid node id. */
> > #define RTE_EDGE_ID_INVALID UINT16_MAX /**< Invalid edge id. */
> > @@ -164,6 +165,10 @@ struct rte_graph_param {
> > uint16_t nb_node_patterns; /**< Number of node patterns. */
> > const char **node_patterns;
> > /**< Array of node patterns based on shell pattern. */
> > +
> > + bool pcap_enable; /**< Pcap enable. */
> > + uint64_t num_pkt_to_capture; /**< Number of packets to capture. */
> > + char *pcap_filename; /**< Filename in which packets to be
> > + captured.*/
> > };
> >
> > /**
> > diff --git a/lib/graph/rte_graph_worker.h
> > b/lib/graph/rte_graph_worker.h index fc6fee48c8..438595b15c 100644
> > --- a/lib/graph/rte_graph_worker.h
> > +++ b/lib/graph/rte_graph_worker.h
> > @@ -44,6 +44,12 @@ struct rte_graph {
> > rte_graph_t id; /**< Graph identifier. */
> > int socket; /**< Socket ID where memory is allocated. */
> > char name[RTE_GRAPH_NAMESIZE]; /**< Name of the graph. */
> > + bool pcap_enable; /**< Pcap trace enabled. */
> > + /** Number of packets captured per core. */
> > + uint64_t nb_pkt_captured;
> > + /** Number of packets to capture per core. */
> > + uint64_t nb_pkt_to_capture;
> > + char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ]; /**< Pcap
> > + filename. */
> > uint64_t fence; /**< Fence. */
> > } __rte_cache_aligned;
> >
> > @@ -64,6 +70,9 @@ struct rte_node {
> > char parent[RTE_NODE_NAMESIZE]; /**< Parent node name. */
> > char name[RTE_NODE_NAMESIZE]; /**< Name of the node. */
> >
> > + /** Original process function when pcap is enabled. */
> > + rte_node_process_t original_process;
> > +
> > /* Fast path area */
> > #define RTE_NODE_CTX_SZ 16
> > uint8_t ctx[RTE_NODE_CTX_SZ] __rte_cache_aligned; /**< Node
> > Context. */
> > --
> > 2.25.1
> >
^ permalink raw reply [relevance 0%]
* [PATCH] doc: update NFP documentation with Corigine information
@ 2023-02-03 8:08 6% Chaoyong He
0 siblings, 0 replies; 200+ results
From: Chaoyong He @ 2023-02-03 8:08 UTC (permalink / raw)
To: dev; +Cc: oss-drivers, niklas.soderlund, Walter Heymans, Chaoyong He
From: Walter Heymans <walter.heymans@corigine.com>
The NFP PMD documentation is updated to include information about
Corigine and their new vendor device ID.
Outdated information regarding the use of the PMD is also updated.
While making major changes to the document, the maximum number of
characters per line is updated to 80 characters to improve the
readability in raw format.
Signed-off-by: Walter Heymans <walter.heymans@corigine.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@corigine.com>
Reviewed-by: Chaoyong He <chaoyong.he@corigine.com>
---
doc/guides/nics/nfp.rst | 168 +++++++++++++++++++++-------------------
1 file changed, 90 insertions(+), 78 deletions(-)
diff --git a/doc/guides/nics/nfp.rst b/doc/guides/nics/nfp.rst
index a085d7d9ae..6fea280411 100644
--- a/doc/guides/nics/nfp.rst
+++ b/doc/guides/nics/nfp.rst
@@ -1,35 +1,34 @@
.. SPDX-License-Identifier: BSD-3-Clause
Copyright(c) 2015-2017 Netronome Systems, Inc. All rights reserved.
- All rights reserved.
+ Copyright(c) 2021 Corigine, Inc. All rights reserved.
NFP poll mode driver library
============================
-Netronome's sixth generation of flow processors pack 216 programmable
-cores and over 100 hardware accelerators that uniquely combine packet,
-flow, security and content processing in a single device that scales
+Netronome and Corigine's sixth generation of flow processors pack 216
+programmable cores and over 100 hardware accelerators that uniquely combine
+packet, flow, security and content processing in a single device that scales
up to 400-Gb/s.
-This document explains how to use DPDK with the Netronome Poll Mode
-Driver (PMD) supporting Netronome's Network Flow Processor 6xxx
-(NFP-6xxx), Netronome's Network Flow Processor 4xxx (NFP-4xxx) and
-Netronome's Network Flow Processor 38xx (NFP-38xx).
+This document explains how to use DPDK with the Network Flow Processor (NFP)
+Poll Mode Driver (PMD) supporting Netronome and Corigine's NFP-6xxx, NFP-4xxx
+and NFP-38xx product lines.
-NFP is a SRIOV capable device and the PMD supports the physical
-function (PF) and the virtual functions (VFs).
+NFP is a SR-IOV capable device and the PMD supports the physical function (PF)
+and the virtual functions (VFs).
Dependencies
------------
-Before using the Netronome's DPDK PMD some NFP configuration,
-which is not related to DPDK, is required. The system requires
-installation of **Netronome's BSP (Board Support Package)** along
-with a specific NFP firmware application. Netronome's NSP ABI
-version should be 0.20 or higher.
+Before using the NFP DPDK PMD some NFP configuration, which is not related to
+DPDK, is required. The system requires installation of
+**NFP-BSP (Board Support Package)** along with a specific NFP firmware
+application. The NSP ABI version should be 0.20 or higher.
-If you have a NFP device you should already have the code and
-documentation for this configuration. Contact
-**support@netronome.com** to obtain the latest available firmware.
+If you have a NFP device you should already have the documentation to perform
+this configuration. Contact **support@netronome.com** (for Netronome products)
+or **smartnic-support@corigine.com** (for Corigine products) to obtain the
+latest available firmware.
The NFP Linux netdev kernel driver for VFs has been a part of the
vanilla kernel since kernel version 4.5, and support for the PF
@@ -44,11 +43,11 @@ Linux kernel driver.
Building the software
---------------------
-Netronome's PMD code is provided in the **drivers/net/nfp** directory.
-Although NFP PMD has Netronome´s BSP dependencies, it is possible to
-compile it along with other DPDK PMDs even if no BSP was installed previously.
-Of course, a DPDK app will require such a BSP installed for using the
-NFP PMD, along with a specific NFP firmware application.
+The NFP PMD code is provided in the **drivers/net/nfp** directory. Although
+NFP PMD has BSP dependencies, it is possible to compile it along with other
+DPDK PMDs even if no BSP was installed previously. Of course, a DPDK app will
+require such a BSP installed for using the NFP PMD, along with a specific NFP
+firmware application.
Once the DPDK is built all the DPDK apps and examples include support for
the NFP PMD.
@@ -57,27 +56,20 @@ the NFP PMD.
Driver compilation and testing
------------------------------
-Refer to the document :ref:`compiling and testing a PMD for a NIC <pmd_build_and_test>`
-for details.
+Refer to the document
+:ref:`compiling and testing a PMD for a NIC <pmd_build_and_test>` for details.
Using the PF
------------
-NFP PMD supports using the NFP PF as another DPDK port, but it does not
-have any functionality for controlling VFs. In fact, it is not possible to use
-the PMD with the VFs if the PF is being used by DPDK, that is, with the NFP PF
-bound to ``igb_uio`` or ``vfio-pci`` kernel drivers. Future DPDK versions will
-have a PMD able to work with the PF and VFs at the same time and with the PF
-implementing VF management along with other PF-only functionalities/offloads.
-
The PMD PF has extra work to do which will delay the DPDK app initialization
-like uploading the firmware and configure the Link state properly when starting or
-stopping a PF port. Since DPDK 18.05 the firmware upload happens when
+like uploading the firmware and configure the Link state properly when starting
+or stopping a PF port. Since DPDK 18.05 the firmware upload happens when
a PF is initialized, which was not always true with older DPDK versions.
-Depending on the Netronome product installed in the system, firmware files
-should be available under ``/lib/firmware/netronome``. DPDK PMD supporting the
-PF looks for a firmware file in this order:
+Depending on the product installed in the system, firmware files should be
+available under ``/lib/firmware/netronome``. DPDK PMD supporting the PF looks
+for a firmware file in this order:
1) First try to find a firmware image specific for this device using the
NFP serial number:
@@ -92,18 +84,21 @@ PF looks for a firmware file in this order:
nic_AMDA0099-0001_2x25.nffw
-Netronome's software packages install firmware files under ``/lib/firmware/netronome``
-to support all the Netronome's SmartNICs and different firmware applications.
-This is usually done using file names based on SmartNIC type and media and with a
-directory per firmware application. Options 1 and 2 for firmware filenames allow
-more than one SmartNIC, same type of SmartNIC or different ones, and to upload a
-different firmware to each SmartNIC.
+Netronome and Corigine's software packages install firmware files under
+``/lib/firmware/netronome`` to support all the SmartNICs and different firmware
+applications. This is usually done using file names based on SmartNIC type and
+media and with a directory per firmware application. Options 1 and 2 for
+firmware filenames allow more than one SmartNIC, same type of SmartNIC or
+different ones, and to upload a different firmware to each SmartNIC.
.. Note::
- Currently the NFP PMD supports using the PF with Agilio Firmware with NFD3
- and Agilio Firmware with NFDk. See https://help.netronome.com/support/solutions
+ Currently the NFP PMD supports using the PF with Agilio Firmware with
+ NFD3 and Agilio Firmware with NFDk. See
+ `Netronome Support <https://help.netronome.com/support/solutions>`_.
for more information on the various firmwares supported by the Netronome
- Agilio CX smartNIC.
+ Agilio SmartNICs range, or
+ `Corigine Support <https://www.corigine.com/productsOverviewList-30.html>`_.
+ for more information about Corigine's range.
PF multiport support
--------------------
@@ -118,7 +113,7 @@ this particular configuration requires the PMD to create ports in a special way,
although once they are created, DPDK apps should be able to use them as normal
PCI ports.
-NFP ports belonging to same PF can be seen inside PMD initialization with a
+NFP ports belonging to the same PF can be seen inside PMD initialization with a
suffix added to the PCI ID: wwww:xx:yy.z_portn. For example, a PF with PCI ID
0000:03:00.0 and four ports is seen by the PMD code as:
@@ -137,50 +132,67 @@ suffix added to the PCI ID: wwww:xx:yy.z_portn. For example, a PF with PCI ID
PF multiprocess support
-----------------------
-Due to how the driver needs to access the NFP through a CPP interface, which implies
-to use specific registers inside the chip, the number of secondary processes with PF
-ports is limited to only one.
+Due to how the driver needs to access the NFP through a CPP interface, which
+implies to use specific registers inside the chip, the number of secondary
+processes with PF ports is limited to only one.
-This limitation will be solved in future versions but having basic multiprocess support
-is important for allowing development and debugging through the PF using a secondary
-process which will create a CPP bridge for user space tools accessing the NFP.
+This limitation will be solved in future versions, but having basic
+multiprocess support is important for allowing development and debugging
+through the PF using a secondary process, which will create a CPP bridge
+for user space tools accessing the NFP.
System configuration
--------------------
#. **Enable SR-IOV on the NFP device:** The current NFP PMD supports the PF and
- the VFs on a NFP device. However, it is not possible to work with both at the
- same time because the VFs require the PF being bound to the NFP PF Linux
- netdev driver. Make sure you are working with a kernel with NFP PF support or
- get the drivers from the above Github repository and follow the instructions
- for building and installing it.
+ the VFs on a NFP device. However, it is not possible to work with both at
+ the same time when using the netdev NFP Linux netdev driver. It is possible
+ to bind the PF to the ``vfio-pci`` kernel module, and create VFs afterwards.
+ This requires loading the ``vfio-pci`` module with the following parameters:
+
+ .. code-block:: console
+
+ modprobe vfio-pci enable_sriov=1 disable_idle_d3=1
+
+ VFs need to be enabled before they can be used with the PMD. Before enabling
+ the VFs it is useful to obtain information about the current NFP PCI device
+ detected by the system. This can be done on Netronome SmartNICs using:
+
+ .. code-block:: console
+
+ lspci -d 19ee:
- VFs need to be enabled before they can be used with the PMD.
- Before enabling the VFs it is useful to obtain information about the
- current NFP PCI device detected by the system:
+ and on Corigine SmartNICs using:
.. code-block:: console
- lspci -d19ee:
+ lspci -d 1da8:
- Now, for example, configure two virtual functions on a NFP-6xxx device
+ Now, for example, to configure two virtual functions on a NFP device
whose PCI system identity is "0000:03:00.0":
.. code-block:: console
echo 2 > /sys/bus/pci/devices/0000:03:00.0/sriov_numvfs
- The result of this command may be shown using lspci again:
+ The result of this command may be shown using lspci again on Netronome
+ SmartNICs:
+
+ .. code-block:: console
+
+ lspci -d 19ee: -k
+
+ and on Corigine SmartNICs:
.. code-block:: console
- lspci -d19ee: -k
+ lspci -d 1da8: -k
Two new PCI devices should appear in the output of the above command. The
- -k option shows the device driver, if any, that devices are bound to.
- Depending on the modules loaded at this point the new PCI devices may be
- bound to nfp_netvf driver.
+ -k option shows the device driver, if any, that the devices are bound to.
+ Depending on the modules loaded, at this point the new PCI devices may be
+ bound to the ``nfp`` kernel driver or ``vfio-pci``.
Flow offload
@@ -193,13 +205,13 @@ The flower firmware application requires the PMD running two services:
* PF vNIC service: handling the feedback traffic.
* ctrl vNIC service: communicate between PMD and firmware through
- control message.
+ control messages.
To achieve the offload of flow, the representor ports are exposed to OVS.
-The flower firmware application support representor port for VF and physical
-port. There will always exist a representor port for each physical port,
-and the number of the representor port for VF is specified by the user through
-parameter.
+The flower firmware application supports VF, PF, and physical port representor
+ports. There will always exist a representor port for a PF and each physical
+port. The number of the representor ports for VFs are specified by the user
+through a parameter.
In the Rx direction, the flower firmware application will prepend the input
port information into metadata for each packet which can't offloaded. The PF
@@ -207,12 +219,12 @@ vNIC service will keep polling packets from the firmware, and multiplex them
to the corresponding representor port.
In the Tx direction, the representor port will prepend the output port
-information into metadata for each packet, and then send it to firmware through
-PF vNIC.
+information into metadata for each packet, and then send it to the firmware
+through the PF vNIC.
-The ctrl vNIC service handling various control message, like the creation and
-configuration of representor port, the pattern and action of flow rules, the
-statistics of flow rules, and so on.
+The ctrl vNIC service handles various control messages, for example, the
+creation and configuration of a representor port, the pattern and action of
+flow rules, the statistics of flow rules, etc.
Metadata Format
---------------
--
2.29.3
^ permalink raw reply [relevance 6%]
* [PATCH v3 1/2] ethdev: introduce the PHY affinity field in Tx queue API
@ 2023-02-03 5:07 6% ` Jiawei Wang
1 sibling, 0 replies; 200+ results
From: Jiawei Wang @ 2023-02-03 5:07 UTC (permalink / raw)
To: viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko
Cc: dev, rasland
For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the
phy affinity of the received packets.
Add the tx_phy_affinity setting in Tx queue API, the affinity
value reflects packets be sent to which hardware port.
Value 0 is no affinity and traffic will be routed between different
physical ports.
Add the nb_phy_ports into device info and value greater than 0 mean
that the number of physical ports connect to the DPDK port.
Add the new tx_phy_affinity field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.
Add the testpmd command line:
testpmd> port config (port_id) txq (queue_id) phy_affinity (value)
For example, there're two hardware ports 0 and 1 connected to
a single DPDK port (port id 0), and phy_affinity 1 stood for
hardware port 0 and phy_affinity 2 stood for hardware port 1,
used the below command to config tx phy affinity for per Tx Queue:
port config 0 txq 0 phy_affinity 1
port config 0 txq 1 phy_affinity 1
port config 0 txq 2 phy_affinity 2
port config 0 txq 3 phy_affinity 2
These commands config the TxQ index 0 and TxQ index 1 with phy affinity 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 0, and similar with hardware port 1 if sending packets
with TxQ 2 or TxQ 3.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
---
app/test-pmd/cmdline.c | 100 ++++++++++++++++++++
app/test-pmd/config.c | 1 +
devtools/libabigail.abignore | 5 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 +++
lib/ethdev/rte_ethdev.h | 13 ++-
5 files changed, 131 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd4..3450b1be36 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -764,6 +764,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
" Cleanup txq mbufs for a specific Tx queue\n\n"
+
+ "port config (port_id) txq (queue_id) phy_affinity (value)\n"
+ " Set the physical affinity value "
+ "on a specific Tx queue\n\n"
);
}
@@ -12621,6 +12625,101 @@ static cmdline_parse_inst_t cmd_show_port_flow_transfer_proxy = {
}
};
+/* *** configure port txq phy_affinity value *** */
+struct cmd_config_tx_phy_affinity {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t config;
+ portid_t portid;
+ cmdline_fixed_string_t txq;
+ uint16_t qid;
+ cmdline_fixed_string_t phy_affinity;
+ uint8_t value;
+};
+
+static void
+cmd_config_tx_phy_affinity_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_config_tx_phy_affinity *res = parsed_result;
+ struct rte_eth_dev_info dev_info;
+ struct rte_port *port;
+ int ret;
+
+ if (port_id_is_invalid(res->portid, ENABLED_WARN))
+ return;
+
+ if (res->portid == (portid_t)RTE_PORT_ALL) {
+ printf("Invalid port id\n");
+ return;
+ }
+
+ port = &ports[res->portid];
+
+ if (strcmp(res->txq, "txq")) {
+ printf("Unknown parameter\n");
+ return;
+ }
+ if (tx_queue_id_is_invalid(res->qid))
+ return;
+
+ ret = eth_dev_info_get_print_err(res->portid, &dev_info);
+ if (ret != 0)
+ return;
+
+ if (dev_info.nb_phy_ports == 0) {
+ printf("Number of physical ports is 0 which is invalid for PHY Affinity\n");
+ return;
+ }
+ printf("The number of physical ports is %u\n", dev_info.nb_phy_ports);
+ if (dev_info.nb_phy_ports < res->value) {
+ printf("The PHY affinity value %u is Invalid, exceeds the "
+ "number of physical ports\n", res->value);
+ return;
+ }
+ port->txq[res->qid].conf.tx_phy_affinity = res->value;
+
+ cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ port, "port");
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_config =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ config, "config");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_portid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_txq =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_qid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_hwport =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ phy_affinity, "phy_affinity");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_value =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ value, RTE_UINT8);
+
+static cmdline_parse_inst_t cmd_config_tx_phy_affinity = {
+ .f = cmd_config_tx_phy_affinity_parsed,
+ .data = (void *)0,
+ .help_str = "port config <port_id> txq <queue_id> phy_affinity <value>",
+ .tokens = {
+ (void *)&cmd_config_tx_phy_affinity_port,
+ (void *)&cmd_config_tx_phy_affinity_config,
+ (void *)&cmd_config_tx_phy_affinity_portid,
+ (void *)&cmd_config_tx_phy_affinity_txq,
+ (void *)&cmd_config_tx_phy_affinity_qid,
+ (void *)&cmd_config_tx_phy_affinity_hwport,
+ (void *)&cmd_config_tx_phy_affinity_value,
+ NULL,
+ },
+};
+
/* ******************************************************************************** */
/* list of instructions */
@@ -12851,6 +12950,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_show_capability,
(cmdline_parse_inst_t *)&cmd_set_flex_is_pattern,
(cmdline_parse_inst_t *)&cmd_set_flex_spec_pattern,
+ (cmdline_parse_inst_t *)&cmd_config_tx_phy_affinity,
NULL,
};
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index acccb6b035..b83fb17cfa 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -936,6 +936,7 @@ port_infos_display(portid_t port_id)
printf("unknown\n");
break;
}
+ printf("Current number of physical ports: %u\n", dev_info.nb_phy_ports);
}
void
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..0f4b5ec74b 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -34,3 +34,8 @@
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Temporary exceptions till next major ABI version ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
+
+; Ignore fields inserted in middle padding of rte_eth_txconf
+[suppress_type]
+ name = rte_eth_txconf
+ has_data_member_inserted_between = {offset_of(tx_deferred_start), offset_of(offloads)}
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 0037506a79..856fb55005 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1605,6 +1605,19 @@ Enable or disable a per queue Tx offloading only on a specific Tx queue::
This command should be run when the port is stopped, or else it will fail.
+config per queue Tx physical affinity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Configure a per queue physical affinity value only on a specific Tx queue::
+
+ testpmd> port (port_id) txq (queue_id) phy_affinity (value)
+
+* ``phy_affinity``: reflects packet can be sent to which hardware port.
+ uses it on multiple hardware ports connect to
+ a single DPDK port (mhpsdp).
+
+This command should be run when the port is stopped, or else it will fail.
+
Config VXLAN Encap outer layers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index c129ca1eaf..ecfa2c6781 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1138,6 +1138,16 @@ struct rte_eth_txconf {
less free descriptors than this value. */
uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
+ /**
+ * Physical affinity to be set.
+ * Value 0 is no affinity and traffic could be routed between different
+ * physical ports, if 0 is disabled then try to match on phy_affinity 0 will
+ * result in an error.
+ *
+ * Value starts from 1 means for specific phy affinity and uses 1 for
+ * the first physical port.
+ */
+ uint8_t tx_phy_affinity;
/**
* Per-queue Tx offloads to be set using RTE_ETH_TX_OFFLOAD_* flags.
* Only offloads set on tx_queue_offload_capa or tx_offload_capa
@@ -1777,7 +1787,8 @@ struct rte_eth_dev_info {
struct rte_eth_switch_info switch_info;
/** Supported error handling mode. */
enum rte_eth_err_handle_mode err_handle_mode;
-
+ uint8_t nb_phy_ports;
+ /** Number of physical ports to connect with single DPDK port. */
uint64_t reserved_64s[2]; /**< Reserved for future fields */
void *reserved_ptrs[2]; /**< Reserved for future fields */
};
--
2.18.1
^ permalink raw reply [relevance 6%]
* RE: Sign changes through function signatures
2023-02-02 20:45 3% ` Thomas Monjalon
@ 2023-02-02 21:26 3% ` Morten Brørup
2023-02-03 12:05 4% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2023-02-02 21:26 UTC (permalink / raw)
To: Thomas Monjalon, Ben Magistro, Tyler Retzlaff, bruce.richardson
Cc: Olivier Matz, ferruh.yigit, andrew.rybchenko, ben.magistro, dev,
Stefan Baranoff, david.marchand, anatoly.burakov
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Thursday, 2 February 2023 21.45
>
> 02/02/2023 21:26, Tyler Retzlaff:
> > On Thu, Feb 02, 2023 at 02:23:39PM -0500, Ben Magistro wrote:
> > > Hello,
> > >
> > > While making some updates to our code base for 22.11.1 that were
> missed in
> > > our first pass through, we hit the numa node change[1]. In the
> process of
> > > updating our code, we noticed that a couple functions
> (rx/tx_queue_setup,
> > > maybe more that we aren't using) state they accept `SOCKET_ID_ANY`
> but the
> > > function signature then asks for an unsigned integer while
> `SOCKET_ID_ANY`
> > > is `-1`. Following it through the redirect to the "real" function
> it also
> > > asks for an unsigned integer which is then passed on to one or more
> > > functions asking for an integer. As an example using the the i40e
> driver
> > > -- we would call `rte_eth_tx_queue_setup` [2] which ultimately
> calls
> > > `i40e_dev_tx_queue_setup`[3] which finally calls
> `rte_zmalloc_socket`[4]
> > > and `rte_eth_dma_zone_reserve`[5].
> > >
> > > I guess what I am looking for is clarification on if this is
> intentional or
> > > if this is additional cleanup that may need to be completed/be
> desirable so
> > > that signs are maintained through the call paths and avoid
> potentially
> > > producing sign-conversion warnings. From the very quick glance I
> took at
> > > the i40e driver, it seems these are just passed through to other
> functions
> > > and no direct use/manipulation occurs (at least in the mentioned
> functions).
> >
> > i believe this is just sloppyness with sign in our api surface. i too
> > find it frustrating that use of these api force either explicit
> > casts or suffer having to suppress warnings.
> >
> > in the past examples of this have been cleaned up without full
> deprecation
> > notices but there are a lot of instances. i also feel (unpopular
> opinion)
> > that for some integer types like this that have constrained range /
> number
> > spaces it would be of value to introduce a typedef that can be used
> > consistently.
> >
> > for now you'll just have to add the casts and hopefully in the future
> we
> > will fix the api making them unnecessary. of course feel free to
> submit
> > patches too, it would be great to have these cleaned up.
>
> I agree it should be cleaned up.
> Those IDs should accept negative values.
> Not sure which type we should choose (int, int32_t, or a typedef).
Why would we use a signed socket ID? We don't use signed port IDs. To me, unsigned seems the way to go. (A minor detail: With unsigned we can use the entire range of values minus one (for the magic "any" value), whereas with signed we can only use the positive range of values. This detail is completely irrelevant when using 32 bit for socket ID, but could be relevant if using fewer bits.)
Also, we don't need 32 bit for socket ID. 8 or 16 bit should suffice, like port ID. But reducing from 32 bit would probably cause major ABI breakage.
>
> Another thing to check is the name of the variable.
> It should be a socket ID when talking about CPU,
> and a NUMA node ID when talking about memory.
>
> And last but not the least,
> how can we keep ABI compatibility?
> I hope we can use function versioning to avoid deprecation and
> breaking.
>
> Trials and suggestions are welcome.
Signedness is not the only problem with the socket ID. The meaning of SOCKET_ID_ANY is excessively overloaded. If we want to clean this up, we should consider the need for another magic value SOCKET_ID_NONE for devices connected to the chipset, as discussed in this other email thread [1]. And as discussed there, there are also size problems, because some device structures use 8 bit to hold the socket ID.
And functions should always return -1, never SOCKET_ID_ANY, to indicate error.
[1]: http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87684@smartserver.smartshare.dk/
I only bring warnings and complications to the discussion here, no solutions. Sorry! :-(
^ permalink raw reply [relevance 3%]
* Re: Sign changes through function signatures
@ 2023-02-02 20:45 3% ` Thomas Monjalon
2023-02-02 21:26 3% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-02-02 20:45 UTC (permalink / raw)
To: Ben Magistro, Tyler Retzlaff
Cc: Olivier Matz, ferruh.yigit, andrew.rybchenko, ben.magistro, dev,
Stefan Baranoff, david.marchand, bruce.richardson,
anatoly.burakov
02/02/2023 21:26, Tyler Retzlaff:
> On Thu, Feb 02, 2023 at 02:23:39PM -0500, Ben Magistro wrote:
> > Hello,
> >
> > While making some updates to our code base for 22.11.1 that were missed in
> > our first pass through, we hit the numa node change[1]. In the process of
> > updating our code, we noticed that a couple functions (rx/tx_queue_setup,
> > maybe more that we aren't using) state they accept `SOCKET_ID_ANY` but the
> > function signature then asks for an unsigned integer while `SOCKET_ID_ANY`
> > is `-1`. Following it through the redirect to the "real" function it also
> > asks for an unsigned integer which is then passed on to one or more
> > functions asking for an integer. As an example using the the i40e driver
> > -- we would call `rte_eth_tx_queue_setup` [2] which ultimately calls
> > `i40e_dev_tx_queue_setup`[3] which finally calls `rte_zmalloc_socket`[4]
> > and `rte_eth_dma_zone_reserve`[5].
> >
> > I guess what I am looking for is clarification on if this is intentional or
> > if this is additional cleanup that may need to be completed/be desirable so
> > that signs are maintained through the call paths and avoid potentially
> > producing sign-conversion warnings. From the very quick glance I took at
> > the i40e driver, it seems these are just passed through to other functions
> > and no direct use/manipulation occurs (at least in the mentioned functions).
>
> i believe this is just sloppyness with sign in our api surface. i too
> find it frustrating that use of these api force either explicit
> casts or suffer having to suppress warnings.
>
> in the past examples of this have been cleaned up without full deprecation
> notices but there are a lot of instances. i also feel (unpopular opinion)
> that for some integer types like this that have constrained range / number
> spaces it would be of value to introduce a typedef that can be used
> consistently.
>
> for now you'll just have to add the casts and hopefully in the future we
> will fix the api making them unnecessary. of course feel free to submit
> patches too, it would be great to have these cleaned up.
I agree it should be cleaned up.
Those IDs should accept negative values.
Not sure which type we should choose (int, int32_t, or a typedef).
Another thing to check is the name of the variable.
It should be a socket ID when talking about CPU,
and a NUMA node ID when talking about memory.
And last but not the least,
how can we keep ABI compatibility?
I hope we can use function versioning to avoid deprecation and breaking.
Trials and suggestions are welcome.
^ permalink raw reply [relevance 3%]
* RE: [PATCH] eal: introduce atomics abstraction
2023-02-02 19:00 4% ` Tyler Retzlaff
@ 2023-02-02 20:44 0% ` Morten Brørup
2023-02-03 13:56 0% ` Bruce Richardson
2023-02-03 12:19 0% ` Bruce Richardson
1 sibling, 1 reply; 200+ results
From: Morten Brørup @ 2023-02-02 20:44 UTC (permalink / raw)
To: Tyler Retzlaff
Cc: Honnappa Nagarahalli, thomas, dev, bruce.richardson,
david.marchand, jerinj, konstantin.ananyev, ferruh.yigit, nd
> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Thursday, 2 February 2023 20.00
>
> On Thu, Feb 02, 2023 at 09:43:58AM +0100, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > > Sent: Wednesday, 1 February 2023 22.41
> > >
> > > On Wed, Feb 01, 2023 at 01:07:59AM +0000, Honnappa Nagarahalli
> wrote:
> > > >
> > > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > > Sent: Tuesday, January 31, 2023 4:42 PM
> > > > >
> > > > > Honnappa, please could you give your view on the future of
> atomics
> > > in DPDK?
> > > > Thanks Thomas, apologies it has taken me a while to get to this
> > > discussion.
> > > >
> > > > IMO, we do not need DPDK's own abstractions. APIs from
> stdatomic.h
> > > (stdatomics as is called here) already serve the purpose. These
> APIs
> > > are well understood and documented.
> > >
> > > i agree that whatever atomics APIs we advocate for should align
> with
> > > the
> > > standard C atomics for the reasons you state including implied
> > > semantics.
> > >
> > > >
> > > > For environments where stdatomics are not supported, we could
> have a
> > > stdatomic.h in DPDK implementing the same APIs (we have to support
> only
> > > _explicit APIs). This allows the code to use stdatomics APIs and
> when
> > > we move to minimum supported standard C11, we just need to get rid
> of
> > > the file in DPDK repo.
> >
> > Perhaps we can use something already existing, such as this:
> > https://android.googlesource.com/platform/bionic/+/lollipop-
> release/libc/include/stdatomic.h
> >
> > >
> > > my concern with this is that if we provide a stdatomic.h or
> introduce
> > > names
> > > from stdatomic.h it's a violation of the C standard.
> > >
> > > references:
> > > * ISO/IEC 9899:2011 sections 7.1.2, 7.1.3.
> > > * GNU libc manual
> > > https://www.gnu.org/software/libc/manual/html_node/Reserved-
> > > Names.html
> > >
> > > in effect the header, the names and in some instances namespaces
> > > introduced
> > > are reserved by the implementation. there are several reasons in
> the
> > > GNU libc
> > > manual that explain the justification for these reservations and if
> > > if we think about ODR and ABI compatibility we can conceive of
> others.
> >
> > I we are going to move to C11 soon, I consider the shim interim, and
> am inclined to ignore these warning factors.
> >
> > If we are not moving to C11 soon, I would consider these
> disadvantages more seriously.
>
> I think it's reasonable to assume that we are talking years here.
>
> We've had a few discussions about minimum C standard. I think my first
> mailing list exchanges about C99 was almost 2 years ago. Given that we
> still aren't on C99 now (though i know Bruce has a series up) indicates
> that progression to C11 isn't going to happen any time soon and even if
> it was the baseline we still can't just use it (reasons described
> later).
>
> Also, i'll point out that we seem to have accepted moving to C99 with
> one of the holdback compilers technically being non-conformant but it
> isn't blocking us because it provides the subset of C99 features
> without
> being conforming that we happen to be using.
>
> >
> > >
> > > i'll also remark that the inter-mingling of names from the POSIX
> > > standard implicitly exposed as a part of the EAL public API has
> been
> > > problematic for portability.
> >
> > This is a very important remark, which should be considered
> carefully! Tyler has firsthand experience with DPDK portability. If he
> thinks porting to Windows is going to be a headache if we expose the
> stdatomic.h API, we must listen! So, what is your gut feeling here,
> Tyler?
>
> I think this is even more of a concern with language standard than it
> is
> with a platform standard. Because the language standard is used across
> platforms.
>
> On the surface it looks appealing to just go through all the dpdk code
> one last time and #include <stdatomic.h> and directly depend on names
> that "look" standard. In practice though we aren't depending on the
> toolchain / libc surface we are binding ourselves to the shim and the
> implementation it provides.
>
> This is aside from the mechanics of making it work in the different
> contexts we now have to care about. Here is a story of how things
> become tricky.
>
> When i #include <stdatomic.h> which one gets used if the implementation
> provides one? Let's force our stdatomic.h
>
> Now i need to force the build system to prefer my shim header? Keeping
> in mind that the presence of a libc stdatomic.h does not mean that the
> toolchain in fact supports standard atomics. Okay, that's under our
> control by editing some meson.build files maybe it isn't so bad but...
>
> It seems my application also has to do the same in their build system
> now because...
>
> The type definitions (size, alignment) and code generated from the
> body of inline functions as seen by the application built translation
> units may differ from those in the dpdk translation units if they don't
> use our header. The potential for ABI compat problems is increasing but
> maybe it is managable? it can be worse...
>
> We can't limit our scope to thinking that there is just an
> application (a single binary) and dpdk. Complex applications will
> invariably depend on other libraries and if the application needs to
> interface with those compatibily at the ABI level using standard
> atomics
> then we've made it very difficult since the application has to choose
> to
> use our conflicting named atomic types which may not be compatible or
> the real standard atomics. They can of course produce horrible shims
> of their own to interoperate.
>
> We need consistency across the entire binary at runtime and i don't
> think it's practical to say that anyone who uses dpdk has to compile
> their whole world with our shim. So dealing with all this complexity
> for the sake of asthetics "looking" like the standard api seems kind
> of not worth it. Sure it saves having to deprecate later and one last
> session of shotgun surgery but that's kind of all we get.
>
> Don't think i'm being biased in favor of windows/msvc here. From the
> perspective of the windows/msvc combination i intend to use only the
> standard C ABI provided by the implementation. I have no intention of
> trying to introduce support for the current ABI that doesn't use the
> standard atomic types. my discouraging of this approach is about
> avoiding
> subtle to detect but very painful problems on
> {linux,unix}/compiler<version>
> combinations that already have a shipped/stable ABI.
>
> > >
> > > let's discuss this from here. if there's still overwhelming desire
> to
> > > go
> > > this route then we'll just do our best.
> > >
> > > ty
> >
> > I have a preference for exposing the stdatomic.h API. Tyler listed
> the disadvantages above. (I also have a preference for moving to C11
> soon.)
>
> I am eager to see this happen, but as explained in my original proposal
> it doesn't eliminate the need for an abstraction. Unless we are willing
> to break our compatibility promises and potentially take a performance
> hit on some platform/compiler combinations which as i understand is not
> acceptable.
>
> >
> > Exposing a 1:1 similar API with RTE prefixes would also be acceptable
> for me. The disadvantage is that the names are different than the C11
> names, which might lead to some confusion. And from an ABI stability
> perspective, such an important API should not be marked experimental.
> This means that years will pass before we can get rid of it again, due
> to ABI stability policies.
>
> I think the key to success with rte_ prefixed names is making
> absolutely
> sure we mirror the semantics and types in the standard.
>
> I will point out one bit of fine print here is that we will not support
> atomic operations on struct/union types (something the standard
> supports).
> With the rte_ namespace i think this becomes less ambiguous, if we
> present
> standard C names though what's to avoid the confusion? Aside from it
> fails
> to compile with one compiler vs another.
>
> I agree that this may be around for years. But how many years depends a
> lot on how long we have to maintain compatibility for the existing
> platform/compiler combinations that can't (and aren't enabled) to use
> the standard.
>
> Even if we introduced standard names we still have to undergo some kind
> of mutant deprecation process to get the world to recompile everything
> against the actual standard, so it doesn't give us forward
> compatibility.
>
> Let me know what folks would like to do, i guess i'm firmly leaned
> toward no-shim and just rte_ explicit. But as a community i'll pursue
> whatever you decide.
>
> Thanks!
Tyler is making a very strong case here.
I have changed my mind, and now support Tyler's approach.
-Morten
^ permalink raw reply [relevance 0%]
* Re: [PATCH] eal: introduce atomics abstraction
2023-02-02 8:43 4% ` Morten Brørup
@ 2023-02-02 19:00 4% ` Tyler Retzlaff
2023-02-02 20:44 0% ` Morten Brørup
2023-02-03 12:19 0% ` Bruce Richardson
0 siblings, 2 replies; 200+ results
From: Tyler Retzlaff @ 2023-02-02 19:00 UTC (permalink / raw)
To: Morten Brørup
Cc: Honnappa Nagarahalli, thomas, dev, bruce.richardson,
david.marchand, jerinj, konstantin.ananyev, ferruh.yigit, nd
On Thu, Feb 02, 2023 at 09:43:58AM +0100, Morten Brørup wrote:
> > From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> > Sent: Wednesday, 1 February 2023 22.41
> >
> > On Wed, Feb 01, 2023 at 01:07:59AM +0000, Honnappa Nagarahalli wrote:
> > >
> > > > From: Thomas Monjalon <thomas@monjalon.net>
> > > > Sent: Tuesday, January 31, 2023 4:42 PM
> > > >
> > > > Honnappa, please could you give your view on the future of atomics
> > in DPDK?
> > > Thanks Thomas, apologies it has taken me a while to get to this
> > discussion.
> > >
> > > IMO, we do not need DPDK's own abstractions. APIs from stdatomic.h
> > (stdatomics as is called here) already serve the purpose. These APIs
> > are well understood and documented.
> >
> > i agree that whatever atomics APIs we advocate for should align with
> > the
> > standard C atomics for the reasons you state including implied
> > semantics.
> >
> > >
> > > For environments where stdatomics are not supported, we could have a
> > stdatomic.h in DPDK implementing the same APIs (we have to support only
> > _explicit APIs). This allows the code to use stdatomics APIs and when
> > we move to minimum supported standard C11, we just need to get rid of
> > the file in DPDK repo.
>
> Perhaps we can use something already existing, such as this:
> https://android.googlesource.com/platform/bionic/+/lollipop-release/libc/include/stdatomic.h
>
> >
> > my concern with this is that if we provide a stdatomic.h or introduce
> > names
> > from stdatomic.h it's a violation of the C standard.
> >
> > references:
> > * ISO/IEC 9899:2011 sections 7.1.2, 7.1.3.
> > * GNU libc manual
> > https://www.gnu.org/software/libc/manual/html_node/Reserved-
> > Names.html
> >
> > in effect the header, the names and in some instances namespaces
> > introduced
> > are reserved by the implementation. there are several reasons in the
> > GNU libc
> > manual that explain the justification for these reservations and if
> > if we think about ODR and ABI compatibility we can conceive of others.
>
> I we are going to move to C11 soon, I consider the shim interim, and am inclined to ignore these warning factors.
>
> If we are not moving to C11 soon, I would consider these disadvantages more seriously.
I think it's reasonable to assume that we are talking years here.
We've had a few discussions about minimum C standard. I think my first
mailing list exchanges about C99 was almost 2 years ago. Given that we
still aren't on C99 now (though i know Bruce has a series up) indicates
that progression to C11 isn't going to happen any time soon and even if
it was the baseline we still can't just use it (reasons described
later).
Also, i'll point out that we seem to have accepted moving to C99 with
one of the holdback compilers technically being non-conformant but it
isn't blocking us because it provides the subset of C99 features without
being conforming that we happen to be using.
>
> >
> > i'll also remark that the inter-mingling of names from the POSIX
> > standard implicitly exposed as a part of the EAL public API has been
> > problematic for portability.
>
> This is a very important remark, which should be considered carefully! Tyler has firsthand experience with DPDK portability. If he thinks porting to Windows is going to be a headache if we expose the stdatomic.h API, we must listen! So, what is your gut feeling here, Tyler?
I think this is even more of a concern with language standard than it is
with a platform standard. Because the language standard is used across
platforms.
On the surface it looks appealing to just go through all the dpdk code
one last time and #include <stdatomic.h> and directly depend on names
that "look" standard. In practice though we aren't depending on the
toolchain / libc surface we are binding ourselves to the shim and the
implementation it provides.
This is aside from the mechanics of making it work in the different
contexts we now have to care about. Here is a story of how things
become tricky.
When i #include <stdatomic.h> which one gets used if the implementation
provides one? Let's force our stdatomic.h
Now i need to force the build system to prefer my shim header? Keeping
in mind that the presence of a libc stdatomic.h does not mean that the
toolchain in fact supports standard atomics. Okay, that's under our
control by editing some meson.build files maybe it isn't so bad but...
It seems my application also has to do the same in their build system
now because...
The type definitions (size, alignment) and code generated from the
body of inline functions as seen by the application built translation
units may differ from those in the dpdk translation units if they don't
use our header. The potential for ABI compat problems is increasing but
maybe it is managable? it can be worse...
We can't limit our scope to thinking that there is just an
application (a single binary) and dpdk. Complex applications will
invariably depend on other libraries and if the application needs to
interface with those compatibily at the ABI level using standard atomics
then we've made it very difficult since the application has to choose to
use our conflicting named atomic types which may not be compatible or
the real standard atomics. They can of course produce horrible shims
of their own to interoperate.
We need consistency across the entire binary at runtime and i don't
think it's practical to say that anyone who uses dpdk has to compile
their whole world with our shim. So dealing with all this complexity
for the sake of asthetics "looking" like the standard api seems kind
of not worth it. Sure it saves having to deprecate later and one last
session of shotgun surgery but that's kind of all we get.
Don't think i'm being biased in favor of windows/msvc here. From the
perspective of the windows/msvc combination i intend to use only the
standard C ABI provided by the implementation. I have no intention of
trying to introduce support for the current ABI that doesn't use the
standard atomic types. my discouraging of this approach is about avoiding
subtle to detect but very painful problems on {linux,unix}/compiler<version>
combinations that already have a shipped/stable ABI.
> >
> > let's discuss this from here. if there's still overwhelming desire to
> > go
> > this route then we'll just do our best.
> >
> > ty
>
> I have a preference for exposing the stdatomic.h API. Tyler listed the disadvantages above. (I also have a preference for moving to C11 soon.)
I am eager to see this happen, but as explained in my original proposal
it doesn't eliminate the need for an abstraction. Unless we are willing
to break our compatibility promises and potentially take a performance
hit on some platform/compiler combinations which as i understand is not
acceptable.
>
> Exposing a 1:1 similar API with RTE prefixes would also be acceptable for me. The disadvantage is that the names are different than the C11 names, which might lead to some confusion. And from an ABI stability perspective, such an important API should not be marked experimental. This means that years will pass before we can get rid of it again, due to ABI stability policies.
I think the key to success with rte_ prefixed names is making absolutely
sure we mirror the semantics and types in the standard.
I will point out one bit of fine print here is that we will not support
atomic operations on struct/union types (something the standard supports).
With the rte_ namespace i think this becomes less ambiguous, if we present
standard C names though what's to avoid the confusion? Aside from it fails
to compile with one compiler vs another.
I agree that this may be around for years. But how many years depends a
lot on how long we have to maintain compatibility for the existing
platform/compiler combinations that can't (and aren't enabled) to use
the standard.
Even if we introduced standard names we still have to undergo some kind
of mutant deprecation process to get the world to recompile everything
against the actual standard, so it doesn't give us forward
compatibility.
Let me know what folks would like to do, i guess i'm firmly leaned
toward no-shim and just rte_ explicit. But as a community i'll pursue
whatever you decide.
Thanks!
^ permalink raw reply [relevance 4%]
* Re: [PATCH V8] ethdev: fix one address occupies two entries in MAC addrs
2023-02-02 12:36 3% ` [PATCH V8] " Huisong Li
@ 2023-02-02 18:09 0% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-02-02 18:09 UTC (permalink / raw)
To: Huisong Li, dev
Cc: thomas, andrew.rybchenko, liudongdong3, huangdaode, fengchengwen
On 2/2/2023 12:36 PM, Huisong Li wrote:
> The dev->data->mac_addrs[0] will be changed to a new MAC address when
> applications modify the default MAC address by .mac_addr_set(). However,
> if the new default one has been added as a non-default MAC address by
> .mac_addr_add(), the .mac_addr_set() doesn't remove it from the mac_addrs
> list. As a result, one MAC address occupies two entries in the list. Like:
> add(MAC1)
> add(MAC2)
> add(MAC3)
> add(MAC4)
> set_default(MAC3)
> default=MAC3, the rest of the list=MAC1, MAC2, MAC3, MAC4
> Note: MAC3 occupies two entries.
>
> In addition, some PMDs, such as i40e, ice, hns3 and so on, do remove the
> old default MAC when set default MAC. If user continues to do
> set_default(MAC5), and the mac_addrs list is default=MAC5, filters=(MAC1,
> MAC2, MAC3, MAC4). At this moment, user can still see MAC3 from the list,
> but packets with MAC3 aren't actually received by the PMD.
>
> So need to ensure that the new default address is removed from the rest of
> the list if the address was already in the list.
>
Same comment from past seems already valid, I am not looking to the set
for a while, sorry if this is already discussed and decided,
if not, I am referring to the side effect that setting MAC addresses
cause to remove MAC addresses, think following case:
add(MAC1) -> MAC1
add(MAC2) -> MAC1, MAC2
add(MAC3) -> MAC1, MAC2, MAC3
add(MAC4) -> MAC1, MAC2, MAC3, MAC4
set(MAC3) -> MAC3, MAC2, MAC4
set(MAC4) -> MAC4, MAC2
set(MAC2) -> MAC2
I am not exactly clear what is the intention with set(), if there is
single MAC I guess intention is to replace it with new one, but if there
are multiple MACs and one of them are already in the list intention may
be just to change the default MAC.
If above assumption is correct, what about following:
set(MAC) {
if only_default_mac_exist
replace_default_mac
if MAC exists in list
swap MAC and list[0]
else
replace_default_mac
}
This swap prevents removing MAC side affect, does it make sense?
> Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier")
> Cc: stable@dpdk.org
>
> Signed-off-by: Huisong Li <lihuisong@huawei.com>
> Acked-by: Chengwen Feng <fengchengwen@huawei.com>
> ---
> v8: fix some comments.
> v7: add announcement in the release notes and document this behavior.
> v6: fix commit log and some code comments.
> v5:
> - merge the second patch into the first patch.
> - add error log when rollback failed.
> v4:
> - fix broken in the patchwork
> v3:
> - first explicitly remove the non-default MAC, then set default one.
> - document default and non-default MAC address
> v2:
> - fixed commit log.
> ---
> doc/guides/rel_notes/release_23_03.rst | 6 +++++
> lib/ethdev/ethdev_driver.h | 6 ++++-
> lib/ethdev/rte_ethdev.c | 35 ++++++++++++++++++++++++--
> lib/ethdev/rte_ethdev.h | 3 +++
> 4 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
> index 84b112a8b1..1c9b9912c2 100644
> --- a/doc/guides/rel_notes/release_23_03.rst
> +++ b/doc/guides/rel_notes/release_23_03.rst
> @@ -105,6 +105,12 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* ethdev: ensured all entries in MAC address list are uniques.
> + When setting a default MAC address with the function
> + ``rte_eth_dev_default_mac_addr_set``,
> + the address is now removed from the rest of the address list
> + in order to ensure it is only at index 0 of the list.
> +
>
> ABI Changes
> -----------
> diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
> index dde3ec84ef..3994c61b86 100644
> --- a/lib/ethdev/ethdev_driver.h
> +++ b/lib/ethdev/ethdev_driver.h
> @@ -117,7 +117,11 @@ struct rte_eth_dev_data {
>
> uint64_t rx_mbuf_alloc_failed; /**< Rx ring mbuf allocation failures */
>
> - /** Device Ethernet link address. @see rte_eth_dev_release_port() */
> + /**
> + * Device Ethernet link addresses.
> + * All entries are unique.
> + * The first entry (index zero) is the default address.
> + */
> struct rte_ether_addr *mac_addrs;
> /** Bitmap associating MAC addresses to pools */
> uint64_t mac_pool_sel[RTE_ETH_NUM_RECEIVE_MAC_ADDR];
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 86ca303ab5..de25183619 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -4498,7 +4498,10 @@ rte_eth_dev_mac_addr_remove(uint16_t port_id, struct rte_ether_addr *addr)
> int
> rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr)
> {
> + uint64_t mac_pool_sel_bk = 0;
> struct rte_eth_dev *dev;
> + uint32_t pool;
> + int index;
> int ret;
>
> RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> @@ -4517,16 +4520,44 @@ rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr)
> if (*dev->dev_ops->mac_addr_set == NULL)
> return -ENOTSUP;
>
> + /* Keep address unique in dev->data->mac_addrs[]. */
> + index = eth_dev_get_mac_addr_index(port_id, addr);
> + if (index > 0) {
> + /* Remove address in dev data structure */
> + mac_pool_sel_bk = dev->data->mac_pool_sel[index];
> + ret = rte_eth_dev_mac_addr_remove(port_id, addr);
> + if (ret < 0) {
> + RTE_ETHDEV_LOG(ERR, "Cannot remove the port %u address from the rest of list.\n",
> + port_id);
> + return ret;
> + }
> + }
> ret = (*dev->dev_ops->mac_addr_set)(dev, addr);
> if (ret < 0)
> - return ret;
> + goto out;
>
> /* Update default address in NIC data structure */
> rte_ether_addr_copy(addr, &dev->data->mac_addrs[0]);
>
> return 0;
> -}
>
> +out:
> + if (index > 0) {
> + pool = 0;
> + do {
> + if (mac_pool_sel_bk & UINT64_C(1)) {
> + if (rte_eth_dev_mac_addr_add(port_id, addr,
> + pool) != 0)
> + RTE_ETHDEV_LOG(ERR, "failed to restore MAC pool id(%u) in port %u.\n",
> + pool, port_id);
> + }
> + mac_pool_sel_bk >>= 1;
> + pool++;
> + } while (mac_pool_sel_bk != 0);
> + }
> +
> + return ret;
> +}
>
> /*
> * Returns index into MAC address array of addr. Use 00:00:00:00:00:00 to find
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index d22de196db..2456153457 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -4356,6 +4356,9 @@ int rte_eth_dev_mac_addr_remove(uint16_t port_id,
>
> /**
> * Set the default MAC address.
> + * It replaces the address at index 0 of the MAC address list.
> + * If the address was already in the MAC address list,
> + * it is removed from the rest of the list.
> *
> * @param port_id
> * The port identifier of the Ethernet device.
^ permalink raw reply [relevance 0%]
* RE: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-30 14:43 0% ` Jerin Jacob
@ 2023-02-02 16:12 0% ` Naga Harish K, S V
2023-02-03 9:44 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Naga Harish K, S V @ 2023-02-02 16:12 UTC (permalink / raw)
To: Jerin Jacob
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Monday, January 30, 2023 8:13 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Mon, Jan 30, 2023 at 3:26 PM Naga Harish K, S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Saturday, January 28, 2023 4:24 PM
> > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > Cc: jerinj@marvell.com; Carrillo, Erik G
> > > <erik.g.carrillo@intel.com>; Gujjar, Abhinandan S
> > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > <jay.jayatheerthan@intel.com>
> > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> > >
> > > On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
> > > <s.v.naga.harish.k@intel.com> wrote:
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > >
> > > > > > > >
> > > > > > > > > > + */
> > > > > > > > > > + uint32_t rsvd[15];
> > > > > > > > > > + /**< Reserved fields for future use */
> > > > > > > > >
> > > > > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init()
> > > > > > > > > to
> > > > > make
> > > > > > > > > sure rsvd is zero.
> > > > > > > > >
> > > > > > > >
> > > > > > > > The reserved fields are not used by the adapter or application.
> > > > > > > > Not sure Is it necessary to Introduce a new API to clear
> > > > > > > > reserved
> > > fields.
> > > > > > >
> > > > > > > When adapter starts using new fileds(when we add new fieds
> > > > > > > in future), the old applicaiton which is not using
> > > > > > > rte_event_eth_rx_adapter_runtime_params_init() may have
> junk
> > > > > > > value and then adapter implementation will behave bad.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > does it mean, the application doesn't re-compile for the new DPDK?
> > > > >
> > > > > Yes. No need recompile if ABI not breaking.
> > > > >
> > > > > > When some of the reserved fields are used in the future, the
> > > > > > application
> > > > > also may need to be recompiled along with DPDK right?
> > > > > > As the application also may need to use the newly consumed
> > > > > > reserved
> > > > > fields?
> > > > >
> > > > > The problematic case is:
> > > > >
> > > > > Adapter implementation of 23.07(Assuming there is change params)
> > > > > field needs to work with application of 23.03.
> > > > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > > > >
> > > >
> > > > As rte_event_eth_rx_adapter_runtime_params_init() initializes only
> > > reserved fields to zero, it may not solve the issue in this case.
> > >
> > > rte_event_eth_rx_adapter_runtime_params_init() needs to zero all
> > > fields, not just reserved field.
> > > The application calling sequence is
> > >
> > > struct my_config c;
> > > rte_event_eth_rx_adapter_runtime_params_init(&c)
> > > c.interseted_filed_to_be_updated = val;
> > >
> > Can it be done like
> > struct my_config c = {0};
> > c.interseted_filed_to_be_updated = val; and update Doxygen
> > comments to recommend above usage to reset all fields?
> > This way, rte_event_eth_rx_adapter_runtime_params_init() can be
> avoided.
>
> Better to have a function for documentation clarity. Similar scheme already
> there in DPDK. See rte_eth_cman_config_init()
>
>
The reference function rte_eth_cman_config_init() is resetting the params struct and initializing the required params with default values in the pmd cb.
The proposed rte_event_eth_rx_adapter_runtime_params_init () API just needs to reset the params struct. There are no pmd CBs involved.
Having an API just to reset the struct seems overkill. What do you think?
> >
> > > Let me share an example and you can tell where is the issue
> > >
> > > 1)Assume parameter structure is 64B and for 22.03 8B are used.
> > > 2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
> > > 3)There is an application written based on 22.03 which using only 8B
> > > after calling rte_event_eth_rx_adapter_runtime_params_init()
> > > 4)Assume, in 22.07 another 8B added to structure.
> > > 5)Now, the application (3) needs to run on 22.07. Since the
> > > application is calling
> > > rte_event_eth_rx_adapter_runtime_params_init()
> > > and 9 to 15B are zero, the implementation will not go bad.
> > >
> > > > The old application only tries to set/get previous valid fields
> > > > and the newly
> > > used fields may still contain junk value.
> > > > If the application wants to make use of any the newly used params,
> > > > the
> > > application changes are required anyway.
> > >
> > > Yes. If application wants to make use of newly added features. No
> > > need to change if new features are not needed for old application.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API
2023-02-02 9:28 0% ` Andrew Rybchenko
@ 2023-02-02 14:43 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-02-02 14:43 UTC (permalink / raw)
To: Jiawei(Jonny) Wang, Andrew Rybchenko
Cc: Slava Ovsiienko, Ori Kam, Aman Singh, Yuying Zhang, Ferruh Yigit,
dev, Raslan Darawsheh
02/02/2023 10:28, Andrew Rybchenko:
> On 2/1/23 18:50, Jiawei(Jonny) Wang wrote:
> > From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> >> On 1/30/23 20:00, Jiawei Wang wrote:
> >>> Adds the new tx_phy_affinity field into the padding hole of
> >>> rte_eth_txconf structure, the size of rte_eth_txconf keeps the same.
> >>> Adds a suppress type for structure change in the ABI check file.
> >>>
> >>> This patch adds the testpmd command line:
> >>> testpmd> port config (port_id) txq (queue_id) phy_affinity (value)
> >>>
> >>> For example, there're two hardware ports 0 and 1 connected to a single
> >>> DPDK port (port id 0), and phy_affinity 1 stood for hardware port 0
> >>> and phy_affinity 2 stood for hardware port 1, used the below command
> >>> to config tx phy affinity for per Tx Queue:
> >>> port config 0 txq 0 phy_affinity 1
> >>> port config 0 txq 1 phy_affinity 1
> >>> port config 0 txq 2 phy_affinity 2
> >>> port config 0 txq 3 phy_affinity 2
> >>>
> >>> These commands config the TxQ index 0 and TxQ index 1 with phy
> >>> affinity 1, uses TxQ 0 or TxQ 1 send packets, these packets will be
> >>> sent from the hardware port 0, and similar with hardware port 1 if
> >>> sending packets with TxQ 2 or TxQ 3.
> >>
> >> Frankly speaking I dislike it. Why do we need to expose it on generic ethdev
> >> layer? IMHO dynamic mbuf field would be a better solution to control Tx
> >> routing to a specific PHY port.
The design of this patch is to map a queue of the front device
with an underlying port.
This design may be applicable to several situations,
including DPDK bonding PMD, or Linux bonding connected to a PMD.
The default 0, meaning the queue is not mapped to anything (no change).
If the affinity is higher than 0, then the queue can be configured as desired.
Then if an application wants to send a packet to a specific underlying port,
it just has to send to the right queue.
Functionnaly, mapping the queue, or setting the port in mbuf (your proposal)
are the same.
The advantages of the queue mapping are:
- faster to use a queue than filling mbuf field
- optimization can be done at queue setup
[...]
> Why are these queues should be visible to DPDK application?
> Nobody denies you to create many HW queues behind one ethdev
> queue. Of course, there questions related to descriptor status
> API in this case, but IMHO it would be better than exposing
> these details to an application level.
Why not mapping the queues if application requires these details?
> >> IMHO, we definitely need dev_info information about a number of physical
> >> ports behind.
Yes dev_info would be needed.
> >> Advertising value greater than 0 should mean that PMD supports
> >> corresponding mbuf dynamic field to contol ongoing physical port on Tx (or
> >> should just reject packets on prepare which try to specify outgoing phy port
> >> otherwise). In the same way the information may be provided on Rx.
> >
> > See above, I think phy affinity is Queue level not for each packet.
> >
> >> I'm OK to have 0 as no phy affinity value and greater than zero as specified phy
> >> affinity. I.e. no dynamic flag is required.
> >
> > Thanks for agreement.
> >
> >> Also I think that order of patches should be different.
> >> We should start from a patch which provides dev_info and flow API matching
> >> and action should be in later patch.
> >
> > OK.
^ permalink raw reply [relevance 0%]
* [PATCH V8] ethdev: fix one address occupies two entries in MAC addrs
2023-02-01 13:15 3% ` [PATCH V7] ethdev: fix one address occupies two entries " Huisong Li
@ 2023-02-02 12:36 3% ` Huisong Li
2023-02-02 18:09 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Huisong Li @ 2023-02-02 12:36 UTC (permalink / raw)
To: dev
Cc: thomas, ferruh.yigit, andrew.rybchenko, liudongdong3, huangdaode,
fengchengwen, lihuisong
The dev->data->mac_addrs[0] will be changed to a new MAC address when
applications modify the default MAC address by .mac_addr_set(). However,
if the new default one has been added as a non-default MAC address by
.mac_addr_add(), the .mac_addr_set() doesn't remove it from the mac_addrs
list. As a result, one MAC address occupies two entries in the list. Like:
add(MAC1)
add(MAC2)
add(MAC3)
add(MAC4)
set_default(MAC3)
default=MAC3, the rest of the list=MAC1, MAC2, MAC3, MAC4
Note: MAC3 occupies two entries.
In addition, some PMDs, such as i40e, ice, hns3 and so on, do remove the
old default MAC when set default MAC. If user continues to do
set_default(MAC5), and the mac_addrs list is default=MAC5, filters=(MAC1,
MAC2, MAC3, MAC4). At this moment, user can still see MAC3 from the list,
but packets with MAC3 aren't actually received by the PMD.
So need to ensure that the new default address is removed from the rest of
the list if the address was already in the list.
Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
v8: fix some comments.
v7: add announcement in the release notes and document this behavior.
v6: fix commit log and some code comments.
v5:
- merge the second patch into the first patch.
- add error log when rollback failed.
v4:
- fix broken in the patchwork
v3:
- first explicitly remove the non-default MAC, then set default one.
- document default and non-default MAC address
v2:
- fixed commit log.
---
doc/guides/rel_notes/release_23_03.rst | 6 +++++
lib/ethdev/ethdev_driver.h | 6 ++++-
lib/ethdev/rte_ethdev.c | 35 ++++++++++++++++++++++++--
lib/ethdev/rte_ethdev.h | 3 +++
4 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index 84b112a8b1..1c9b9912c2 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -105,6 +105,12 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* ethdev: ensured all entries in MAC address list are uniques.
+ When setting a default MAC address with the function
+ ``rte_eth_dev_default_mac_addr_set``,
+ the address is now removed from the rest of the address list
+ in order to ensure it is only at index 0 of the list.
+
ABI Changes
-----------
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index dde3ec84ef..3994c61b86 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -117,7 +117,11 @@ struct rte_eth_dev_data {
uint64_t rx_mbuf_alloc_failed; /**< Rx ring mbuf allocation failures */
- /** Device Ethernet link address. @see rte_eth_dev_release_port() */
+ /**
+ * Device Ethernet link addresses.
+ * All entries are unique.
+ * The first entry (index zero) is the default address.
+ */
struct rte_ether_addr *mac_addrs;
/** Bitmap associating MAC addresses to pools */
uint64_t mac_pool_sel[RTE_ETH_NUM_RECEIVE_MAC_ADDR];
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 86ca303ab5..de25183619 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -4498,7 +4498,10 @@ rte_eth_dev_mac_addr_remove(uint16_t port_id, struct rte_ether_addr *addr)
int
rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr)
{
+ uint64_t mac_pool_sel_bk = 0;
struct rte_eth_dev *dev;
+ uint32_t pool;
+ int index;
int ret;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
@@ -4517,16 +4520,44 @@ rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr)
if (*dev->dev_ops->mac_addr_set == NULL)
return -ENOTSUP;
+ /* Keep address unique in dev->data->mac_addrs[]. */
+ index = eth_dev_get_mac_addr_index(port_id, addr);
+ if (index > 0) {
+ /* Remove address in dev data structure */
+ mac_pool_sel_bk = dev->data->mac_pool_sel[index];
+ ret = rte_eth_dev_mac_addr_remove(port_id, addr);
+ if (ret < 0) {
+ RTE_ETHDEV_LOG(ERR, "Cannot remove the port %u address from the rest of list.\n",
+ port_id);
+ return ret;
+ }
+ }
ret = (*dev->dev_ops->mac_addr_set)(dev, addr);
if (ret < 0)
- return ret;
+ goto out;
/* Update default address in NIC data structure */
rte_ether_addr_copy(addr, &dev->data->mac_addrs[0]);
return 0;
-}
+out:
+ if (index > 0) {
+ pool = 0;
+ do {
+ if (mac_pool_sel_bk & UINT64_C(1)) {
+ if (rte_eth_dev_mac_addr_add(port_id, addr,
+ pool) != 0)
+ RTE_ETHDEV_LOG(ERR, "failed to restore MAC pool id(%u) in port %u.\n",
+ pool, port_id);
+ }
+ mac_pool_sel_bk >>= 1;
+ pool++;
+ } while (mac_pool_sel_bk != 0);
+ }
+
+ return ret;
+}
/*
* Returns index into MAC address array of addr. Use 00:00:00:00:00:00 to find
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index d22de196db..2456153457 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -4356,6 +4356,9 @@ int rte_eth_dev_mac_addr_remove(uint16_t port_id,
/**
* Set the default MAC address.
+ * It replaces the address at index 0 of the MAC address list.
+ * If the address was already in the MAC address list,
+ * it is removed from the rest of the list.
*
* @param port_id
* The port identifier of the Ethernet device.
--
2.22.0
^ permalink raw reply [relevance 3%]
* [PATCH v6 1/3] ethdev: add IPv6 routing extension header definition
@ 2023-02-02 10:00 3% ` Rongwei Liu
0 siblings, 0 replies; 200+ results
From: Rongwei Liu @ 2023-02-02 10:00 UTC (permalink / raw)
To: dev, matan, viacheslavo, orika, thomas
Cc: rasland, Andrew Rybchenko, Aman Singh, Yuying Zhang,
Ferruh Yigit, Olivier Matz
Add IPv6 routing extension header definition and no
TLV support for now.
At rte_flow layer, there are new items defined for matching
type/nexthdr/segments_left field.
Add command line support for IPv6 routing extension header
matching: type/nexthdr/segment_list.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
Acked-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
---
app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 9 +++++
doc/guides/rel_notes/release_23_03.rst | 9 +++++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 19 +++++++++++
lib/net/rte_ip.h | 20 +++++++++++
6 files changed, 104 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88108498e0..7a8516829c 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -298,6 +298,10 @@ enum index {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_ICMP,
ITEM_ICMP_TYPE,
ITEM_ICMP_CODE,
@@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
ITEM_ARP_ETH_IPV4,
ITEM_IPV6_EXT,
ITEM_IPV6_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
ITEM_ICMP6,
ITEM_ICMP6_ND_NS,
ITEM_ICMP6_ND_NA,
@@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index item_ipv6_routing_ext[] = {
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_NEXT,
ZERO,
};
@@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
has_frag_ext, 1)),
},
+ [ITEM_IPV6_ROUTING_EXT] = {
+ .name = "ipv6_routing_ext",
+ .help = "match IPv6 routing extension header",
+ .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
+ sizeof(struct rte_flow_item_ipv6_routing_ext)),
+ .next = NEXT(item_ipv6_routing_ext),
+ .call = parse_vc,
+ },
+ [ITEM_IPV6_ROUTING_EXT_TYPE] = {
+ .name = "ext_type",
+ .help = "match IPv6 routing extension header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.type)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
+ .name = "ext_next_hdr",
+ .help = "match IPv6 routing extension header next header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.next_hdr)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
+ .name = "ext_seg_left",
+ .help = "match IPv6 routing extension header segment left",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.segments_left)),
+ },
[ITEM_ICMP] = {
.name = "icmp",
.help = "match ICMP header",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3e6242803d..602fab29d3 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
- ``color``: Metering color marker.
+Item: ``IPV6_ROUTING_EXT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches IPv6 routing extension header.
+
+- ``next_hdr``: Next layer header type.
+- ``type``: IPv6 routing extension header type.
+- ``segments_left``: How many IPv6 destination addresses carries on.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index c15f6fbb9f..1337da73b8 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -69,6 +69,11 @@ New Features
``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
required for eth_rx, eth_tx, crypto and timer eventdev adapters.
+* **Added rte_flow support for matching IPv6 routing extension header fields.**
+
+ Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
+ header.
+
Removed Items
-------------
@@ -98,6 +103,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* net: added a new structure:
+
+ - IPv6 routing extension header ``rte_ipv6_routing_ext``.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 7d0c24366c..4da581146e 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -157,6 +157,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
+ MK_FLOW_ITEM(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b60987db4b..9b9018cba2 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -624,6 +624,13 @@ enum rte_flow_item_type {
* See struct rte_flow_item_meter_color.
*/
RTE_FLOW_ITEM_TYPE_METER_COLOR,
+
+ /**
+ * Matches the presence of IPv6 routing extension header.
+ *
+ * @see struct rte_flow_item_ipv6_routing_ext.
+ */
+ RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
};
/**
@@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
uint32_t reserved:23;
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
+ *
+ * Matches an IPv6 routing extension header.
+ */
+struct rte_flow_item_ipv6_routing_ext {
+ struct rte_ipv6_routing_ext hdr;
+};
+
/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
#ifndef __cplusplus
static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index 9c8e8206f0..a310e9d498 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -539,6 +539,26 @@ struct rte_ipv6_hdr {
uint8_t dst_addr[16]; /**< IP address of destination host(s). */
} __rte_packed;
+/**
+ * IPv6 Routing Extension Header
+ */
+struct rte_ipv6_routing_ext {
+ uint8_t next_hdr; /**< Protocol, next header. */
+ uint8_t hdr_len; /**< Header length. */
+ uint8_t type; /**< Extension header type. */
+ uint8_t segments_left; /**< Valid segments number. */
+ __extension__
+ union {
+ rte_be32_t flags; /**< Packet control data per type. */
+ struct {
+ uint8_t last_entry; /**< The last_entry field of SRH */
+ uint8_t flag; /**< Packet flag. */
+ rte_be16_t tag; /**< Packet tag. */
+ };
+ };
+ /* Next are 128-bit IPv6 address fields to describe segments. */
+} __rte_packed;
+
/* IPv6 vtc_flow: IPv / TC / flow_label */
#define RTE_IPV6_HDR_FL_SHIFT 0
#define RTE_IPV6_HDR_TC_SHIFT 20
--
2.27.0
^ permalink raw reply [relevance 3%]
* Re: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API
2023-02-01 15:50 0% ` Jiawei(Jonny) Wang
@ 2023-02-02 9:28 0% ` Andrew Rybchenko
2023-02-02 14:43 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2023-02-02 9:28 UTC (permalink / raw)
To: Jiawei(Jonny) Wang, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Aman Singh, Yuying Zhang, Ferruh Yigit
Cc: dev, Raslan Darawsheh
On 2/1/23 18:50, Jiawei(Jonny) Wang wrote:
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Subject: Re: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue
>> API
>>
>> On 1/30/23 20:00, Jiawei Wang wrote:
>>> Adds the new tx_phy_affinity field into the padding hole of
>>> rte_eth_txconf structure, the size of rte_eth_txconf keeps the same.
>>> Adds a suppress type for structure change in the ABI check file.
>>>
>>> This patch adds the testpmd command line:
>>> testpmd> port config (port_id) txq (queue_id) phy_affinity (value)
>>>
>>> For example, there're two hardware ports 0 and 1 connected to a single
>>> DPDK port (port id 0), and phy_affinity 1 stood for hardware port 0
>>> and phy_affinity 2 stood for hardware port 1, used the below command
>>> to config tx phy affinity for per Tx Queue:
>>> port config 0 txq 0 phy_affinity 1
>>> port config 0 txq 1 phy_affinity 1
>>> port config 0 txq 2 phy_affinity 2
>>> port config 0 txq 3 phy_affinity 2
>>>
>>> These commands config the TxQ index 0 and TxQ index 1 with phy
>>> affinity 1, uses TxQ 0 or TxQ 1 send packets, these packets will be
>>> sent from the hardware port 0, and similar with hardware port 1 if
>>> sending packets with TxQ 2 or TxQ 3.
>>
>> Frankly speaking I dislike it. Why do we need to expose it on generic ethdev
>> layer? IMHO dynamic mbuf field would be a better solution to control Tx
>> routing to a specific PHY port.
>>
>
> OK, the phy affinity is not part of packet information(like timestamp).
Why? port_id is a packet information. Why phy_subport_id is not
a packet information.
> And second, the phy affinity is Queue layer, that is, the phy affinity value
> should keep the same behavior per Queue.
> After the TxQ was created, the packets should be sent the same physical port
> If using the same TxQ index.
Why are these queues should be visible to DPDK application?
Nobody denies you to create many HW queues behind one ethdev
queue. Of course, there questions related to descriptor status
API in this case, but IMHO it would be better than exposing
these details to an application level.
>
>> IMHO, we definitely need dev_info information about a number of physical
>> ports behind. Advertising value greater than 0 should mean that PMD supports
>> corresponding mbuf dynamic field to contol ongoing physical port on Tx (or
>> should just reject packets on prepare which try to specify outgoing phy port
>> otherwise). In the same way the information may be provided on Rx.
>>
>
> See above, I think phy affinity is Queue level not for each packet.
>
>> I'm OK to have 0 as no phy affinity value and greater than zero as specified phy
>> affinity. I.e. no dynamic flag is required.
>>
>
> Thanks for agreement.
>
>> Also I think that order of patches should be different.
>> We should start from a patch which provides dev_info and flow API matching
>> and action should be in later patch.
>>
>
> OK.
>
>>>
>>> Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
>>
>> [snip]
>
^ permalink raw reply [relevance 0%]
* RE: [PATCH] eal: introduce atomics abstraction
2023-02-01 21:41 3% ` Tyler Retzlaff
@ 2023-02-02 8:43 4% ` Morten Brørup
2023-02-02 19:00 4% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2023-02-02 8:43 UTC (permalink / raw)
To: Tyler Retzlaff, Honnappa Nagarahalli
Cc: thomas, dev, bruce.richardson, david.marchand, jerinj,
konstantin.ananyev, ferruh.yigit, nd
> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
> Sent: Wednesday, 1 February 2023 22.41
>
> On Wed, Feb 01, 2023 at 01:07:59AM +0000, Honnappa Nagarahalli wrote:
> >
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Tuesday, January 31, 2023 4:42 PM
> > >
> > > Honnappa, please could you give your view on the future of atomics
> in DPDK?
> > Thanks Thomas, apologies it has taken me a while to get to this
> discussion.
> >
> > IMO, we do not need DPDK's own abstractions. APIs from stdatomic.h
> (stdatomics as is called here) already serve the purpose. These APIs
> are well understood and documented.
>
> i agree that whatever atomics APIs we advocate for should align with
> the
> standard C atomics for the reasons you state including implied
> semantics.
>
> >
> > For environments where stdatomics are not supported, we could have a
> stdatomic.h in DPDK implementing the same APIs (we have to support only
> _explicit APIs). This allows the code to use stdatomics APIs and when
> we move to minimum supported standard C11, we just need to get rid of
> the file in DPDK repo.
Perhaps we can use something already existing, such as this:
https://android.googlesource.com/platform/bionic/+/lollipop-release/libc/include/stdatomic.h
>
> my concern with this is that if we provide a stdatomic.h or introduce
> names
> from stdatomic.h it's a violation of the C standard.
>
> references:
> * ISO/IEC 9899:2011 sections 7.1.2, 7.1.3.
> * GNU libc manual
> https://www.gnu.org/software/libc/manual/html_node/Reserved-
> Names.html
>
> in effect the header, the names and in some instances namespaces
> introduced
> are reserved by the implementation. there are several reasons in the
> GNU libc
> manual that explain the justification for these reservations and if
> if we think about ODR and ABI compatibility we can conceive of others.
I we are going to move to C11 soon, I consider the shim interim, and am inclined to ignore these warning factors.
If we are not moving to C11 soon, I would consider these disadvantages more seriously.
>
> i'll also remark that the inter-mingling of names from the POSIX
> standard implicitly exposed as a part of the EAL public API has been
> problematic for portability.
This is a very important remark, which should be considered carefully! Tyler has firsthand experience with DPDK portability. If he thinks porting to Windows is going to be a headache if we expose the stdatomic.h API, we must listen! So, what is your gut feeling here, Tyler?
>
> let's discuss this from here. if there's still overwhelming desire to
> go
> this route then we'll just do our best.
>
> ty
I have a preference for exposing the stdatomic.h API. Tyler listed the disadvantages above. (I also have a preference for moving to C11 soon.)
Exposing a 1:1 similar API with RTE prefixes would also be acceptable for me. The disadvantage is that the names are different than the C11 names, which might lead to some confusion. And from an ABI stability perspective, such an important API should not be marked experimental. This means that years will pass before we can get rid of it again, due to ABI stability policies.
-Morten
^ permalink raw reply [relevance 4%]
* Re: [PATCH] eal: introduce atomics abstraction
@ 2023-02-01 21:41 3% ` Tyler Retzlaff
2023-02-02 8:43 4% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2023-02-01 21:41 UTC (permalink / raw)
To: Honnappa Nagarahalli
Cc: thomas, dev, bruce.richardson, mb, david.marchand, jerinj,
konstantin.ananyev, ferruh.yigit, nd
On Wed, Feb 01, 2023 at 01:07:59AM +0000, Honnappa Nagarahalli wrote:
>
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Tuesday, January 31, 2023 4:42 PM
> > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Cc: dev@dpdk.org; bruce.richardson@intel.com; mb@smartsharesystems.com;
> > Tyler Retzlaff <roretzla@linux.microsoft.com>; david.marchand@redhat.com;
> > jerinj@marvell.com; konstantin.ananyev@huawei.com; ferruh.yigit@amd.com
> > Subject: Re: [PATCH] eal: introduce atomics abstraction
> >
> > Honnappa, please could you give your view on the future of atomics in DPDK?
> Thanks Thomas, apologies it has taken me a while to get to this discussion.
>
> IMO, we do not need DPDK's own abstractions. APIs from stdatomic.h (stdatomics as is called here) already serve the purpose. These APIs are well understood and documented.
i agree that whatever atomics APIs we advocate for should align with the
standard C atomics for the reasons you state including implied semantics.
>
> For environments where stdatomics are not supported, we could have a stdatomic.h in DPDK implementing the same APIs (we have to support only _explicit APIs). This allows the code to use stdatomics APIs and when we move to minimum supported standard C11, we just need to get rid of the file in DPDK repo.
my concern with this is that if we provide a stdatomic.h or introduce names
from stdatomic.h it's a violation of the C standard.
references:
* ISO/IEC 9899:2011 sections 7.1.2, 7.1.3.
* GNU libc manual
https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html
in effect the header, the names and in some instances namespaces introduced
are reserved by the implementation. there are several reasons in the GNU libc
manual that explain the justification for these reservations and if
if we think about ODR and ABI compatibility we can conceive of others.
i'll also remark that the inter-mingling of names from the POSIX
standard implicitly exposed as a part of the EAL public API has been
problematic for portability.
let's discuss this from here. if there's still overwhelming desire to go
this route then we'll just do our best.
ty
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API
2023-02-01 9:05 0% ` Andrew Rybchenko
@ 2023-02-01 15:50 0% ` Jiawei(Jonny) Wang
2023-02-02 9:28 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Jiawei(Jonny) Wang @ 2023-02-01 15:50 UTC (permalink / raw)
To: Andrew Rybchenko, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Aman Singh, Yuying Zhang, Ferruh Yigit
Cc: dev, Raslan Darawsheh
Hi,
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Subject: Re: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue
> API
>
> On 1/30/23 20:00, Jiawei Wang wrote:
> > For the multiple hardware ports connect to a single DPDK port
> > (mhpsdp), the previous patch introduces the new rte flow item to match
> > the phy affinity of the received packets.
> >
> > This patch adds the tx_phy_affinity setting in Tx queue API, the
> > affinity
>
> "This patch adds" -> "Add ..."
>
OK, will change to 'Add the tx_phy_affinity...."
> > value reflects packets be sent to which hardware port.
> > Value 0 is no affinity and traffic will be routed between different
> > physical ports,
>
> Who will it be routed?
>
Assume there's two slave physical port bonded and DPDK attached the bond master bond,
The packets can be sent from first physical port or second physical port, it depends on the PMD
Driver and low level 'routing' selection.
> > if 0 is disabled then try to match on phy_affinity 0 will result in an
> > error.
>
> Why are you talking about matching here?
>
Previous patch we mentioned the same phy affinity can be used to handled the packet on same hardware
Port, so if 0 is no affinity then match it should report error.
> >
> > Adds the new tx_phy_affinity field into the padding hole of
> > rte_eth_txconf structure, the size of rte_eth_txconf keeps the same.
> > Adds a suppress type for structure change in the ABI check file.
> >
> > This patch adds the testpmd command line:
> > testpmd> port config (port_id) txq (queue_id) phy_affinity (value)
> >
> > For example, there're two hardware ports 0 and 1 connected to a single
> > DPDK port (port id 0), and phy_affinity 1 stood for hardware port 0
> > and phy_affinity 2 stood for hardware port 1, used the below command
> > to config tx phy affinity for per Tx Queue:
> > port config 0 txq 0 phy_affinity 1
> > port config 0 txq 1 phy_affinity 1
> > port config 0 txq 2 phy_affinity 2
> > port config 0 txq 3 phy_affinity 2
> >
> > These commands config the TxQ index 0 and TxQ index 1 with phy
> > affinity 1, uses TxQ 0 or TxQ 1 send packets, these packets will be
> > sent from the hardware port 0, and similar with hardware port 1 if
> > sending packets with TxQ 2 or TxQ 3.
>
> Frankly speaking I dislike it. Why do we need to expose it on generic ethdev
> layer? IMHO dynamic mbuf field would be a better solution to control Tx
> routing to a specific PHY port.
>
OK, the phy affinity is not part of packet information(like timestamp).
And second, the phy affinity is Queue layer, that is, the phy affinity value
should keep the same behavior per Queue.
After the TxQ was created, the packets should be sent the same physical port
If using the same TxQ index.
> IMHO, we definitely need dev_info information about a number of physical
> ports behind. Advertising value greater than 0 should mean that PMD supports
> corresponding mbuf dynamic field to contol ongoing physical port on Tx (or
> should just reject packets on prepare which try to specify outgoing phy port
> otherwise). In the same way the information may be provided on Rx.
>
See above, I think phy affinity is Queue level not for each packet.
> I'm OK to have 0 as no phy affinity value and greater than zero as specified phy
> affinity. I.e. no dynamic flag is required.
>
Thanks for agreement.
> Also I think that order of patches should be different.
> We should start from a patch which provides dev_info and flow API matching
> and action should be in later patch.
>
OK.
> >
> > Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
>
> [snip]
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH] compressdev: fix end of comp PMD list macro conflict
2023-02-01 13:29 0% ` Michael Baum
@ 2023-02-01 14:02 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2023-02-01 14:02 UTC (permalink / raw)
To: Michael Baum, dev
Cc: Matan Azrad, Ashish Gupta, Fan Zhang, Kai Ji,
NBU-Contact-Thomas Monjalon (EXTERNAL),
fiona.trahe, stable
> > Hi,
> > > > >
> > > > > After this change, I'm not sure about the purpose of
> > > > > "RTE_COMP_ALGO_LIST_END".
> > > > > There is no any other use of it in DPDK code, and it isn't
> > > > > represent the number of algorithms supported by the API since the
> > > > > "RTE_COMP_ALGO_UNSPECIFIED" is part of the enum.
> > > > >
> > > > > Due to the compress API is experimental I think the
> > > > > "RTE_COMP_ALGO_LIST_END" can be removed.
> > > > >
> > > > +1 to remove the list end enums. This will also help in avoiding ABI
> > > > +breakage
> > > > When we make this lib as stable.
> > >
> > > Even RTE_COMP_HASH_ALGO_LIST_END can also be removed.
> > > It is not used anywhere.
> >
> > Can you send a patch to remove these list end enums along with this patch?
>
> In the same patch? Or add one?
Separate patch would be better as the current patch is talking about a conflict.
Removing the enums need not be backported, but this patch is required to be backported.
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH] compressdev: fix end of comp PMD list macro conflict
2023-02-01 13:19 0% ` Akhil Goyal
@ 2023-02-01 13:29 0% ` Michael Baum
2023-02-01 14:02 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Michael Baum @ 2023-02-01 13:29 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: Matan Azrad, Ashish Gupta, Fan Zhang, Kai Ji,
NBU-Contact-Thomas Monjalon (EXTERNAL),
fiona.trahe, stable
Hi,
>
>
> Hi,
> > > >
> > > > After this change, I'm not sure about the purpose of
> > > > "RTE_COMP_ALGO_LIST_END".
> > > > There is no any other use of it in DPDK code, and it isn't
> > > > represent the number of algorithms supported by the API since the
> > > > "RTE_COMP_ALGO_UNSPECIFIED" is part of the enum.
> > > >
> > > > Due to the compress API is experimental I think the
> > > > "RTE_COMP_ALGO_LIST_END" can be removed.
> > > >
> > > +1 to remove the list end enums. This will also help in avoiding ABI
> > > +breakage
> > > When we make this lib as stable.
> >
> > Even RTE_COMP_HASH_ALGO_LIST_END can also be removed.
> > It is not used anywhere.
>
> Can you send a patch to remove these list end enums along with this patch?
In the same patch? Or add one?
>
> -Akhil
^ permalink raw reply [relevance 0%]
* RE: [EXT] [PATCH] compressdev: fix end of comp PMD list macro conflict
2023-01-31 8:23 0% ` Akhil Goyal
@ 2023-02-01 13:19 0% ` Akhil Goyal
2023-02-01 13:29 0% ` Michael Baum
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2023-02-01 13:19 UTC (permalink / raw)
To: Akhil Goyal, Michael Baum, dev
Cc: Matan Azrad, Ashish Gupta, Fan Zhang, Kai Ji, Thomas Monjalon,
fiona.trahe, stable
Hi,
> > >
> > > After this change, I'm not sure about the purpose of
> > > "RTE_COMP_ALGO_LIST_END".
> > > There is no any other use of it in DPDK code, and it isn't represent the
> > > number of algorithms supported by the API since the
> > > "RTE_COMP_ALGO_UNSPECIFIED" is part of the enum.
> > >
> > > Due to the compress API is experimental I think the
> > > "RTE_COMP_ALGO_LIST_END" can be removed.
> > >
> > +1 to remove the list end enums. This will also help in avoiding ABI breakage
> > When we make this lib as stable.
>
> Even RTE_COMP_HASH_ALGO_LIST_END can also be removed.
> It is not used anywhere.
Can you send a patch to remove these list end enums along with this patch?
-Akhil
^ permalink raw reply [relevance 0%]
* [PATCH V7] ethdev: fix one address occupies two entries in MAC addrs
@ 2023-02-01 13:15 3% ` Huisong Li
2023-02-02 12:36 3% ` [PATCH V8] " Huisong Li
1 sibling, 0 replies; 200+ results
From: Huisong Li @ 2023-02-01 13:15 UTC (permalink / raw)
To: dev
Cc: thomas, ferruh.yigit, andrew.rybchenko, liudongdong3, huangdaode,
fengchengwen, lihuisong
The dev->data->mac_addrs[0] will be changed to a new MAC address when
applications modify the default MAC address by .mac_addr_set(). However,
if the new default one has been added as a non-default MAC address by
.mac_addr_add(), the .mac_addr_set() doesn't remove it from the mac_addrs
list. As a result, one MAC address occupies two entries in the list. Like:
add(MAC1)
add(MAC2)
add(MAC3)
add(MAC4)
set_default(MAC3)
default=MAC3, the rest of list=MAC1, MAC2, MAC3, MAC4
Note: MAC3 occupies two entries.
In addition, some PMDs, such as i40e, ice, hns3 and so on, do remove the
old default MAC when set default MAC. If user continues to do
set_default(MAC5), and the mac_addrs list is default=MAC5, filters=(MAC1,
MAC2, MAC3, MAC4). At this moment, user can still see MAC3 from the list,
but packets with MAC3 aren't actually received by the PMD.
So need to ensure that the new default address is removed from the rest of
the list if the address was already in the list.
Fixes: 854d8ad4ef68 ("ethdev: add default mac address modifier")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Acked-by: Chengwen Feng <fengchengwen@huawei.com>
---
v7: add announcement in the release notes and document this behavior.
v6: fix commit log and some code comments.
v5:
- merge the second patch into the first patch.
- add error log when rollback failed.
v4:
- fix broken in the patchwork
v3:
- first explicitly remove the non-default MAC, then set default one.
- document default and non-default MAC address
v2:
- fixed commit log.
---
doc/guides/rel_notes/release_23_03.rst | 6 +++++
lib/ethdev/ethdev_driver.h | 6 ++++-
lib/ethdev/rte_ethdev.c | 35 ++++++++++++++++++++++++--
lib/ethdev/rte_ethdev.h | 3 +++
4 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index 84b112a8b1..f63ec2b399 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -101,10 +101,16 @@ API Changes
Use fixed width quotes for ``function_names`` or ``struct_names``.
Use the past tense.
+
This section is a comment. Do not overwrite or remove it.
Also, make sure to start the actual text at the margin.
=======================================================
+ * ethdev: ensured all entries in MAC address list is unique.
+ The function ``rte_eth_dev_default_mac_addr_set`` replaces the address
+ at index 0 of the address list. If the address was already in the
+ address list, it is removed from the rest of the list.
+
ABI Changes
-----------
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index dde3ec84ef..14a1d9adad 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -117,7 +117,11 @@ struct rte_eth_dev_data {
uint64_t rx_mbuf_alloc_failed; /**< Rx ring mbuf allocation failures */
- /** Device Ethernet link address. @see rte_eth_dev_release_port() */
+ /**
+ * Device Ethernet link addresses.
+ * All entries are unique. The first entry (index zero) is the
+ * default address.
+ */
struct rte_ether_addr *mac_addrs;
/** Bitmap associating MAC addresses to pools */
uint64_t mac_pool_sel[RTE_ETH_NUM_RECEIVE_MAC_ADDR];
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 86ca303ab5..de25183619 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -4498,7 +4498,10 @@ rte_eth_dev_mac_addr_remove(uint16_t port_id, struct rte_ether_addr *addr)
int
rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr)
{
+ uint64_t mac_pool_sel_bk = 0;
struct rte_eth_dev *dev;
+ uint32_t pool;
+ int index;
int ret;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
@@ -4517,16 +4520,44 @@ rte_eth_dev_default_mac_addr_set(uint16_t port_id, struct rte_ether_addr *addr)
if (*dev->dev_ops->mac_addr_set == NULL)
return -ENOTSUP;
+ /* Keep address unique in dev->data->mac_addrs[]. */
+ index = eth_dev_get_mac_addr_index(port_id, addr);
+ if (index > 0) {
+ /* Remove address in dev data structure */
+ mac_pool_sel_bk = dev->data->mac_pool_sel[index];
+ ret = rte_eth_dev_mac_addr_remove(port_id, addr);
+ if (ret < 0) {
+ RTE_ETHDEV_LOG(ERR, "Cannot remove the port %u address from the rest of list.\n",
+ port_id);
+ return ret;
+ }
+ }
ret = (*dev->dev_ops->mac_addr_set)(dev, addr);
if (ret < 0)
- return ret;
+ goto out;
/* Update default address in NIC data structure */
rte_ether_addr_copy(addr, &dev->data->mac_addrs[0]);
return 0;
-}
+out:
+ if (index > 0) {
+ pool = 0;
+ do {
+ if (mac_pool_sel_bk & UINT64_C(1)) {
+ if (rte_eth_dev_mac_addr_add(port_id, addr,
+ pool) != 0)
+ RTE_ETHDEV_LOG(ERR, "failed to restore MAC pool id(%u) in port %u.\n",
+ pool, port_id);
+ }
+ mac_pool_sel_bk >>= 1;
+ pool++;
+ } while (mac_pool_sel_bk != 0);
+ }
+
+ return ret;
+}
/*
* Returns index into MAC address array of addr. Use 00:00:00:00:00:00 to find
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index d22de196db..609328f1e3 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -4356,6 +4356,9 @@ int rte_eth_dev_mac_addr_remove(uint16_t port_id,
/**
* Set the default MAC address.
+ * It replaces the address at index 0 of the MAC address list.
+ * If the address was already in the MAC address list, it is removed from
+ * the rest of the list.
*
* @param port_id
* The port identifier of the Ethernet device.
--
2.22.0
^ permalink raw reply [relevance 3%]
* [PATCH v5 1/3] ethdev: add IPv6 routing extension header definition
@ 2023-02-01 11:35 3% ` Rongwei Liu
0 siblings, 0 replies; 200+ results
From: Rongwei Liu @ 2023-02-01 11:35 UTC (permalink / raw)
To: dev, matan, viacheslavo, orika, thomas
Cc: rasland, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, Olivier Matz
Add IPv6 routing extension header definition and no
TLV support for now.
At rte_flow layer, there are new items defined for matching
type/nexthdr/segments_left field.
Add command line support for IPv6 routing extension header
matching: type/nexthdr/segment_list.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 9 +++++
doc/guides/rel_notes/release_23_03.rst | 9 +++++
lib/ethdev/rte_flow.c | 1 +
lib/ethdev/rte_flow.h | 19 +++++++++++
lib/net/rte_ip.h | 20 +++++++++++
6 files changed, 104 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88108498e0..7a8516829c 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -298,6 +298,10 @@ enum index {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_ICMP,
ITEM_ICMP_TYPE,
ITEM_ICMP_CODE,
@@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
ITEM_ARP_ETH_IPV4,
ITEM_IPV6_EXT,
ITEM_IPV6_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
ITEM_ICMP6,
ITEM_ICMP6_ND_NS,
ITEM_ICMP6_ND_NA,
@@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index item_ipv6_routing_ext[] = {
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_NEXT,
ZERO,
};
@@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
has_frag_ext, 1)),
},
+ [ITEM_IPV6_ROUTING_EXT] = {
+ .name = "ipv6_routing_ext",
+ .help = "match IPv6 routing extension header",
+ .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
+ sizeof(struct rte_flow_item_ipv6_routing_ext)),
+ .next = NEXT(item_ipv6_routing_ext),
+ .call = parse_vc,
+ },
+ [ITEM_IPV6_ROUTING_EXT_TYPE] = {
+ .name = "ext_type",
+ .help = "match IPv6 routing extension header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.type)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
+ .name = "ext_next_hdr",
+ .help = "match IPv6 routing extension header next header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.next_hdr)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
+ .name = "ext_seg_left",
+ .help = "match IPv6 routing extension header segment left",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.segments_left)),
+ },
[ITEM_ICMP] = {
.name = "icmp",
.help = "match ICMP header",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3e6242803d..602fab29d3 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
- ``color``: Metering color marker.
+Item: ``IPV6_ROUTING_EXT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches IPv6 routing extension header.
+
+- ``next_hdr``: Next layer header type.
+- ``type``: IPv6 routing extension header type.
+- ``segments_left``: How many IPv6 destination addresses carries on.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index c15f6fbb9f..1337da73b8 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -69,6 +69,11 @@ New Features
``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
required for eth_rx, eth_tx, crypto and timer eventdev adapters.
+* **Added rte_flow support for matching IPv6 routing extension header fields.**
+
+ Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
+ header.
+
Removed Items
-------------
@@ -98,6 +103,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* net: added a new structure:
+
+ - IPv6 routing extension header ``rte_ipv6_routing_ext``.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 7d0c24366c..4da581146e 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -157,6 +157,7 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
+ MK_FLOW_ITEM(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext)),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b60987db4b..9b9018cba2 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -624,6 +624,13 @@ enum rte_flow_item_type {
* See struct rte_flow_item_meter_color.
*/
RTE_FLOW_ITEM_TYPE_METER_COLOR,
+
+ /**
+ * Matches the presence of IPv6 routing extension header.
+ *
+ * @see struct rte_flow_item_ipv6_routing_ext.
+ */
+ RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
};
/**
@@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
uint32_t reserved:23;
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
+ *
+ * Matches an IPv6 routing extension header.
+ */
+struct rte_flow_item_ipv6_routing_ext {
+ struct rte_ipv6_routing_ext hdr;
+};
+
/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
#ifndef __cplusplus
static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index 9c8e8206f0..1f23e24af5 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -539,6 +539,26 @@ struct rte_ipv6_hdr {
uint8_t dst_addr[16]; /**< IP address of destination host(s). */
} __rte_packed;
+/**
+ * IPv6 Routing Extension Header
+ */
+struct rte_ipv6_routing_ext {
+ uint8_t next_hdr; /**< Protocol, next header. */
+ uint8_t hdr_len; /**< Header length. */
+ uint8_t type; /**< Extension header type. */
+ uint8_t segments_left; /**< Valid segments number. */
+ __extension__
+ union {
+ rte_be32_t flags; /**< Packet control data per type. */
+ struct {
+ uint8_t last_entry; /**< The last_entry field of SRH */
+ uint8_t flag; /**< Packet flag. */
+ rte_be16_t tag; /**< Packet tag. */
+ };
+ };
+ /** Following variable number of segments. */
+} __rte_packed;
+
/* IPv6 vtc_flow: IPv / TC / flow_label */
#define RTE_IPV6_HDR_FL_SHIFT 0
#define RTE_IPV6_HDR_TC_SHIFT 20
--
2.27.0
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API
2023-01-31 17:26 3% ` Thomas Monjalon
@ 2023-02-01 9:45 0% ` Jiawei(Jonny) Wang
0 siblings, 0 replies; 200+ results
From: Jiawei(Jonny) Wang @ 2023-02-01 9:45 UTC (permalink / raw)
To: NBU-Contact-Thomas Monjalon (EXTERNAL)
Cc: Slava Ovsiienko, Ori Kam, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, Raslan Darawsheh, david.marchand
> 30/01/2023 18:00, Jiawei Wang:
> > --- a/devtools/libabigail.abignore
> > +++ b/devtools/libabigail.abignore
> > @@ -20,6 +20,11 @@
> > [suppress_file]
> > soname_regexp = ^librte_.*mlx.*glue\.
> >
> > +; Ignore fields inserted in middle padding of rte_eth_txconf
> > +[suppress_type]
> > + name = rte_eth_txconf
> > + has_data_member_inserted_between =
> > +{offset_after(tx_deferred_start), offset_of(offloads)}
>
> You are adding the exception inside
> "Core suppression rules: DO NOT TOUCH".
>
> Please move it at the end in the section "Temporary exceptions till next major
> ABI version"
>
OK, will move.
> Also the rule does not work.
> It should be:
> has_data_member_inserted_between = {offset_of(tx_deferred_start),
> offset_of(offloads)}
>
Thanks, Will change it and send with new version.
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 1/3] ethdev: add IPv6 routing extension header definition
2023-02-01 9:27 0% ` Rongwei Liu
@ 2023-02-01 9:31 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2023-02-01 9:31 UTC (permalink / raw)
To: Rongwei Liu, dev, Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL)
Cc: Raslan Darawsheh, Aman Singh, Yuying Zhang, Ferruh Yigit, Olivier Matz
On 2/1/23 12:27, Rongwei Liu wrote:
> HI Andrew:
>
> BR
> Rongwei
>
>> -----Original Message-----
>> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
>> Sent: Wednesday, February 1, 2023 17:21
>> To: Rongwei Liu <rongweil@nvidia.com>; dev@dpdk.org; Matan Azrad
>> <matan@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>; Ori Kam
>> <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
>> <thomas@monjalon.net>
>> Cc: Raslan Darawsheh <rasland@nvidia.com>; Aman Singh
>> <aman.deep.singh@intel.com>; Yuying Zhang <yuying.zhang@intel.com>;
>> Ferruh Yigit <ferruh.yigit@amd.com>; Olivier Matz <olivier.matz@6wind.com>
>> Subject: Re: [PATCH v4 1/3] ethdev: add IPv6 routing extension header
>> definition
>>
>> External email: Use caution opening links or attachments
>>
>>
>> On 1/31/23 12:36, Rongwei Liu wrote:
>>> Add IPv6 routing extension header definition and no TLV support for
>>> now.
>>>
>>> At rte_flow layer, there are new items defined for matching
>>> type/nexthdr/segments_left field.
>>>
>>> Add command line support for IPv6 routing extension header
>>> matching: type/nexthdr/segment_list.
>>>
>>> Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
>>> Acked-by: Ori Kam <orika@nvidia.com>
>>> ---
>>> app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
>>> doc/guides/prog_guide/rte_flow.rst | 9 +++++
>>> doc/guides/rel_notes/release_23_03.rst | 9 +++++
>>> lib/ethdev/rte_flow.c | 19 +++++++++++
>>> lib/ethdev/rte_flow.h | 21 ++++++++++++
>>> lib/net/rte_ip.h | 19 +++++++++++
>>> 6 files changed, 123 insertions(+)
>>>
>>> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
>>> index 88108498e0..7a8516829c 100644
>>> --- a/app/test-pmd/cmdline_flow.c
>>> +++ b/app/test-pmd/cmdline_flow.c
>>> @@ -298,6 +298,10 @@ enum index {
>>> ITEM_IPV6_SRC,
>>> ITEM_IPV6_DST,
>>> ITEM_IPV6_HAS_FRAG_EXT,
>>> + ITEM_IPV6_ROUTING_EXT,
>>> + ITEM_IPV6_ROUTING_EXT_TYPE,
>>> + ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
>>> + ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
>>> ITEM_ICMP,
>>> ITEM_ICMP_TYPE,
>>> ITEM_ICMP_CODE,
>>> @@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
>>> ITEM_ARP_ETH_IPV4,
>>> ITEM_IPV6_EXT,
>>> ITEM_IPV6_FRAG_EXT,
>>> + ITEM_IPV6_ROUTING_EXT,
>>> ITEM_ICMP6,
>>> ITEM_ICMP6_ND_NS,
>>> ITEM_ICMP6_ND_NA,
>>> @@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
>>> ITEM_IPV6_SRC,
>>> ITEM_IPV6_DST,
>>> ITEM_IPV6_HAS_FRAG_EXT,
>>> + ITEM_IPV6_ROUTING_EXT,
>>> + ITEM_NEXT,
>>> + ZERO,
>>> +};
>>> +
>>> +static const enum index item_ipv6_routing_ext[] = {
>>> + ITEM_IPV6_ROUTING_EXT_TYPE,
>>> + ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
>>> + ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
>>> ITEM_NEXT,
>>> ZERO,
>>> };
>>> @@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
>>> .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
>>> has_frag_ext, 1)),
>>> },
>>> + [ITEM_IPV6_ROUTING_EXT] = {
>>> + .name = "ipv6_routing_ext",
>>> + .help = "match IPv6 routing extension header",
>>> + .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
>>> + sizeof(struct rte_flow_item_ipv6_routing_ext)),
>>> + .next = NEXT(item_ipv6_routing_ext),
>>> + .call = parse_vc,
>>> + },
>>> + [ITEM_IPV6_ROUTING_EXT_TYPE] = {
>>> + .name = "ext_type",
>>> + .help = "match IPv6 routing extension header type",
>>> + .next = NEXT(item_ipv6_routing_ext,
>> NEXT_ENTRY(COMMON_UNSIGNED),
>>> + item_param),
>>> + .args = ARGS(ARGS_ENTRY_HTON(struct
>> rte_flow_item_ipv6_routing_ext,
>>> + hdr.type)),
>>> + },
>>> + [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
>>> + .name = "ext_next_hdr",
>>> + .help = "match IPv6 routing extension header next header type",
>>> + .next = NEXT(item_ipv6_routing_ext,
>> NEXT_ENTRY(COMMON_UNSIGNED),
>>> + item_param),
>>> + .args = ARGS(ARGS_ENTRY_HTON(struct
>> rte_flow_item_ipv6_routing_ext,
>>> + hdr.next_hdr)),
>>> + },
>>> + [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
>>> + .name = "ext_seg_left",
>>> + .help = "match IPv6 routing extension header segment left",
>>> + .next = NEXT(item_ipv6_routing_ext,
>> NEXT_ENTRY(COMMON_UNSIGNED),
>>> + item_param),
>>> + .args = ARGS(ARGS_ENTRY_HTON(struct
>> rte_flow_item_ipv6_routing_ext,
>>> + hdr.segments_left)),
>>> + },
>>> [ITEM_ICMP] = {
>>> .name = "icmp",
>>> .help = "match ICMP header", diff --git
>>> a/doc/guides/prog_guide/rte_flow.rst
>>> b/doc/guides/prog_guide/rte_flow.rst
>>> index 3e6242803d..602fab29d3 100644
>>> --- a/doc/guides/prog_guide/rte_flow.rst
>>> +++ b/doc/guides/prog_guide/rte_flow.rst
>>> @@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
>>>
>>> - ``color``: Metering color marker.
>>>
>>> +Item: ``IPV6_ROUTING_EXT``
>>> +^^^^^^^^^^^^^^^^^^^^^^^^^^
>>> +
>>> +Matches IPv6 routing extension header.
>>> +
>>> +- ``next_hdr``: Next layer header type.
>>> +- ``type``: IPv6 routing extension header type.
>>> +- ``segments_left``: How many IPv6 destination addresses carries on.
>>> +
>>> Actions
>>> ~~~~~~~
>>>
>>> diff --git a/doc/guides/rel_notes/release_23_03.rst
>>> b/doc/guides/rel_notes/release_23_03.rst
>>> index c15f6fbb9f..1337da73b8 100644
>>> --- a/doc/guides/rel_notes/release_23_03.rst
>>> +++ b/doc/guides/rel_notes/release_23_03.rst
>>> @@ -69,6 +69,11 @@ New Features
>>> ``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
>>> required for eth_rx, eth_tx, crypto and timer eventdev adapters.
>>>
>>> +* **Added rte_flow support for matching IPv6 routing extension header
>>> +fields.**
>>> +
>>> + Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing
>>> + extension header.
>>> +
>>>
>>> Removed Items
>>> -------------
>>> @@ -98,6 +103,10 @@ API Changes
>>> Also, make sure to start the actual text at the margin.
>>> =======================================================
>>>
>>> +* net: added a new structure:
>>> +
>>> + - IPv6 routing extension header ``rte_ipv6_routing_ext``.
>>> +
>>>
>>> ABI Changes
>>> -----------
>>> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c index
>>> 7d0c24366c..833382c466 100644
>>> --- a/lib/ethdev/rte_flow.c
>>> +++ b/lib/ethdev/rte_flow.c
>>> @@ -76,6 +76,23 @@ rte_flow_item_flex_conv(void *buf, const void *data)
>>> return src->length;
>>> }
>>>
>>> +static size_t
>>> +rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data) {
>>> + struct rte_flow_item_ipv6_routing_ext *dst = buf;
>>> + const struct rte_flow_item_ipv6_routing_ext *src = data;
>>> + size_t len;
>>> +
>>> + if (src->hdr.hdr_len)
>>
>> Please, compare vs 0
>>
>>> + len = src->hdr.hdr_len << 3;
>>> + else
>>> + len = src->hdr.segments_left << 4;
>>> + if (dst == NULL)
>>> + return 0;
>>> + memcpy(dst->segments, src->segments, len);
>>> + return len;
>>> +}
>>> +
>>> /** Generate flow_item[] entry. */
>>> #define MK_FLOW_ITEM(t, s) \
>>> [RTE_FLOW_ITEM_TYPE_ ## t] = { \ @@ -157,6 +174,8 @@ static
>>> const struct rte_flow_desc_data rte_flow_desc_item[] = {
>>> MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
>>> MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
>>> MK_FLOW_ITEM(METER_COLOR, sizeof(struct
>>> rte_flow_item_meter_color)),
>>> + MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct
>> rte_flow_item_ipv6_routing_ext),
>>> + rte_flow_item_ipv6_routing_ext_conv),
>>> };
>>>
>>> /** Generate flow_action[] entry. */ diff --git
>>> a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
>>> b60987db4b..ff9270690c 100644
>>> --- a/lib/ethdev/rte_flow.h
>>> +++ b/lib/ethdev/rte_flow.h
>>> @@ -624,6 +624,13 @@ enum rte_flow_item_type {
>>> * See struct rte_flow_item_meter_color.
>>> */
>>> RTE_FLOW_ITEM_TYPE_METER_COLOR,
>>> +
>>> + /**
>>> + * Matches the presence of IPv6 routing extension header.
>>> + *
>>> + * @see struct rte_flow_item_ipv6_routing_ext.
>>> + */
>>> + RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
>>> };
>>>
>>> /**
>>> @@ -873,6 +880,20 @@ struct rte_flow_item_ipv6 {
>>> uint32_t reserved:23;
>>> };
>>>
>>> +/**
>>> + * @warning
>>> + * @b EXPERIMENTAL: this structure may change without prior notice
>>> + *
>>> + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
>>> + *
>>> + * Matches an IPv6 routing extension header.
>>> + */
>>> +struct rte_flow_item_ipv6_routing_ext {
>>> + struct rte_ipv6_routing_ext hdr;
>>> + __extension__
>>> + rte_be32_t segments[]; /**< Each hop IPv6 address. */
>>
>> Do we really need it? Are you going to support it?
>> Will testpmd and flow conf work correctly since it uses size of the structure?
>>
> In the rte_flow.c and testpmd raw_encap() function, it relies on the hdr_len or segment_left fild not sizeof this structure.
We still have a number of sizeof() invocations for the
structure in the patch. I worry that related code will
not work fine if someone tries to specify segments.
>> IMHO we should just remove it right now if we're not going to support it.
>>
> In matching, we don't support segments field. I am ok to remove it.
Me too
^ permalink raw reply [relevance 0%]
* RE: [PATCH v4 1/3] ethdev: add IPv6 routing extension header definition
2023-02-01 9:21 0% ` Andrew Rybchenko
@ 2023-02-01 9:27 0% ` Rongwei Liu
2023-02-01 9:31 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2023-02-01 9:27 UTC (permalink / raw)
To: Andrew Rybchenko, dev, Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL)
Cc: Raslan Darawsheh, Aman Singh, Yuying Zhang, Ferruh Yigit, Olivier Matz
HI Andrew:
BR
Rongwei
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Wednesday, February 1, 2023 17:21
> To: Rongwei Liu <rongweil@nvidia.com>; dev@dpdk.org; Matan Azrad
> <matan@nvidia.com>; Slava Ovsiienko <viacheslavo@nvidia.com>; Ori Kam
> <orika@nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>
> Cc: Raslan Darawsheh <rasland@nvidia.com>; Aman Singh
> <aman.deep.singh@intel.com>; Yuying Zhang <yuying.zhang@intel.com>;
> Ferruh Yigit <ferruh.yigit@amd.com>; Olivier Matz <olivier.matz@6wind.com>
> Subject: Re: [PATCH v4 1/3] ethdev: add IPv6 routing extension header
> definition
>
> External email: Use caution opening links or attachments
>
>
> On 1/31/23 12:36, Rongwei Liu wrote:
> > Add IPv6 routing extension header definition and no TLV support for
> > now.
> >
> > At rte_flow layer, there are new items defined for matching
> > type/nexthdr/segments_left field.
> >
> > Add command line support for IPv6 routing extension header
> > matching: type/nexthdr/segment_list.
> >
> > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> > Acked-by: Ori Kam <orika@nvidia.com>
> > ---
> > app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
> > doc/guides/prog_guide/rte_flow.rst | 9 +++++
> > doc/guides/rel_notes/release_23_03.rst | 9 +++++
> > lib/ethdev/rte_flow.c | 19 +++++++++++
> > lib/ethdev/rte_flow.h | 21 ++++++++++++
> > lib/net/rte_ip.h | 19 +++++++++++
> > 6 files changed, 123 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> > index 88108498e0..7a8516829c 100644
> > --- a/app/test-pmd/cmdline_flow.c
> > +++ b/app/test-pmd/cmdline_flow.c
> > @@ -298,6 +298,10 @@ enum index {
> > ITEM_IPV6_SRC,
> > ITEM_IPV6_DST,
> > ITEM_IPV6_HAS_FRAG_EXT,
> > + ITEM_IPV6_ROUTING_EXT,
> > + ITEM_IPV6_ROUTING_EXT_TYPE,
> > + ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
> > + ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
> > ITEM_ICMP,
> > ITEM_ICMP_TYPE,
> > ITEM_ICMP_CODE,
> > @@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
> > ITEM_ARP_ETH_IPV4,
> > ITEM_IPV6_EXT,
> > ITEM_IPV6_FRAG_EXT,
> > + ITEM_IPV6_ROUTING_EXT,
> > ITEM_ICMP6,
> > ITEM_ICMP6_ND_NS,
> > ITEM_ICMP6_ND_NA,
> > @@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
> > ITEM_IPV6_SRC,
> > ITEM_IPV6_DST,
> > ITEM_IPV6_HAS_FRAG_EXT,
> > + ITEM_IPV6_ROUTING_EXT,
> > + ITEM_NEXT,
> > + ZERO,
> > +};
> > +
> > +static const enum index item_ipv6_routing_ext[] = {
> > + ITEM_IPV6_ROUTING_EXT_TYPE,
> > + ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
> > + ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
> > ITEM_NEXT,
> > ZERO,
> > };
> > @@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
> > .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
> > has_frag_ext, 1)),
> > },
> > + [ITEM_IPV6_ROUTING_EXT] = {
> > + .name = "ipv6_routing_ext",
> > + .help = "match IPv6 routing extension header",
> > + .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
> > + sizeof(struct rte_flow_item_ipv6_routing_ext)),
> > + .next = NEXT(item_ipv6_routing_ext),
> > + .call = parse_vc,
> > + },
> > + [ITEM_IPV6_ROUTING_EXT_TYPE] = {
> > + .name = "ext_type",
> > + .help = "match IPv6 routing extension header type",
> > + .next = NEXT(item_ipv6_routing_ext,
> NEXT_ENTRY(COMMON_UNSIGNED),
> > + item_param),
> > + .args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_ipv6_routing_ext,
> > + hdr.type)),
> > + },
> > + [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
> > + .name = "ext_next_hdr",
> > + .help = "match IPv6 routing extension header next header type",
> > + .next = NEXT(item_ipv6_routing_ext,
> NEXT_ENTRY(COMMON_UNSIGNED),
> > + item_param),
> > + .args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_ipv6_routing_ext,
> > + hdr.next_hdr)),
> > + },
> > + [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
> > + .name = "ext_seg_left",
> > + .help = "match IPv6 routing extension header segment left",
> > + .next = NEXT(item_ipv6_routing_ext,
> NEXT_ENTRY(COMMON_UNSIGNED),
> > + item_param),
> > + .args = ARGS(ARGS_ENTRY_HTON(struct
> rte_flow_item_ipv6_routing_ext,
> > + hdr.segments_left)),
> > + },
> > [ITEM_ICMP] = {
> > .name = "icmp",
> > .help = "match ICMP header", diff --git
> > a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index 3e6242803d..602fab29d3 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
> >
> > - ``color``: Metering color marker.
> >
> > +Item: ``IPV6_ROUTING_EXT``
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Matches IPv6 routing extension header.
> > +
> > +- ``next_hdr``: Next layer header type.
> > +- ``type``: IPv6 routing extension header type.
> > +- ``segments_left``: How many IPv6 destination addresses carries on.
> > +
> > Actions
> > ~~~~~~~
> >
> > diff --git a/doc/guides/rel_notes/release_23_03.rst
> > b/doc/guides/rel_notes/release_23_03.rst
> > index c15f6fbb9f..1337da73b8 100644
> > --- a/doc/guides/rel_notes/release_23_03.rst
> > +++ b/doc/guides/rel_notes/release_23_03.rst
> > @@ -69,6 +69,11 @@ New Features
> > ``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
> > required for eth_rx, eth_tx, crypto and timer eventdev adapters.
> >
> > +* **Added rte_flow support for matching IPv6 routing extension header
> > +fields.**
> > +
> > + Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing
> > + extension header.
> > +
> >
> > Removed Items
> > -------------
> > @@ -98,6 +103,10 @@ API Changes
> > Also, make sure to start the actual text at the margin.
> > =======================================================
> >
> > +* net: added a new structure:
> > +
> > + - IPv6 routing extension header ``rte_ipv6_routing_ext``.
> > +
> >
> > ABI Changes
> > -----------
> > diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c index
> > 7d0c24366c..833382c466 100644
> > --- a/lib/ethdev/rte_flow.c
> > +++ b/lib/ethdev/rte_flow.c
> > @@ -76,6 +76,23 @@ rte_flow_item_flex_conv(void *buf, const void *data)
> > return src->length;
> > }
> >
> > +static size_t
> > +rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data) {
> > + struct rte_flow_item_ipv6_routing_ext *dst = buf;
> > + const struct rte_flow_item_ipv6_routing_ext *src = data;
> > + size_t len;
> > +
> > + if (src->hdr.hdr_len)
>
> Please, compare vs 0
>
> > + len = src->hdr.hdr_len << 3;
> > + else
> > + len = src->hdr.segments_left << 4;
> > + if (dst == NULL)
> > + return 0;
> > + memcpy(dst->segments, src->segments, len);
> > + return len;
> > +}
> > +
> > /** Generate flow_item[] entry. */
> > #define MK_FLOW_ITEM(t, s) \
> > [RTE_FLOW_ITEM_TYPE_ ## t] = { \ @@ -157,6 +174,8 @@ static
> > const struct rte_flow_desc_data rte_flow_desc_item[] = {
> > MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
> > MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
> > MK_FLOW_ITEM(METER_COLOR, sizeof(struct
> > rte_flow_item_meter_color)),
> > + MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct
> rte_flow_item_ipv6_routing_ext),
> > + rte_flow_item_ipv6_routing_ext_conv),
> > };
> >
> > /** Generate flow_action[] entry. */ diff --git
> > a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
> > b60987db4b..ff9270690c 100644
> > --- a/lib/ethdev/rte_flow.h
> > +++ b/lib/ethdev/rte_flow.h
> > @@ -624,6 +624,13 @@ enum rte_flow_item_type {
> > * See struct rte_flow_item_meter_color.
> > */
> > RTE_FLOW_ITEM_TYPE_METER_COLOR,
> > +
> > + /**
> > + * Matches the presence of IPv6 routing extension header.
> > + *
> > + * @see struct rte_flow_item_ipv6_routing_ext.
> > + */
> > + RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
> > };
> >
> > /**
> > @@ -873,6 +880,20 @@ struct rte_flow_item_ipv6 {
> > uint32_t reserved:23;
> > };
> >
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
> > + *
> > + * Matches an IPv6 routing extension header.
> > + */
> > +struct rte_flow_item_ipv6_routing_ext {
> > + struct rte_ipv6_routing_ext hdr;
> > + __extension__
> > + rte_be32_t segments[]; /**< Each hop IPv6 address. */
>
> Do we really need it? Are you going to support it?
> Will testpmd and flow conf work correctly since it uses size of the structure?
>
In the rte_flow.c and testpmd raw_encap() function, it relies on the hdr_len or segment_left fild not sizeof this structure.
> IMHO we should just remove it right now if we're not going to support it.
>
In matching, we don't support segments field. I am ok to remove it.
> > +};
> > +
> > /** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
> > #ifndef __cplusplus
> > static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
> > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h index
> > 9c8e8206f0..778fb5ef83 100644
> > --- a/lib/net/rte_ip.h
> > +++ b/lib/net/rte_ip.h
> > @@ -539,6 +539,25 @@ struct rte_ipv6_hdr {
> > uint8_t dst_addr[16]; /**< IP address of destination host(s). */
> > } __rte_packed;
> >
> > +/**
> > + * IPv6 Routing Extension Header
> > + */
> > +struct rte_ipv6_routing_ext {
> > + uint8_t next_hdr; /**< Protocol, next header. */
> > + uint8_t hdr_len; /**< Header length. */
> > + uint8_t type; /**< Extension header type. */
> > + uint8_t segments_left; /**< Valid segments number. */
> > + __extension__
> > + union {
> > + rte_be32_t flags;
>
> flags should be documented as well.
Sure.
>
> > + struct {
> > + uint8_t last_entry; /**< The last_entry field of SRH */
> > + uint8_t flag; /**< Packet flag. */
> > + rte_be16_t tag; /**< Packet tag. */
> > + };
> > + };
>
> May be we should add a comment here that segments follow?
Sure.
>
> > +} __rte_packed;
> > +
> > /* IPv6 vtc_flow: IPv / TC / flow_label */
> > #define RTE_IPV6_HDR_FL_SHIFT 0
> > #define RTE_IPV6_HDR_TC_SHIFT 20
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 1/3] ethdev: add IPv6 routing extension header definition
2023-01-31 9:36 3% ` [PATCH v4 1/3] ethdev: add IPv6 routing extension header definition Rongwei Liu
@ 2023-02-01 9:21 0% ` Andrew Rybchenko
2023-02-01 9:27 0% ` Rongwei Liu
0 siblings, 1 reply; 200+ results
From: Andrew Rybchenko @ 2023-02-01 9:21 UTC (permalink / raw)
To: Rongwei Liu, dev, matan, viacheslavo, orika, thomas
Cc: rasland, Aman Singh, Yuying Zhang, Ferruh Yigit, Olivier Matz
On 1/31/23 12:36, Rongwei Liu wrote:
> Add IPv6 routing extension header definition and no
> TLV support for now.
>
> At rte_flow layer, there are new items defined for matching
> type/nexthdr/segments_left field.
>
> Add command line support for IPv6 routing extension header
> matching: type/nexthdr/segment_list.
>
> Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> Acked-by: Ori Kam <orika@nvidia.com>
> ---
> app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
> doc/guides/prog_guide/rte_flow.rst | 9 +++++
> doc/guides/rel_notes/release_23_03.rst | 9 +++++
> lib/ethdev/rte_flow.c | 19 +++++++++++
> lib/ethdev/rte_flow.h | 21 ++++++++++++
> lib/net/rte_ip.h | 19 +++++++++++
> 6 files changed, 123 insertions(+)
>
> diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
> index 88108498e0..7a8516829c 100644
> --- a/app/test-pmd/cmdline_flow.c
> +++ b/app/test-pmd/cmdline_flow.c
> @@ -298,6 +298,10 @@ enum index {
> ITEM_IPV6_SRC,
> ITEM_IPV6_DST,
> ITEM_IPV6_HAS_FRAG_EXT,
> + ITEM_IPV6_ROUTING_EXT,
> + ITEM_IPV6_ROUTING_EXT_TYPE,
> + ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
> + ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
> ITEM_ICMP,
> ITEM_ICMP_TYPE,
> ITEM_ICMP_CODE,
> @@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
> ITEM_ARP_ETH_IPV4,
> ITEM_IPV6_EXT,
> ITEM_IPV6_FRAG_EXT,
> + ITEM_IPV6_ROUTING_EXT,
> ITEM_ICMP6,
> ITEM_ICMP6_ND_NS,
> ITEM_ICMP6_ND_NA,
> @@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
> ITEM_IPV6_SRC,
> ITEM_IPV6_DST,
> ITEM_IPV6_HAS_FRAG_EXT,
> + ITEM_IPV6_ROUTING_EXT,
> + ITEM_NEXT,
> + ZERO,
> +};
> +
> +static const enum index item_ipv6_routing_ext[] = {
> + ITEM_IPV6_ROUTING_EXT_TYPE,
> + ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
> + ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
> ITEM_NEXT,
> ZERO,
> };
> @@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
> .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
> has_frag_ext, 1)),
> },
> + [ITEM_IPV6_ROUTING_EXT] = {
> + .name = "ipv6_routing_ext",
> + .help = "match IPv6 routing extension header",
> + .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
> + sizeof(struct rte_flow_item_ipv6_routing_ext)),
> + .next = NEXT(item_ipv6_routing_ext),
> + .call = parse_vc,
> + },
> + [ITEM_IPV6_ROUTING_EXT_TYPE] = {
> + .name = "ext_type",
> + .help = "match IPv6 routing extension header type",
> + .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
> + item_param),
> + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
> + hdr.type)),
> + },
> + [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
> + .name = "ext_next_hdr",
> + .help = "match IPv6 routing extension header next header type",
> + .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
> + item_param),
> + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
> + hdr.next_hdr)),
> + },
> + [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
> + .name = "ext_seg_left",
> + .help = "match IPv6 routing extension header segment left",
> + .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
> + item_param),
> + .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
> + hdr.segments_left)),
> + },
> [ITEM_ICMP] = {
> .name = "icmp",
> .help = "match ICMP header",
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 3e6242803d..602fab29d3 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
>
> - ``color``: Metering color marker.
>
> +Item: ``IPV6_ROUTING_EXT``
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Matches IPv6 routing extension header.
> +
> +- ``next_hdr``: Next layer header type.
> +- ``type``: IPv6 routing extension header type.
> +- ``segments_left``: How many IPv6 destination addresses carries on.
> +
> Actions
> ~~~~~~~
>
> diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
> index c15f6fbb9f..1337da73b8 100644
> --- a/doc/guides/rel_notes/release_23_03.rst
> +++ b/doc/guides/rel_notes/release_23_03.rst
> @@ -69,6 +69,11 @@ New Features
> ``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
> required for eth_rx, eth_tx, crypto and timer eventdev adapters.
>
> +* **Added rte_flow support for matching IPv6 routing extension header fields.**
> +
> + Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
> + header.
> +
>
> Removed Items
> -------------
> @@ -98,6 +103,10 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* net: added a new structure:
> +
> + - IPv6 routing extension header ``rte_ipv6_routing_ext``.
> +
>
> ABI Changes
> -----------
> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> index 7d0c24366c..833382c466 100644
> --- a/lib/ethdev/rte_flow.c
> +++ b/lib/ethdev/rte_flow.c
> @@ -76,6 +76,23 @@ rte_flow_item_flex_conv(void *buf, const void *data)
> return src->length;
> }
>
> +static size_t
> +rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)
> +{
> + struct rte_flow_item_ipv6_routing_ext *dst = buf;
> + const struct rte_flow_item_ipv6_routing_ext *src = data;
> + size_t len;
> +
> + if (src->hdr.hdr_len)
Please, compare vs 0
> + len = src->hdr.hdr_len << 3;
> + else
> + len = src->hdr.segments_left << 4;
> + if (dst == NULL)
> + return 0;
> + memcpy(dst->segments, src->segments, len);
> + return len;
> +}
> +
> /** Generate flow_item[] entry. */
> #define MK_FLOW_ITEM(t, s) \
> [RTE_FLOW_ITEM_TYPE_ ## t] = { \
> @@ -157,6 +174,8 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
> MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
> MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
> MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
> + MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext),
> + rte_flow_item_ipv6_routing_ext_conv),
> };
>
> /** Generate flow_action[] entry. */
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index b60987db4b..ff9270690c 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -624,6 +624,13 @@ enum rte_flow_item_type {
> * See struct rte_flow_item_meter_color.
> */
> RTE_FLOW_ITEM_TYPE_METER_COLOR,
> +
> + /**
> + * Matches the presence of IPv6 routing extension header.
> + *
> + * @see struct rte_flow_item_ipv6_routing_ext.
> + */
> + RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
> };
>
> /**
> @@ -873,6 +880,20 @@ struct rte_flow_item_ipv6 {
> uint32_t reserved:23;
> };
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
> + *
> + * Matches an IPv6 routing extension header.
> + */
> +struct rte_flow_item_ipv6_routing_ext {
> + struct rte_ipv6_routing_ext hdr;
> + __extension__
> + rte_be32_t segments[]; /**< Each hop IPv6 address. */
Do we really need it? Are you going to support it?
Will testpmd and flow conf work correctly since it uses size of
the structure?
IMHO we should just remove it right now if we're not going to
support it.
> +};
> +
> /** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
> #ifndef __cplusplus
> static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
> diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
> index 9c8e8206f0..778fb5ef83 100644
> --- a/lib/net/rte_ip.h
> +++ b/lib/net/rte_ip.h
> @@ -539,6 +539,25 @@ struct rte_ipv6_hdr {
> uint8_t dst_addr[16]; /**< IP address of destination host(s). */
> } __rte_packed;
>
> +/**
> + * IPv6 Routing Extension Header
> + */
> +struct rte_ipv6_routing_ext {
> + uint8_t next_hdr; /**< Protocol, next header. */
> + uint8_t hdr_len; /**< Header length. */
> + uint8_t type; /**< Extension header type. */
> + uint8_t segments_left; /**< Valid segments number. */
> + __extension__
> + union {
> + rte_be32_t flags;
flags should be documented as well.
> + struct {
> + uint8_t last_entry; /**< The last_entry field of SRH */
> + uint8_t flag; /**< Packet flag. */
> + rte_be16_t tag; /**< Packet tag. */
> + };
> + };
May be we should add a comment here that segments follow?
> +} __rte_packed;
> +
> /* IPv6 vtc_flow: IPv / TC / flow_label */
> #define RTE_IPV6_HDR_FL_SHIFT 0
> #define RTE_IPV6_HDR_TC_SHIFT 20
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API
2023-01-30 17:00 2% ` [PATCH v2 2/2] ethdev: introduce the PHY affinity field in " Jiawei Wang
2023-01-31 17:26 3% ` Thomas Monjalon
@ 2023-02-01 9:05 0% ` Andrew Rybchenko
2023-02-01 15:50 0% ` Jiawei(Jonny) Wang
1 sibling, 1 reply; 200+ results
From: Andrew Rybchenko @ 2023-02-01 9:05 UTC (permalink / raw)
To: Jiawei Wang, viacheslavo, orika, thomas, Aman Singh,
Yuying Zhang, Ferruh Yigit
Cc: dev, rasland
On 1/30/23 20:00, Jiawei Wang wrote:
> For the multiple hardware ports connect to a single DPDK port (mhpsdp),
> the previous patch introduces the new rte flow item to match the
> phy affinity of the received packets.
>
> This patch adds the tx_phy_affinity setting in Tx queue API, the affinity
"This patch adds" -> "Add ..."
> value reflects packets be sent to which hardware port.
> Value 0 is no affinity and traffic will be routed between different
> physical ports,
Who will it be routed?
> if 0 is disabled then try to match on phy_affinity 0
> will result in an error.
Why are you talking about matching here?
>
> Adds the new tx_phy_affinity field into the padding hole of rte_eth_txconf
> structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> type for structure change in the ABI check file.
>
> This patch adds the testpmd command line:
> testpmd> port config (port_id) txq (queue_id) phy_affinity (value)
>
> For example, there're two hardware ports 0 and 1 connected to
> a single DPDK port (port id 0), and phy_affinity 1 stood for
> hardware port 0 and phy_affinity 2 stood for hardware port 1,
> used the below command to config tx phy affinity for per Tx Queue:
> port config 0 txq 0 phy_affinity 1
> port config 0 txq 1 phy_affinity 1
> port config 0 txq 2 phy_affinity 2
> port config 0 txq 3 phy_affinity 2
>
> These commands config the TxQ index 0 and TxQ index 1 with phy affinity 1,
> uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> hardware port 0, and similar with hardware port 1 if sending packets
> with TxQ 2 or TxQ 3.
Frankly speaking I dislike it. Why do we need to expose it on
generic ethdev layer? IMHO dynamic mbuf field would be a better
solution to control Tx routing to a specific PHY port.
IMHO, we definitely need dev_info information about a number of
physical ports behind. Advertising value greater than 0 should
mean that PMD supports corresponding mbuf dynamic field to
contol ongoing physical port on Tx (or should just reject
packets on prepare which try to specify outgoing phy port
otherwise). In the same way the information may be provided
on Rx.
I'm OK to have 0 as no phy affinity value and greater than
zero as specified phy affinity. I.e. no dynamic flag is
required.
Also I think that order of patches should be different.
We should start from a patch which provides dev_info and
flow API matching and action should be in later patch.
>
> Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
[snip]
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API
2023-01-30 17:00 2% ` [PATCH v2 2/2] ethdev: introduce the PHY affinity field in " Jiawei Wang
@ 2023-01-31 17:26 3% ` Thomas Monjalon
2023-02-01 9:45 0% ` Jiawei(Jonny) Wang
2023-02-01 9:05 0% ` Andrew Rybchenko
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-31 17:26 UTC (permalink / raw)
To: Jiawei Wang
Cc: viacheslavo, orika, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, rasland, david.marchand
30/01/2023 18:00, Jiawei Wang:
> --- a/devtools/libabigail.abignore
> +++ b/devtools/libabigail.abignore
> @@ -20,6 +20,11 @@
> [suppress_file]
> soname_regexp = ^librte_.*mlx.*glue\.
>
> +; Ignore fields inserted in middle padding of rte_eth_txconf
> +[suppress_type]
> + name = rte_eth_txconf
> + has_data_member_inserted_between = {offset_after(tx_deferred_start), offset_of(offloads)}
You are adding the exception inside
"Core suppression rules: DO NOT TOUCH".
Please move it at the end in the section
"Temporary exceptions till next major ABI version"
Also the rule does not work.
It should be:
has_data_member_inserted_between = {offset_of(tx_deferred_start), offset_of(offloads)}
^ permalink raw reply [relevance 3%]
* [PATCH v4 1/3] ethdev: add IPv6 routing extension header definition
@ 2023-01-31 9:36 3% ` Rongwei Liu
2023-02-01 9:21 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2023-01-31 9:36 UTC (permalink / raw)
To: dev, matan, viacheslavo, orika, thomas
Cc: rasland, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, Olivier Matz
Add IPv6 routing extension header definition and no
TLV support for now.
At rte_flow layer, there are new items defined for matching
type/nexthdr/segments_left field.
Add command line support for IPv6 routing extension header
matching: type/nexthdr/segment_list.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 9 +++++
doc/guides/rel_notes/release_23_03.rst | 9 +++++
lib/ethdev/rte_flow.c | 19 +++++++++++
lib/ethdev/rte_flow.h | 21 ++++++++++++
lib/net/rte_ip.h | 19 +++++++++++
6 files changed, 123 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88108498e0..7a8516829c 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -298,6 +298,10 @@ enum index {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_ICMP,
ITEM_ICMP_TYPE,
ITEM_ICMP_CODE,
@@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
ITEM_ARP_ETH_IPV4,
ITEM_IPV6_EXT,
ITEM_IPV6_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
ITEM_ICMP6,
ITEM_ICMP6_ND_NS,
ITEM_ICMP6_ND_NA,
@@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index item_ipv6_routing_ext[] = {
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_NEXT,
ZERO,
};
@@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
has_frag_ext, 1)),
},
+ [ITEM_IPV6_ROUTING_EXT] = {
+ .name = "ipv6_routing_ext",
+ .help = "match IPv6 routing extension header",
+ .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
+ sizeof(struct rte_flow_item_ipv6_routing_ext)),
+ .next = NEXT(item_ipv6_routing_ext),
+ .call = parse_vc,
+ },
+ [ITEM_IPV6_ROUTING_EXT_TYPE] = {
+ .name = "ext_type",
+ .help = "match IPv6 routing extension header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.type)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
+ .name = "ext_next_hdr",
+ .help = "match IPv6 routing extension header next header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.next_hdr)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
+ .name = "ext_seg_left",
+ .help = "match IPv6 routing extension header segment left",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.segments_left)),
+ },
[ITEM_ICMP] = {
.name = "icmp",
.help = "match ICMP header",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3e6242803d..602fab29d3 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
- ``color``: Metering color marker.
+Item: ``IPV6_ROUTING_EXT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches IPv6 routing extension header.
+
+- ``next_hdr``: Next layer header type.
+- ``type``: IPv6 routing extension header type.
+- ``segments_left``: How many IPv6 destination addresses carries on.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index c15f6fbb9f..1337da73b8 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -69,6 +69,11 @@ New Features
``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
required for eth_rx, eth_tx, crypto and timer eventdev adapters.
+* **Added rte_flow support for matching IPv6 routing extension header fields.**
+
+ Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
+ header.
+
Removed Items
-------------
@@ -98,6 +103,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* net: added a new structure:
+
+ - IPv6 routing extension header ``rte_ipv6_routing_ext``.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 7d0c24366c..833382c466 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -76,6 +76,23 @@ rte_flow_item_flex_conv(void *buf, const void *data)
return src->length;
}
+static size_t
+rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)
+{
+ struct rte_flow_item_ipv6_routing_ext *dst = buf;
+ const struct rte_flow_item_ipv6_routing_ext *src = data;
+ size_t len;
+
+ if (src->hdr.hdr_len)
+ len = src->hdr.hdr_len << 3;
+ else
+ len = src->hdr.segments_left << 4;
+ if (dst == NULL)
+ return 0;
+ memcpy(dst->segments, src->segments, len);
+ return len;
+}
+
/** Generate flow_item[] entry. */
#define MK_FLOW_ITEM(t, s) \
[RTE_FLOW_ITEM_TYPE_ ## t] = { \
@@ -157,6 +174,8 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
+ MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext),
+ rte_flow_item_ipv6_routing_ext_conv),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b60987db4b..ff9270690c 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -624,6 +624,13 @@ enum rte_flow_item_type {
* See struct rte_flow_item_meter_color.
*/
RTE_FLOW_ITEM_TYPE_METER_COLOR,
+
+ /**
+ * Matches the presence of IPv6 routing extension header.
+ *
+ * @see struct rte_flow_item_ipv6_routing_ext.
+ */
+ RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
};
/**
@@ -873,6 +880,20 @@ struct rte_flow_item_ipv6 {
uint32_t reserved:23;
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
+ *
+ * Matches an IPv6 routing extension header.
+ */
+struct rte_flow_item_ipv6_routing_ext {
+ struct rte_ipv6_routing_ext hdr;
+ __extension__
+ rte_be32_t segments[]; /**< Each hop IPv6 address. */
+};
+
/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
#ifndef __cplusplus
static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index 9c8e8206f0..778fb5ef83 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -539,6 +539,25 @@ struct rte_ipv6_hdr {
uint8_t dst_addr[16]; /**< IP address of destination host(s). */
} __rte_packed;
+/**
+ * IPv6 Routing Extension Header
+ */
+struct rte_ipv6_routing_ext {
+ uint8_t next_hdr; /**< Protocol, next header. */
+ uint8_t hdr_len; /**< Header length. */
+ uint8_t type; /**< Extension header type. */
+ uint8_t segments_left; /**< Valid segments number. */
+ __extension__
+ union {
+ rte_be32_t flags;
+ struct {
+ uint8_t last_entry; /**< The last_entry field of SRH */
+ uint8_t flag; /**< Packet flag. */
+ rte_be16_t tag; /**< Packet tag. */
+ };
+ };
+} __rte_packed;
+
/* IPv6 vtc_flow: IPv / TC / flow_label */
#define RTE_IPV6_HDR_FL_SHIFT 0
#define RTE_IPV6_HDR_TC_SHIFT 20
--
2.27.0
^ permalink raw reply [relevance 3%]
* RE: [EXT] [PATCH] compressdev: fix end of comp PMD list macro conflict
2023-01-30 19:30 3% ` [EXT] " Akhil Goyal
@ 2023-01-31 8:23 0% ` Akhil Goyal
2023-02-01 13:19 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2023-01-31 8:23 UTC (permalink / raw)
To: Michael Baum, dev
Cc: Matan Azrad, Ashish Gupta, Fan Zhang, Kai Ji, Thomas Monjalon,
fiona.trahe, stable
> Subject: RE: [EXT] [PATCH] compressdev: fix end of comp PMD list macro
> conflict
>
> > The "rte_compressdev_info_get()" function retrieves the contextual
> > information of a device.
> > The output structure "dev_info" contains a list of devices supported
> > capabilities for each supported algorithm.
> >
> > In this function description, it says the element after the last valid
> > element has op field set to "RTE_COMP_ALGO_LIST_END".
> > On the other hand, when this function used by
> > "rte_compressdev_capability_get()" function, it uses
> > "RTE_COMP_ALGO_UNSPECIFIED" as end of list as same as the
> > "RTE_COMP_END_OF_CAPABILITIES_LIST()".
> >
> > The mlx5 and qat PMDs use "RTE_COMP_ALGO_LIST_END" as the end of
> > capabilities list. When "rte_compressdev_capability_get()" function is
> > called with unsupported algorithm, it might read memory out of bound.
> >
> > This patch change the "rte_compressdev_info_get()" function description
> > to say using "RTE_COMP_ALGO_UNSPECIFIED" as the end of capabilities
> > list.
> > In addition, it moves both mlx5 and qat PMDs to use
> > "RTE_COMP_ALGO_UNSPECIFIED" through
> > "RTE_COMP_END_OF_CAPABILITIES_LIST()" macro.
> >
> > Fixes: 5d432f364078 ("compressdev: add device capabilities")
> > Fixes: 2d148597ce76 ("compress/qat: add gen-specific implementation")
> > Fixes: 384bac8d6555 ("compress/mlx5: add supported capabilities")
> > Cc: fiona.trahe@intel.com
> > Cc: roy.fan.zhang@intel.com
> > Cc: matan@nvidia.com
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Michael Baum <michaelba@nvidia.com>
> >
> > ---
> >
> > After this change, I'm not sure about the purpose of
> > "RTE_COMP_ALGO_LIST_END".
> > There is no any other use of it in DPDK code, and it isn't represent the
> > number of algorithms supported by the API since the
> > "RTE_COMP_ALGO_UNSPECIFIED" is part of the enum.
> >
> > Due to the compress API is experimental I think the
> > "RTE_COMP_ALGO_LIST_END" can be removed.
> >
> +1 to remove the list end enums. This will also help in avoiding ABI breakage
> When we make this lib as stable.
Even RTE_COMP_HASH_ALGO_LIST_END can also be removed.
It is not used anywhere.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 2/3] graph: pcap capture for graph nodes
2023-01-24 11:21 2% ` [PATCH v4 2/3] graph: pcap capture for graph nodes Amit Prakash Shukla
@ 2023-01-31 8:06 0% ` Jerin Jacob
2023-02-03 8:15 0% ` [EXT] " Amit Prakash Shukla
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-31 8:06 UTC (permalink / raw)
To: Amit Prakash Shukla
Cc: Jerin Jacob, Kiran Kumar K, Nithin Dabilpuram, Anatoly Burakov, dev
On Tue, Jan 24, 2023 at 4:52 PM Amit Prakash Shukla
<amitprakashs@marvell.com> wrote:
>
> Implementation adds support to capture packets at each node with
> packet metadata and node name.
>
> Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
> ---
> v2:
> - Fixed code style issue
> - Fixed CI compilation issue on github-robot
>
> v3:
> - Code review suggestion from Stephen
> - Fixed potential memory leak
>
> v4:
> - Code review suggestion from Jerin
>
> app/test/test_graph_perf.c | 2 +-
> doc/guides/rel_notes/release_23_03.rst | 7 +
> lib/graph/graph.c | 17 +-
> lib/graph/graph_pcap.c | 217 +++++++++++++++++++++++++
> lib/graph/graph_pcap_private.h | 124 ++++++++++++++
> lib/graph/graph_populate.c | 12 +-
> lib/graph/graph_private.h | 5 +
> lib/graph/meson.build | 3 +-
> lib/graph/rte_graph.h | 5 +
> lib/graph/rte_graph_worker.h | 9 +
> 10 files changed, 397 insertions(+), 4 deletions(-)
> create mode 100644 lib/graph/graph_pcap.c
> create mode 100644 lib/graph/graph_pcap_private.h
>
> diff --git a/app/test/test_graph_perf.c b/app/test/test_graph_perf.c
> index 1d065438a6..c5b463f700 100644
> --- a/app/test/test_graph_perf.c
> +++ b/app/test/test_graph_perf.c
> @@ -324,7 +324,7 @@ graph_init(const char *gname, uint8_t nb_srcs, uint8_t nb_sinks,
> char nname[RTE_NODE_NAMESIZE / 2];
> struct test_node_data *node_data;
> char *ename[nodes_per_stage];
> - struct rte_graph_param gconf;
> + struct rte_graph_param gconf = {0};
If it is Fix move to seperate patch out this series.
> const struct rte_memzone *mz;
> uint8_t total_percent = 0;
> rte_node_t *src_nodes;
> diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
> index 8c360b89e4..9ba392fb58 100644
> --- a/doc/guides/rel_notes/release_23_03.rst
> +++ b/doc/guides/rel_notes/release_23_03.rst
> @@ -69,6 +69,10 @@ New Features
> ``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
> required for eth_rx, eth_tx, crypto and timer eventdev adapters.
>
> +* **Added pcap trace support in graph library.**
> +
> + * Added support to capture packets at each graph node with packet metadata and
> + node name.
>
> Removed Items
> -------------
> @@ -101,6 +105,9 @@ API Changes
> * Experimental function ``rte_pcapng_copy`` was updated to support comment
> section in enhanced packet block in pcapng library.
>
> +* Experimental structures ``struct rte_graph_param``, ``struct rte_graph`` and
> + ``struct graph`` were updated to support pcap trace in graph library.
> +
> ABI Changes
> -----------
>
> diff --git a/lib/graph/graph.c b/lib/graph/graph.c
> index 3a617cc369..a839a2803b 100644
> --- a/lib/graph/graph.c
> +++ b/lib/graph/graph.c
> @@ -15,6 +15,7 @@
> #include <rte_string_fns.h>
>
> #include "graph_private.h"
> +#include "graph_pcap_private.h"
>
> static struct graph_head graph_list = STAILQ_HEAD_INITIALIZER(graph_list);
> static rte_spinlock_t graph_lock = RTE_SPINLOCK_INITIALIZER;
> @@ -228,7 +229,12 @@ graph_mem_fixup_node_ctx(struct rte_graph *graph)
> node_db = node_from_name(name);
> if (node_db == NULL)
> SET_ERR_JMP(ENOLINK, fail, "Node %s not found", name);
> - node->process = node_db->process;
> +
> + if (graph->pcap_enable) {
> + node->process = graph_pcap_dispatch;
> + node->original_process = node_db->process;
> + } else
> + node->process = node_db->process;
> }
>
> return graph;
> @@ -242,6 +248,9 @@ graph_mem_fixup_secondary(struct rte_graph *graph)
> if (graph == NULL || rte_eal_process_type() == RTE_PROC_PRIMARY)
> return graph;
>
> + if (graph_pcap_file_open(graph->pcap_filename) || graph_pcap_mp_init())
> + graph_pcap_exit(graph);
> +
> return graph_mem_fixup_node_ctx(graph);
> }
>
> @@ -323,11 +332,17 @@ rte_graph_create(const char *name, struct rte_graph_param *prm)
> if (graph_has_isolated_node(graph))
> goto graph_cleanup;
>
> + /* Initialize pcap config. */
> + graph_pcap_enable(prm->pcap_enable);
> +
> /* Initialize graph object */
> graph->socket = prm->socket_id;
> graph->src_node_count = src_node_count;
> graph->node_count = graph_nodes_count(graph);
> graph->id = graph_id;
> + graph->num_pkt_to_capture = prm->num_pkt_to_capture;
> + if (prm->pcap_filename)
> + rte_strscpy(graph->pcap_filename, prm->pcap_filename, RTE_GRAPH_PCAP_FILE_SZ);
>
> /* Allocate the Graph fast path memory and populate the data */
> if (graph_fp_mem_create(graph))
> diff --git a/lib/graph/graph_pcap.c b/lib/graph/graph_pcap.c
> new file mode 100644
> index 0000000000..7bd13ed61e
> --- /dev/null
> +++ b/lib/graph/graph_pcap.c
> @@ -0,0 +1,217 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2023 Marvell International Ltd.
> + */
> +
> +#include <errno.h>
> +#include <unistd.h>
> +#include <stdlib.h>
> +#include <pwd.h>
Sort in alphabetical order.
> +
> +#include <rte_mbuf.h>
> +#include <rte_pcapng.h>
> +
> +#include "rte_graph_worker.h"
> +
> +#include "graph_pcap_private.h"
> +
> +#define GRAPH_PCAP_BUF_SZ 128
> +#define GRAPH_PCAP_NUM_PACKETS 1024
> +#define GRAPH_PCAP_PKT_POOL "graph_pcap_pkt_pool"
> +#define GRAPH_PCAP_FILE_NAME "dpdk_graph_pcap_capture_XXXXXX.pcapng"
> +
> +/* For multi-process, packets are captured in separate files. */
> +static rte_pcapng_t *pcapng_fd;
> +static bool pcap_enable;
> +struct rte_mempool *pkt_mp;
> +
> +void
> +graph_pcap_enable(bool val)
> +{
> + pcap_enable = val;
> +}
> +
> +int
> +graph_pcap_is_enable(void)
> +{
> + return pcap_enable;
> +}
> +
> +void
> +graph_pcap_exit(struct rte_graph *graph)
> +{
> + if (rte_eal_process_type() == RTE_PROC_PRIMARY)
> + if (pkt_mp)
> + rte_mempool_free(pkt_mp);
> +
> + if (pcapng_fd) {
> + rte_pcapng_close(pcapng_fd);
> + pcapng_fd = NULL;
> + }
> +
> + /* Disable pcap. */
> + graph->pcap_enable = 0;
> + graph_pcap_enable(0);
> +}
> +
> +static int
> +graph_pcap_default_path_get(char **dir_path)
> +{
> + struct passwd *pwd;
> + char *home_dir;
> +
> + /* First check for shell environment variable */
> + home_dir = getenv("HOME");
> + if (home_dir == NULL) {
> + graph_warn("Home env not preset.");
> + /* Fallback to password file entry */
> + pwd = getpwuid(getuid());
> + if (pwd == NULL)
> + return -EINVAL;
> +
> + home_dir = pwd->pw_dir;
> + }
> +
> + /* Append default pcap file to directory */
> + if (asprintf(dir_path, "%s/%s", home_dir, GRAPH_PCAP_FILE_NAME) == -1)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +int
> +graph_pcap_file_open(const char *filename)
> +{
> + int fd;
> + char file_name[RTE_GRAPH_PCAP_FILE_SZ];
> + char *pcap_dir;
> +
> + if (pcapng_fd)
> + goto done;
> +
> + if (!filename || filename[0] == '\0') {
> + if (graph_pcap_default_path_get(&pcap_dir) < 0)
> + return -1;
> + snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ, "%s", pcap_dir);
> + free(pcap_dir);
> + } else {
> + snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ, "%s_XXXXXX.pcapng",
> + filename);
> + }
> +
> + fd = mkstemps(file_name, strlen(".pcapng"));
> + if (fd < 0) {
> + graph_err("mkstemps() failure");
> + return -1;
> + }
> +
> + graph_info("pcap filename: %s", file_name);
> +
> + /* Open a capture file */
> + pcapng_fd = rte_pcapng_fdopen(fd, NULL, NULL, "Graph pcap tracer",
> + NULL);
> + if (pcapng_fd == NULL) {
> + graph_err("Graph rte_pcapng_fdopen failed.");
> + close(fd);
> + return -1;
> + }
> +
> +done:
> + return 0;
> +}
> +
> +int
> +graph_pcap_mp_init(void)
> +{
> + pkt_mp = rte_mempool_lookup(GRAPH_PCAP_PKT_POOL);
> + if (pkt_mp)
> + goto done;
> +
> + /* Make a pool for cloned packets */
> + pkt_mp = rte_pktmbuf_pool_create_by_ops(GRAPH_PCAP_PKT_POOL,
> + IOV_MAX + RTE_GRAPH_BURST_SIZE, 0, 0,
> + rte_pcapng_mbuf_size(RTE_MBUF_DEFAULT_BUF_SIZE),
> + SOCKET_ID_ANY, "ring_mp_mc");
> + if (pkt_mp == NULL) {
> + graph_err("Cannot create mempool for graph pcap capture.");
> + return -1;
> + }
> +
> +done:
> + return 0;
> +}
> +
> +int
> +graph_pcap_init(struct graph *graph)
> +{
> + struct rte_graph *graph_data = graph->graph;
> +
> + if (graph_pcap_file_open(graph->pcap_filename) < 0)
> + goto error;
> +
> + if (graph_pcap_mp_init() < 0)
> + goto error;
> +
> + /* User configured number of packets to capture. */
> + if (graph->num_pkt_to_capture)
> + graph_data->nb_pkt_to_capture = graph->num_pkt_to_capture;
> + else
> + graph_data->nb_pkt_to_capture = GRAPH_PCAP_NUM_PACKETS;
> +
> + /* All good. Now populate data for secondary process. */
No need new line.
> +
> + rte_strscpy(graph_data->pcap_filename, graph->pcap_filename, RTE_GRAPH_PCAP_FILE_SZ);
> + graph_data->pcap_enable = 1;
> +
> + return 0;
> +
> +error:
> + graph_pcap_exit(graph_data);
> + graph_pcap_enable(0);
> + graph_err("Graph pcap initialization failed. Disabling pcap trace.");
> + return -1;
> +}
> +
> +uint16_t
> +graph_pcap_dispatch(struct rte_graph *graph,
> + struct rte_node *node, void **objs,
> + uint16_t nb_objs)
> +{
> + struct rte_mbuf *mbuf_clones[RTE_GRAPH_BURST_SIZE];
> + char buffer[GRAPH_PCAP_BUF_SZ];
> + uint64_t i, num_packets;
> + struct rte_mbuf *mbuf;
> + ssize_t len;
> +
> + if (!nb_objs || (graph->nb_pkt_captured >= graph->nb_pkt_to_capture))
> + goto done;
> +
> + num_packets = graph->nb_pkt_to_capture - graph->nb_pkt_captured;
> + /* nb_objs will never be greater than RTE_GRAPH_BURST_SIZE */
> + if (num_packets > nb_objs)
> + num_packets = nb_objs;
> +
> + snprintf(buffer, GRAPH_PCAP_BUF_SZ, "%s: %s", graph->name, node->name);
> +
> + for (i = 0; i < num_packets; i++) {
> + struct rte_mbuf *mc;
> + mbuf = (struct rte_mbuf *)objs[i];
> +
> + mc = rte_pcapng_copy(mbuf->port, 0, mbuf, pkt_mp, mbuf->pkt_len,
> + rte_get_tsc_cycles(), 0, buffer);
> + if (mc == NULL)
> + break;
> +
> + mbuf_clones[i] = mc;
> + }
> +
> + /* write it to capture file */
> + len = rte_pcapng_write_packets(pcapng_fd, mbuf_clones, i);
> + rte_pktmbuf_free_bulk(mbuf_clones, i);
> + if (len <= 0)
> + goto done;
> +
> + graph->nb_pkt_captured += i;
> +
> +done:
> + return node->original_process(graph, node, objs, nb_objs);
> +}
> diff --git a/lib/graph/graph_pcap_private.h b/lib/graph/graph_pcap_private.h
> new file mode 100644
> index 0000000000..198add67e2
> --- /dev/null
> +++ b/lib/graph/graph_pcap_private.h
> @@ -0,0 +1,124 @@
> +/* SPDX-License-Identifier: BSD-3-Clause
> + * Copyright(C) 2023 Marvell International Ltd.
> + */
> +
> +#ifndef _RTE_GRAPH_PCAP_PRIVATE_H_
> +#define _RTE_GRAPH_PCAP_PRIVATE_H_
> +
> +#include <stdint.h>
> +#include <sys/types.h>
> +
> +#include "graph_private.h"
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
No need this for internal header files
> +
> +/**
> + * @internal
> + *
> + * Pcap trace enable/disable function.
> + *
> + * The function is called to enable/disable graph pcap trace functionality.
> + *
> + * @param val
> + * Value to be set to enable/disable graph pcap trace.
> + */
> +void graph_pcap_enable(bool val);
> +
> +/**
> + * @internal
> + *
> + * Check graph pcap trace is enable/disable.
> + *
> + * The function is called to check if the graph pcap trace is enabled/disabled.
> + *
> + * @return
> + * - 1: Enable
> + * - 0: Disable
> + */
> +int graph_pcap_is_enable(void);
> +
> +/**
> + * @internal
> + *
> + * Initialise graph pcap trace functionality.
> + *
> + * The function invoked to allocate mempool.
> + *
> + * @return
> + * 0 on success and -1 on failure.
> + */
> +int graph_pcap_mp_init(void);
> +
> +/**
> + * @internal
> + *
> + * Initialise graph pcap trace functionality.
> + *
> + * The function invoked to open pcap file.
> + *
> + * @param filename
> + * Pcap filename.
> + *
> + * @return
> + * 0 on success and -1 on failure.
> + */
> +int graph_pcap_file_open(const char *filename);
> +
> +/**
> + * @internal
> + *
> + * Initialise graph pcap trace functionality.
> + *
> + * The function invoked when the graph pcap trace is enabled. This function
> + * open's pcap file and allocates mempool. Information needed for secondary
> + * process is populated.
> + *
> + * @param graph
> + * Pointer to graph structure.
> + *
> + * @return
> + * 0 on success and -1 on failure.
> + */
> +int graph_pcap_init(struct graph *graph);
> +
> +/**
> + * @internal
> + *
> + * Exit graph pcap trace functionality.
> + *
> + * The function is called to exit graph pcap trace and close open fd's and
> + * free up memory. Pcap trace is also disabled.
> + *
> + * @param graph
> + * Pointer to graph structure.
> + */
> +void graph_pcap_exit(struct rte_graph *graph);
> +
> +/**
> + * @internal
> + *
> + * Capture mbuf metadata and node metadata to a pcap file.
> + *
> + * When graph pcap trace enabled, this function is invoked prior to each node
> + * and mbuf, node metadata is parsed and captured in a pcap file.
> + *
> + * @param graph
> + * Pointer to the graph object.
> + * @param node
> + * Pointer to the node object.
> + * @param objs
> + * Pointer to an array of objects to be processed.
> + * @param nb_objs
> + * Number of objects in the array.
> + */
> +uint16_t graph_pcap_dispatch(struct rte_graph *graph,
> + struct rte_node *node, void **objs,
> + uint16_t nb_objs);
> +
> +#ifdef __cplusplus
> +}
> +#endif
> +
> +#endif /* _RTE_GRAPH_PCAP_PRIVATE_H_ */
> diff --git a/lib/graph/graph_populate.c b/lib/graph/graph_populate.c
> index 102fd6c29b..2c0844ce92 100644
> --- a/lib/graph/graph_populate.c
> +++ b/lib/graph/graph_populate.c
> @@ -9,6 +9,7 @@
> #include <rte_memzone.h>
>
> #include "graph_private.h"
> +#include "graph_pcap_private.h"
>
> static size_t
> graph_fp_mem_calc_size(struct graph *graph)
> @@ -75,7 +76,11 @@ graph_nodes_populate(struct graph *_graph)
> memset(node, 0, sizeof(*node));
> node->fence = RTE_GRAPH_FENCE;
> node->off = off;
> - node->process = graph_node->node->process;
> + if (graph_pcap_is_enable()) {
> + node->process = graph_pcap_dispatch;
> + node->original_process = graph_node->node->process;
> + } else
> + node->process = graph_node->node->process;
> memcpy(node->name, graph_node->node->name, RTE_GRAPH_NAMESIZE);
> pid = graph_node->node->parent_id;
> if (pid != RTE_NODE_ID_INVALID) { /* Cloned node */
> @@ -183,6 +188,8 @@ graph_fp_mem_populate(struct graph *graph)
> int rc;
>
> graph_header_popluate(graph);
> + if (graph_pcap_is_enable())
> + graph_pcap_init(graph);
> graph_nodes_populate(graph);
> rc = graph_node_nexts_populate(graph);
> rc |= graph_src_nodes_populate(graph);
> @@ -227,6 +234,9 @@ graph_nodes_mem_destroy(struct rte_graph *graph)
> int
> graph_fp_mem_destroy(struct graph *graph)
> {
> + if (graph_pcap_is_enable())
> + graph_pcap_exit(graph->graph);
> +
> graph_nodes_mem_destroy(graph->graph);
> return rte_memzone_free(graph->mz);
> }
> diff --git a/lib/graph/graph_private.h b/lib/graph/graph_private.h
> index f9a85c8926..7d1b30b8ac 100644
> --- a/lib/graph/graph_private.h
> +++ b/lib/graph/graph_private.h
> @@ -22,6 +22,7 @@ extern int rte_graph_logtype;
> __func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__, )))
>
> #define graph_err(...) GRAPH_LOG(ERR, __VA_ARGS__)
> +#define graph_warn(...) GRAPH_LOG(WARNING, __VA_ARGS__)
> #define graph_info(...) GRAPH_LOG(INFO, __VA_ARGS__)
> #define graph_dbg(...) GRAPH_LOG(DEBUG, __VA_ARGS__)
>
> @@ -100,6 +101,10 @@ struct graph {
> /**< Memory size of the graph. */
> int socket;
> /**< Socket identifier where memory is allocated. */
> + uint64_t num_pkt_to_capture;
> + /**< Number of packets to be captured per core. */
> + char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ];
> + /**< pcap file name/path. */
> STAILQ_HEAD(gnode_list, graph_node) node_list;
> /**< Nodes in a graph. */
> };
> diff --git a/lib/graph/meson.build b/lib/graph/meson.build
> index c7327549e8..3526d1b5d4 100644
> --- a/lib/graph/meson.build
> +++ b/lib/graph/meson.build
> @@ -14,7 +14,8 @@ sources = files(
> 'graph_debug.c',
> 'graph_stats.c',
> 'graph_populate.c',
> + 'graph_pcap.c',
> )
> headers = files('rte_graph.h', 'rte_graph_worker.h')
>
> -deps += ['eal']
> +deps += ['eal', 'pcapng']
> diff --git a/lib/graph/rte_graph.h b/lib/graph/rte_graph.h
> index b32c4bc217..c9a77297fc 100644
> --- a/lib/graph/rte_graph.h
> +++ b/lib/graph/rte_graph.h
> @@ -35,6 +35,7 @@ extern "C" {
>
> #define RTE_GRAPH_NAMESIZE 64 /**< Max length of graph name. */
> #define RTE_NODE_NAMESIZE 64 /**< Max length of node name. */
> +#define RTE_GRAPH_PCAP_FILE_SZ 64 /**< Max length of pcap file name. */
> #define RTE_GRAPH_OFF_INVALID UINT32_MAX /**< Invalid graph offset. */
> #define RTE_NODE_ID_INVALID UINT32_MAX /**< Invalid node id. */
> #define RTE_EDGE_ID_INVALID UINT16_MAX /**< Invalid edge id. */
> @@ -164,6 +165,10 @@ struct rte_graph_param {
> uint16_t nb_node_patterns; /**< Number of node patterns. */
> const char **node_patterns;
> /**< Array of node patterns based on shell pattern. */
> +
> + bool pcap_enable; /**< Pcap enable. */
> + uint64_t num_pkt_to_capture; /**< Number of packets to capture. */
> + char *pcap_filename; /**< Filename in which packets to be captured.*/
> };
>
> /**
> diff --git a/lib/graph/rte_graph_worker.h b/lib/graph/rte_graph_worker.h
> index fc6fee48c8..438595b15c 100644
> --- a/lib/graph/rte_graph_worker.h
> +++ b/lib/graph/rte_graph_worker.h
> @@ -44,6 +44,12 @@ struct rte_graph {
> rte_graph_t id; /**< Graph identifier. */
> int socket; /**< Socket ID where memory is allocated. */
> char name[RTE_GRAPH_NAMESIZE]; /**< Name of the graph. */
> + bool pcap_enable; /**< Pcap trace enabled. */
> + /** Number of packets captured per core. */
> + uint64_t nb_pkt_captured;
> + /** Number of packets to capture per core. */
> + uint64_t nb_pkt_to_capture;
> + char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ]; /**< Pcap filename. */
> uint64_t fence; /**< Fence. */
> } __rte_cache_aligned;
>
> @@ -64,6 +70,9 @@ struct rte_node {
> char parent[RTE_NODE_NAMESIZE]; /**< Parent node name. */
> char name[RTE_NODE_NAMESIZE]; /**< Name of the node. */
>
> + /** Original process function when pcap is enabled. */
> + rte_node_process_t original_process;
> +
> /* Fast path area */
> #define RTE_NODE_CTX_SZ 16
> uint8_t ctx[RTE_NODE_CTX_SZ] __rte_cache_aligned; /**< Node Context. */
> --
> 2.25.1
>
^ permalink raw reply [relevance 0%]
* [PATCH V5 2/5] ethdev: fix skip valid port in probing callback
2023-01-31 3:33 3% ` [PATCH V5 0/5] app/testpmd: support multiple " Huisong Li
@ 2023-01-31 3:33 2% ` Huisong Li
0 siblings, 0 replies; 200+ results
From: Huisong Li @ 2023-01-31 3:33 UTC (permalink / raw)
To: dev
Cc: thomas, ferruh.yigit, andrew.rybchenko, liudongdong3, huangdaode,
fengchengwen, lihuisong
The event callback in application may use the macro RTE_ETH_FOREACH_DEV to
iterate over all enabled ports to do something(like, verifying the port id
validity) when receive a probing event. If the ethdev state of a port is
not RTE_ETH_DEV_UNUSED, this port will be considered as a valid port.
However, this state is set to RTE_ETH_DEV_ATTACHED after pushing probing
event. It means that probing callback will skip this port. But this
assignment can not move to front of probing notification. See
commit be8cd210379a ("ethdev: fix port probing notification")
So this patch has to add a new state, RTE_ETH_DEV_ALLOCATED. Set the ethdev
state to RTE_ETH_DEV_ALLOCATED before pushing probing event and set it to
RTE_ETH_DEV_ATTACHED after definitely probed. And this port is valid if its
device state is 'ALLOCATED' or 'ATTACHED'.
In addition, the new state has to be placed behind 'REMOVED' to avoid ABI
break. Fortunately, this ethdev state is internal and applications can not
access it directly. So this patch encapsulates an API, rte_eth_dev_is_used,
for ethdev or PMD to call and eliminate concerns about using this state
enum value comparison.
Fixes: be8cd210379a ("ethdev: fix port probing notification")
Cc: stable@dpdk.org
Signed-off-by: Huisong Li <lihuisong@huawei.com>
---
drivers/net/bnxt/bnxt_ethdev.c | 3 ++-
drivers/net/mlx5/mlx5.c | 2 +-
lib/ethdev/ethdev_driver.c | 13 ++++++++++---
lib/ethdev/ethdev_driver.h | 12 ++++++++++++
lib/ethdev/ethdev_pci.h | 2 +-
lib/ethdev/rte_class_eth.c | 2 +-
lib/ethdev/rte_ethdev.c | 4 ++--
lib/ethdev/rte_ethdev.h | 4 +++-
lib/ethdev/version.map | 1 +
9 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index b3de490d36..be5c93010e 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -6003,7 +6003,8 @@ bnxt_dev_uninit(struct rte_eth_dev *eth_dev)
PMD_DRV_LOG(DEBUG, "Calling Device uninit\n");
- if (eth_dev->state != RTE_ETH_DEV_UNUSED)
+
+ if (rte_eth_dev_is_used(eth_dev->state))
bnxt_dev_close_op(eth_dev);
return 0;
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index e55be8720e..7f4dafaa22 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -3014,7 +3014,7 @@ mlx5_eth_find_next(uint16_t port_id, struct rte_device *odev)
while (port_id < RTE_MAX_ETHPORTS) {
struct rte_eth_dev *dev = &rte_eth_devices[port_id];
- if (dev->state != RTE_ETH_DEV_UNUSED &&
+ if (rte_eth_dev_is_used(dev->state) &&
dev->device &&
(dev->device == odev ||
(dev->device->driver &&
diff --git a/lib/ethdev/ethdev_driver.c b/lib/ethdev/ethdev_driver.c
index 0be1e8ca04..29e9417bea 100644
--- a/lib/ethdev/ethdev_driver.c
+++ b/lib/ethdev/ethdev_driver.c
@@ -50,8 +50,8 @@ eth_dev_find_free_port(void)
for (i = 0; i < RTE_MAX_ETHPORTS; i++) {
/* Using shared name field to find a free port. */
if (eth_dev_shared_data->data[i].name[0] == '\0') {
- RTE_ASSERT(rte_eth_devices[i].state ==
- RTE_ETH_DEV_UNUSED);
+ RTE_ASSERT(!rte_eth_dev_is_used(
+ rte_eth_devices[i].state));
return i;
}
}
@@ -208,11 +208,18 @@ rte_eth_dev_probing_finish(struct rte_eth_dev *dev)
if (rte_eal_process_type() == RTE_PROC_SECONDARY)
eth_dev_fp_ops_setup(rte_eth_fp_ops + dev->data->port_id, dev);
+ dev->state = RTE_ETH_DEV_ALLOCATED;
rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_NEW, NULL);
dev->state = RTE_ETH_DEV_ATTACHED;
}
+bool rte_eth_dev_is_used(uint16_t dev_state)
+{
+ return dev_state == RTE_ETH_DEV_ALLOCATED ||
+ dev_state == RTE_ETH_DEV_ATTACHED;
+}
+
int
rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
{
@@ -221,7 +228,7 @@ rte_eth_dev_release_port(struct rte_eth_dev *eth_dev)
eth_dev_shared_data_prepare();
- if (eth_dev->state != RTE_ETH_DEV_UNUSED)
+ if (rte_eth_dev_is_used(eth_dev->state))
rte_eth_dev_callback_process(eth_dev,
RTE_ETH_EVENT_DESTROY, NULL);
diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
index 6a550cfc83..dde3ec84ef 100644
--- a/lib/ethdev/ethdev_driver.h
+++ b/lib/ethdev/ethdev_driver.h
@@ -1542,6 +1542,18 @@ int rte_eth_dev_callback_process(struct rte_eth_dev *dev,
__rte_internal
void rte_eth_dev_probing_finish(struct rte_eth_dev *dev);
+/**
+ * Check if a Ethernet device state is used or not
+ *
+ * @param dev_state
+ * The state of the Ethernet device
+ * @return
+ * - true if the state of the Ethernet device is allocated or attached
+ * - false if this state is neither allocated nor attached
+ */
+__rte_internal
+bool rte_eth_dev_is_used(uint16_t dev_state);
+
/**
* Create memzone for HW rings.
* malloc can't be used as the physical address is needed.
diff --git a/lib/ethdev/ethdev_pci.h b/lib/ethdev/ethdev_pci.h
index 94b8fba5d7..23270ccd73 100644
--- a/lib/ethdev/ethdev_pci.h
+++ b/lib/ethdev/ethdev_pci.h
@@ -164,7 +164,7 @@ rte_eth_dev_pci_generic_remove(struct rte_pci_device *pci_dev,
* eth device has been released.
*/
if (rte_eal_process_type() == RTE_PROC_SECONDARY &&
- eth_dev->state == RTE_ETH_DEV_UNUSED)
+ !rte_eth_dev_is_used(eth_dev->state))
return 0;
if (dev_uninit) {
diff --git a/lib/ethdev/rte_class_eth.c b/lib/ethdev/rte_class_eth.c
index 838b3a8f9f..504bfd99c9 100644
--- a/lib/ethdev/rte_class_eth.c
+++ b/lib/ethdev/rte_class_eth.c
@@ -118,7 +118,7 @@ eth_dev_match(const struct rte_eth_dev *edev,
const struct rte_kvargs *kvlist = arg->kvlist;
unsigned int pair;
- if (edev->state == RTE_ETH_DEV_UNUSED)
+ if (!rte_eth_dev_is_used(edev->state))
return -1;
if (arg->device != NULL && arg->device != edev->device)
return -1;
diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
index 5d5e18db1e..86ca303ab5 100644
--- a/lib/ethdev/rte_ethdev.c
+++ b/lib/ethdev/rte_ethdev.c
@@ -325,7 +325,7 @@ uint16_t
rte_eth_find_next(uint16_t port_id)
{
while (port_id < RTE_MAX_ETHPORTS &&
- rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED)
+ !rte_eth_dev_is_used(rte_eth_devices[port_id].state))
port_id++;
if (port_id >= RTE_MAX_ETHPORTS)
@@ -372,7 +372,7 @@ int
rte_eth_dev_is_valid_port(uint16_t port_id)
{
if (port_id >= RTE_MAX_ETHPORTS ||
- (rte_eth_devices[port_id].state == RTE_ETH_DEV_UNUSED))
+ !rte_eth_dev_is_used(rte_eth_devices[port_id].state))
return 0;
else
return 1;
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index c129ca1eaf..d22de196db 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -2000,10 +2000,12 @@ typedef uint16_t (*rte_tx_callback_fn)(uint16_t port_id, uint16_t queue,
enum rte_eth_dev_state {
/** Device is unused before being probed. */
RTE_ETH_DEV_UNUSED = 0,
- /** Device is attached when allocated in probing. */
+ /** Device is attached when definitely probed. */
RTE_ETH_DEV_ATTACHED,
/** Device is in removed state when plug-out is detected. */
RTE_ETH_DEV_REMOVED,
+ /** Device is allocated and is set before reporting new event. */
+ RTE_ETH_DEV_ALLOCATED,
};
struct rte_eth_dev_sriov {
diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
index 17201fbe0f..094c2a952e 100644
--- a/lib/ethdev/version.map
+++ b/lib/ethdev/version.map
@@ -327,4 +327,5 @@ INTERNAL {
rte_eth_representor_id_get;
rte_eth_switch_domain_alloc;
rte_eth_switch_domain_free;
+ rte_eth_dev_is_used;
};
--
2.22.0
^ permalink raw reply [relevance 2%]
* [PATCH V5 0/5] app/testpmd: support multiple process attach and detach port
[not found] <20220825024425.10534-1-lihuisong@huawei.com>
@ 2023-01-31 3:33 3% ` Huisong Li
2023-01-31 3:33 2% ` [PATCH V5 2/5] ethdev: fix skip valid port in probing callback Huisong Li
1 sibling, 1 reply; 200+ results
From: Huisong Li @ 2023-01-31 3:33 UTC (permalink / raw)
To: dev
Cc: thomas, ferruh.yigit, andrew.rybchenko, liudongdong3, huangdaode,
fengchengwen, lihuisong
This patchset fix some bugs and support attaching and detaching port
in primary and secondary.
---
-v5: move 'ALLOCATED' state to the back of 'REMOVED' to avoid abi break.
-v4: fix a misspelling.
-v3:
#1 merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
for other bus type.
#2 add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
the probelm in patch 2/5.
-v2: resend due to CI unexplained failure.
Huisong Li (5):
drivers/bus: restore driver assignment at front of probing
ethdev: fix skip valid port in probing callback
app/testpmd: check the validity of the port
app/testpmd: add attach and detach port for multiple process
app/testpmd: stop forwarding in new or destroy event
app/test-pmd/testpmd.c | 47 +++++++++++++++---------
app/test-pmd/testpmd.h | 1 -
drivers/bus/auxiliary/auxiliary_common.c | 9 ++++-
drivers/bus/dpaa/dpaa_bus.c | 9 ++++-
drivers/bus/fslmc/fslmc_bus.c | 8 +++-
drivers/bus/ifpga/ifpga_bus.c | 12 ++++--
drivers/bus/pci/pci_common.c | 9 ++++-
drivers/bus/vdev/vdev.c | 10 ++++-
drivers/bus/vmbus/vmbus_common.c | 9 ++++-
drivers/net/bnxt/bnxt_ethdev.c | 3 +-
drivers/net/bonding/bonding_testpmd.c | 1 -
drivers/net/mlx5/mlx5.c | 2 +-
lib/ethdev/ethdev_driver.c | 13 +++++--
lib/ethdev/ethdev_driver.h | 12 ++++++
lib/ethdev/ethdev_pci.h | 2 +-
lib/ethdev/rte_class_eth.c | 2 +-
lib/ethdev/rte_ethdev.c | 4 +-
lib/ethdev/rte_ethdev.h | 4 +-
lib/ethdev/version.map | 1 +
19 files changed, 114 insertions(+), 44 deletions(-)
--
2.22.0
^ permalink raw reply [relevance 3%]
* Re: [PATCH v10 1/2] cmdline: handle EOF in cmdline_poll
@ 2023-01-30 22:12 3% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-01-30 22:12 UTC (permalink / raw)
To: Stephen Hemminger, dev; +Cc: Olivier Matz
On 1/30/2023 8:09 PM, Stephen Hemminger wrote:
> If end of file is reached on input, then cmdline_read_char()
> will return 0. The problem is that cmdline_poll() was not checking
> for this and would continue and not return the status.
>
> Fixes: 9251cd97a6be ("cmdline: add internal wrappers for character input")
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> ---
> lib/cmdline/cmdline.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/cmdline/cmdline.c b/lib/cmdline/cmdline.c
> index e1009ba4c413..de41406d61e0 100644
> --- a/lib/cmdline/cmdline.c
> +++ b/lib/cmdline/cmdline.c
> @@ -194,7 +194,7 @@ cmdline_poll(struct cmdline *cl)
> else if (status > 0) {
> c = -1;
> read_status = cmdline_read_char(cl, &c);
> - if (read_status < 0)
> + if (read_status <= 0)
> return read_status;
According API doc it will be wrong to return '0', which imply 'RDLINE_INIT'.
But function may return any negative value on error, what about to get
eof as and error case:
if (read_status < 0)
return read_status;
else if (read_status == 0)
return -EIO;
With this 'cmdline_poll()' can be used in testpmd as it is used in v9 of
this patch:
while (f_quit == 0 && cl_quit == 0) {
if (cmdline_poll(cl) < 0)
break;
}
But still I guess this is an ABI break because of API behavior change.
^ permalink raw reply [relevance 3%]
* RE: [EXT] [PATCH] compressdev: fix end of comp PMD list macro conflict
@ 2023-01-30 19:30 3% ` Akhil Goyal
2023-01-31 8:23 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2023-01-30 19:30 UTC (permalink / raw)
To: Michael Baum, dev
Cc: Matan Azrad, Ashish Gupta, Fan Zhang, Kai Ji, Thomas Monjalon,
fiona.trahe, roy.fan.zhang, stable
> The "rte_compressdev_info_get()" function retrieves the contextual
> information of a device.
> The output structure "dev_info" contains a list of devices supported
> capabilities for each supported algorithm.
>
> In this function description, it says the element after the last valid
> element has op field set to "RTE_COMP_ALGO_LIST_END".
> On the other hand, when this function used by
> "rte_compressdev_capability_get()" function, it uses
> "RTE_COMP_ALGO_UNSPECIFIED" as end of list as same as the
> "RTE_COMP_END_OF_CAPABILITIES_LIST()".
>
> The mlx5 and qat PMDs use "RTE_COMP_ALGO_LIST_END" as the end of
> capabilities list. When "rte_compressdev_capability_get()" function is
> called with unsupported algorithm, it might read memory out of bound.
>
> This patch change the "rte_compressdev_info_get()" function description
> to say using "RTE_COMP_ALGO_UNSPECIFIED" as the end of capabilities
> list.
> In addition, it moves both mlx5 and qat PMDs to use
> "RTE_COMP_ALGO_UNSPECIFIED" through
> "RTE_COMP_END_OF_CAPABILITIES_LIST()" macro.
>
> Fixes: 5d432f364078 ("compressdev: add device capabilities")
> Fixes: 2d148597ce76 ("compress/qat: add gen-specific implementation")
> Fixes: 384bac8d6555 ("compress/mlx5: add supported capabilities")
> Cc: fiona.trahe@intel.com
> Cc: roy.fan.zhang@intel.com
> Cc: matan@nvidia.com
> Cc: stable@dpdk.org
>
> Signed-off-by: Michael Baum <michaelba@nvidia.com>
>
> ---
>
> After this change, I'm not sure about the purpose of
> "RTE_COMP_ALGO_LIST_END".
> There is no any other use of it in DPDK code, and it isn't represent the
> number of algorithms supported by the API since the
> "RTE_COMP_ALGO_UNSPECIFIED" is part of the enum.
>
> Due to the compress API is experimental I think the
> "RTE_COMP_ALGO_LIST_END" can be removed.
>
+1 to remove the list end enums. This will also help in avoiding ABI breakage
When we make this lib as stable.
^ permalink raw reply [relevance 3%]
* [PATCH v2 2/2] ethdev: introduce the PHY affinity field in Tx queue API
@ 2023-01-30 17:00 2% ` Jiawei Wang
2023-01-31 17:26 3% ` Thomas Monjalon
2023-02-01 9:05 0% ` Andrew Rybchenko
0 siblings, 2 replies; 200+ results
From: Jiawei Wang @ 2023-01-30 17:00 UTC (permalink / raw)
To: viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko
Cc: dev, rasland
For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the
phy affinity of the received packets.
This patch adds the tx_phy_affinity setting in Tx queue API, the affinity
value reflects packets be sent to which hardware port.
Value 0 is no affinity and traffic will be routed between different
physical ports, if 0 is disabled then try to match on phy_affinity 0
will result in an error.
Adds the new tx_phy_affinity field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.
This patch adds the testpmd command line:
testpmd> port config (port_id) txq (queue_id) phy_affinity (value)
For example, there're two hardware ports 0 and 1 connected to
a single DPDK port (port id 0), and phy_affinity 1 stood for
hardware port 0 and phy_affinity 2 stood for hardware port 1,
used the below command to config tx phy affinity for per Tx Queue:
port config 0 txq 0 phy_affinity 1
port config 0 txq 1 phy_affinity 1
port config 0 txq 2 phy_affinity 2
port config 0 txq 3 phy_affinity 2
These commands config the TxQ index 0 and TxQ index 1 with phy affinity 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 0, and similar with hardware port 1 if sending packets
with TxQ 2 or TxQ 3.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
---
app/test-pmd/cmdline.c | 84 +++++++++++++++++++++
devtools/libabigail.abignore | 5 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 ++++
lib/ethdev/rte_ethdev.h | 7 ++
4 files changed, 109 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd4..768f35cb02 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -764,6 +764,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
" Cleanup txq mbufs for a specific Tx queue\n\n"
+
+ "port config (port_id) txq (queue_id) phy_affinity (value)\n"
+ " Set the physical affinity value "
+ "on a specific Tx queue\n\n"
);
}
@@ -12621,6 +12625,85 @@ static cmdline_parse_inst_t cmd_show_port_flow_transfer_proxy = {
}
};
+/* *** configure port txq phy_affinity value *** */
+struct cmd_config_tx_phy_affinity {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t config;
+ portid_t portid;
+ cmdline_fixed_string_t txq;
+ uint16_t qid;
+ cmdline_fixed_string_t phy_affinity;
+ uint16_t value;
+};
+
+static void
+cmd_config_tx_phy_affinity_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_config_tx_phy_affinity *res = parsed_result;
+ struct rte_port *port;
+
+ if (port_id_is_invalid(res->portid, ENABLED_WARN))
+ return;
+
+ if (res->portid == (portid_t)RTE_PORT_ALL) {
+ printf("Invalid port id\n");
+ return;
+ }
+
+ port = &ports[res->portid];
+
+ if (strcmp(res->txq, "txq")) {
+ printf("Unknown parameter\n");
+ return;
+ }
+ if (tx_queue_id_is_invalid(res->qid))
+ return;
+
+ port->txq[res->qid].conf.tx_phy_affinity = res->value;
+
+ cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ port, "port");
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_config =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ config, "config");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_portid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_txq =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_qid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_phy_affinity_hwport =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ phy_affinity, "phy_affinity");
+cmdline_parse_token_num_t cmd_config_tx_phy_affinity_value =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_phy_affinity,
+ value, RTE_UINT16);
+
+static cmdline_parse_inst_t cmd_config_tx_phy_affinity = {
+ .f = cmd_config_tx_phy_affinity_parsed,
+ .data = (void *)0,
+ .help_str = "port config <port_id> txq <queue_id> phy_affinity <value>",
+ .tokens = {
+ (void *)&cmd_config_tx_phy_affinity_port,
+ (void *)&cmd_config_tx_phy_affinity_config,
+ (void *)&cmd_config_tx_phy_affinity_portid,
+ (void *)&cmd_config_tx_phy_affinity_txq,
+ (void *)&cmd_config_tx_phy_affinity_qid,
+ (void *)&cmd_config_tx_phy_affinity_hwport,
+ (void *)&cmd_config_tx_phy_affinity_value,
+ NULL,
+ },
+};
+
/* ******************************************************************************** */
/* list of instructions */
@@ -12851,6 +12934,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_show_capability,
(cmdline_parse_inst_t *)&cmd_set_flex_is_pattern,
(cmdline_parse_inst_t *)&cmd_set_flex_spec_pattern,
+ (cmdline_parse_inst_t *)&cmd_config_tx_phy_affinity,
NULL,
};
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..cbbde4ef05 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -20,6 +20,11 @@
[suppress_file]
soname_regexp = ^librte_.*mlx.*glue\.
+; Ignore fields inserted in middle padding of rte_eth_txconf
+[suppress_type]
+ name = rte_eth_txconf
+ has_data_member_inserted_between = {offset_after(tx_deferred_start), offset_of(offloads)}
+
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Experimental APIs exceptions ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 1853030e93..e9f20607a2 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1605,6 +1605,19 @@ Enable or disable a per queue Tx offloading only on a specific Tx queue::
This command should be run when the port is stopped, or else it will fail.
+config per queue Tx physical affinity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Configure a per queue physical affinity value only on a specific Tx queue::
+
+ testpmd> port (port_id) txq (queue_id) phy_affinity (value)
+
+* ``phy_affinity``: reflects packet can be sent to which hardware port.
+ uses it on multiple hardware ports connect to
+ a single DPDK port (mhpsdp).
+
+This command should be run when the port is stopped, or else it will fail.
+
Config VXLAN Encap outer layers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index c129ca1eaf..b30467c192 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1138,6 +1138,13 @@ struct rte_eth_txconf {
less free descriptors than this value. */
uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
+ /**
+ * Physical affinity to be set.
+ * Value 0 is no affinity and traffic could be routed between different
+ * physical ports, if 0 is disabled then try to match on phy_affinity 0 will
+ * result in an error.
+ */
+ uint8_t tx_phy_affinity;
/**
* Per-queue Tx offloads to be set using RTE_ETH_TX_OFFLOAD_* flags.
* Only offloads set on tx_queue_offload_capa or tx_offload_capa
--
2.18.1
^ permalink raw reply [relevance 2%]
* Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-30 9:56 0% ` Naga Harish K, S V
@ 2023-01-30 14:43 0% ` Jerin Jacob
2023-02-02 16:12 0% ` Naga Harish K, S V
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-30 14:43 UTC (permalink / raw)
To: Naga Harish K, S V
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Mon, Jan 30, 2023 at 3:26 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Saturday, January 28, 2023 4:24 PM
> > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> > Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> > Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
> > <s.v.naga.harish.k@intel.com> wrote:
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> >
> > > > > > >
> > > > > > > > > + */
> > > > > > > > > + uint32_t rsvd[15];
> > > > > > > > > + /**< Reserved fields for future use */
> > > > > > > >
> > > > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> > > > make
> > > > > > > > sure rsvd is zero.
> > > > > > > >
> > > > > > >
> > > > > > > The reserved fields are not used by the adapter or application.
> > > > > > > Not sure Is it necessary to Introduce a new API to clear reserved
> > fields.
> > > > > >
> > > > > > When adapter starts using new fileds(when we add new fieds in
> > > > > > future), the old applicaiton which is not using
> > > > > > rte_event_eth_rx_adapter_runtime_params_init() may have junk
> > > > > > value and then adapter implementation will behave bad.
> > > > > >
> > > > > >
> > > > >
> > > > > does it mean, the application doesn't re-compile for the new DPDK?
> > > >
> > > > Yes. No need recompile if ABI not breaking.
> > > >
> > > > > When some of the reserved fields are used in the future, the
> > > > > application
> > > > also may need to be recompiled along with DPDK right?
> > > > > As the application also may need to use the newly consumed
> > > > > reserved
> > > > fields?
> > > >
> > > > The problematic case is:
> > > >
> > > > Adapter implementation of 23.07(Assuming there is change params)
> > > > field needs to work with application of 23.03.
> > > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > > >
> > >
> > > As rte_event_eth_rx_adapter_runtime_params_init() initializes only
> > reserved fields to zero, it may not solve the issue in this case.
> >
> > rte_event_eth_rx_adapter_runtime_params_init() needs to zero all fields,
> > not just reserved field.
> > The application calling sequence is
> >
> > struct my_config c;
> > rte_event_eth_rx_adapter_runtime_params_init(&c)
> > c.interseted_filed_to_be_updated = val;
> >
> Can it be done like
> struct my_config c = {0};
> c.interseted_filed_to_be_updated = val;
> and update Doxygen comments to recommend above usage to reset all fields?
> This way, rte_event_eth_rx_adapter_runtime_params_init() can be avoided.
Better to have a function for documentation clarity. Similar scheme
already there
in DPDK. See rte_eth_cman_config_init()
>
> > Let me share an example and you can tell where is the issue
> >
> > 1)Assume parameter structure is 64B and for 22.03 8B are used.
> > 2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
> > 3)There is an application written based on 22.03 which using only 8B after
> > calling rte_event_eth_rx_adapter_runtime_params_init()
> > 4)Assume, in 22.07 another 8B added to structure.
> > 5)Now, the application (3) needs to run on 22.07. Since the application is
> > calling rte_event_eth_rx_adapter_runtime_params_init()
> > and 9 to 15B are zero, the implementation will not go bad.
> >
> > > The old application only tries to set/get previous valid fields and the newly
> > used fields may still contain junk value.
> > > If the application wants to make use of any the newly used params, the
> > application changes are required anyway.
> >
> > Yes. If application wants to make use of newly added features. No need to
> > change if new features are not needed for old application.
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
2023-01-25 16:09 2% ` Ferruh Yigit
@ 2023-01-30 13:35 0% ` Ankur Dwivedi
0 siblings, 0 replies; 200+ results
From: Ankur Dwivedi @ 2023-01-30 13:35 UTC (permalink / raw)
To: Ferruh Yigit, dev
Cc: thomas, david.marchand, mdr, orika, chas3, humin29, linville,
ciara.loftus, qi.z.zhang, mw, mk, shaibran, evgenys, igorch,
chandu, Igor Russkikh, shepard.siegel, ed.czeck, john.miller,
ajit.khaparde, somnath.kotur, Jerin Jacob Kollanukkaran,
Maciej Czekaj [C],
Shijith Thotton, Srisivasubramanian Srinivasan, Harman Kalra,
rahul.lakkireddy, johndale, hyonkim, liudongdong3, yisen.zhuang,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, simei.su,
wenjun1.wu, qiming.yang, Yuying.Zhang, beilei.xing, xiao.w.wang,
jingjing.wu, junfeng.guo, rosen.xu, Nithin Kumar Dabilpuram,
Kiran Kumar Kokkilagadda, Sunil Kumar Kori,
Satha Koteswara Rao Kottidi, Liron Himi, zr, Radha Chintakuntla,
Veerasenareddy Burru, Sathesh B Edara, matan, viacheslavo,
longli, spinler, chaoyong.he, niklas.soderlund, hemant.agrawal,
sachin.saxena, g.singh, apeksha.gupta, sachin.saxena, aboyer,
Rasesh Mody, Shahed Shaikh, Devendra Singh Rawat,
andrew.rybchenko, jiawenwu, jianwang, jbehrens, maxime.coquelin,
chenbo.xia, steven.webster, matt.peters, bruce.richardson,
mtetsuyah, grive, jasvinder.singh, cristian.dumitrescu, jgrajcia,
mb
>-----Original Message-----
>From: Ferruh Yigit <ferruh.yigit@amd.com>
>Sent: Wednesday, January 25, 2023 9:40 PM
>To: Ankur Dwivedi <adwivedi@marvell.com>; dev@dpdk.org
>Cc: thomas@monjalon.net; david.marchand@redhat.com; mdr@ashroe.eu;
>orika@nvidia.com; chas3@att.com; humin29@huawei.com;
>linville@tuxdriver.com; ciara.loftus@intel.com; qi.z.zhang@intel.com;
>mw@semihalf.com; mk@semihalf.com; shaibran@amazon.com;
>evgenys@amazon.com; igorch@amazon.com; chandu@amd.com; Igor
>Russkikh <irusskikh@marvell.com>; shepard.siegel@atomicrules.com;
>ed.czeck@atomicrules.com; john.miller@atomicrules.com;
>ajit.khaparde@broadcom.com; somnath.kotur@broadcom.com; Jerin Jacob
>Kollanukkaran <jerinj@marvell.com>; Maciej Czekaj [C]
><mczekaj@marvell.com>; Shijith Thotton <sthotton@marvell.com>;
>Srisivasubramanian Srinivasan <srinivasan@marvell.com>; Harman Kalra
><hkalra@marvell.com>; rahul.lakkireddy@chelsio.com; johndale@cisco.com;
>hyonkim@cisco.com; liudongdong3@huawei.com;
>yisen.zhuang@huawei.com; xuanziyang2@huawei.com;
>cloud.wangxiaoyun@huawei.com; zhouguoyang@huawei.com;
>simei.su@intel.com; wenjun1.wu@intel.com; qiming.yang@intel.com;
>Yuying.Zhang@intel.com; beilei.xing@intel.com; xiao.w.wang@intel.com;
>jingjing.wu@intel.com; junfeng.guo@intel.com; rosen.xu@intel.com; Nithin
>Kumar Dabilpuram <ndabilpuram@marvell.com>; Kiran Kumar Kokkilagadda
><kirankumark@marvell.com>; Sunil Kumar Kori <skori@marvell.com>; Satha
>Koteswara Rao Kottidi <skoteshwar@marvell.com>; Liron Himi
><lironh@marvell.com>; zr@semihalf.com; Radha Chintakuntla
><radhac@marvell.com>; Veerasenareddy Burru <vburru@marvell.com>;
>Sathesh B Edara <sedara@marvell.com>; matan@nvidia.com;
>viacheslavo@nvidia.com; longli@microsoft.com; spinler@cesnet.cz;
>chaoyong.he@corigine.com; niklas.soderlund@corigine.com;
>hemant.agrawal@nxp.com; sachin.saxena@oss.nxp.com; g.singh@nxp.com;
>apeksha.gupta@nxp.com; sachin.saxena@nxp.com; aboyer@pensando.io;
>Rasesh Mody <rmody@marvell.com>; Shahed Shaikh
><shshaikh@marvell.com>; Devendra Singh Rawat
><dsinghrawat@marvell.com>; andrew.rybchenko@oktetlabs.ru;
>jiawenwu@trustnetic.com; jianwang@trustnetic.com;
>jbehrens@vmware.com; maxime.coquelin@redhat.com;
>chenbo.xia@intel.com; steven.webster@windriver.com;
>matt.peters@windriver.com; bruce.richardson@intel.com;
>mtetsuyah@gmail.com; grive@u256.net; jasvinder.singh@intel.com;
>cristian.dumitrescu@intel.com; jgrajcia@cisco.com;
>mb@smartsharesystems.com
>Subject: Re: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
>
>On 1/25/2023 3:02 PM, Ankur Dwivedi wrote:
>>
>>>
>>> ---------------------------------------------------------------------
>>> - On 1/20/2023 8:40 AM, Ankur Dwivedi wrote:
>>>> Adds a trace point emit function for capturing a blob. The blob
>>>> captures the length passed by the application followed by the array.
>>>>
>>>> The maximum blob bytes which can be captured is bounded by
>>>> RTE_TRACE_BLOB_LEN_MAX macro. The value for max blob length macro
>is
>>>> 64 bytes. If the length is less than 64 the remaining trailing bytes
>>>> are set to zero.
>>>>
>>>> This patch also adds test case for emit blob tracepoint function.
>>>>
>>>> Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
>>>> ---
>>>> app/test/test_trace.c | 11 ++++++++
>>>> doc/guides/prog_guide/trace_lib.rst | 12 ++++++++
>>>> lib/eal/common/eal_common_trace_points.c | 2 ++
>>>> lib/eal/include/rte_eal_trace.h | 6 ++++
>>>> lib/eal/include/rte_trace_point.h | 32 ++++++++++++++++++++++
>>>> lib/eal/include/rte_trace_point_register.h | 9 ++++++
>>>> lib/eal/version.map | 3 ++
>>>> 7 files changed, 75 insertions(+)
>>>>
>>>> diff --git a/app/test/test_trace.c b/app/test/test_trace.c index
>>>> 6bedf14024..ad4a394a29 100644
>>>> --- a/app/test/test_trace.c
>>>> +++ b/app/test/test_trace.c
>>>> @@ -4,6 +4,7 @@
>>>>
>>>> #include <rte_eal_trace.h>
>>>> #include <rte_lcore.h>
>>>> +#include <rte_random.h>
>>>> #include <rte_trace.h>
>>>>
>>>> #include "test.h"
>>>> @@ -177,7 +178,12 @@ test_fp_trace_points(void) static int
>>>> test_generic_trace_points(void)
>>>> {
>>>> + uint8_t arr[RTE_TRACE_BLOB_LEN_MAX];
>>>> int tmp;
>>>> + int i;
>>>> +
>>>> + for (i = 0; i < RTE_TRACE_BLOB_LEN_MAX; i++)
>>>> + arr[i] = i;
>>>>
>>>> rte_eal_trace_generic_void();
>>>> rte_eal_trace_generic_u64(0x10000000000000);
>>>> @@ -195,6 +201,11 @@ test_generic_trace_points(void)
>>>> rte_eal_trace_generic_ptr(&tmp);
>>>> rte_eal_trace_generic_str("my string");
>>>> rte_eal_trace_generic_size_t(sizeof(void *));
>>>> + rte_eal_trace_generic_blob(arr, 0);
>>>> + rte_eal_trace_generic_blob(arr, 17);
>>>> + rte_eal_trace_generic_blob(arr, RTE_TRACE_BLOB_LEN_MAX);
>>>> + rte_eal_trace_generic_blob(arr, rte_rand() %
>>>> + RTE_TRACE_BLOB_LEN_MAX);
>>>> RTE_EAL_TRACE_GENERIC_FUNC;
>>>>
>>>> return TEST_SUCCESS;
>>>> diff --git a/doc/guides/prog_guide/trace_lib.rst
>>>> b/doc/guides/prog_guide/trace_lib.rst
>>>> index 9a8f38073d..3e0ea5835c 100644
>>>> --- a/doc/guides/prog_guide/trace_lib.rst
>>>> +++ b/doc/guides/prog_guide/trace_lib.rst
>>>> @@ -352,3 +352,15 @@ event ID.
>>>> The ``packet.header`` and ``packet.context`` will be written in the
>>>> slow path at the time of trace memory creation. The
>>>> ``trace.header`` and trace payload will be emitted when the tracepoint
>function is invoked.
>>>> +
>>>> +Limitations
>>>> +-----------
>>>> +
>>>> +- The ``rte_trace_point_emit_blob()`` function can capture a
>>>> +maximum blob of
>>>> + length ``RTE_TRACE_BLOB_LEN_MAX`` bytes. The application can call
>>>> + ``rte_trace_point_emit_blob()`` multiple times with length less
>>>> +than or equal to
>>>> + ``RTE_TRACE_BLOB_LEN_MAX``, if it needs to capture more than
>>>> +``RTE_TRACE_BLOB_LEN_MAX``
>>>> + bytes.
>>>> +- If the length passed to the ``rte_trace_point_emit_blob()`` is
>>>> +less than
>>>> + ``RTE_TRACE_BLOB_LEN_MAX``, then the trailing
>>>> +``(RTE_TRACE_BLOB_LEN_MAX - len)``
>>>> + bytes in the trace are set to zero.
>>>> diff --git a/lib/eal/common/eal_common_trace_points.c
>>>> b/lib/eal/common/eal_common_trace_points.c
>>>> index 0b0b254615..051f89809c 100644
>>>> --- a/lib/eal/common/eal_common_trace_points.c
>>>> +++ b/lib/eal/common/eal_common_trace_points.c
>>>> @@ -40,6 +40,8 @@
>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_size_t,
>>>> lib.eal.generic.size_t)
>>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_func,
>>>> lib.eal.generic.func)
>>>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_blob,
>>>> + lib.eal.generic.blob)
>>>>
>>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_set,
>>>> lib.eal.alarm.set)
>>>> diff --git a/lib/eal/include/rte_eal_trace.h
>>>> b/lib/eal/include/rte_eal_trace.h index 5ef4398230..e0b836eb2f
>>>> 100644
>>>> --- a/lib/eal/include/rte_eal_trace.h
>>>> +++ b/lib/eal/include/rte_eal_trace.h
>>>> @@ -143,6 +143,12 @@ RTE_TRACE_POINT(
>>>> rte_trace_point_emit_string(func);
>>>> )
>>>>
>>>> +RTE_TRACE_POINT(
>>>> + rte_eal_trace_generic_blob,
>>>> + RTE_TRACE_POINT_ARGS(void *in, uint8_t len),
>>>> + rte_trace_point_emit_blob(in, len);
>>>> +)
>>>> +
>>>> #define RTE_EAL_TRACE_GENERIC_FUNC
>>>> rte_eal_trace_generic_func(__func__)
>>>>
>>>> /* Interrupt */
>>>> diff --git a/lib/eal/include/rte_trace_point.h
>>>> b/lib/eal/include/rte_trace_point.h
>>>> index 0f8700974f..aca8344dbf 100644
>>>> --- a/lib/eal/include/rte_trace_point.h
>>>> +++ b/lib/eal/include/rte_trace_point.h
>>>> @@ -144,6 +144,16 @@ _tp _args \
>>>> #define rte_trace_point_emit_ptr(val)
>>>> /** Tracepoint function payload for string datatype */ #define
>>>> rte_trace_point_emit_string(val)
>>>> +/**
>>>> + * Tracepoint function to capture a blob.
>>>> + *
>>>> + * @param val
>>>> + * Pointer to the array to be captured.
>>>> + * @param len
>>>> + * Length to be captured. The maximum supported length is
>>>> + * RTE_TRACE_BLOB_LEN_MAX bytes.
>>>> + */
>>>> +#define rte_trace_point_emit_blob(val, len)
>>>>
>>>
>>> This is just for doxygen right, why doxygen comments are not above
>>> the actual macros but there is a separate #if block for it?
>>
>> The actual macro is within a #ifndef __DOXYGEN__ block. I think that
>> is the reason for including Doxygen comments here.
>
>Thanks for confirming.
>
>Why comments are not as part of actual macro, but there is a separate '#ifdef
>__DOXYGEN__' block?
The actual rte_trace_point_emit_blob macro containing the definition, is inside a #ifdef ALLOW_EXPERIMENTAL_API block, so the doxygen will not get generated for rte_trace_point_emit_blob unless ALLOW_EXPERIMENTAL_API is defined in doxygen config.
Putting the macro in #ifdef __DOXYGEN__ generates doxygen for the macro, even if ALLOW_EXPERIMENTAL_API is not defined.
>
>>>
>>>> #endif /* __DOXYGEN__ */
>>>>
>>>> @@ -152,6 +162,9 @@ _tp _args \
>>>> /** @internal Macro to define event header size. */ #define
>>>> __RTE_TRACE_EVENT_HEADER_SZ sizeof(uint64_t)
>>>>
>>>> +/** Macro to define maximum emit length of blob. */ #define
>>>> +RTE_TRACE_BLOB_LEN_MAX 64
>>>> +
>>>> /**
>>>> * Enable recording events of the given tracepoint in the trace buffer.
>>>> *
>>>> @@ -374,12 +387,31 @@ do { \
>>>> mem = RTE_PTR_ADD(mem, __RTE_TRACE_EMIT_STRING_LEN_MAX);
>>> \ } while
>>>> (0)
>>>>
>>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>>> + if (unlikely(in == NULL)) \
>>>> + return; \
>>>> + if (len > RTE_TRACE_BLOB_LEN_MAX) \
>>>> + len = RTE_TRACE_BLOB_LEN_MAX; \
>>>> + __rte_trace_point_emit(len, uint8_t); \
>>>> + memcpy(mem, in, len); \
>>>> + mem = RTE_PTR_ADD(mem, len); \
>>>> + memset(mem, 0, RTE_TRACE_BLOB_LEN_MAX - len); \
>>>> + mem = RTE_PTR_ADD(mem, RTE_TRACE_BLOB_LEN_MAX - len); \
>>>
>>>
>>> Is first memset later memcpy not done because of performance concerns?
>>
>> The memset sets to 0 the unused bytes (RTE_TRACE_BLOB_LEN_MAX - len).
>So memset is done after memcpy.
>
>yep, I can see what is done.
>
>Question is, you can do more simply:
>memset(mem, 0, RTE_TRACE_BLOB_LEN_MAX);
>memcpy(mem, in, len);
>mem = RTE_PTR_ADD(mem, RTE_TRACE_BLOB_LEN_MAX - len);
>
>Why did you prefer the implementation you did, intentionally? If so what is
>the intention, performance concerns?
Yes performance is a concern. If memset is done before memcpy, then,
64 <= number of bytes written <= 128, depending on length value from 0 to 64.
But in memset after memcpy, always 64 bytes will be written.
>
>btw, I want to remind that size of the 'len' can be max 64 bytes.
>
>>>
>>>> +} while (0)
>>>> +
>>>> #else
>>>>
>>>> #define __rte_trace_point_emit_header_generic(t) RTE_SET_USED(t)
>>>> #define __rte_trace_point_emit_header_fp(t) RTE_SET_USED(t) #define
>>>> __rte_trace_point_emit(in, type) RTE_SET_USED(in) #define
>>>> rte_trace_point_emit_string(in) RTE_SET_USED(in)
>>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>>> + RTE_SET_USED(in); \
>>>> + RTE_SET_USED(len); \
>>>> +} while (0)
>>>> +
>>>>
>>>> #endif /* ALLOW_EXPERIMENTAL_API */ #endif /*
>>>> _RTE_TRACE_POINT_REGISTER_H_ */ diff --git
>>>> a/lib/eal/include/rte_trace_point_register.h
>>>> b/lib/eal/include/rte_trace_point_register.h
>>>> index a32f4d731b..7efbac8a72 100644
>>>> --- a/lib/eal/include/rte_trace_point_register.h
>>>> +++ b/lib/eal/include/rte_trace_point_register.h
>>>> @@ -47,6 +47,15 @@ do { \
>>>> RTE_STR(in)"[32]", "string_bounded_t"); \ } while (0)
>>>>
>>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>>> + RTE_SET_USED(in); \
>>>> + __rte_trace_point_emit(len, uint8_t); \
>>>> + __rte_trace_point_emit_field(RTE_TRACE_BLOB_LEN_MAX, \
>>>> + RTE_STR(in)"["RTE_STR(RTE_TRACE_BLOB_LEN_MAX)"]", \
>>>> + RTE_STR(uint8_t)); \
>>>> +} while (0)
>>>> +
>>>
>>> Why this macro defined here again, it is also defined in 'rte_trace_point.h'
>>> already?
>>> Is it because of 'register_fn()' in '__rte_trace_point_register()'?
>>
>> Yes the register happens in this function.
>
>You are not really answering questions.
>
>There are three copy of '#define rte_trace_point_emit_blob(in, len)' one of
>them is for doxygen comment, please explain why there are two more copies
>of it?
>
The rte_trace_point_emit_blob is used when ALLOW_EXPERIMENTAL_API is defined. One definition is for that. The other is basically a null definition when ALLOW_EXPERIMENTAL_API is not defined.
>>>
>>>> #ifdef __cplusplus
>>>> }
>>>> #endif
>>>> diff --git a/lib/eal/version.map b/lib/eal/version.map index
>>>> 7ad12a7dc9..67be24686a 100644
>>>> --- a/lib/eal/version.map
>>>> +++ b/lib/eal/version.map
>>>> @@ -440,6 +440,9 @@ EXPERIMENTAL {
>>>> rte_thread_detach;
>>>> rte_thread_equal;
>>>> rte_thread_join;
>>>> +
>>>> + # added in 23.03
>>>> + __rte_eal_trace_generic_blob;
>>>
>>> This is not a function but a trace object.
>>> I guess it was agreed that trace object not need to be exported, and
>>> trace can be found by name?
>>
>> Yes the export in version.map can be removed. Will remove it in next patch
>series.
>
>ack.
>
>Will there be a separate patch to remove existing symbols? Although I am not
>sure if it will be ABI break.
I will send a separate patch to remove existing tracepoint symbols.
^ permalink raw reply [relevance 0%]
* Re: [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API
2023-01-16 12:06 0% ` lihuisong (C)
@ 2023-01-30 10:39 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2023-01-30 10:39 UTC (permalink / raw)
To: dev, Ferruh Yigit, Andrew Rybchenko
Cc: bruce.richardson, mb, huangdaode, liudongdong3, fengchengwen
Kindly ping.
在 2023/1/16 20:06, lihuisong (C) 写道:
> Hi Ferruh and Andrew,
>
> This patch series optimizes some codes and bug.
> Can you take a look at this patch series?
> If there are no other questions, can it be merged?
>
> Best,
> Huisong
>
> 在 2022/12/19 15:06, Huisong Li 写道:
>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>> rte_tel_data_add_dict/array_int API. This may cause data conversion
>> error or data truncation. This patch series uses 'u64' functions to
>> do this.
>>
>> In addition, this patch series introduces two APIs to store unsigned
>> integer values as hexadecimal encoded strings in telemetry library.
>>
>> ---
>> -v8: fix the coding style in patch 7/8
>> -v7: replace sprintf with snprintf in patch 6/8
>> -v6: fix code alignment to keep in line with codes in the file
>> -v5:
>> - drop a refactor patch.
>> - no limit the bit width for xxx_uint_hex API.
>> -v4:
>> - remove 'u32' value type.merg
>> - add padding zero for hexadecimal value
>> -v3: fix a misspelling mistake in commit log.
>> -v2:
>> - fix ABI break warning.
>> - introduce two APIs to store u32 and u64 values as hexadecimal
>> encoded strings.
>>
>> Huisong Li (8):
>> telemetry: move to header to controllable range
>> ethdev: fix possible data truncation and conversion error
>> mempool: fix possible data truncation and conversion error
>> cryptodev: fix possible data conversion error
>> mem: possible data truncation and conversion error
>> telemetry: support adding integer value as hexadecimal
>> test: add test cases for adding hex integer value API
>> ethdev: display capability values in hexadecimal format
>>
>> app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
>> lib/cryptodev/rte_cryptodev.c | 2 +-
>> lib/eal/common/eal_common_memory.c | 10 +-
>> lib/ethdev/rte_ethdev.c | 19 ++--
>> lib/mempool/rte_mempool.c | 24 ++---
>> lib/telemetry/rte_telemetry.h | 52 +++++++++-
>> lib/telemetry/telemetry_data.c | 73 ++++++++++++++
>> lib/telemetry/version.map | 9 ++
>> 8 files changed, 309 insertions(+), 30 deletions(-)
>>
>
> .
^ permalink raw reply [relevance 0%]
* RE: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-28 10:53 0% ` Jerin Jacob
2023-01-28 17:21 3% ` Stephen Hemminger
@ 2023-01-30 9:56 0% ` Naga Harish K, S V
2023-01-30 14:43 0% ` Jerin Jacob
1 sibling, 1 reply; 200+ results
From: Naga Harish K, S V @ 2023-01-30 9:56 UTC (permalink / raw)
To: Jerin Jacob
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Saturday, January 28, 2023 4:24 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
>
> > > > > >
> > > > > > > > + */
> > > > > > > > + uint32_t rsvd[15];
> > > > > > > > + /**< Reserved fields for future use */
> > > > > > >
> > > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> > > make
> > > > > > > sure rsvd is zero.
> > > > > > >
> > > > > >
> > > > > > The reserved fields are not used by the adapter or application.
> > > > > > Not sure Is it necessary to Introduce a new API to clear reserved
> fields.
> > > > >
> > > > > When adapter starts using new fileds(when we add new fieds in
> > > > > future), the old applicaiton which is not using
> > > > > rte_event_eth_rx_adapter_runtime_params_init() may have junk
> > > > > value and then adapter implementation will behave bad.
> > > > >
> > > > >
> > > >
> > > > does it mean, the application doesn't re-compile for the new DPDK?
> > >
> > > Yes. No need recompile if ABI not breaking.
> > >
> > > > When some of the reserved fields are used in the future, the
> > > > application
> > > also may need to be recompiled along with DPDK right?
> > > > As the application also may need to use the newly consumed
> > > > reserved
> > > fields?
> > >
> > > The problematic case is:
> > >
> > > Adapter implementation of 23.07(Assuming there is change params)
> > > field needs to work with application of 23.03.
> > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > >
> >
> > As rte_event_eth_rx_adapter_runtime_params_init() initializes only
> reserved fields to zero, it may not solve the issue in this case.
>
> rte_event_eth_rx_adapter_runtime_params_init() needs to zero all fields,
> not just reserved field.
> The application calling sequence is
>
> struct my_config c;
> rte_event_eth_rx_adapter_runtime_params_init(&c)
> c.interseted_filed_to_be_updated = val;
>
Can it be done like
struct my_config c = {0};
c.interseted_filed_to_be_updated = val;
and update Doxygen comments to recommend above usage to reset all fields?
This way, rte_event_eth_rx_adapter_runtime_params_init() can be avoided.
> Let me share an example and you can tell where is the issue
>
> 1)Assume parameter structure is 64B and for 22.03 8B are used.
> 2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
> 3)There is an application written based on 22.03 which using only 8B after
> calling rte_event_eth_rx_adapter_runtime_params_init()
> 4)Assume, in 22.07 another 8B added to structure.
> 5)Now, the application (3) needs to run on 22.07. Since the application is
> calling rte_event_eth_rx_adapter_runtime_params_init()
> and 9 to 15B are zero, the implementation will not go bad.
>
> > The old application only tries to set/get previous valid fields and the newly
> used fields may still contain junk value.
> > If the application wants to make use of any the newly used params, the
> application changes are required anyway.
>
> Yes. If application wants to make use of newly added features. No need to
> change if new features are not needed for old application.
^ permalink raw reply [relevance 0%]
* [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition
@ 2023-01-30 3:59 3% ` Rongwei Liu
0 siblings, 0 replies; 200+ results
From: Rongwei Liu @ 2023-01-30 3:59 UTC (permalink / raw)
To: matan, viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko, Olivier Matz
Cc: dev, rasland
Add IPv6 routing extension header definition and no
TLV support for now.
At rte_flow layer, there are new items defined for matching
type/nexthdr/segments_left field.
Add command line support for IPv6 routing extension header
matching: type/nexthdr/segment_list.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 9 +++++
doc/guides/rel_notes/release_23_03.rst | 9 +++++
lib/ethdev/rte_flow.c | 19 +++++++++++
lib/ethdev/rte_flow.h | 19 +++++++++++
lib/net/rte_ip.h | 21 ++++++++++++
6 files changed, 123 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88108498e0..7a8516829c 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -298,6 +298,10 @@ enum index {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_ICMP,
ITEM_ICMP_TYPE,
ITEM_ICMP_CODE,
@@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
ITEM_ARP_ETH_IPV4,
ITEM_IPV6_EXT,
ITEM_IPV6_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
ITEM_ICMP6,
ITEM_ICMP6_ND_NS,
ITEM_ICMP6_ND_NA,
@@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index item_ipv6_routing_ext[] = {
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_NEXT,
ZERO,
};
@@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
has_frag_ext, 1)),
},
+ [ITEM_IPV6_ROUTING_EXT] = {
+ .name = "ipv6_routing_ext",
+ .help = "match IPv6 routing extension header",
+ .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
+ sizeof(struct rte_flow_item_ipv6_routing_ext)),
+ .next = NEXT(item_ipv6_routing_ext),
+ .call = parse_vc,
+ },
+ [ITEM_IPV6_ROUTING_EXT_TYPE] = {
+ .name = "ext_type",
+ .help = "match IPv6 routing extension header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.type)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
+ .name = "ext_next_hdr",
+ .help = "match IPv6 routing extension header next header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.next_hdr)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
+ .name = "ext_seg_left",
+ .help = "match IPv6 routing extension header segment left",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.segments_left)),
+ },
[ITEM_ICMP] = {
.name = "icmp",
.help = "match ICMP header",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3e6242803d..602fab29d3 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
- ``color``: Metering color marker.
+Item: ``IPV6_ROUTING_EXT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches IPv6 routing extension header.
+
+- ``next_hdr``: Next layer header type.
+- ``type``: IPv6 routing extension header type.
+- ``segments_left``: How many IPv6 destination addresses carries on.
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index b8c5b68d6c..8f482301f7 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -55,6 +55,11 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added rte_flow support for matching IPv6 routing extension header fields.**
+
+ Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
+ header.
+
Removed Items
-------------
@@ -84,6 +89,10 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* net: added a new structure:
+
+ - IPv6 routing extension header ``rte_ipv6_routing_ext``.
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 7d0c24366c..5c423db160 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -76,6 +76,23 @@ rte_flow_item_flex_conv(void *buf, const void *data)
return src->length;
}
+static size_t
+rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)
+{
+ struct rte_flow_item_ipv6_routing_ext *dst = buf;
+ const struct rte_flow_item_ipv6_routing_ext *src = data;
+ size_t len;
+
+ if (src->hdr.hdr_len)
+ len = src->hdr.hdr_len << 3;
+ else
+ len = src->hdr.segments_left << 4;
+ if (dst == NULL)
+ return 0;
+ rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)), src->hdr.segments, len);
+ return len;
+}
+
/** Generate flow_item[] entry. */
#define MK_FLOW_ITEM(t, s) \
[RTE_FLOW_ITEM_TYPE_ ## t] = { \
@@ -157,6 +174,8 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
+ MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext),
+ rte_flow_item_ipv6_routing_ext_conv),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b60987db4b..9b9018cba2 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -624,6 +624,13 @@ enum rte_flow_item_type {
* See struct rte_flow_item_meter_color.
*/
RTE_FLOW_ITEM_TYPE_METER_COLOR,
+
+ /**
+ * Matches the presence of IPv6 routing extension header.
+ *
+ * @see struct rte_flow_item_ipv6_routing_ext.
+ */
+ RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
};
/**
@@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
uint32_t reserved:23;
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
+ *
+ * Matches an IPv6 routing extension header.
+ */
+struct rte_flow_item_ipv6_routing_ext {
+ struct rte_ipv6_routing_ext hdr;
+};
+
/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
#ifndef __cplusplus
static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index 9c8e8206f0..56c151372a 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -539,6 +539,27 @@ struct rte_ipv6_hdr {
uint8_t dst_addr[16]; /**< IP address of destination host(s). */
} __rte_packed;
+/**
+ * IPv6 Routing Extension Header
+ */
+struct rte_ipv6_routing_ext {
+ uint8_t next_hdr; /**< Protocol, next header. */
+ uint8_t hdr_len; /**< Header length. */
+ uint8_t type; /**< Extension header type. */
+ uint8_t segments_left; /**< Valid segments number. */
+ __extension__
+ union {
+ rte_be32_t flags;
+ struct {
+ uint8_t last_entry; /**< The last_entry field of SRH */
+ uint8_t flag; /**< Packet flag. */
+ rte_be16_t tag; /**< Packet tag. */
+ };
+ };
+ __extension__
+ rte_be32_t segments[0]; /**< Each hop IPv6 address. */
+} __rte_packed;
+
/* IPv6 vtc_flow: IPv / TC / flow_label */
#define RTE_IPV6_HDR_FL_SHIFT 0
#define RTE_IPV6_HDR_TC_SHIFT 20
--
2.27.0
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition
2023-01-20 9:20 0% ` Andrew Rybchenko
@ 2023-01-30 3:46 0% ` Rongwei Liu
1 sibling, 0 replies; 200+ results
From: Rongwei Liu @ 2023-01-30 3:46 UTC (permalink / raw)
To: Andrew Rybchenko, Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Aman Singh, Yuying Zhang, Ferruh Yigit, Olivier Matz
Cc: dev, Raslan Darawsheh
HI Andrew
BR
Rongwei
> -----Original Message-----
> From: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>
> Sent: Friday, January 20, 2023 17:21
> To: Rongwei Liu <rongweil@nvidia.com>; Matan Azrad <matan@nvidia.com>;
> Slava Ovsiienko <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Aman
> Singh <aman.deep.singh@intel.com>; Yuying Zhang
> <yuying.zhang@intel.com>; Ferruh Yigit <ferruh.yigit@amd.com>; Olivier
> Matz <olivier.matz@6wind.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> Subject: Re: [PATCH v2 1/8] ethdev: add IPv6 routing extension header
> definition
>
> External email: Use caution opening links or attachments
>
>
> On 1/19/23 06:11, Rongwei Liu wrote:
> > Add IPv6 routing extension header definition and no TLV support for
> > now.
> >
> > At rte_flow layer, there are new items defined for matching
> > type/nexthdr/segments_left field.
> >
> > Add command line support for IPv6 routing extension header
> > matching: type/nexthdr/segment_list.
> >
> > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> > Acked-by: Ori Kam <orika@nvidia.com>
>
> [snip]
>
> > diff --git a/doc/guides/prog_guide/rte_flow.rst
> > b/doc/guides/prog_guide/rte_flow.rst
> > index 3e6242803d..ae99036be0 100644
> > --- a/doc/guides/prog_guide/rte_flow.rst
> > +++ b/doc/guides/prog_guide/rte_flow.rst
> > @@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
> >
> > - ``color``: Metering color marker.
> >
> > +Item: ``IPV6_ROUTING_EXT``
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Matches ipv6 routing extension header.
>
> ipv6 -> IPv6
Sure.
>
> > +
> > +- ``next_hdr``: Next layer header type.
> > +- ``type``: IPv6 routing extension header type.
> > +- ``segments_left``: How many IPv6 destination addresses carries on
>
> Why are only 3 fields mentioned above?
>
This is the 1st phase to matching the 1st uint32 of IPv6 routing extension.
No need to match hdr_len since TLV is ignored.
> > +
> > Actions
> > ~~~~~~~
> >
> > diff --git a/doc/guides/rel_notes/release_23_03.rst
> > b/doc/guides/rel_notes/release_23_03.rst
> > index b8c5b68d6c..2a794d598e 100644
> > --- a/doc/guides/rel_notes/release_23_03.rst
> > +++ b/doc/guides/rel_notes/release_23_03.rst
> > @@ -55,6 +55,11 @@ New Features
> > Also, make sure to start the actual text at the margin.
> > =======================================================
> >
> > +* **Added rte_flow support for matching IPv6 routing extension header
> > +fields.**
> > +
> > + Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing
> > + extension header
>
> Missing full stop above.
>
Sure
> > +
> >
> > Removed Items
> > -------------
> > @@ -84,6 +89,11 @@ API Changes
> > Also, make sure to start the actual text at the margin.
> > =======================================================
> >
> > +* ethdev: added a new structure:
> > +
> > + - IPv6 routing extension header ``rte_flow_item_ipv6_routing_ext`` and
> > + ``rte_ipv6_routing_ext``
> > +
>
> If I'm not mistaken, additions should not be here. It is not an API change.
>
Checked existing release doc, "ihl" and "version" of IPv4 header is added here but with "net:" prefix.
Do you think it' good to follow?
> >
> > ABI Changes
> > -----------
> > diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c index
> > 7d0c24366c..4074b475c8 100644
> > --- a/lib/ethdev/rte_flow.c
> > +++ b/lib/ethdev/rte_flow.c
> > @@ -76,6 +76,20 @@ rte_flow_item_flex_conv(void *buf, const void *data)
> > return src->length;
> > }
> >
> > +static size_t
> > +rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data) {
> > + struct rte_flow_item_ipv6_routing_ext *dst = buf;
> > + const struct rte_flow_item_ipv6_routing_ext *src = data;
> > + size_t len;
> > +
> > + len = src->hdr.hdr_len ? src->hdr.hdr_len << 3 :
> > + src->hdr.segments_left << 4;
>
> Compare hdr_len vs 0 explicitly.
> Also I'd add parenthesis around ternary operator values to make it simpler to
> understand.
Sure.
>
> > + if (buf)
>
> Please, compare vs NULL explicitly. May be 'dst' would be better here?
>
> > + rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)),
> > + src->hdr.segments, len);
> > + return len;
> > +}
> > +
Sure.
> > /** Generate flow_item[] entry. */
> > #define MK_FLOW_ITEM(t, s) \
> > [RTE_FLOW_ITEM_TYPE_ ## t] = { \ @@ -157,6 +171,8 @@ static
> > const struct rte_flow_desc_data rte_flow_desc_item[] = {
> > MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
> > MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
> > MK_FLOW_ITEM(METER_COLOR, sizeof(struct
> > rte_flow_item_meter_color)),
> > + MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct
> rte_flow_item_ipv6_routing_ext),
> > + rte_flow_item_ipv6_routing_ext_conv),
> > };
> >
> > /** Generate flow_action[] entry. */ diff --git
> > a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index
> > b60987db4b..0120d3e7d2 100644
> > --- a/lib/ethdev/rte_flow.h
> > +++ b/lib/ethdev/rte_flow.h
> > @@ -624,6 +624,13 @@ enum rte_flow_item_type {
> > * See struct rte_flow_item_meter_color.
> > */
> > RTE_FLOW_ITEM_TYPE_METER_COLOR,
> > +
> > + /**
> > + * Matches the presence of IPv6 routing extension header.
> > + *
> > + * See struct rte_flow_item_ipv6_routing_ext.
>
> @see
>
Sure. Looks like there are so many existing wrong usages "See struct" in this file.
> > + */
> > + RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
> > };
> >
> > /**
> > @@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
> > uint32_t reserved:23;
> > };
> >
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this structure may change without prior notice
> > + *
> > + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
> > + *
> > + * Matches an IPv6 routing extension header.
> > + */
> > +struct rte_flow_item_ipv6_routing_ext {
> > + struct rte_ipv6_routing_ext hdr; };
> > +
>
> What about default mask?
Tried to add default mask declaration in this file but got "unused variable" warning.
Moved it to "cmdline_flow.c" since it' only used in testpmd encap logic.
>
> > /** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
> > #ifndef __cplusplus
> > static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
> > diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h index
> > 9c8e8206f0..158a2f83ce 100644
> > --- a/lib/net/rte_ip.h
> > +++ b/lib/net/rte_ip.h
> > @@ -539,6 +539,27 @@ struct rte_ipv6_hdr {
> > uint8_t dst_addr[16]; /**< IP address of destination host(s). */
> > } __rte_packed;
> >
> > +/**
> > + * IPv6 Routing Extension Header
> > + */
> > +struct rte_ipv6_routing_ext {
> > + uint8_t next_hdr; /**< Protocol, next header. */
> > + uint8_t hdr_len; /**< Header length. */
> > + uint8_t type; /**< Extension header type. */
> > + uint8_t segments_left; /**< Valid segments number. */
> > + __extension__
> > + union {
> > + uint32_t flags;
>
> rte_be32_t ?
Sure.
>
> > + struct {
> > + uint8_t last_entry; /**< The last_entry field of SRH */
> > + uint8_t flag; /**< Packet flag. */
> > + uint16_t tag; /**< Packet tag. */
>
> rte_be16_t
Sure.
>
> > + };
> > + };
> > + __extension__
> > + uint32_t segments[0]; /**< Each hop IPv6 address. */
>
> rte_be32_t
Sure.
>
> > +} __rte_packed;
> > +
> > /* IPv6 vtc_flow: IPv / TC / flow_label */
> > #define RTE_IPV6_HDR_FL_SHIFT 0
> > #define RTE_IPV6_HDR_TC_SHIFT 20
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-28 10:53 0% ` Jerin Jacob
@ 2023-01-28 17:21 3% ` Stephen Hemminger
2023-01-30 9:56 0% ` Naga Harish K, S V
1 sibling, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-01-28 17:21 UTC (permalink / raw)
To: Jerin Jacob
Cc: Naga Harish K, S V, jerinj, Carrillo, Erik G, Gujjar,
Abhinandan S, dev, Jayatheerthan, Jay
On Sat, 28 Jan 2023 16:23:45 +0530
Jerin Jacob <jerinjacobk@gmail.com> wrote:
> > >
> > > Yes. No need recompile if ABI not breaking.
> > >
> > > > When some of the reserved fields are used in the future, the application
> > > also may need to be recompiled along with DPDK right?
> > > > As the application also may need to use the newly consumed reserved
> > > fields?
> > >
> > > The problematic case is:
> > >
> > > Adapter implementation of 23.07(Assuming there is change params) field
> > > needs to work with application of 23.03.
> > > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> > >
> >
First off, reserved fields are a problematic design choice IMHO (see YAGNI).
Second. any reserved fields can not be used in future unless the
original code enforced that all reserved fields are zero.
Same is true for holes in structs which some times get reused.
You can't use a reserved field without breaking ABI unless the previous
code enforced that the field must be zero.
^ permalink raw reply [relevance 3%]
* [PATCH 2/2] ethdev: introduce the mhpsdp hwport field in Tx queue API
@ 2023-01-28 13:08 2% ` Jiawei Wang
0 siblings, 0 replies; 200+ results
From: Jiawei Wang @ 2023-01-28 13:08 UTC (permalink / raw)
To: viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko
Cc: dev, rasland
For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the
hardware port of the received packets.
This patch adds the tx_mhpsdp_hwport setting in Tx queue API, the hwport
value reflects packets be sent to which hardware port.
0 is no port assigned and traffic will be routed between different hardware
ports, if 0 is disabled then try to match on MHPSDP_HW_PORT with 0 will
result in an error.
Adds the new tx_mhpsdp_hwport field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.
This patch adds the testpmd command line:
testpmd> port config (port_id) txq (queue_id) mhpsdp_hwport (value)
For example, there're two hardware ports 0 and 1 connected to
a single DPDK port (port id 0), and mhpsdp_hwport 1 stood for
hardware port 0 and mhpsdp_hwport 2 stood for hardware port 1,
used the below command to config tx mhpsdp_hwport for per Tx Queue:
port config 0 txq 0 mhpsdp_hwport 1
port config 0 txq 1 mhpsdp_hwport 1
port config 0 txq 2 mhpsdp_hwport 2
port config 0 txq 3 mhpsdp_hwport 2
These commands config the TxQ index 0 and TxQ index 1 with mhpsdp_hwport 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 0, and similar with hardware port 1 if sending packets
with TxQ 2 or TxQ 3.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
---
app/test-pmd/cmdline.c | 84 +++++++++++++++++++++
devtools/libabigail.abignore | 5 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 ++++
lib/ethdev/rte_ethdev.h | 8 ++
4 files changed, 110 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd4..db9ea8b18a 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -764,6 +764,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
" Cleanup txq mbufs for a specific Tx queue\n\n"
+
+ "port config (port_id) txq (queue_id) mhpsdp_hwport (value)\n"
+ " Set the hwport value in mhpsdp "
+ "on a specific Tx queue\n\n"
);
}
@@ -12621,6 +12625,85 @@ static cmdline_parse_inst_t cmd_show_port_flow_transfer_proxy = {
}
};
+/* *** configure port txq mhpsdp_hwport value *** */
+struct cmd_config_tx_mhpsdp_hwport {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t config;
+ portid_t portid;
+ cmdline_fixed_string_t txq;
+ uint16_t qid;
+ cmdline_fixed_string_t mhpsdp_hwport;
+ uint16_t value;
+};
+
+static void
+cmd_config_tx_mhpsdp_hwport_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_config_tx_mhpsdp_hwport *res = parsed_result;
+ struct rte_port *port;
+
+ if (port_id_is_invalid(res->portid, ENABLED_WARN))
+ return;
+
+ if (res->portid == (portid_t)RTE_PORT_ALL) {
+ printf("Invalid port id\n");
+ return;
+ }
+
+ port = &ports[res->portid];
+
+ if (strcmp(res->txq, "txq")) {
+ printf("Unknown parameter\n");
+ return;
+ }
+ if (tx_queue_id_is_invalid(res->qid))
+ return;
+
+ port->txq[res->qid].conf.tx_mhpsdp_hwport = res->value;
+
+ cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_mhpsdp_hwport_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ port, "port");
+cmdline_parse_token_string_t cmd_config_tx_mhpsdp_hwport_config =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ config, "config");
+cmdline_parse_token_num_t cmd_config_tx_mhpsdp_hwport_portid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_mhpsdp_hwport_txq =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_mhpsdp_hwport_qid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_mhpsdp_hwport_hwport =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ mhpsdp_hwport, "mhpsdp_hwport");
+cmdline_parse_token_num_t cmd_config_tx_mhpsdp_hwport_value =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_mhpsdp_hwport,
+ value, RTE_UINT16);
+
+static cmdline_parse_inst_t cmd_config_tx_mhpsdp_hwport = {
+ .f = cmd_config_tx_mhpsdp_hwport_parsed,
+ .data = (void *)0,
+ .help_str = "port config <port_id> txq <queue_id> mhpsdp_hwport <value>",
+ .tokens = {
+ (void *)&cmd_config_tx_mhpsdp_hwport_port,
+ (void *)&cmd_config_tx_mhpsdp_hwport_config,
+ (void *)&cmd_config_tx_mhpsdp_hwport_portid,
+ (void *)&cmd_config_tx_mhpsdp_hwport_txq,
+ (void *)&cmd_config_tx_mhpsdp_hwport_qid,
+ (void *)&cmd_config_tx_mhpsdp_hwport_hwport,
+ (void *)&cmd_config_tx_mhpsdp_hwport_value,
+ NULL,
+ },
+};
+
/* ******************************************************************************** */
/* list of instructions */
@@ -12851,6 +12934,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_show_capability,
(cmdline_parse_inst_t *)&cmd_set_flex_is_pattern,
(cmdline_parse_inst_t *)&cmd_set_flex_spec_pattern,
+ (cmdline_parse_inst_t *)&cmd_config_tx_mhpsdp_hwport,
NULL,
};
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..cbbde4ef05 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -20,6 +20,11 @@
[suppress_file]
soname_regexp = ^librte_.*mlx.*glue\.
+; Ignore fields inserted in middle padding of rte_eth_txconf
+[suppress_type]
+ name = rte_eth_txconf
+ has_data_member_inserted_between = {offset_after(tx_deferred_start), offset_of(offloads)}
+
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Experimental APIs exceptions ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 7be7c55d63..a05fd0e7d0 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1605,6 +1605,19 @@ Enable or disable a per queue Tx offloading only on a specific Tx queue::
This command should be run when the port is stopped, or else it will fail.
+config per queue Tx mhpsdp_hwport
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Configure a mhpsdp_hwport value per queue Tx offloading only on a specific Tx queue::
+
+ testpmd> port (port_id) txq (queue_id) mhpsdp_hwport (value)
+
+* ``mhpsdp_hwport``: reflects packet can be sent to which hardware port.
+ uses it on multiple hardware ports connect to
+ a single DPDK port (mhpsdp).
+
+This command should be run when the port is stopped, or else it will fail.
+
Config VXLAN Encap outer layers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index c129ca1eaf..c1cef9e21d 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1138,6 +1138,14 @@ struct rte_eth_txconf {
less free descriptors than this value. */
uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
+ /**
+ * Hardware port index for mhpsdp.
+ * Value 0 is no port assigned and traffic could be routed between different
+ * hardware ports, if 0 is disabled then try to match on MHPSDP_HW_PORT with
+ * 0 will result in an error.
+ * Value starts from 1 means that the first hw port in the mhpsdp.
+ */
+ uint8_t tx_mhpsdp_hwport;
/**
* Per-queue Tx offloads to be set using RTE_ETH_TX_OFFLOAD_* flags.
* Only offloads set on tx_queue_offload_capa or tx_offload_capa
--
2.18.1
^ permalink raw reply [relevance 2%]
* Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-25 16:32 0% ` Naga Harish K, S V
@ 2023-01-28 10:53 0% ` Jerin Jacob
2023-01-28 17:21 3% ` Stephen Hemminger
2023-01-30 9:56 0% ` Naga Harish K, S V
0 siblings, 2 replies; 200+ results
From: Jerin Jacob @ 2023-01-28 10:53 UTC (permalink / raw)
To: Naga Harish K, S V
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Wed, Jan 25, 2023 at 10:02 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > >
> > > > > > > + */
> > > > > > > + uint32_t rsvd[15];
> > > > > > > + /**< Reserved fields for future use */
> > > > > >
> > > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> > make
> > > > > > sure rsvd is zero.
> > > > > >
> > > > >
> > > > > The reserved fields are not used by the adapter or application.
> > > > > Not sure Is it necessary to Introduce a new API to clear reserved fields.
> > > >
> > > > When adapter starts using new fileds(when we add new fieds in
> > > > future), the old applicaiton which is not using
> > > > rte_event_eth_rx_adapter_runtime_params_init() may have junk value
> > > > and then adapter implementation will behave bad.
> > > >
> > > >
> > >
> > > does it mean, the application doesn't re-compile for the new DPDK?
> >
> > Yes. No need recompile if ABI not breaking.
> >
> > > When some of the reserved fields are used in the future, the application
> > also may need to be recompiled along with DPDK right?
> > > As the application also may need to use the newly consumed reserved
> > fields?
> >
> > The problematic case is:
> >
> > Adapter implementation of 23.07(Assuming there is change params) field
> > needs to work with application of 23.03.
> > rte_event_eth_rx_adapter_runtime_params_init() will sove that.
> >
>
> As rte_event_eth_rx_adapter_runtime_params_init() initializes only reserved fields to zero, it may not solve the issue in this case.
rte_event_eth_rx_adapter_runtime_params_init() needs to zero all
fields, not just reserved field.
The application calling sequence is
struct my_config c;
rte_event_eth_rx_adapter_runtime_params_init(&c)
c.interseted_filed_to_be_updated = val;
Let me share an example and you can tell where is the issue
1)Assume parameter structure is 64B and for 22.03 8B are used.
2)rte_event_eth_rx_adapter_runtime_params_init() will clear all 64B.
3)There is an application written based on 22.03 which using only 8B
after calling rte_event_eth_rx_adapter_runtime_params_init()
4)Assume, in 22.07 another 8B added to structure.
5)Now, the application (3) needs to run on 22.07. Since the
application is calling rte_event_eth_rx_adapter_runtime_params_init()
and 9 to 15B are zero, the implementation will not go bad.
> The old application only tries to set/get previous valid fields and the newly used fields may still contain junk value.
> If the application wants to make use of any the newly used params, the application changes are required anyway.
Yes. If application wants to make use of newly added features. No need
to change if new features are not needed for old application.
^ permalink raw reply [relevance 0%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-19 14:35 0% ` Thomas Monjalon
@ 2023-01-28 1:39 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2023-01-28 1:39 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit
Cc: dev, andrew.rybchenko, liudongdong3, huangdaode, fengchengwen
在 2023/1/19 22:35, Thomas Monjalon 写道:
> 19/01/2023 11:31, lihuisong (C):
>> 在 2023/1/18 22:12, Thomas Monjalon 写道:
>>> 11/01/2023 11:46, Ferruh Yigit:
>>>> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
>>>>> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>>>>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>>>>>> Hi Huisong,
>>>>>>>
>>>>>>> I haven't checked the patch in detail yet, but I can see it gives some
>>>>>>> ABI compatibility warnings, is this expected:
>>>>>> This is to be expected. Because we insert a device state,
>>>>>> RTE_ETH_DEV_ALLOCATED,
>>>>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>>>>>> We may have to announce it. What do you think?
>>>>> If there is an actual ABI break, it can't go in this release, need to
>>>>> wait LTS release and yes needs deprecation notice in advance.
>>>>>
>>>>> But not all enum value change warnings are real break, need to
>>>>> investigate all warnings one by one.
>>>>> Need to investigate if old application & new dpdk library may cause any
>>>>> unexpected behavior for application.
>>>>>
>>>> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
>>>> enum solves the issue, although logically it won't look nice.
>>>> Perhaps order can be fixed in next LTS, to have more logical order, but
>>>> not quite sure if order worth the disturbance may cause in application.
>>> It is a state with a logical order, so it would be nice to be able to do
>>> if (state > RTE_ETH_DEV_ALLOCATED)
>>> but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful.
>> The device state is internel. Applications should not access it
>> directly, right?
> Right
>
>> Currently, ethdev layer or PMD use it by enum value instead of the way like
>> 'state > RTE_ETH_DEV_ALLOCATED'.
> Right
>
>> But, I encapsulated an API, rte_eth_dev_is_used(), for ethdev or PMD to
>> call.
>> I'm not sure if it can help to eliminate our concerns.
> Yes I think it's OK.
ok, I will fix it based on our discussion.
>
>
> .
^ permalink raw reply [relevance 0%]
* Re: deprecation notice process / clarification
2023-01-25 22:36 3% deprecation notice process / clarification Tyler Retzlaff
@ 2023-01-27 12:47 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-27 12:47 UTC (permalink / raw)
To: Tyler Retzlaff; +Cc: dev
25/01/2023 23:36, Tyler Retzlaff:
> hi,
>
> i'm looking for some guidance when cleaning up / removing the remaining
> shim functions for pthread in windows and i'm not sure how our
> deprecation notice / policies apply.
>
> windows has been providing lib/eal/windows/include/pthread.h shim that
> allowed applications to use e.g. pthread_xxx functions on windows.
>
> these shim functions were all being provided as inline functions and
> were not part of the EAL api but on windows they were implicitly part of
> the api surface exposed (to windows only). on posix platforms applications
> did not rely on EAL for pthread abi or api (obviously).
>
> recently we introduced a set of platform agnostic thread api in the EAL.
> the functions were marked __rte_experimental as a part of new API
> addition policy.
>
> what's the most appropriate way to remove the pthread_xxx shim inline
> functions from lib/eal/windows/include/pthread.h? do we have to wait the
> full deprecation notice period which can't be started until we make the
> new functions stable? also keeping in mind we can't actually mark inline
> functions __rte_deprecated.
>
> is this a special case where we can just rip them out and break
> compilation?
Probably yes.
> input is appreciated, particularly from any consumers of the windows
> port who might be unhappy.
I think there is not too much users of Windows DPDK yet.
I would be in favor of just removing the pthread shim layer
for Windows when rte_thread equivalent is declared stable.
^ permalink raw reply [relevance 0%]
* deprecation notice process / clarification
@ 2023-01-25 22:36 3% Tyler Retzlaff
2023-01-27 12:47 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2023-01-25 22:36 UTC (permalink / raw)
To: dev
hi,
i'm looking for some guidance when cleaning up / removing the remaining
shim functions for pthread in windows and i'm not sure how our
deprecation notice / policies apply.
windows has been providing lib/eal/windows/include/pthread.h shim that
allowed applications to use e.g. pthread_xxx functions on windows.
these shim functions were all being provided as inline functions and
were not part of the EAL api but on windows they were implicitly part of
the api surface exposed (to windows only). on posix platforms applications
did not rely on EAL for pthread abi or api (obviously).
recently we introduced a set of platform agnostic thread api in the EAL.
the functions were marked __rte_experimental as a part of new API
addition policy.
what's the most appropriate way to remove the pthread_xxx shim inline
functions from lib/eal/windows/include/pthread.h? do we have to wait the
full deprecation notice period which can't be started until we make the
new functions stable? also keeping in mind we can't actually mark inline
functions __rte_deprecated.
is this a special case where we can just rip them out and break
compilation?
input is appreciated, particularly from any consumers of the windows
port who might be unhappy.
thanks
^ permalink raw reply [relevance 3%]
* RE: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-25 10:38 3% ` Jerin Jacob
@ 2023-01-25 16:32 0% ` Naga Harish K, S V
2023-01-28 10:53 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Naga Harish K, S V @ 2023-01-25 16:32 UTC (permalink / raw)
To: Jerin Jacob
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, January 25, 2023 4:08 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Wed, Jan 25, 2023 at 3:22 PM Naga Harish K, S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> > Hi Jerin,
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, January 25, 2023 9:42 AM
> > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > Cc: jerinj@marvell.com; Carrillo, Erik G
> > > <erik.g.carrillo@intel.com>; Gujjar, Abhinandan S
> > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > <jay.jayatheerthan@intel.com>
> > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> > >
> > > On Tue, Jan 24, 2023 at 6:37 PM Naga Harish K, S V
> > > <s.v.naga.harish.k@intel.com> wrote:
> > > >
> > > > Hi Jerin,
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Tuesday, January 24, 2023 10:00 AM
> > > > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > > > Cc: jerinj@marvell.com; Carrillo, Erik G
> > > > > <erik.g.carrillo@intel.com>; Gujjar, Abhinandan S
> > > > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > > > <jay.jayatheerthan@intel.com>
> > > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get
> > > > > APIs
> > > > >
> > > > > On Mon, Jan 23, 2023 at 11:35 PM Naga Harish K S V
> > > > > <s.v.naga.harish.k@intel.com> wrote:
> > > > > >
> > > > > > The adapter configuration parameters defined in the ``struct
> > > > > > rte_event_eth_rx_adapter_runtime_params`` can be configured
> > > > > > and retrieved using
> > > > > > ``rte_event_eth_rx_adapter_runtime_params_set``
> > > > > > and ``rte_event_eth_tx_adapter_runtime_params_get``
> respectively.
> > > > > >
> > > > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > > >
> > > > > > diff --git
> > > > > > a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > > b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > > index 461eca566f..2207d6ffc3 100644
> > > > > > --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > > +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > > @@ -185,6 +185,26 @@ flags for handling received packets,
> > > > > > event queue identifier, scheduler type, event priority,
> > > > > > polling frequency of the receive queue and flow identifier in
> > > > > > struct
> > > > > ``rte_event_eth_rx_adapter_queue_conf``.
> > > > > >
> > > > > > +Set/Get adapter runtime configuration parameters
> > > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > +
> > > > > > +The runtime configuration parameters of adapter can be
> > > > > > +set/read using
> > > > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` and
> ``rte_event_eth_rx_adapter_runtime_params_get()`` respectively.
> > > > > > +The parameters that can be set/read are defined in ``struct
> > > > > rte_event_eth_rx_adapter_runtime_params``.
> > > > >
> > > > > Good.
> > > > >
> > > > > > +
> > > > > > +``rte_event_eth_rx_adapter_create()`` or
> > > > > > +``rte_event_eth_rx_adapter_create_with_params()`` configures
> > > > > > +the adapter with default value for maximum packets processed
> > > > > > +per request to
> > > > > 128.
> > > > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` function
> > > > > > +allows to reconfigure maximum number of packets processed by
> > > > > > +adapter per service request. This is alternative to
> > > > > > +configuring the maximum packets processed per request by
> > > > > > +adapter by using ``rte_event_eth_rx_adapter_create_ext()``
> > > > > > +with parameter
> > > > > ``rte_event_eth_rx_adapter_conf::max_nb_rx``.
> > > > >
> > > > > This paragraph is not needed IMO. As it is specific to a driver,
> > > > > and we can keep Doxygen comment only.
> > > > >
> > > > >
> > > > > > +
> > > > > > +``rte_event_eth_rx_adapter_runtime_parmas_get()`` function
> > > > > > +retrieves the configuration parameters that are defined in
> > > > > > +``struct
> > > > > rte_event_eth_rx_adapter_runtime_params``.
> > > > >
> > > > > Good.
> > > > >
> > > > > > +
> > > > > > Getting and resetting Adapter queue stats
> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > >
> > > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > > b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > > index 34aa87379e..d8f3e750b7 100644
> > > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > > @@ -35,6 +35,8 @@
> > > > > > #define MAX_VECTOR_NS 1E9
> > > > > > #define MIN_VECTOR_NS 1E5
> > > > > >
> > > > > > +#define RXA_NB_RX_WORK_DEFAULT 128
> > > > > > +
> > > > > > #define ETH_RX_ADAPTER_SERVICE_NAME_LEN 32
> > > > > > #define ETH_RX_ADAPTER_MEM_NAME_LEN 32
> > > > > >
> > > > > > @@ -1554,7 +1556,7 @@ rxa_default_conf_cb(uint8_t id, uint8_t
> > > dev_id,
> > > > > > }
> > > > > >
> > > > > > conf->event_port_id = port_id;
> > > > > > - conf->max_nb_rx = 128;
> > > > > > + conf->max_nb_rx = RXA_NB_RX_WORK_DEFAULT;
> > > > > > if (started)
> > > > > > ret = rte_event_dev_start(dev_id);
> > > > > > rx_adapter->default_cb_arg = 1; @@ -3436,6 +3438,90 @@
> > > > > > rte_event_eth_rx_adapter_instance_get(uint16_t eth_dev_id,
> > > > > > return -EINVAL;
> > > > > > }
> > > > >
> > > > > > +
> > > > > > +int
> > > > > > +rte_event_eth_rx_adapter_runtime_params_set(uint8_t id,
> > > > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > > > +*params) {
> > > > > > + struct event_eth_rx_adapter *rxa;
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (params == NULL)
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + if (rxa_memzone_lookup())
> > > > > > + return -ENOMEM;
> > > > >
> > > > > Introduce an adapter callback and move SW adapter related logic
> > > > > under callback handler.
> > > > >
> > > > >
> > > > Do you mean introducing eventdev PMD callback for HW
> implementation?
> > >
> > > Yes.
> > >
> >
> > Can this be taken care as and when the HW implementation is required?
>
> OK. As long as when case INTERNAL PORT it return -ENOSUP now.
>
> >
> > > > There are no adapter callback currently for service based SW
> > > Implementation.
> > > >
> > > > > > +
> > > > > > + rxa = rxa_id_to_adapter(id);
> > > > > > + if (rxa == NULL)
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + ret = rxa_caps_check(rxa);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > +
> > > > > > + rte_spinlock_lock(&rxa->rx_lock);
> > > > > > + rxa->max_nb_rx = params->max_nb_rx;
> > > > > > + rte_spinlock_unlock(&rxa->rx_lock);
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +int
> > > > > > +rte_event_eth_rx_adapter_runtime_params_get(uint8_t id,
> > > > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > > > +*params) {
> > > > > > + struct event_eth_rx_adapter *rxa;
> > > > > > + int ret;
> > > > > > +
> > > > > > + if (params == NULL)
> > > > > > + return -EINVAL;
> > > > >
> > > > >
> > > > > Introduce an adapter callback and move SW adapter related logic
> > > > > under callback handler.
> > > > >
> > > > >
> > > >
> > > > Same as above
> > > >
> > > > > > +
> > > > > > + if (rxa_memzone_lookup())
> > > > > > + return -ENOMEM;
> > > > > +
> > > > > > + rxa = rxa_id_to_adapter(id);
> > > > > > + if (rxa == NULL)
> > > > > > + return -EINVAL;
> > > > > > +
> > > > > > + ret = rxa_caps_check(rxa);
> > > > > > + if (ret)
> > > > > > + return ret;
> > > > > > +
> > > > > > + params->max_nb_rx = rxa->max_nb_rx;
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +/* RX-adapter telemetry callbacks */
> > > > > > #define RXA_ADD_DICT(stats, s) rte_tel_data_add_dict_u64(d,
> > > > > > #s,
> > > > > > stats.s)
> > > > > >
> > > > > > static int
> > > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > > b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > > index f4652f40e8..214ffd018c 100644
> > > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > > @@ -39,10 +39,21 @@
> > > > > > * - rte_event_eth_rx_adapter_queue_stats_reset()
> > > > > > * - rte_event_eth_rx_adapter_event_port_get()
> > > > > > * - rte_event_eth_rx_adapter_instance_get()
> > > > > > + * - rte_event_eth_rx_adapter_runtime_params_get()
> > > > > > + * - rte_event_eth_rx_adapter_runtime_params_set()
> > > > > > *
> > > > > > * The application creates an ethernet to event adapter using
> > > > > > * rte_event_eth_rx_adapter_create_ext() or
> > > > > rte_event_eth_rx_adapter_create()
> > > > > > * or rte_event_eth_rx_adapter_create_with_params() functions.
> > > > > > + *
> > > > > > + * rte_event_eth_rx_adapter_create() or
> > > > > > + rte_event_eth_adapter_create_with_params()
> > > > > > + * configures the adapter with default value of maximum
> > > > > > + packets processed per
> > > > > > + * iteration to RXA_NB_RX_WORK_DEFAULT(128).
> > > > > > + * rte_event_eth_rx_adapter_runtime_params_set() allows to
> > > > > > + re-configure maximum
> > > > > > + * packets processed per iteration. This is alternative to
> > > > > > + using
> > > > > > + * rte_event_eth_rx_adapter_create_ext() with parameter
> > > > > > + * rte_event_eth_rx_adapter_conf::max_nb_rx
> > > > >
> > > > > Move this to Doxygen comment against max_nb_rx
> > > > >
> > > > > > + *
> > > > > > * The adapter needs to know which ethernet rx queues to poll
> > > > > > for mbufs as
> > > > > well
> > > > > > * as event device parameters such as the event queue
> > > > > > identifier,
> > > event
> > > > > > * priority and scheduling type that the adapter should use
> > > > > > when constructing @@ -299,6 +310,19 @@ struct
> > > > > rte_event_eth_rx_adapter_params {
> > > > > > /**< flag to indicate that event buffer is separate
> > > > > > for each queue */ };
> > > > > >
> > > > > > +/**
> > > > > > + * Adapter configuration parameters */ struct
> > > > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > > > + uint32_t max_nb_rx;
> > > > > > + /**< The adapter can return early if it has processed at least
> > > > > > + * max_nb_rx mbufs. This isn't treated as a
> > > > > > +requirement; batching
> > > may
> > > > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > > > >
> > > > > Also tell it is valid only for INTERNAL PORT capablity is set.
> > > > >
> > > >
> > > > Do you mean, it is valid only for INTERNAL PORT capability is 'not' set?
> > >
> > > Yes.
> > >
> > > >
> > > > > > + */
> > > > > > + uint32_t rsvd[15];
> > > > > > + /**< Reserved fields for future use */
> > > > >
> > > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to
> make
> > > > > sure rsvd is zero.
> > > > >
> > > >
> > > > The reserved fields are not used by the adapter or application.
> > > > Not sure Is it necessary to Introduce a new API to clear reserved fields.
> > >
> > > When adapter starts using new fileds(when we add new fieds in
> > > future), the old applicaiton which is not using
> > > rte_event_eth_rx_adapter_runtime_params_init() may have junk value
> > > and then adapter implementation will behave bad.
> > >
> > >
> >
> > does it mean, the application doesn't re-compile for the new DPDK?
>
> Yes. No need recompile if ABI not breaking.
>
> > When some of the reserved fields are used in the future, the application
> also may need to be recompiled along with DPDK right?
> > As the application also may need to use the newly consumed reserved
> fields?
>
> The problematic case is:
>
> Adapter implementation of 23.07(Assuming there is change params) field
> needs to work with application of 23.03.
> rte_event_eth_rx_adapter_runtime_params_init() will sove that.
>
As rte_event_eth_rx_adapter_runtime_params_init() initializes only reserved fields to zero, it may not solve the issue in this case.
The old application only tries to set/get previous valid fields and the newly used fields may still contain junk value.
If the application wants to make use of any the newly used params, the application changes are required anyway.
> >
> > > >
> > > > > > +};
> > > > > > +
> > > > > > /**
> > > > > > *
> > > > > > * Callback function invoked by the SW adapter before it
> > > > > > continues @@
> > > > > > -377,7 +401,7 @@ int
> > > > > > rte_event_eth_rx_adapter_create_ext(uint8_t
> > > > > > id,
> > > > > uint8_t dev_id,
> > > > > > * Create a new ethernet Rx event adapter with the specified
> > > identifier.
> > > > > > * This function uses an internal configuration function that
> > > > > > creates an
> > > event
> > > > > > * port. This default function reconfigures the event device
> > > > > > with an
> > > > > > - * additional event port and setups up the event port using
> > > > > > the port_config
> > > > > > + * additional event port and setup the event port using the
> > > > > > + port_config
> > > > > > * parameter passed into this function. In case the
> > > > > > application needs
> > > more
> > > > > > * control in configuration of the service, it should use the
> > > > > > * rte_event_eth_rx_adapter_create_ext() version.
> > > > > > @@ -743,6 +767,50 @@
> > > > > > rte_event_eth_rx_adapter_instance_get(uint16_t
> > > > > eth_dev_id,
> > > > > > uint16_t rx_queue_id,
> > > > > > uint8_t *rxa_inst_id);
> > > > > >
^ permalink raw reply [relevance 0%]
* Re: [EXT] Re: [PATCH v6 1/6] eal: trace: add trace point emit for blob
@ 2023-01-25 16:09 2% ` Ferruh Yigit
2023-01-30 13:35 0% ` Ankur Dwivedi
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-25 16:09 UTC (permalink / raw)
To: Ankur Dwivedi, dev
Cc: thomas, david.marchand, mdr, orika, chas3, humin29, linville,
ciara.loftus, qi.z.zhang, mw, mk, shaibran, evgenys, igorch,
chandu, Igor Russkikh, shepard.siegel, ed.czeck, john.miller,
ajit.khaparde, somnath.kotur, Jerin Jacob Kollanukkaran,
Maciej Czekaj [C],
Shijith Thotton, Srisivasubramanian Srinivasan, Harman Kalra,
rahul.lakkireddy, johndale, hyonkim, liudongdong3, yisen.zhuang,
xuanziyang2, cloud.wangxiaoyun, zhouguoyang, simei.su,
wenjun1.wu, qiming.yang, Yuying.Zhang, beilei.xing, xiao.w.wang,
jingjing.wu, junfeng.guo, rosen.xu, Nithin Kumar Dabilpuram,
Kiran Kumar Kokkilagadda, Sunil Kumar Kori,
Satha Koteswara Rao Kottidi, Liron Himi, zr, Radha Chintakuntla,
Veerasenareddy Burru, Sathesh B Edara, matan, viacheslavo,
longli, spinler, chaoyong.he, niklas.soderlund, hemant.agrawal,
sachin.saxena, g.singh, apeksha.gupta, sachin.saxena, aboyer,
Rasesh Mody, Shahed Shaikh, Devendra Singh Rawat,
andrew.rybchenko, jiawenwu, jianwang, jbehrens, maxime.coquelin,
chenbo.xia, steven.webster, matt.peters, bruce.richardson,
mtetsuyah, grive, jasvinder.singh, cristian.dumitrescu, jgrajcia,
mb
On 1/25/2023 3:02 PM, Ankur Dwivedi wrote:
>
>>
>> ----------------------------------------------------------------------
>> On 1/20/2023 8:40 AM, Ankur Dwivedi wrote:
>>> Adds a trace point emit function for capturing a blob. The blob
>>> captures the length passed by the application followed by the array.
>>>
>>> The maximum blob bytes which can be captured is bounded by
>>> RTE_TRACE_BLOB_LEN_MAX macro. The value for max blob length macro is
>>> 64 bytes. If the length is less than 64 the remaining trailing bytes
>>> are set to zero.
>>>
>>> This patch also adds test case for emit blob tracepoint function.
>>>
>>> Signed-off-by: Ankur Dwivedi <adwivedi@marvell.com>
>>> ---
>>> app/test/test_trace.c | 11 ++++++++
>>> doc/guides/prog_guide/trace_lib.rst | 12 ++++++++
>>> lib/eal/common/eal_common_trace_points.c | 2 ++
>>> lib/eal/include/rte_eal_trace.h | 6 ++++
>>> lib/eal/include/rte_trace_point.h | 32 ++++++++++++++++++++++
>>> lib/eal/include/rte_trace_point_register.h | 9 ++++++
>>> lib/eal/version.map | 3 ++
>>> 7 files changed, 75 insertions(+)
>>>
>>> diff --git a/app/test/test_trace.c b/app/test/test_trace.c index
>>> 6bedf14024..ad4a394a29 100644
>>> --- a/app/test/test_trace.c
>>> +++ b/app/test/test_trace.c
>>> @@ -4,6 +4,7 @@
>>>
>>> #include <rte_eal_trace.h>
>>> #include <rte_lcore.h>
>>> +#include <rte_random.h>
>>> #include <rte_trace.h>
>>>
>>> #include "test.h"
>>> @@ -177,7 +178,12 @@ test_fp_trace_points(void) static int
>>> test_generic_trace_points(void)
>>> {
>>> + uint8_t arr[RTE_TRACE_BLOB_LEN_MAX];
>>> int tmp;
>>> + int i;
>>> +
>>> + for (i = 0; i < RTE_TRACE_BLOB_LEN_MAX; i++)
>>> + arr[i] = i;
>>>
>>> rte_eal_trace_generic_void();
>>> rte_eal_trace_generic_u64(0x10000000000000);
>>> @@ -195,6 +201,11 @@ test_generic_trace_points(void)
>>> rte_eal_trace_generic_ptr(&tmp);
>>> rte_eal_trace_generic_str("my string");
>>> rte_eal_trace_generic_size_t(sizeof(void *));
>>> + rte_eal_trace_generic_blob(arr, 0);
>>> + rte_eal_trace_generic_blob(arr, 17);
>>> + rte_eal_trace_generic_blob(arr, RTE_TRACE_BLOB_LEN_MAX);
>>> + rte_eal_trace_generic_blob(arr, rte_rand() %
>>> + RTE_TRACE_BLOB_LEN_MAX);
>>> RTE_EAL_TRACE_GENERIC_FUNC;
>>>
>>> return TEST_SUCCESS;
>>> diff --git a/doc/guides/prog_guide/trace_lib.rst
>>> b/doc/guides/prog_guide/trace_lib.rst
>>> index 9a8f38073d..3e0ea5835c 100644
>>> --- a/doc/guides/prog_guide/trace_lib.rst
>>> +++ b/doc/guides/prog_guide/trace_lib.rst
>>> @@ -352,3 +352,15 @@ event ID.
>>> The ``packet.header`` and ``packet.context`` will be written in the
>>> slow path at the time of trace memory creation. The ``trace.header``
>>> and trace payload will be emitted when the tracepoint function is invoked.
>>> +
>>> +Limitations
>>> +-----------
>>> +
>>> +- The ``rte_trace_point_emit_blob()`` function can capture a maximum
>>> +blob of
>>> + length ``RTE_TRACE_BLOB_LEN_MAX`` bytes. The application can call
>>> + ``rte_trace_point_emit_blob()`` multiple times with length less
>>> +than or equal to
>>> + ``RTE_TRACE_BLOB_LEN_MAX``, if it needs to capture more than
>>> +``RTE_TRACE_BLOB_LEN_MAX``
>>> + bytes.
>>> +- If the length passed to the ``rte_trace_point_emit_blob()`` is less
>>> +than
>>> + ``RTE_TRACE_BLOB_LEN_MAX``, then the trailing
>>> +``(RTE_TRACE_BLOB_LEN_MAX - len)``
>>> + bytes in the trace are set to zero.
>>> diff --git a/lib/eal/common/eal_common_trace_points.c
>>> b/lib/eal/common/eal_common_trace_points.c
>>> index 0b0b254615..051f89809c 100644
>>> --- a/lib/eal/common/eal_common_trace_points.c
>>> +++ b/lib/eal/common/eal_common_trace_points.c
>>> @@ -40,6 +40,8 @@
>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_size_t,
>>> lib.eal.generic.size_t)
>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_func,
>>> lib.eal.generic.func)
>>> +RTE_TRACE_POINT_REGISTER(rte_eal_trace_generic_blob,
>>> + lib.eal.generic.blob)
>>>
>>> RTE_TRACE_POINT_REGISTER(rte_eal_trace_alarm_set,
>>> lib.eal.alarm.set)
>>> diff --git a/lib/eal/include/rte_eal_trace.h
>>> b/lib/eal/include/rte_eal_trace.h index 5ef4398230..e0b836eb2f 100644
>>> --- a/lib/eal/include/rte_eal_trace.h
>>> +++ b/lib/eal/include/rte_eal_trace.h
>>> @@ -143,6 +143,12 @@ RTE_TRACE_POINT(
>>> rte_trace_point_emit_string(func);
>>> )
>>>
>>> +RTE_TRACE_POINT(
>>> + rte_eal_trace_generic_blob,
>>> + RTE_TRACE_POINT_ARGS(void *in, uint8_t len),
>>> + rte_trace_point_emit_blob(in, len);
>>> +)
>>> +
>>> #define RTE_EAL_TRACE_GENERIC_FUNC
>>> rte_eal_trace_generic_func(__func__)
>>>
>>> /* Interrupt */
>>> diff --git a/lib/eal/include/rte_trace_point.h
>>> b/lib/eal/include/rte_trace_point.h
>>> index 0f8700974f..aca8344dbf 100644
>>> --- a/lib/eal/include/rte_trace_point.h
>>> +++ b/lib/eal/include/rte_trace_point.h
>>> @@ -144,6 +144,16 @@ _tp _args \
>>> #define rte_trace_point_emit_ptr(val)
>>> /** Tracepoint function payload for string datatype */ #define
>>> rte_trace_point_emit_string(val)
>>> +/**
>>> + * Tracepoint function to capture a blob.
>>> + *
>>> + * @param val
>>> + * Pointer to the array to be captured.
>>> + * @param len
>>> + * Length to be captured. The maximum supported length is
>>> + * RTE_TRACE_BLOB_LEN_MAX bytes.
>>> + */
>>> +#define rte_trace_point_emit_blob(val, len)
>>>
>>
>> This is just for doxygen right, why doxygen comments are not above the actual
>> macros but there is a separate #if block for it?
>
> The actual macro is within a #ifndef __DOXYGEN__ block. I think that is the reason for including
> Doxygen comments here.
Thanks for confirming.
Why comments are not as part of actual macro, but there is a separate
'#ifdef __DOXYGEN__' block?
>>
>>> #endif /* __DOXYGEN__ */
>>>
>>> @@ -152,6 +162,9 @@ _tp _args \
>>> /** @internal Macro to define event header size. */ #define
>>> __RTE_TRACE_EVENT_HEADER_SZ sizeof(uint64_t)
>>>
>>> +/** Macro to define maximum emit length of blob. */ #define
>>> +RTE_TRACE_BLOB_LEN_MAX 64
>>> +
>>> /**
>>> * Enable recording events of the given tracepoint in the trace buffer.
>>> *
>>> @@ -374,12 +387,31 @@ do { \
>>> mem = RTE_PTR_ADD(mem, __RTE_TRACE_EMIT_STRING_LEN_MAX);
>> \ } while
>>> (0)
>>>
>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>> + if (unlikely(in == NULL)) \
>>> + return; \
>>> + if (len > RTE_TRACE_BLOB_LEN_MAX) \
>>> + len = RTE_TRACE_BLOB_LEN_MAX; \
>>> + __rte_trace_point_emit(len, uint8_t); \
>>> + memcpy(mem, in, len); \
>>> + mem = RTE_PTR_ADD(mem, len); \
>>> + memset(mem, 0, RTE_TRACE_BLOB_LEN_MAX - len); \
>>> + mem = RTE_PTR_ADD(mem, RTE_TRACE_BLOB_LEN_MAX - len); \
>>
>>
>> Is first memset later memcpy not done because of performance concerns?
>
> The memset sets to 0 the unused bytes (RTE_TRACE_BLOB_LEN_MAX - len). So memset is done after memcpy.
yep, I can see what is done.
Question is, you can do more simply:
memset(mem, 0, RTE_TRACE_BLOB_LEN_MAX);
memcpy(mem, in, len);
mem = RTE_PTR_ADD(mem, RTE_TRACE_BLOB_LEN_MAX - len);
Why did you prefer the implementation you did, intentionally? If so what
is the intention, performance concerns?
btw, I want to remind that size of the 'len' can be max 64 bytes.
>>
>>> +} while (0)
>>> +
>>> #else
>>>
>>> #define __rte_trace_point_emit_header_generic(t) RTE_SET_USED(t)
>>> #define __rte_trace_point_emit_header_fp(t) RTE_SET_USED(t) #define
>>> __rte_trace_point_emit(in, type) RTE_SET_USED(in) #define
>>> rte_trace_point_emit_string(in) RTE_SET_USED(in)
>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>> + RTE_SET_USED(in); \
>>> + RTE_SET_USED(len); \
>>> +} while (0)
>>> +
>>>
>>> #endif /* ALLOW_EXPERIMENTAL_API */
>>> #endif /* _RTE_TRACE_POINT_REGISTER_H_ */ diff --git
>>> a/lib/eal/include/rte_trace_point_register.h
>>> b/lib/eal/include/rte_trace_point_register.h
>>> index a32f4d731b..7efbac8a72 100644
>>> --- a/lib/eal/include/rte_trace_point_register.h
>>> +++ b/lib/eal/include/rte_trace_point_register.h
>>> @@ -47,6 +47,15 @@ do { \
>>> RTE_STR(in)"[32]", "string_bounded_t"); \ } while (0)
>>>
>>> +#define rte_trace_point_emit_blob(in, len) \ do { \
>>> + RTE_SET_USED(in); \
>>> + __rte_trace_point_emit(len, uint8_t); \
>>> + __rte_trace_point_emit_field(RTE_TRACE_BLOB_LEN_MAX, \
>>> + RTE_STR(in)"["RTE_STR(RTE_TRACE_BLOB_LEN_MAX)"]", \
>>> + RTE_STR(uint8_t)); \
>>> +} while (0)
>>> +
>>
>> Why this macro defined here again, it is also defined in 'rte_trace_point.h'
>> already?
>> Is it because of 'register_fn()' in '__rte_trace_point_register()'?
>
> Yes the register happens in this function.
You are not really answering questions.
There are three copy of '#define rte_trace_point_emit_blob(in, len)' one
of them is for doxygen comment, please explain why there are two more
copies of it?
>>
>>> #ifdef __cplusplus
>>> }
>>> #endif
>>> diff --git a/lib/eal/version.map b/lib/eal/version.map index
>>> 7ad12a7dc9..67be24686a 100644
>>> --- a/lib/eal/version.map
>>> +++ b/lib/eal/version.map
>>> @@ -440,6 +440,9 @@ EXPERIMENTAL {
>>> rte_thread_detach;
>>> rte_thread_equal;
>>> rte_thread_join;
>>> +
>>> + # added in 23.03
>>> + __rte_eal_trace_generic_blob;
>>
>> This is not a function but a trace object.
>> I guess it was agreed that trace object not need to be exported, and trace can
>> be found by name?
>
> Yes the export in version.map can be removed. Will remove it in next patch series.
ack.
Will there be a separate patch to remove existing symbols? Although I am
not sure if it will be ABI break.
^ permalink raw reply [relevance 2%]
* Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
@ 2023-01-25 10:38 3% ` Jerin Jacob
2023-01-25 16:32 0% ` Naga Harish K, S V
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-25 10:38 UTC (permalink / raw)
To: Naga Harish K, S V
Cc: jerinj, Carrillo, Erik G, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Wed, Jan 25, 2023 at 3:22 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, January 25, 2023 9:42 AM
> > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > Cc: jerinj@marvell.com; Carrillo, Erik G <erik.g.carrillo@intel.com>; Gujjar,
> > Abhinandan S <abhinandan.gujjar@intel.com>; dev@dpdk.org;
> > Jayatheerthan, Jay <jay.jayatheerthan@intel.com>
> > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Tue, Jan 24, 2023 at 6:37 PM Naga Harish K, S V
> > <s.v.naga.harish.k@intel.com> wrote:
> > >
> > > Hi Jerin,
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Tuesday, January 24, 2023 10:00 AM
> > > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > > Cc: jerinj@marvell.com; Carrillo, Erik G
> > > > <erik.g.carrillo@intel.com>; Gujjar, Abhinandan S
> > > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > > <jay.jayatheerthan@intel.com>
> > > > Subject: Re: [PATCH v2 1/3] eventdev/eth_rx: add params set/get APIs
> > > >
> > > > On Mon, Jan 23, 2023 at 11:35 PM Naga Harish K S V
> > > > <s.v.naga.harish.k@intel.com> wrote:
> > > > >
> > > > > The adapter configuration parameters defined in the ``struct
> > > > > rte_event_eth_rx_adapter_runtime_params`` can be configured and
> > > > > retrieved using ``rte_event_eth_rx_adapter_runtime_params_set``
> > > > > and ``rte_event_eth_tx_adapter_runtime_params_get`` respectively.
> > > > >
> > > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > >
> > > > > diff --git a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > index 461eca566f..2207d6ffc3 100644
> > > > > --- a/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > +++ b/doc/guides/prog_guide/event_ethernet_rx_adapter.rst
> > > > > @@ -185,6 +185,26 @@ flags for handling received packets, event
> > > > > queue identifier, scheduler type, event priority, polling
> > > > > frequency of the receive queue and flow identifier in struct
> > > > ``rte_event_eth_rx_adapter_queue_conf``.
> > > > >
> > > > > +Set/Get adapter runtime configuration parameters
> > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > +
> > > > > +The runtime configuration parameters of adapter can be set/read
> > > > > +using ``rte_event_eth_rx_adapter_runtime_params_set()`` and
> > > > > +``rte_event_eth_rx_adapter_runtime_params_get()`` respectively.
> > > > > +The parameters that can be set/read are defined in ``struct
> > > > rte_event_eth_rx_adapter_runtime_params``.
> > > >
> > > > Good.
> > > >
> > > > > +
> > > > > +``rte_event_eth_rx_adapter_create()`` or
> > > > > +``rte_event_eth_rx_adapter_create_with_params()`` configures the
> > > > > +adapter with default value for maximum packets processed per
> > > > > +request to
> > > > 128.
> > > > > +``rte_event_eth_rx_adapter_runtime_params_set()`` function allows
> > > > > +to reconfigure maximum number of packets processed by adapter per
> > > > > +service request. This is alternative to configuring the maximum
> > > > > +packets processed per request by adapter by using
> > > > > +``rte_event_eth_rx_adapter_create_ext()`` with parameter
> > > > ``rte_event_eth_rx_adapter_conf::max_nb_rx``.
> > > >
> > > > This paragraph is not needed IMO. As it is specific to a driver, and
> > > > we can keep Doxygen comment only.
> > > >
> > > >
> > > > > +
> > > > > +``rte_event_eth_rx_adapter_runtime_parmas_get()`` function
> > > > > +retrieves the configuration parameters that are defined in
> > > > > +``struct
> > > > rte_event_eth_rx_adapter_runtime_params``.
> > > >
> > > > Good.
> > > >
> > > > > +
> > > > > Getting and resetting Adapter queue stats
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > index 34aa87379e..d8f3e750b7 100644
> > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.c
> > > > > @@ -35,6 +35,8 @@
> > > > > #define MAX_VECTOR_NS 1E9
> > > > > #define MIN_VECTOR_NS 1E5
> > > > >
> > > > > +#define RXA_NB_RX_WORK_DEFAULT 128
> > > > > +
> > > > > #define ETH_RX_ADAPTER_SERVICE_NAME_LEN 32
> > > > > #define ETH_RX_ADAPTER_MEM_NAME_LEN 32
> > > > >
> > > > > @@ -1554,7 +1556,7 @@ rxa_default_conf_cb(uint8_t id, uint8_t
> > dev_id,
> > > > > }
> > > > >
> > > > > conf->event_port_id = port_id;
> > > > > - conf->max_nb_rx = 128;
> > > > > + conf->max_nb_rx = RXA_NB_RX_WORK_DEFAULT;
> > > > > if (started)
> > > > > ret = rte_event_dev_start(dev_id);
> > > > > rx_adapter->default_cb_arg = 1; @@ -3436,6 +3438,90 @@
> > > > > rte_event_eth_rx_adapter_instance_get(uint16_t eth_dev_id,
> > > > > return -EINVAL;
> > > > > }
> > > >
> > > > > +
> > > > > +int
> > > > > +rte_event_eth_rx_adapter_runtime_params_set(uint8_t id,
> > > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > > +*params) {
> > > > > + struct event_eth_rx_adapter *rxa;
> > > > > + int ret;
> > > > > +
> > > > > + if (params == NULL)
> > > > > + return -EINVAL;
> > > > > +
> > > > > + if (rxa_memzone_lookup())
> > > > > + return -ENOMEM;
> > > >
> > > > Introduce an adapter callback and move SW adapter related logic
> > > > under callback handler.
> > > >
> > > >
> > > Do you mean introducing eventdev PMD callback for HW implementation?
> >
> > Yes.
> >
>
> Can this be taken care as and when the HW implementation is required?
OK. As long as when case INTERNAL PORT it return -ENOSUP now.
>
> > > There are no adapter callback currently for service based SW
> > Implementation.
> > >
> > > > > +
> > > > > + rxa = rxa_id_to_adapter(id);
> > > > > + if (rxa == NULL)
> > > > > + return -EINVAL;
> > > > > +
> > > > > + ret = rxa_caps_check(rxa);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + rte_spinlock_lock(&rxa->rx_lock);
> > > > > + rxa->max_nb_rx = params->max_nb_rx;
> > > > > + rte_spinlock_unlock(&rxa->rx_lock);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +int
> > > > > +rte_event_eth_rx_adapter_runtime_params_get(uint8_t id,
> > > > > + struct rte_event_eth_rx_adapter_runtime_params
> > > > > +*params) {
> > > > > + struct event_eth_rx_adapter *rxa;
> > > > > + int ret;
> > > > > +
> > > > > + if (params == NULL)
> > > > > + return -EINVAL;
> > > >
> > > >
> > > > Introduce an adapter callback and move SW adapter related logic
> > > > under callback handler.
> > > >
> > > >
> > >
> > > Same as above
> > >
> > > > > +
> > > > > + if (rxa_memzone_lookup())
> > > > > + return -ENOMEM;
> > > > +
> > > > > + rxa = rxa_id_to_adapter(id);
> > > > > + if (rxa == NULL)
> > > > > + return -EINVAL;
> > > > > +
> > > > > + ret = rxa_caps_check(rxa);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + params->max_nb_rx = rxa->max_nb_rx;
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +/* RX-adapter telemetry callbacks */
> > > > > #define RXA_ADD_DICT(stats, s) rte_tel_data_add_dict_u64(d, #s,
> > > > > stats.s)
> > > > >
> > > > > static int
> > > > > diff --git a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > index f4652f40e8..214ffd018c 100644
> > > > > --- a/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > +++ b/lib/eventdev/rte_event_eth_rx_adapter.h
> > > > > @@ -39,10 +39,21 @@
> > > > > * - rte_event_eth_rx_adapter_queue_stats_reset()
> > > > > * - rte_event_eth_rx_adapter_event_port_get()
> > > > > * - rte_event_eth_rx_adapter_instance_get()
> > > > > + * - rte_event_eth_rx_adapter_runtime_params_get()
> > > > > + * - rte_event_eth_rx_adapter_runtime_params_set()
> > > > > *
> > > > > * The application creates an ethernet to event adapter using
> > > > > * rte_event_eth_rx_adapter_create_ext() or
> > > > rte_event_eth_rx_adapter_create()
> > > > > * or rte_event_eth_rx_adapter_create_with_params() functions.
> > > > > + *
> > > > > + * rte_event_eth_rx_adapter_create() or
> > > > > + rte_event_eth_adapter_create_with_params()
> > > > > + * configures the adapter with default value of maximum packets
> > > > > + processed per
> > > > > + * iteration to RXA_NB_RX_WORK_DEFAULT(128).
> > > > > + * rte_event_eth_rx_adapter_runtime_params_set() allows to
> > > > > + re-configure maximum
> > > > > + * packets processed per iteration. This is alternative to using
> > > > > + * rte_event_eth_rx_adapter_create_ext() with parameter
> > > > > + * rte_event_eth_rx_adapter_conf::max_nb_rx
> > > >
> > > > Move this to Doxygen comment against max_nb_rx
> > > >
> > > > > + *
> > > > > * The adapter needs to know which ethernet rx queues to poll for
> > > > > mbufs as
> > > > well
> > > > > * as event device parameters such as the event queue identifier,
> > event
> > > > > * priority and scheduling type that the adapter should use when
> > > > > constructing @@ -299,6 +310,19 @@ struct
> > > > rte_event_eth_rx_adapter_params {
> > > > > /**< flag to indicate that event buffer is separate for
> > > > > each queue */ };
> > > > >
> > > > > +/**
> > > > > + * Adapter configuration parameters */ struct
> > > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > > + uint32_t max_nb_rx;
> > > > > + /**< The adapter can return early if it has processed at least
> > > > > + * max_nb_rx mbufs. This isn't treated as a requirement; batching
> > may
> > > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > > >
> > > > Also tell it is valid only for INTERNAL PORT capablity is set.
> > > >
> > >
> > > Do you mean, it is valid only for INTERNAL PORT capability is 'not' set?
> >
> > Yes.
> >
> > >
> > > > > + */
> > > > > + uint32_t rsvd[15];
> > > > > + /**< Reserved fields for future use */
> > > >
> > > > Introduce rte_event_eth_rx_adapter_runtime_params_init() to make
> > > > sure rsvd is zero.
> > > >
> > >
> > > The reserved fields are not used by the adapter or application. Not
> > > sure Is it necessary to Introduce a new API to clear reserved fields.
> >
> > When adapter starts using new fileds(when we add new fieds in future), the
> > old applicaiton which is not using
> > rte_event_eth_rx_adapter_runtime_params_init() may have junk value and
> > then adapter implementation will behave bad.
> >
> >
>
> does it mean, the application doesn't re-compile for the new DPDK?
Yes. No need recompile if ABI not breaking.
> When some of the reserved fields are used in the future, the application also may need to be recompiled along with DPDK right?
> As the application also may need to use the newly consumed reserved fields?
The problematic case is:
Adapter implementation of 23.07(Assuming there is change params) field
needs to work with application of 23.03.
rte_event_eth_rx_adapter_runtime_params_init() will sove that.
>
> > >
> > > > > +};
> > > > > +
> > > > > /**
> > > > > *
> > > > > * Callback function invoked by the SW adapter before it
> > > > > continues @@
> > > > > -377,7 +401,7 @@ int rte_event_eth_rx_adapter_create_ext(uint8_t
> > > > > id,
> > > > uint8_t dev_id,
> > > > > * Create a new ethernet Rx event adapter with the specified
> > identifier.
> > > > > * This function uses an internal configuration function that creates an
> > event
> > > > > * port. This default function reconfigures the event device with
> > > > > an
> > > > > - * additional event port and setups up the event port using the
> > > > > port_config
> > > > > + * additional event port and setup the event port using the
> > > > > + port_config
> > > > > * parameter passed into this function. In case the application needs
> > more
> > > > > * control in configuration of the service, it should use the
> > > > > * rte_event_eth_rx_adapter_create_ext() version.
> > > > > @@ -743,6 +767,50 @@
> > > > > rte_event_eth_rx_adapter_instance_get(uint16_t
> > > > eth_dev_id,
> > > > > uint16_t rx_queue_id,
> > > > > uint8_t *rxa_inst_id);
> > > > >
^ permalink raw reply [relevance 3%]
* RE: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2023-01-18 16:31 0% ` Thomas Monjalon
@ 2023-01-24 13:32 0% ` Jiawei(Jonny) Wang
0 siblings, 0 replies; 200+ results
From: Jiawei(Jonny) Wang @ 2023-01-24 13:32 UTC (permalink / raw)
To: NBU-Contact-Thomas Monjalon (EXTERNAL)
Cc: Slava Ovsiienko, Ori Kam, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, Raslan Darawsheh, jerinj
Hi,
> 18/01/2023 15:44, Jiawei(Jonny) Wang:
> > > 21/12/2022 11:29, Jiawei Wang:
> > > > For the multiple hardware ports connect to a single DPDK port
> > > > (mhpsdp), the previous patch introduces the new rte flow item to
> > > > match the port affinity of the received packets.
> > > >
> > > > This patch adds the tx_affinity setting in Tx queue API, the
> > > > affinity value reflects packets be sent to which hardware port.
> > >
> > > I think "affinity" means we would like packet to be sent on a
> > > specific hardware port, but it is not mandatory.
> > > Is it the meaning you want? Or should it be a mandatory port?
> >
> > Right, it's optional setting not mandatory.
>
> I think there is a misunderstanding.
> I mean that "affinity" with port 0 may suggest that we try to send to port 0 but
> sometimes the packet will be sent to port 1.
>
> And I think you want the packet to be always sent to port 0 if affinity is 0, right?
>
These packets should be always sent to port 0 if 'affinity' be set with hardware port 0.
'affinity is 0' -> 0 means that no affinity be set and traffic should be kept the same behavior
as before, for example, routing between different hardware ports.
> If yes, I think the word "affinity" does not convey the right idea.
> And again, the naming should give the idea that we are talking about multiple
> ports merged in one DPDK port.
>
OK, how about 'tx_mhpsdp_hwport?
'mhpsdp' as mentioned before, 'hwport' means for one 'hardware port'.
> > > > Adds the new tx_affinity field into the padding hole of
> > > > rte_eth_txconf structure, the size of rte_eth_txconf keeps the
> > > > same. Adds a suppress type for structure change in the ABI check file.
> > > >
> > > > This patch adds the testpmd command line:
> > > > testpmd> port config (port_id) txq (queue_id) affinity (value)
> > > >
> > > > For example, there're two hardware ports connects to a single DPDK
> > >
> > > connects -> connected
> >
> > OK, will fix in next version.
> >
> > > > port (port id 0), and affinity 1 stood for hard port 1 and
> > > > affinity
> > > > 2 stood for hardware port 2, used the below command to config tx
> > > > affinity for each TxQ:
> > > > port config 0 txq 0 affinity 1
> > > > port config 0 txq 1 affinity 1
> > > > port config 0 txq 2 affinity 2
> > > > port config 0 txq 3 affinity 2
> > > >
> > > > These commands config the TxQ index 0 and TxQ index 1 with
> > > > affinity 1, uses TxQ 0 or TxQ 1 send packets, these packets will
> > > > be sent from the hardware port 1, and similar with hardware port 2
> > > > if sending packets with TxQ 2 or TxQ 3.
> > >
> > > [...]
> > > > @@ -212,6 +212,10 @@ API Changes
> > > > +* ethdev: added a new field:
> > > > +
> > > > + - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
> > >
> > > Adding a new field is not an API change because existing
> > > applications don't need to update their code if they don't care this new field.
> > > I think you can remove this note.
> >
> > OK, will remove in next version.
> >
> > > > --- a/lib/ethdev/rte_ethdev.h
> > > > +++ b/lib/ethdev/rte_ethdev.h
> > > > @@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
> > > > less free descriptors than this value. */
> > > >
> > > > uint8_t tx_deferred_start; /**< Do not start queue with
> > > > rte_eth_dev_start(). */
> > > > + uint8_t tx_affinity; /**< Drives the setting of affinity per-queue.
> > > > +*/
> > >
> > > Why "Drives"? It is the setting, right?
> > > rte_eth_txconf is per-queue so no need to repeat.
> > > I think a good comment here would be to mention it is a physical
> > > port index for mhpsdp.
> > > Another good comment would be to specify how ports are numbered.
> >
> > OK, will update the comment for this new setting.
> >
> > Thanks.
>
>
^ permalink raw reply [relevance 0%]
* [PATCH v4 2/3] graph: pcap capture for graph nodes
2023-01-24 11:21 4% ` [PATCH v4 " Amit Prakash Shukla
@ 2023-01-24 11:21 2% ` Amit Prakash Shukla
2023-01-31 8:06 0% ` Jerin Jacob
2023-02-03 8:19 4% ` [PATCH v5 1/3] pcapng: comment option support for epb Amit Prakash Shukla
1 sibling, 1 reply; 200+ results
From: Amit Prakash Shukla @ 2023-01-24 11:21 UTC (permalink / raw)
To: Jerin Jacob, Kiran Kumar K, Nithin Dabilpuram, Anatoly Burakov
Cc: dev, Amit Prakash Shukla
Implementation adds support to capture packets at each node with
packet metadata and node name.
Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
---
v2:
- Fixed code style issue
- Fixed CI compilation issue on github-robot
v3:
- Code review suggestion from Stephen
- Fixed potential memory leak
v4:
- Code review suggestion from Jerin
app/test/test_graph_perf.c | 2 +-
doc/guides/rel_notes/release_23_03.rst | 7 +
lib/graph/graph.c | 17 +-
lib/graph/graph_pcap.c | 217 +++++++++++++++++++++++++
lib/graph/graph_pcap_private.h | 124 ++++++++++++++
lib/graph/graph_populate.c | 12 +-
lib/graph/graph_private.h | 5 +
lib/graph/meson.build | 3 +-
lib/graph/rte_graph.h | 5 +
lib/graph/rte_graph_worker.h | 9 +
10 files changed, 397 insertions(+), 4 deletions(-)
create mode 100644 lib/graph/graph_pcap.c
create mode 100644 lib/graph/graph_pcap_private.h
diff --git a/app/test/test_graph_perf.c b/app/test/test_graph_perf.c
index 1d065438a6..c5b463f700 100644
--- a/app/test/test_graph_perf.c
+++ b/app/test/test_graph_perf.c
@@ -324,7 +324,7 @@ graph_init(const char *gname, uint8_t nb_srcs, uint8_t nb_sinks,
char nname[RTE_NODE_NAMESIZE / 2];
struct test_node_data *node_data;
char *ename[nodes_per_stage];
- struct rte_graph_param gconf;
+ struct rte_graph_param gconf = {0};
const struct rte_memzone *mz;
uint8_t total_percent = 0;
rte_node_t *src_nodes;
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index 8c360b89e4..9ba392fb58 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -69,6 +69,10 @@ New Features
``rte_event_dev_config::nb_single_link_event_port_queues`` parameter
required for eth_rx, eth_tx, crypto and timer eventdev adapters.
+* **Added pcap trace support in graph library.**
+
+ * Added support to capture packets at each graph node with packet metadata and
+ node name.
Removed Items
-------------
@@ -101,6 +105,9 @@ API Changes
* Experimental function ``rte_pcapng_copy`` was updated to support comment
section in enhanced packet block in pcapng library.
+* Experimental structures ``struct rte_graph_param``, ``struct rte_graph`` and
+ ``struct graph`` were updated to support pcap trace in graph library.
+
ABI Changes
-----------
diff --git a/lib/graph/graph.c b/lib/graph/graph.c
index 3a617cc369..a839a2803b 100644
--- a/lib/graph/graph.c
+++ b/lib/graph/graph.c
@@ -15,6 +15,7 @@
#include <rte_string_fns.h>
#include "graph_private.h"
+#include "graph_pcap_private.h"
static struct graph_head graph_list = STAILQ_HEAD_INITIALIZER(graph_list);
static rte_spinlock_t graph_lock = RTE_SPINLOCK_INITIALIZER;
@@ -228,7 +229,12 @@ graph_mem_fixup_node_ctx(struct rte_graph *graph)
node_db = node_from_name(name);
if (node_db == NULL)
SET_ERR_JMP(ENOLINK, fail, "Node %s not found", name);
- node->process = node_db->process;
+
+ if (graph->pcap_enable) {
+ node->process = graph_pcap_dispatch;
+ node->original_process = node_db->process;
+ } else
+ node->process = node_db->process;
}
return graph;
@@ -242,6 +248,9 @@ graph_mem_fixup_secondary(struct rte_graph *graph)
if (graph == NULL || rte_eal_process_type() == RTE_PROC_PRIMARY)
return graph;
+ if (graph_pcap_file_open(graph->pcap_filename) || graph_pcap_mp_init())
+ graph_pcap_exit(graph);
+
return graph_mem_fixup_node_ctx(graph);
}
@@ -323,11 +332,17 @@ rte_graph_create(const char *name, struct rte_graph_param *prm)
if (graph_has_isolated_node(graph))
goto graph_cleanup;
+ /* Initialize pcap config. */
+ graph_pcap_enable(prm->pcap_enable);
+
/* Initialize graph object */
graph->socket = prm->socket_id;
graph->src_node_count = src_node_count;
graph->node_count = graph_nodes_count(graph);
graph->id = graph_id;
+ graph->num_pkt_to_capture = prm->num_pkt_to_capture;
+ if (prm->pcap_filename)
+ rte_strscpy(graph->pcap_filename, prm->pcap_filename, RTE_GRAPH_PCAP_FILE_SZ);
/* Allocate the Graph fast path memory and populate the data */
if (graph_fp_mem_create(graph))
diff --git a/lib/graph/graph_pcap.c b/lib/graph/graph_pcap.c
new file mode 100644
index 0000000000..7bd13ed61e
--- /dev/null
+++ b/lib/graph/graph_pcap.c
@@ -0,0 +1,217 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell International Ltd.
+ */
+
+#include <errno.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <pwd.h>
+
+#include <rte_mbuf.h>
+#include <rte_pcapng.h>
+
+#include "rte_graph_worker.h"
+
+#include "graph_pcap_private.h"
+
+#define GRAPH_PCAP_BUF_SZ 128
+#define GRAPH_PCAP_NUM_PACKETS 1024
+#define GRAPH_PCAP_PKT_POOL "graph_pcap_pkt_pool"
+#define GRAPH_PCAP_FILE_NAME "dpdk_graph_pcap_capture_XXXXXX.pcapng"
+
+/* For multi-process, packets are captured in separate files. */
+static rte_pcapng_t *pcapng_fd;
+static bool pcap_enable;
+struct rte_mempool *pkt_mp;
+
+void
+graph_pcap_enable(bool val)
+{
+ pcap_enable = val;
+}
+
+int
+graph_pcap_is_enable(void)
+{
+ return pcap_enable;
+}
+
+void
+graph_pcap_exit(struct rte_graph *graph)
+{
+ if (rte_eal_process_type() == RTE_PROC_PRIMARY)
+ if (pkt_mp)
+ rte_mempool_free(pkt_mp);
+
+ if (pcapng_fd) {
+ rte_pcapng_close(pcapng_fd);
+ pcapng_fd = NULL;
+ }
+
+ /* Disable pcap. */
+ graph->pcap_enable = 0;
+ graph_pcap_enable(0);
+}
+
+static int
+graph_pcap_default_path_get(char **dir_path)
+{
+ struct passwd *pwd;
+ char *home_dir;
+
+ /* First check for shell environment variable */
+ home_dir = getenv("HOME");
+ if (home_dir == NULL) {
+ graph_warn("Home env not preset.");
+ /* Fallback to password file entry */
+ pwd = getpwuid(getuid());
+ if (pwd == NULL)
+ return -EINVAL;
+
+ home_dir = pwd->pw_dir;
+ }
+
+ /* Append default pcap file to directory */
+ if (asprintf(dir_path, "%s/%s", home_dir, GRAPH_PCAP_FILE_NAME) == -1)
+ return -ENOMEM;
+
+ return 0;
+}
+
+int
+graph_pcap_file_open(const char *filename)
+{
+ int fd;
+ char file_name[RTE_GRAPH_PCAP_FILE_SZ];
+ char *pcap_dir;
+
+ if (pcapng_fd)
+ goto done;
+
+ if (!filename || filename[0] == '\0') {
+ if (graph_pcap_default_path_get(&pcap_dir) < 0)
+ return -1;
+ snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ, "%s", pcap_dir);
+ free(pcap_dir);
+ } else {
+ snprintf(file_name, RTE_GRAPH_PCAP_FILE_SZ, "%s_XXXXXX.pcapng",
+ filename);
+ }
+
+ fd = mkstemps(file_name, strlen(".pcapng"));
+ if (fd < 0) {
+ graph_err("mkstemps() failure");
+ return -1;
+ }
+
+ graph_info("pcap filename: %s", file_name);
+
+ /* Open a capture file */
+ pcapng_fd = rte_pcapng_fdopen(fd, NULL, NULL, "Graph pcap tracer",
+ NULL);
+ if (pcapng_fd == NULL) {
+ graph_err("Graph rte_pcapng_fdopen failed.");
+ close(fd);
+ return -1;
+ }
+
+done:
+ return 0;
+}
+
+int
+graph_pcap_mp_init(void)
+{
+ pkt_mp = rte_mempool_lookup(GRAPH_PCAP_PKT_POOL);
+ if (pkt_mp)
+ goto done;
+
+ /* Make a pool for cloned packets */
+ pkt_mp = rte_pktmbuf_pool_create_by_ops(GRAPH_PCAP_PKT_POOL,
+ IOV_MAX + RTE_GRAPH_BURST_SIZE, 0, 0,
+ rte_pcapng_mbuf_size(RTE_MBUF_DEFAULT_BUF_SIZE),
+ SOCKET_ID_ANY, "ring_mp_mc");
+ if (pkt_mp == NULL) {
+ graph_err("Cannot create mempool for graph pcap capture.");
+ return -1;
+ }
+
+done:
+ return 0;
+}
+
+int
+graph_pcap_init(struct graph *graph)
+{
+ struct rte_graph *graph_data = graph->graph;
+
+ if (graph_pcap_file_open(graph->pcap_filename) < 0)
+ goto error;
+
+ if (graph_pcap_mp_init() < 0)
+ goto error;
+
+ /* User configured number of packets to capture. */
+ if (graph->num_pkt_to_capture)
+ graph_data->nb_pkt_to_capture = graph->num_pkt_to_capture;
+ else
+ graph_data->nb_pkt_to_capture = GRAPH_PCAP_NUM_PACKETS;
+
+ /* All good. Now populate data for secondary process. */
+
+ rte_strscpy(graph_data->pcap_filename, graph->pcap_filename, RTE_GRAPH_PCAP_FILE_SZ);
+ graph_data->pcap_enable = 1;
+
+ return 0;
+
+error:
+ graph_pcap_exit(graph_data);
+ graph_pcap_enable(0);
+ graph_err("Graph pcap initialization failed. Disabling pcap trace.");
+ return -1;
+}
+
+uint16_t
+graph_pcap_dispatch(struct rte_graph *graph,
+ struct rte_node *node, void **objs,
+ uint16_t nb_objs)
+{
+ struct rte_mbuf *mbuf_clones[RTE_GRAPH_BURST_SIZE];
+ char buffer[GRAPH_PCAP_BUF_SZ];
+ uint64_t i, num_packets;
+ struct rte_mbuf *mbuf;
+ ssize_t len;
+
+ if (!nb_objs || (graph->nb_pkt_captured >= graph->nb_pkt_to_capture))
+ goto done;
+
+ num_packets = graph->nb_pkt_to_capture - graph->nb_pkt_captured;
+ /* nb_objs will never be greater than RTE_GRAPH_BURST_SIZE */
+ if (num_packets > nb_objs)
+ num_packets = nb_objs;
+
+ snprintf(buffer, GRAPH_PCAP_BUF_SZ, "%s: %s", graph->name, node->name);
+
+ for (i = 0; i < num_packets; i++) {
+ struct rte_mbuf *mc;
+ mbuf = (struct rte_mbuf *)objs[i];
+
+ mc = rte_pcapng_copy(mbuf->port, 0, mbuf, pkt_mp, mbuf->pkt_len,
+ rte_get_tsc_cycles(), 0, buffer);
+ if (mc == NULL)
+ break;
+
+ mbuf_clones[i] = mc;
+ }
+
+ /* write it to capture file */
+ len = rte_pcapng_write_packets(pcapng_fd, mbuf_clones, i);
+ rte_pktmbuf_free_bulk(mbuf_clones, i);
+ if (len <= 0)
+ goto done;
+
+ graph->nb_pkt_captured += i;
+
+done:
+ return node->original_process(graph, node, objs, nb_objs);
+}
diff --git a/lib/graph/graph_pcap_private.h b/lib/graph/graph_pcap_private.h
new file mode 100644
index 0000000000..198add67e2
--- /dev/null
+++ b/lib/graph/graph_pcap_private.h
@@ -0,0 +1,124 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(C) 2023 Marvell International Ltd.
+ */
+
+#ifndef _RTE_GRAPH_PCAP_PRIVATE_H_
+#define _RTE_GRAPH_PCAP_PRIVATE_H_
+
+#include <stdint.h>
+#include <sys/types.h>
+
+#include "graph_private.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @internal
+ *
+ * Pcap trace enable/disable function.
+ *
+ * The function is called to enable/disable graph pcap trace functionality.
+ *
+ * @param val
+ * Value to be set to enable/disable graph pcap trace.
+ */
+void graph_pcap_enable(bool val);
+
+/**
+ * @internal
+ *
+ * Check graph pcap trace is enable/disable.
+ *
+ * The function is called to check if the graph pcap trace is enabled/disabled.
+ *
+ * @return
+ * - 1: Enable
+ * - 0: Disable
+ */
+int graph_pcap_is_enable(void);
+
+/**
+ * @internal
+ *
+ * Initialise graph pcap trace functionality.
+ *
+ * The function invoked to allocate mempool.
+ *
+ * @return
+ * 0 on success and -1 on failure.
+ */
+int graph_pcap_mp_init(void);
+
+/**
+ * @internal
+ *
+ * Initialise graph pcap trace functionality.
+ *
+ * The function invoked to open pcap file.
+ *
+ * @param filename
+ * Pcap filename.
+ *
+ * @return
+ * 0 on success and -1 on failure.
+ */
+int graph_pcap_file_open(const char *filename);
+
+/**
+ * @internal
+ *
+ * Initialise graph pcap trace functionality.
+ *
+ * The function invoked when the graph pcap trace is enabled. This function
+ * open's pcap file and allocates mempool. Information needed for secondary
+ * process is populated.
+ *
+ * @param graph
+ * Pointer to graph structure.
+ *
+ * @return
+ * 0 on success and -1 on failure.
+ */
+int graph_pcap_init(struct graph *graph);
+
+/**
+ * @internal
+ *
+ * Exit graph pcap trace functionality.
+ *
+ * The function is called to exit graph pcap trace and close open fd's and
+ * free up memory. Pcap trace is also disabled.
+ *
+ * @param graph
+ * Pointer to graph structure.
+ */
+void graph_pcap_exit(struct rte_graph *graph);
+
+/**
+ * @internal
+ *
+ * Capture mbuf metadata and node metadata to a pcap file.
+ *
+ * When graph pcap trace enabled, this function is invoked prior to each node
+ * and mbuf, node metadata is parsed and captured in a pcap file.
+ *
+ * @param graph
+ * Pointer to the graph object.
+ * @param node
+ * Pointer to the node object.
+ * @param objs
+ * Pointer to an array of objects to be processed.
+ * @param nb_objs
+ * Number of objects in the array.
+ */
+uint16_t graph_pcap_dispatch(struct rte_graph *graph,
+ struct rte_node *node, void **objs,
+ uint16_t nb_objs);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_GRAPH_PCAP_PRIVATE_H_ */
diff --git a/lib/graph/graph_populate.c b/lib/graph/graph_populate.c
index 102fd6c29b..2c0844ce92 100644
--- a/lib/graph/graph_populate.c
+++ b/lib/graph/graph_populate.c
@@ -9,6 +9,7 @@
#include <rte_memzone.h>
#include "graph_private.h"
+#include "graph_pcap_private.h"
static size_t
graph_fp_mem_calc_size(struct graph *graph)
@@ -75,7 +76,11 @@ graph_nodes_populate(struct graph *_graph)
memset(node, 0, sizeof(*node));
node->fence = RTE_GRAPH_FENCE;
node->off = off;
- node->process = graph_node->node->process;
+ if (graph_pcap_is_enable()) {
+ node->process = graph_pcap_dispatch;
+ node->original_process = graph_node->node->process;
+ } else
+ node->process = graph_node->node->process;
memcpy(node->name, graph_node->node->name, RTE_GRAPH_NAMESIZE);
pid = graph_node->node->parent_id;
if (pid != RTE_NODE_ID_INVALID) { /* Cloned node */
@@ -183,6 +188,8 @@ graph_fp_mem_populate(struct graph *graph)
int rc;
graph_header_popluate(graph);
+ if (graph_pcap_is_enable())
+ graph_pcap_init(graph);
graph_nodes_populate(graph);
rc = graph_node_nexts_populate(graph);
rc |= graph_src_nodes_populate(graph);
@@ -227,6 +234,9 @@ graph_nodes_mem_destroy(struct rte_graph *graph)
int
graph_fp_mem_destroy(struct graph *graph)
{
+ if (graph_pcap_is_enable())
+ graph_pcap_exit(graph->graph);
+
graph_nodes_mem_destroy(graph->graph);
return rte_memzone_free(graph->mz);
}
diff --git a/lib/graph/graph_private.h b/lib/graph/graph_private.h
index f9a85c8926..7d1b30b8ac 100644
--- a/lib/graph/graph_private.h
+++ b/lib/graph/graph_private.h
@@ -22,6 +22,7 @@ extern int rte_graph_logtype;
__func__, __LINE__, RTE_FMT_TAIL(__VA_ARGS__, )))
#define graph_err(...) GRAPH_LOG(ERR, __VA_ARGS__)
+#define graph_warn(...) GRAPH_LOG(WARNING, __VA_ARGS__)
#define graph_info(...) GRAPH_LOG(INFO, __VA_ARGS__)
#define graph_dbg(...) GRAPH_LOG(DEBUG, __VA_ARGS__)
@@ -100,6 +101,10 @@ struct graph {
/**< Memory size of the graph. */
int socket;
/**< Socket identifier where memory is allocated. */
+ uint64_t num_pkt_to_capture;
+ /**< Number of packets to be captured per core. */
+ char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ];
+ /**< pcap file name/path. */
STAILQ_HEAD(gnode_list, graph_node) node_list;
/**< Nodes in a graph. */
};
diff --git a/lib/graph/meson.build b/lib/graph/meson.build
index c7327549e8..3526d1b5d4 100644
--- a/lib/graph/meson.build
+++ b/lib/graph/meson.build
@@ -14,7 +14,8 @@ sources = files(
'graph_debug.c',
'graph_stats.c',
'graph_populate.c',
+ 'graph_pcap.c',
)
headers = files('rte_graph.h', 'rte_graph_worker.h')
-deps += ['eal']
+deps += ['eal', 'pcapng']
diff --git a/lib/graph/rte_graph.h b/lib/graph/rte_graph.h
index b32c4bc217..c9a77297fc 100644
--- a/lib/graph/rte_graph.h
+++ b/lib/graph/rte_graph.h
@@ -35,6 +35,7 @@ extern "C" {
#define RTE_GRAPH_NAMESIZE 64 /**< Max length of graph name. */
#define RTE_NODE_NAMESIZE 64 /**< Max length of node name. */
+#define RTE_GRAPH_PCAP_FILE_SZ 64 /**< Max length of pcap file name. */
#define RTE_GRAPH_OFF_INVALID UINT32_MAX /**< Invalid graph offset. */
#define RTE_NODE_ID_INVALID UINT32_MAX /**< Invalid node id. */
#define RTE_EDGE_ID_INVALID UINT16_MAX /**< Invalid edge id. */
@@ -164,6 +165,10 @@ struct rte_graph_param {
uint16_t nb_node_patterns; /**< Number of node patterns. */
const char **node_patterns;
/**< Array of node patterns based on shell pattern. */
+
+ bool pcap_enable; /**< Pcap enable. */
+ uint64_t num_pkt_to_capture; /**< Number of packets to capture. */
+ char *pcap_filename; /**< Filename in which packets to be captured.*/
};
/**
diff --git a/lib/graph/rte_graph_worker.h b/lib/graph/rte_graph_worker.h
index fc6fee48c8..438595b15c 100644
--- a/lib/graph/rte_graph_worker.h
+++ b/lib/graph/rte_graph_worker.h
@@ -44,6 +44,12 @@ struct rte_graph {
rte_graph_t id; /**< Graph identifier. */
int socket; /**< Socket ID where memory is allocated. */
char name[RTE_GRAPH_NAMESIZE]; /**< Name of the graph. */
+ bool pcap_enable; /**< Pcap trace enabled. */
+ /** Number of packets captured per core. */
+ uint64_t nb_pkt_captured;
+ /** Number of packets to capture per core. */
+ uint64_t nb_pkt_to_capture;
+ char pcap_filename[RTE_GRAPH_PCAP_FILE_SZ]; /**< Pcap filename. */
uint64_t fence; /**< Fence. */
} __rte_cache_aligned;
@@ -64,6 +70,9 @@ struct rte_node {
char parent[RTE_NODE_NAMESIZE]; /**< Parent node name. */
char name[RTE_NODE_NAMESIZE]; /**< Name of the node. */
+ /** Original process function when pcap is enabled. */
+ rte_node_process_t original_process;
+
/* Fast path area */
#define RTE_NODE_CTX_SZ 16
uint8_t ctx[RTE_NODE_CTX_SZ] __rte_cache_aligned; /**< Node Context. */
--
2.25.1
^ permalink raw reply [relevance 2%]
* [PATCH v4 1/3] pcapng: comment option support for epb
@ 2023-01-24 11:21 4% ` Amit Prakash Shukla
2023-01-24 11:21 2% ` [PATCH v4 2/3] graph: pcap capture for graph nodes Amit Prakash Shukla
2023-02-03 8:19 4% ` [PATCH v5 1/3] pcapng: comment option support for epb Amit Prakash Shukla
0 siblings, 2 replies; 200+ results
From: Amit Prakash Shukla @ 2023-01-24 11:21 UTC (permalink / raw)
To: Reshma Pattan, Stephen Hemminger; +Cc: dev, jerinj, Amit Prakash Shukla
This change enhances rte_pcapng_copy to have comment in enhanced
packet block.
Signed-off-by: Amit Prakash Shukla <amitprakashs@marvell.com>
---
v2:
- Fixed code style issue
- Fixed CI compilation issue on github-robot
v3:
- Code review suggestion from Stephen
- Fixed potential memory leak
v4:
- Code review suggestion from Jerin
app/test/test_pcapng.c | 4 ++--
doc/guides/rel_notes/release_23_03.rst | 2 ++
lib/pcapng/rte_pcapng.c | 10 +++++++++-
lib/pcapng/rte_pcapng.h | 4 +++-
lib/pdump/rte_pdump.c | 2 +-
5 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/app/test/test_pcapng.c b/app/test/test_pcapng.c
index a7acbdc058..303d3d66f9 100644
--- a/app/test/test_pcapng.c
+++ b/app/test/test_pcapng.c
@@ -139,7 +139,7 @@ test_write_packets(void)
struct rte_mbuf *mc;
mc = rte_pcapng_copy(port_id, 0, orig, mp, pkt_len,
- rte_get_tsc_cycles(), 0);
+ rte_get_tsc_cycles(), 0, NULL);
if (mc == NULL) {
fprintf(stderr, "Cannot copy packet\n");
return -1;
@@ -255,7 +255,7 @@ test_write_over_limit_iov_max(void)
struct rte_mbuf *mc;
mc = rte_pcapng_copy(port_id, 0, orig, mp, pkt_len,
- rte_get_tsc_cycles(), 0);
+ rte_get_tsc_cycles(), 0, NULL);
if (mc == NULL) {
fprintf(stderr, "Cannot copy packet\n");
return -1;
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index c15f6fbb9f..8c360b89e4 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -98,6 +98,8 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* Experimental function ``rte_pcapng_copy`` was updated to support comment
+ section in enhanced packet block in pcapng library.
ABI Changes
-----------
diff --git a/lib/pcapng/rte_pcapng.c b/lib/pcapng/rte_pcapng.c
index 80d08e1a3b..acb31a9d93 100644
--- a/lib/pcapng/rte_pcapng.c
+++ b/lib/pcapng/rte_pcapng.c
@@ -450,7 +450,8 @@ rte_pcapng_copy(uint16_t port_id, uint32_t queue,
const struct rte_mbuf *md,
struct rte_mempool *mp,
uint32_t length, uint64_t cycles,
- enum rte_pcapng_direction direction)
+ enum rte_pcapng_direction direction,
+ const char *comment)
{
struct pcapng_enhance_packet_block *epb;
uint32_t orig_len, data_len, padding, flags;
@@ -511,6 +512,9 @@ rte_pcapng_copy(uint16_t port_id, uint32_t queue,
if (rss_hash)
optlen += pcapng_optlen(sizeof(uint8_t) + sizeof(uint32_t));
+ if (comment)
+ optlen += pcapng_optlen(strlen(comment));
+
/* reserve trailing options and block length */
opt = (struct pcapng_option *)
rte_pktmbuf_append(mc, optlen + sizeof(uint32_t));
@@ -548,6 +552,10 @@ rte_pcapng_copy(uint16_t port_id, uint32_t queue,
&hash_opt, sizeof(hash_opt));
}
+ if (comment)
+ opt = pcapng_add_option(opt, PCAPNG_OPT_COMMENT, comment,
+ strlen(comment));
+
/* Note: END_OPT necessary here. Wireshark doesn't do it. */
/* Add PCAPNG packet header */
diff --git a/lib/pcapng/rte_pcapng.h b/lib/pcapng/rte_pcapng.h
index 7d2697c647..6d286cda41 100644
--- a/lib/pcapng/rte_pcapng.h
+++ b/lib/pcapng/rte_pcapng.h
@@ -100,6 +100,8 @@ enum rte_pcapng_direction {
* The timestamp in TSC cycles.
* @param direction
* The direction of the packer: receive, transmit or unknown.
+ * @param comment
+ * Packet comment.
*
* @return
* - The pointer to the new mbuf formatted for pcapng_write
@@ -111,7 +113,7 @@ struct rte_mbuf *
rte_pcapng_copy(uint16_t port_id, uint32_t queue,
const struct rte_mbuf *m, struct rte_mempool *mp,
uint32_t length, uint64_t timestamp,
- enum rte_pcapng_direction direction);
+ enum rte_pcapng_direction direction, const char *comment);
/**
diff --git a/lib/pdump/rte_pdump.c b/lib/pdump/rte_pdump.c
index a81544cb57..9bc4bab4f2 100644
--- a/lib/pdump/rte_pdump.c
+++ b/lib/pdump/rte_pdump.c
@@ -122,7 +122,7 @@ pdump_copy(uint16_t port_id, uint16_t queue,
if (cbs->ver == V2)
p = rte_pcapng_copy(port_id, queue,
pkts[i], mp, cbs->snaplen,
- ts, direction);
+ ts, direction, NULL);
else
p = rte_pktmbuf_copy(pkts[i], mp, 0, cbs->snaplen);
--
2.25.1
^ permalink raw reply [relevance 4%]
* DPDK Release Status Meeting 2023-01-19
@ 2023-01-24 10:33 3% Mcnamara, John
0 siblings, 0 replies; 200+ results
From: Mcnamara, John @ 2023-01-24 10:33 UTC (permalink / raw)
To: dev; +Cc: thomas, david.marchand
[-- Attachment #1: Type: text/plain, Size: 3381 bytes --]
Release status meeting minutes 2023-01-19
=========================================
Agenda:
* Release Dates
* Subtrees
* Roadmaps
* LTS
* Defects
* Opens
Participants:
* AMD
* ARM
* Debian/Microsoft [No]
* Intel
* Marvell
* Nvidia
* Red Hat
Release Dates
-------------
The following are the proposed current dates for 23.03:
* V1: 25 December 2022
* RC1: 8 February 2023
* RC2: 1 March 2023
* RC3: 8 March 2023
* Release: 20 March 2023
Subtrees
--------
* next-net
* Patches being merged but slowly
* rte_flow has a lot of changes in this release and needs support
* Some reviews ongoing but we are missing reviewer support on this tree.
* next-net-intel
* No update.
* next-net-mlx
* No update.
* next-net-mvl
* Nearly all patches merged. Ready for pull.
* next-eventdev
* Nearly all patches merged. Waiting for some review comments
3 sets of patches from Intel.
* Some CNXK updates
* next-baseband
* New tree from this release.
* Some series merged and some under review.
* next-virtio
* Not many series under review.
* Vhost async and VDPA patches need review.
* next-crypto
* Some patches merged this week.
* Build patches for QAT
* PDCP (Packet Data Convergence Protocol) new library targeted for this release
* Patch for CCP driver from last release
* main
* Thread API from Tyler under review
* ABI check merged
* ML Dev patches need review
* CNI (Container Network Interface) for the AF_XDP driver.
* Will update patch to include explanation/docs.
* Request for Roadmaps
Proposed Schedule for 2023
--------------------------
See also http://core.dpdk.org/roadmap/#dates
23.03
* Proposal deadline (RFC/v1 patches): 25 December 2022
* API freeze (-rc1): 8 February 2023
* PMD features freeze (-rc2): 1 March 2023
* Builtin applications features freeze (-rc3): 8 March 2023
* Release: 20 March 2023
23.07
* Proposal deadline (RFC/v1 patches): 15 April 2023
* API freeze (-rc1): 31 May 2023
* PMD features freeze (-rc2): 21 June 2023
* Builtin applications features freeze (-rc3): 28 June 2023
* Release: 12 July 2023
23.11
* Proposal deadline (RFC/v1 patches): 12 August 2023
* API freeze (-rc1): 29 September 2023
* PMD features freeze (-rc2): 20 October 2023
* Builtin applications features freeze (-rc3): 27 October 2023
* Release: 15 November 2023
Other
-----
* TBA
LTS
---
Next releases will be:
* 22.11.1
* 21.11.4
* 20.11.8
* 19.11.15?
* CVE and critical fixes only.
* Distros
* v20.11 in Debian 11
* Ubuntu 22.04 contains 21.11
Defects
-------
* Bugzilla links, 'Bugs', added for hosted projects
* https://www.dpdk.org/hosted-projects/
Opens
-----
* None
DPDK Release Status Meetings
----------------------------
The DPDK Release Status Meeting is intended for DPDK Committers to discuss the
status of the master tree and sub-trees, and for project managers to track
progress or milestone dates.
The meeting occurs on every Thursday at 9:30 UTC over Jitsi on https://meet.jit.si/DPDK
You don't need an invite to join the meeting but if you want a calendar reminder just
send an email to "John McNamara john.mcnamara@intel.com" for the invite.
[-- Attachment #2: Type: text/html, Size: 18068 bytes --]
^ permalink raw reply [relevance 3%]
* RE: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-23 9:31 0% ` Jerin Jacob
@ 2023-01-23 18:07 0% ` Naga Harish K, S V
0 siblings, 0 replies; 200+ results
From: Naga Harish K, S V @ 2023-01-23 18:07 UTC (permalink / raw)
To: Jerin Jacob; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Monday, January 23, 2023 3:02 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Fri, Jan 20, 2023 at 4:03 PM Naga Harish K, S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> > Hi Jerin,
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Friday, January 20, 2023 3:02 PM
> > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > <jay.jayatheerthan@intel.com>
> > > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> > >
> > > On Fri, Jan 20, 2023 at 2:28 PM Naga Harish K, S V
> > > <s.v.naga.harish.k@intel.com> wrote:
> > > >
> > > > Hi Jerin,
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Wednesday, January 18, 2023 3:52 PM
> > > > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > > > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > > > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > > > <jay.jayatheerthan@intel.com>
> > > > > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get
> > > > > APIs
> > > > >
> > > > > On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> > > > > <s.v.naga.harish.k@intel.com> wrote:
> > > > > >
> > > > > > The adapter configuration parameters defined in the ``struct
> > > > > > rte_event_eth_rx_adapter_config_params`` can be configured and
> > > > > > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > > > > > ``rte_event_eth_tx_adapter_get_params`` respectively.
> > > > > >
> > > > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > > > > ---
> > > > > >
> > > > > > +/**
> > > > > > + * Adapter configuration parameters */ struct
> > > > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > > > + uint32_t max_nb_rx;
> > > > > > + /**< The adapter can return early if it has processed at least
> > > > > > + * max_nb_rx mbufs. This isn't treated as a
> > > > > > +requirement; batching
> > > may
> > > > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > > > >
> > > > > This parameter as specific to SW only driver. So future
> > > > > something added from HW only driver item then it won't work for
> > > > > SW driver. So we need capability per adapter.
> > > > >
> > > > > So, I would suggest following theme across _all_ adapters.
> > > > >
> > > > > 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> > > associate
> > > > > each parameter(the one we think, it is not common for all
> > > > > adapters)
> > > >
> > > > The parameters that are exposed in the patch are all existing
> > > > parameters and they are made runtime configurable for SW
> > > > implementation. I think, there are no such parameters existing
> > > > today for HW driver implementation. Hence it may be better to
> > > > introduce these
> > > flags when the HW driver Implementation requires runtime
> > > configurable parameters.
> > >
> > > Since current values are not applicable to HW. So we any way need
> > > the capability now to tell this is not applicable for HW.
> > >
> >
> > Depending on the existing adapter capability flag
> > "RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT",
> > the current values can be applied to only SW implementation. In this
> > way, there is no need for creating new capability flags.
>
> OK. Makes sense. Please send next version with remaining suggestions.
>
V2 version of the patch is posted with remaining suggestions.
> >
> > > >
> > > > > 2) Add some reserved fields in
> > > > > rte_event_eth_rx_adapter_runtime_params
> > > > > so that we don't break ABI in future
> > > >
> > > > Agreed.
> > > >
> > > > > 3) Add rte_event_eth_rx_adapter_runtime_params_init() function
> > > > > just make structure fill with default to avoid ABI break
> > > > > 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> > > > > capability flags and other items can be return via this
> > > >
> > > > These two items(3,4) can be taken as and when item "1" above is
> > > implemented.
> > >
> > > See above.
> > >
> > > >
> > > > > 5) Change rte_event_eth_rx_adapter_set_params as
> > > > > rte_event_eth_rx_adapter_runtime_set() or
> > > > > rte_event_eth_rx_adapter_runtime_params_set() to make it
> runtime
> > > > > explicit
> > > >
> > > > Agreed
> > > >
> > > > > 6) Change rte_event_eth_rx_adapter_get_params as
> > > > > rte_event_eth_rx_adapter_runtime_get() or
> > > > > rte_event_eth_rx_adapter_runtime_params_get() to make it
> > > > > runtime explicit
> > > >
> > > > Agreed
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
2023-01-23 14:36 0% ` Bruce Richardson
@ 2023-01-23 14:42 0% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2023-01-23 14:42 UTC (permalink / raw)
To: Bruce Richardson, Dodji Seketeli; +Cc: dev, Thomas Monjalon
On Mon, Jan 23, 2023 at 3:37 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Mon, Jan 23, 2023 at 03:31:58PM +0100, David Marchand wrote:
> > On Mon, Jan 23, 2023 at 3:24 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Sun, Jan 22, 2023 at 03:56:12PM +0100, David Marchand wrote:
> > > > Hi Bruce,
> > > >
> > > > On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
> > > > <bruce.richardson@intel.com> wrote:
> > > > >
> > > > > There is a general desire to reduce the size and scope of EAL. To this
> > > > > end, this patchset makes a (very) small step in that direction by taking
> > > > > the logging functionality out of EAL and putting it into its own library
> > > > > that can be built and maintained separately.
> > > > >
> > > > > As with the first RFC for this, the main obstacle is the "fnmatch"
> > > > > function which is needed by both EAL and the new log function when
> > > > > building on windows. While the function cannot stay in EAL - or we would
> > > > > have a circular dependency, moving it to a new library or just putting
> > > > > it in the log library have the disadvantages that it then "leaks" into
> > > > > the public namespace without an rte_prefix, which could cause issues.
> > > > > Since only a single function is involved, subsequent versions take a
> > > > > different approach to v1, and just moves the offending function to be a
> > > > > static function in a header file. This allows use by multiple libs
> > > > > without conflicting names or making it public.
> > > > >
> > > > > The other complication, as explained in v1 RFC was that of multiple
> > > > > implementations for different OS's. This is solved here in the same
> > > > > way as v1, by including the OS in the name and having meson pick the
> > > > > correct file for each build. Since only one file is involved, there
> > > > > seemed little need for replicating EAL's separate subdirectories
> > > > > per-OS.
> > > >
> > > > There is another complication.
> > > >
> > > > The ABI check is not handling properly the case where symbols are
> > > > moved to the new log library (even though the dependency to librte_log
> > > > is explicit in librte_eal elf).
> > > > For now, I don't have a good way to handle this.
> > > >
> > > > A workaround to pass the check is to suppress those symbols wrt the eal dump:
> > > > [suppress_function]
> > > > symbol_name_regexp = rte_log
> > > > [suppress_function]
> > > > symbol_name = rte_openlog_stream
> > > > [suppress_function]
> > > > symbol_name = rte_vlog
> > > >
> > > > But this is not a good solution because we would be losing checks on
> > > > them for the rest of the v23 ABI life.
> > > >
> > > Right, I got error messages from the CI job for this too, but I also have
> > > no idea how to work around this. Perhaps we only get to move content
> > > between libraries when we do an ABI bump? Seems a bit restrictive, though.
> >
> > Moving symbols as you did does not seem an ABI breakage.
> > An application that links to eal would see the dt_needed entry for the
> > new log library, load it accordingly and gets the right symbols.
> >
> Yes, I agree. However, I also agree with you that it is risky to lose
> symbol checking for the moved symbols if we need to remove them from
> analysis. That said, maybe others have some ideas as to how to work around
> this, or perhaps we just take the risk of disabling checking.
I opened a bz for libabigail.
https://sourceware.org/bugzilla/show_bug.cgi?id=30034
If it is handled fast enough, we may have a solution by the time 23.03
is released and we will remove this workaround for 23.07 development
(no pressure Dodji :-p).
--
David Marchand
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
2023-01-23 14:31 3% ` David Marchand
@ 2023-01-23 14:36 0% ` Bruce Richardson
2023-01-23 14:42 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2023-01-23 14:36 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon, Dodji Seketeli
On Mon, Jan 23, 2023 at 03:31:58PM +0100, David Marchand wrote:
> On Mon, Jan 23, 2023 at 3:24 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > On Sun, Jan 22, 2023 at 03:56:12PM +0100, David Marchand wrote:
> > > Hi Bruce,
> > >
> > > On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
> > > <bruce.richardson@intel.com> wrote:
> > > >
> > > > There is a general desire to reduce the size and scope of EAL. To this
> > > > end, this patchset makes a (very) small step in that direction by taking
> > > > the logging functionality out of EAL and putting it into its own library
> > > > that can be built and maintained separately.
> > > >
> > > > As with the first RFC for this, the main obstacle is the "fnmatch"
> > > > function which is needed by both EAL and the new log function when
> > > > building on windows. While the function cannot stay in EAL - or we would
> > > > have a circular dependency, moving it to a new library or just putting
> > > > it in the log library have the disadvantages that it then "leaks" into
> > > > the public namespace without an rte_prefix, which could cause issues.
> > > > Since only a single function is involved, subsequent versions take a
> > > > different approach to v1, and just moves the offending function to be a
> > > > static function in a header file. This allows use by multiple libs
> > > > without conflicting names or making it public.
> > > >
> > > > The other complication, as explained in v1 RFC was that of multiple
> > > > implementations for different OS's. This is solved here in the same
> > > > way as v1, by including the OS in the name and having meson pick the
> > > > correct file for each build. Since only one file is involved, there
> > > > seemed little need for replicating EAL's separate subdirectories
> > > > per-OS.
> > >
> > > There is another complication.
> > >
> > > The ABI check is not handling properly the case where symbols are
> > > moved to the new log library (even though the dependency to librte_log
> > > is explicit in librte_eal elf).
> > > For now, I don't have a good way to handle this.
> > >
> > > A workaround to pass the check is to suppress those symbols wrt the eal dump:
> > > [suppress_function]
> > > symbol_name_regexp = rte_log
> > > [suppress_function]
> > > symbol_name = rte_openlog_stream
> > > [suppress_function]
> > > symbol_name = rte_vlog
> > >
> > > But this is not a good solution because we would be losing checks on
> > > them for the rest of the v23 ABI life.
> > >
> > Right, I got error messages from the CI job for this too, but I also have
> > no idea how to work around this. Perhaps we only get to move content
> > between libraries when we do an ABI bump? Seems a bit restrictive, though.
>
> Moving symbols as you did does not seem an ABI breakage.
> An application that links to eal would see the dt_needed entry for the
> new log library, load it accordingly and gets the right symbols.
>
Yes, I agree. However, I also agree with you that it is risky to lose
symbol checking for the moved symbols if we need to remove them from
analysis. That said, maybe others have some ideas as to how to work around
this, or perhaps we just take the risk of disabling checking.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
2023-01-23 14:24 3% ` Bruce Richardson
@ 2023-01-23 14:31 3% ` David Marchand
2023-01-23 14:36 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-01-23 14:31 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Thomas Monjalon, Dodji Seketeli
On Mon, Jan 23, 2023 at 3:24 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Sun, Jan 22, 2023 at 03:56:12PM +0100, David Marchand wrote:
> > Hi Bruce,
> >
> > On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > There is a general desire to reduce the size and scope of EAL. To this
> > > end, this patchset makes a (very) small step in that direction by taking
> > > the logging functionality out of EAL and putting it into its own library
> > > that can be built and maintained separately.
> > >
> > > As with the first RFC for this, the main obstacle is the "fnmatch"
> > > function which is needed by both EAL and the new log function when
> > > building on windows. While the function cannot stay in EAL - or we would
> > > have a circular dependency, moving it to a new library or just putting
> > > it in the log library have the disadvantages that it then "leaks" into
> > > the public namespace without an rte_prefix, which could cause issues.
> > > Since only a single function is involved, subsequent versions take a
> > > different approach to v1, and just moves the offending function to be a
> > > static function in a header file. This allows use by multiple libs
> > > without conflicting names or making it public.
> > >
> > > The other complication, as explained in v1 RFC was that of multiple
> > > implementations for different OS's. This is solved here in the same
> > > way as v1, by including the OS in the name and having meson pick the
> > > correct file for each build. Since only one file is involved, there
> > > seemed little need for replicating EAL's separate subdirectories
> > > per-OS.
> >
> > There is another complication.
> >
> > The ABI check is not handling properly the case where symbols are
> > moved to the new log library (even though the dependency to librte_log
> > is explicit in librte_eal elf).
> > For now, I don't have a good way to handle this.
> >
> > A workaround to pass the check is to suppress those symbols wrt the eal dump:
> > [suppress_function]
> > symbol_name_regexp = rte_log
> > [suppress_function]
> > symbol_name = rte_openlog_stream
> > [suppress_function]
> > symbol_name = rte_vlog
> >
> > But this is not a good solution because we would be losing checks on
> > them for the rest of the v23 ABI life.
> >
> Right, I got error messages from the CI job for this too, but I also have
> no idea how to work around this. Perhaps we only get to move content
> between libraries when we do an ABI bump? Seems a bit restrictive, though.
Moving symbols as you did does not seem an ABI breakage.
An application that links to eal would see the dt_needed entry for the
new log library, load it accordingly and gets the right symbols.
--
David Marchand
^ permalink raw reply [relevance 3%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
2023-01-22 14:56 4% ` David Marchand
@ 2023-01-23 14:24 3% ` Bruce Richardson
2023-01-23 14:31 3% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2023-01-23 14:24 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Thomas Monjalon, Dodji Seketeli
On Sun, Jan 22, 2023 at 03:56:12PM +0100, David Marchand wrote:
> Hi Bruce,
>
> On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
> <bruce.richardson@intel.com> wrote:
> >
> > There is a general desire to reduce the size and scope of EAL. To this
> > end, this patchset makes a (very) small step in that direction by taking
> > the logging functionality out of EAL and putting it into its own library
> > that can be built and maintained separately.
> >
> > As with the first RFC for this, the main obstacle is the "fnmatch"
> > function which is needed by both EAL and the new log function when
> > building on windows. While the function cannot stay in EAL - or we would
> > have a circular dependency, moving it to a new library or just putting
> > it in the log library have the disadvantages that it then "leaks" into
> > the public namespace without an rte_prefix, which could cause issues.
> > Since only a single function is involved, subsequent versions take a
> > different approach to v1, and just moves the offending function to be a
> > static function in a header file. This allows use by multiple libs
> > without conflicting names or making it public.
> >
> > The other complication, as explained in v1 RFC was that of multiple
> > implementations for different OS's. This is solved here in the same
> > way as v1, by including the OS in the name and having meson pick the
> > correct file for each build. Since only one file is involved, there
> > seemed little need for replicating EAL's separate subdirectories
> > per-OS.
>
> There is another complication.
>
> The ABI check is not handling properly the case where symbols are
> moved to the new log library (even though the dependency to librte_log
> is explicit in librte_eal elf).
> For now, I don't have a good way to handle this.
>
> A workaround to pass the check is to suppress those symbols wrt the eal dump:
> [suppress_function]
> symbol_name_regexp = rte_log
> [suppress_function]
> symbol_name = rte_openlog_stream
> [suppress_function]
> symbol_name = rte_vlog
>
> But this is not a good solution because we would be losing checks on
> them for the rest of the v23 ABI life.
>
Right, I got error messages from the CI job for this too, but I also have
no idea how to work around this. Perhaps we only get to move content
between libraries when we do an ABI bump? Seems a bit restrictive, though.
/Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-20 10:33 0% ` Naga Harish K, S V
@ 2023-01-23 9:31 0% ` Jerin Jacob
2023-01-23 18:07 0% ` Naga Harish K, S V
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-23 9:31 UTC (permalink / raw)
To: Naga Harish K, S V; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Fri, Jan 20, 2023 at 4:03 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Friday, January 20, 2023 3:02 PM
> > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > <jay.jayatheerthan@intel.com>
> > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Fri, Jan 20, 2023 at 2:28 PM Naga Harish K, S V
> > <s.v.naga.harish.k@intel.com> wrote:
> > >
> > > Hi Jerin,
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, January 18, 2023 3:52 PM
> > > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > > <jay.jayatheerthan@intel.com>
> > > > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> > > >
> > > > On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> > > > <s.v.naga.harish.k@intel.com> wrote:
> > > > >
> > > > > The adapter configuration parameters defined in the ``struct
> > > > > rte_event_eth_rx_adapter_config_params`` can be configured and
> > > > > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > > > > ``rte_event_eth_tx_adapter_get_params`` respectively.
> > > > >
> > > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > > > ---
> > > > >
> > > > > +/**
> > > > > + * Adapter configuration parameters */ struct
> > > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > > + uint32_t max_nb_rx;
> > > > > + /**< The adapter can return early if it has processed at least
> > > > > + * max_nb_rx mbufs. This isn't treated as a requirement; batching
> > may
> > > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > > >
> > > > This parameter as specific to SW only driver. So future something
> > > > added from HW only driver item then it won't work for SW driver. So
> > > > we need capability per adapter.
> > > >
> > > > So, I would suggest following theme across _all_ adapters.
> > > >
> > > > 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> > associate
> > > > each parameter(the one we think, it is not common for all
> > > > adapters)
> > >
> > > The parameters that are exposed in the patch are all existing
> > > parameters and they are made runtime configurable for SW
> > > implementation. I think, there are no such parameters existing today
> > > for HW driver implementation. Hence it may be better to introduce these
> > flags when the HW driver Implementation requires runtime configurable
> > parameters.
> >
> > Since current values are not applicable to HW. So we any way need the
> > capability now to tell this is not applicable for HW.
> >
>
> Depending on the existing adapter capability flag "RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT",
> the current values can be applied to only SW implementation. In this way, there is no need for
> creating new capability flags.
OK. Makes sense. Please send next version with remaining suggestions.
>
> > >
> > > > 2) Add some reserved fields in
> > > > rte_event_eth_rx_adapter_runtime_params
> > > > so that we don't break ABI in future
> > >
> > > Agreed.
> > >
> > > > 3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
> > > > make structure fill with default to avoid ABI break
> > > > 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> > > > capability flags and other items can be return via this
> > >
> > > These two items(3,4) can be taken as and when item "1" above is
> > implemented.
> >
> > See above.
> >
> > >
> > > > 5) Change rte_event_eth_rx_adapter_set_params as
> > > > rte_event_eth_rx_adapter_runtime_set() or
> > > > rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
> > > > explicit
> > >
> > > Agreed
> > >
> > > > 6) Change rte_event_eth_rx_adapter_get_params as
> > > > rte_event_eth_rx_adapter_runtime_get() or
> > > > rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
> > > > explicit
> > >
> > > Agreed
^ permalink raw reply [relevance 0%]
* Minutes of Technical Board Meeting, 2022-11-30
@ 2023-01-23 9:03 4% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-23 9:03 UTC (permalink / raw)
To: dev
1/ Traces in ethdev API
It has been decided to have traces everywhere.
In datapath or in grey area (not sure how fast it should be),
we must use compile-time enabled trace for performance reason.
2/ Tech writer hiring
Hiring failed so far.
Thomas to ask explanations for recent candidates.
3/ MIT license exception
No progress at this date.
4/ UNH SOW
The accomplishments of 2022 must be categorized to fit with 2022 SOW.
The 2023 plan must be voted in a sheet during the next 2 weeks,
and it could be validated during the next meeting.
5/ Release 22.11.1 with hotfix
There is an issue for comparing ABI with 22.11.0.
We need review and testing of the hotfix for making 22.11.1.
The new tag will be the reference for ABI checks.
^ permalink raw reply [relevance 4%]
* Minutes of Technical Board Meeting, 2022-09-06
@ 2023-01-23 9:02 4% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-23 9:02 UTC (permalink / raw)
To: dev; +Cc: Lincoln Lavoie
We had a in-person Technical Board meeting
at the end of the first day of the summit in Arcachon, France.
Some attendees joined virtually, many were in the room.
This is a very late recap of what was said,
mainly based on notes taken by Lincoln, thanks to him.
1/ Testing
Lincoln provided a summary of the Community Lab and the CI process.
Discussed which "rolling" distribution should be used for testing,
group seemed to lean toward support of Arch Linux,
and dropping support for Fedora Rawhide.
When a container upgrade (likely the rolling) starts causing errors,
the previous container must be kept for regular testing,
but we need to be notified of the failure caused by an upgrade.
A badge could be added to the top of the patchwork page,
to represent the status of the rolling distro,
tested periodically on the DPDK main branch.
Honnappa did an intro about the improvements of DTS.
DTS will move in the main DPDK repository.
A future goal is to require DTS update for new DPDK features submissions.
The scope of DTS is testing on real hardware, compared to unit testing.
2/ Security Process
Last week there were two CVEs fixed in all releases in parallel.
There is a specific mailing list, security-prerelease@dpdk.org,
very low volume, with mails coming a few days in advance of the security releases.
3/ Minimum Versions of Software
Meson
It could be interesting to benefit from latest Meson features.
Python
Minimum version is 3.5, which is no longer included in any stable distro.
DTS seems to be aiming for 3.8 as the minimum version,
which might break on older distros.
4/ ABI/API Change Allowances
We had a long discussion about API allowed to break,
and ABI allowed to break every year for LTS versions.
These breaking changes have an impact on users upgrading or not,
and how LTS branches are used.
We need to take into account any change which has an impact for the users.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v4 0/3] Split logging functionality out of EAL
@ 2023-01-22 14:56 4% ` David Marchand
2023-01-23 14:24 3% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-01-22 14:56 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, Thomas Monjalon, Dodji Seketeli
Hi Bruce,
On Fri, Jan 20, 2023 at 7:22 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> There is a general desire to reduce the size and scope of EAL. To this
> end, this patchset makes a (very) small step in that direction by taking
> the logging functionality out of EAL and putting it into its own library
> that can be built and maintained separately.
>
> As with the first RFC for this, the main obstacle is the "fnmatch"
> function which is needed by both EAL and the new log function when
> building on windows. While the function cannot stay in EAL - or we would
> have a circular dependency, moving it to a new library or just putting
> it in the log library have the disadvantages that it then "leaks" into
> the public namespace without an rte_prefix, which could cause issues.
> Since only a single function is involved, subsequent versions take a
> different approach to v1, and just moves the offending function to be a
> static function in a header file. This allows use by multiple libs
> without conflicting names or making it public.
>
> The other complication, as explained in v1 RFC was that of multiple
> implementations for different OS's. This is solved here in the same
> way as v1, by including the OS in the name and having meson pick the
> correct file for each build. Since only one file is involved, there
> seemed little need for replicating EAL's separate subdirectories
> per-OS.
There is another complication.
The ABI check is not handling properly the case where symbols are
moved to the new log library (even though the dependency to librte_log
is explicit in librte_eal elf).
For now, I don't have a good way to handle this.
A workaround to pass the check is to suppress those symbols wrt the eal dump:
[suppress_function]
symbol_name_regexp = rte_log
[suppress_function]
symbol_name = rte_openlog_stream
[suppress_function]
symbol_name = rte_vlog
But this is not a good solution because we would be losing checks on
them for the rest of the v23 ABI life.
--
David Marchand
^ permalink raw reply [relevance 4%]
* RE: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-20 9:32 0% ` Jerin Jacob
@ 2023-01-20 10:33 0% ` Naga Harish K, S V
2023-01-23 9:31 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Naga Harish K, S V @ 2023-01-20 10:33 UTC (permalink / raw)
To: Jerin Jacob; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Friday, January 20, 2023 3:02 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Fri, Jan 20, 2023 at 2:28 PM Naga Harish K, S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> > Hi Jerin,
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, January 18, 2023 3:52 PM
> > > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > > <jay.jayatheerthan@intel.com>
> > > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> > >
> > > On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> > > <s.v.naga.harish.k@intel.com> wrote:
> > > >
> > > > The adapter configuration parameters defined in the ``struct
> > > > rte_event_eth_rx_adapter_config_params`` can be configured and
> > > > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > > > ``rte_event_eth_tx_adapter_get_params`` respectively.
> > > >
> > > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > > ---
> > > >
> > > > +/**
> > > > + * Adapter configuration parameters */ struct
> > > > +rte_event_eth_rx_adapter_runtime_params {
> > > > + uint32_t max_nb_rx;
> > > > + /**< The adapter can return early if it has processed at least
> > > > + * max_nb_rx mbufs. This isn't treated as a requirement; batching
> may
> > > > + * cause the adapter to process more than max_nb_rx mbufs.
> > >
> > > This parameter as specific to SW only driver. So future something
> > > added from HW only driver item then it won't work for SW driver. So
> > > we need capability per adapter.
> > >
> > > So, I would suggest following theme across _all_ adapters.
> > >
> > > 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> associate
> > > each parameter(the one we think, it is not common for all
> > > adapters)
> >
> > The parameters that are exposed in the patch are all existing
> > parameters and they are made runtime configurable for SW
> > implementation. I think, there are no such parameters existing today
> > for HW driver implementation. Hence it may be better to introduce these
> flags when the HW driver Implementation requires runtime configurable
> parameters.
>
> Since current values are not applicable to HW. So we any way need the
> capability now to tell this is not applicable for HW.
>
Depending on the existing adapter capability flag "RTE_EVENT_ETH_RX_ADAPTER_CAP_INTERNAL_PORT",
the current values can be applied to only SW implementation. In this way, there is no need for
creating new capability flags.
> >
> > > 2) Add some reserved fields in
> > > rte_event_eth_rx_adapter_runtime_params
> > > so that we don't break ABI in future
> >
> > Agreed.
> >
> > > 3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
> > > make structure fill with default to avoid ABI break
> > > 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> > > capability flags and other items can be return via this
> >
> > These two items(3,4) can be taken as and when item "1" above is
> implemented.
>
> See above.
>
> >
> > > 5) Change rte_event_eth_rx_adapter_set_params as
> > > rte_event_eth_rx_adapter_runtime_set() or
> > > rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
> > > explicit
> >
> > Agreed
> >
> > > 6) Change rte_event_eth_rx_adapter_get_params as
> > > rte_event_eth_rx_adapter_runtime_get() or
> > > rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
> > > explicit
> >
> > Agreed
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-20 8:58 0% ` Naga Harish K, S V
@ 2023-01-20 9:32 0% ` Jerin Jacob
2023-01-20 10:33 0% ` Naga Harish K, S V
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-20 9:32 UTC (permalink / raw)
To: Naga Harish K, S V; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
On Fri, Jan 20, 2023 at 2:28 PM Naga Harish K, S V
<s.v.naga.harish.k@intel.com> wrote:
>
> Hi Jerin,
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, January 18, 2023 3:52 PM
> > To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> > Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> > <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> > <jay.jayatheerthan@intel.com>
> > Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
> >
> > On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> > <s.v.naga.harish.k@intel.com> wrote:
> > >
> > > The adapter configuration parameters defined in the ``struct
> > > rte_event_eth_rx_adapter_config_params`` can be configured and
> > > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > > ``rte_event_eth_tx_adapter_get_params`` respectively.
> > >
> > > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > > ---
> > >
> > > +/**
> > > + * Adapter configuration parameters
> > > + */
> > > +struct rte_event_eth_rx_adapter_runtime_params {
> > > + uint32_t max_nb_rx;
> > > + /**< The adapter can return early if it has processed at least
> > > + * max_nb_rx mbufs. This isn't treated as a requirement; batching may
> > > + * cause the adapter to process more than max_nb_rx mbufs.
> >
> > This parameter as specific to SW only driver. So future something added from
> > HW only driver item then it won't work for SW driver. So we need capability
> > per adapter.
> >
> > So, I would suggest following theme across _all_ adapters.
> >
> > 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> > associate each parameter(the one we think, it is not common for all
> > adapters)
>
> The parameters that are exposed in the patch are all existing parameters and they are made
> runtime configurable for SW implementation. I think, there are no such parameters existing today for
> HW driver implementation. Hence it may be better to introduce these flags when the HW driver
> Implementation requires runtime configurable parameters.
Since current values are not applicable to HW. So we any way need the
capability now to tell this is not
applicable for HW.
>
> > 2) Add some reserved fields in rte_event_eth_rx_adapter_runtime_params
> > so that we don't break ABI in future
>
> Agreed.
>
> > 3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
> > make structure fill with default to avoid ABI break
> > 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> > capability flags and other items can be return via this
>
> These two items(3,4) can be taken as and when item "1" above is implemented.
See above.
>
> > 5) Change rte_event_eth_rx_adapter_set_params as
> > rte_event_eth_rx_adapter_runtime_set() or
> > rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
> > explicit
>
> Agreed
>
> > 6) Change rte_event_eth_rx_adapter_get_params as
> > rte_event_eth_rx_adapter_runtime_get() or
> > rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
> > explicit
>
> Agreed
^ permalink raw reply [relevance 0%]
* Re: [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition
2023-01-19 3:11 3% ` [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition Rongwei Liu
@ 2023-01-20 9:20 0% ` Andrew Rybchenko
2023-01-30 3:46 0% ` Rongwei Liu
0 siblings, 2 replies; 200+ results
From: Andrew Rybchenko @ 2023-01-20 9:20 UTC (permalink / raw)
To: Rongwei Liu, matan, viacheslavo, orika, thomas, Aman Singh,
Yuying Zhang, Ferruh Yigit, Olivier Matz
Cc: dev, rasland
On 1/19/23 06:11, Rongwei Liu wrote:
> Add IPv6 routing extension header definition and no
> TLV support for now.
>
> At rte_flow layer, there are new items defined for matching
> type/nexthdr/segments_left field.
>
> Add command line support for IPv6 routing extension header
> matching: type/nexthdr/segment_list.
>
> Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> Acked-by: Ori Kam <orika@nvidia.com>
[snip]
> diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
> index 3e6242803d..ae99036be0 100644
> --- a/doc/guides/prog_guide/rte_flow.rst
> +++ b/doc/guides/prog_guide/rte_flow.rst
> @@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
>
> - ``color``: Metering color marker.
>
> +Item: ``IPV6_ROUTING_EXT``
> +^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Matches ipv6 routing extension header.
ipv6 -> IPv6
> +
> +- ``next_hdr``: Next layer header type.
> +- ``type``: IPv6 routing extension header type.
> +- ``segments_left``: How many IPv6 destination addresses carries on
Why are only 3 fields mentioned above?
> +
> Actions
> ~~~~~~~
>
> diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
> index b8c5b68d6c..2a794d598e 100644
> --- a/doc/guides/rel_notes/release_23_03.rst
> +++ b/doc/guides/rel_notes/release_23_03.rst
> @@ -55,6 +55,11 @@ New Features
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* **Added rte_flow support for matching IPv6 routing extension header fields.**
> +
> + Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
> + header
Missing full stop above.
> +
>
> Removed Items
> -------------
> @@ -84,6 +89,11 @@ API Changes
> Also, make sure to start the actual text at the margin.
> =======================================================
>
> +* ethdev: added a new structure:
> +
> + - IPv6 routing extension header ``rte_flow_item_ipv6_routing_ext`` and
> + ``rte_ipv6_routing_ext``
> +
If I'm not mistaken, additions should not be here. It is not an
API change.
>
> ABI Changes
> -----------
> diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
> index 7d0c24366c..4074b475c8 100644
> --- a/lib/ethdev/rte_flow.c
> +++ b/lib/ethdev/rte_flow.c
> @@ -76,6 +76,20 @@ rte_flow_item_flex_conv(void *buf, const void *data)
> return src->length;
> }
>
> +static size_t
> +rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)
> +{
> + struct rte_flow_item_ipv6_routing_ext *dst = buf;
> + const struct rte_flow_item_ipv6_routing_ext *src = data;
> + size_t len;
> +
> + len = src->hdr.hdr_len ? src->hdr.hdr_len << 3 : src->hdr.segments_left << 4;
Compare hdr_len vs 0 explicitly.
Also I'd add parenthesis around ternary operator
values to make it simpler to understand.
> + if (buf)
Please, compare vs NULL explicitly. May be 'dst' would be
better here?
> + rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)),
> + src->hdr.segments, len);
> + return len;
> +}
> +
> /** Generate flow_item[] entry. */
> #define MK_FLOW_ITEM(t, s) \
> [RTE_FLOW_ITEM_TYPE_ ## t] = { \
> @@ -157,6 +171,8 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
> MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
> MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
> MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
> + MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext),
> + rte_flow_item_ipv6_routing_ext_conv),
> };
>
> /** Generate flow_action[] entry. */
> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
> index b60987db4b..0120d3e7d2 100644
> --- a/lib/ethdev/rte_flow.h
> +++ b/lib/ethdev/rte_flow.h
> @@ -624,6 +624,13 @@ enum rte_flow_item_type {
> * See struct rte_flow_item_meter_color.
> */
> RTE_FLOW_ITEM_TYPE_METER_COLOR,
> +
> + /**
> + * Matches the presence of IPv6 routing extension header.
> + *
> + * See struct rte_flow_item_ipv6_routing_ext.
@see
> + */
> + RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
> };
>
> /**
> @@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
> uint32_t reserved:23;
> };
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this structure may change without prior notice
> + *
> + * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
> + *
> + * Matches an IPv6 routing extension header.
> + */
> +struct rte_flow_item_ipv6_routing_ext {
> + struct rte_ipv6_routing_ext hdr;
> +};
> +
What about default mask?
> /** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
> #ifndef __cplusplus
> static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
> diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
> index 9c8e8206f0..158a2f83ce 100644
> --- a/lib/net/rte_ip.h
> +++ b/lib/net/rte_ip.h
> @@ -539,6 +539,27 @@ struct rte_ipv6_hdr {
> uint8_t dst_addr[16]; /**< IP address of destination host(s). */
> } __rte_packed;
>
> +/**
> + * IPv6 Routing Extension Header
> + */
> +struct rte_ipv6_routing_ext {
> + uint8_t next_hdr; /**< Protocol, next header. */
> + uint8_t hdr_len; /**< Header length. */
> + uint8_t type; /**< Extension header type. */
> + uint8_t segments_left; /**< Valid segments number. */
> + __extension__
> + union {
> + uint32_t flags;
rte_be32_t ?
> + struct {
> + uint8_t last_entry; /**< The last_entry field of SRH */
> + uint8_t flag; /**< Packet flag. */
> + uint16_t tag; /**< Packet tag. */
rte_be16_t
> + };
> + };
> + __extension__
> + uint32_t segments[0]; /**< Each hop IPv6 address. */
rte_be32_t
> +} __rte_packed;
> +
> /* IPv6 vtc_flow: IPv / TC / flow_label */
> #define RTE_IPV6_HDR_FL_SHIFT 0
> #define RTE_IPV6_HDR_TC_SHIFT 20
^ permalink raw reply [relevance 0%]
* RE: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
2023-01-18 10:22 4% ` Jerin Jacob
@ 2023-01-20 8:58 0% ` Naga Harish K, S V
2023-01-20 9:32 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Naga Harish K, S V @ 2023-01-20 8:58 UTC (permalink / raw)
To: Jerin Jacob; +Cc: jerinj, Gujjar, Abhinandan S, dev, Jayatheerthan, Jay
Hi Jerin,
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, January 18, 2023 3:52 PM
> To: Naga Harish K, S V <s.v.naga.harish.k@intel.com>
> Cc: jerinj@marvell.com; Gujjar, Abhinandan S
> <abhinandan.gujjar@intel.com>; dev@dpdk.org; Jayatheerthan, Jay
> <jay.jayatheerthan@intel.com>
> Subject: Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
>
> On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
> <s.v.naga.harish.k@intel.com> wrote:
> >
> > The adapter configuration parameters defined in the ``struct
> > rte_event_eth_rx_adapter_config_params`` can be configured and
> > retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> > ``rte_event_eth_tx_adapter_get_params`` respectively.
> >
> > Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> > ---
> >
> > +/**
> > + * Adapter configuration parameters
> > + */
> > +struct rte_event_eth_rx_adapter_runtime_params {
> > + uint32_t max_nb_rx;
> > + /**< The adapter can return early if it has processed at least
> > + * max_nb_rx mbufs. This isn't treated as a requirement; batching may
> > + * cause the adapter to process more than max_nb_rx mbufs.
>
> This parameter as specific to SW only driver. So future something added from
> HW only driver item then it won't work for SW driver. So we need capability
> per adapter.
>
> So, I would suggest following theme across _all_ adapters.
>
> 1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and
> associate each parameter(the one we think, it is not common for all
> adapters)
The parameters that are exposed in the patch are all existing parameters and they are made
runtime configurable for SW implementation. I think, there are no such parameters existing today for
HW driver implementation. Hence it may be better to introduce these flags when the HW driver
Implementation requires runtime configurable parameters.
> 2) Add some reserved fields in rte_event_eth_rx_adapter_runtime_params
> so that we don't break ABI in future
Agreed.
> 3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
> make structure fill with default to avoid ABI break
> 4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
> capability flags and other items can be return via this
These two items(3,4) can be taken as and when item "1" above is implemented.
> 5) Change rte_event_eth_rx_adapter_set_params as
> rte_event_eth_rx_adapter_runtime_set() or
> rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
> explicit
Agreed
> 6) Change rte_event_eth_rx_adapter_get_params as
> rte_event_eth_rx_adapter_runtime_get() or
> rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
> explicit
Agreed
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] ethdev: improve link speed to string
2023-01-19 11:41 3% ` Ferruh Yigit
@ 2023-01-19 16:45 0% ` Stephen Hemminger
0 siblings, 0 replies; 200+ results
From: Stephen Hemminger @ 2023-01-19 16:45 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Min Hu (Connor), Andrew Rybchenko, thomas, dev
On Thu, 19 Jan 2023 11:41:12 +0000
Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >>>> Nothing good will happen if you try to use the function to
> >>>> print two different link speeds in one log message.
> >>> You are right.
> >>> And use malloc for "name" will result in memory leakage, which is also
> >>> not a good option.
> >>>
> >>> BTW, do you think if we need to modify the function
> >>> "rte_eth_link_speed_to_str"?
> >>
> >> IMHO it would be more pain than gain in this case.
> >>
> >> .
> >>
> > Agree with you. Thanks Andrew
> >
>
> It can be option to update the API as following in next ABI break release:
>
> const char *
> rte_eth_link_speed_to_str(uint32_t link_speed, char *buf, size_t buf_size);
>
> For this a deprecation notice needs to be sent and approved, not sure
> though if it worth.
>
>
> Meanwhile, what do you think to update string 'Invalid' to something
> like 'Irregular' or 'Erratic', does this help to convey the right message?
API versioning is possible here.
^ permalink raw reply [relevance 0%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-19 10:31 0% ` lihuisong (C)
@ 2023-01-19 14:35 0% ` Thomas Monjalon
2023-01-28 1:39 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-19 14:35 UTC (permalink / raw)
To: Ferruh Yigit, lihuisong (C)
Cc: dev, andrew.rybchenko, liudongdong3, huangdaode, fengchengwen
19/01/2023 11:31, lihuisong (C):
> 在 2023/1/18 22:12, Thomas Monjalon 写道:
> > 11/01/2023 11:46, Ferruh Yigit:
> >> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
> >>> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
> >>>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
> >>>>> Hi Huisong,
> >>>>>
> >>>>> I haven't checked the patch in detail yet, but I can see it gives some
> >>>>> ABI compatibility warnings, is this expected:
> >>>> This is to be expected. Because we insert a device state,
> >>>> RTE_ETH_DEV_ALLOCATED,
> >>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
> >>>> We may have to announce it. What do you think?
> >>> If there is an actual ABI break, it can't go in this release, need to
> >>> wait LTS release and yes needs deprecation notice in advance.
> >>>
> >>> But not all enum value change warnings are real break, need to
> >>> investigate all warnings one by one.
> >>> Need to investigate if old application & new dpdk library may cause any
> >>> unexpected behavior for application.
> >>>
> >> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
> >> enum solves the issue, although logically it won't look nice.
> >> Perhaps order can be fixed in next LTS, to have more logical order, but
> >> not quite sure if order worth the disturbance may cause in application.
> > It is a state with a logical order, so it would be nice to be able to do
> > if (state > RTE_ETH_DEV_ALLOCATED)
> > but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful.
>
> The device state is internel. Applications should not access it
> directly, right?
Right
> Currently, ethdev layer or PMD use it by enum value instead of the way like
> 'state > RTE_ETH_DEV_ALLOCATED'.
Right
> But, I encapsulated an API, rte_eth_dev_is_used(), for ethdev or PMD to
> call.
> I'm not sure if it can help to eliminate our concerns.
Yes I think it's OK.
^ permalink raw reply [relevance 0%]
* Re: [dpdk-dev] [RFC] ethdev: improve link speed to string
@ 2023-01-19 11:41 3% ` Ferruh Yigit
2023-01-19 16:45 0% ` Stephen Hemminger
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-19 11:41 UTC (permalink / raw)
To: Min Hu (Connor), Andrew Rybchenko; +Cc: thomas, dev
On 9/17/2021 1:43 AM, Min Hu (Connor) wrote:
> 在 2021/9/16 16:21, Andrew Rybchenko 写道:
>> On 9/16/21 11:16 AM, Min Hu (Connor) wrote:
>>> Hi, Andrew,
>>>
>>> 在 2021/9/16 14:22, Andrew Rybchenko 写道:
>>>> On 9/16/21 5:56 AM, Min Hu (Connor) wrote:
>>>>> Currently, link speed to string only supports specific speeds, like
>>>>> 10M,
>>>>> 100M, 1G etc.
>>>>>
>>>>> This patch expands support for any link speed which is over 1M and one
>>>>> decimal place will kept for display at most.
>>>>>
>>>>> Signed-off-by: Min Hu (Connor) <humin29@huawei.com>
>>>>> ---
>>>>> lib/ethdev/rte_ethdev.c | 34 +++++++++++++++++-----------------
>>>>> 1 file changed, 17 insertions(+), 17 deletions(-)
>>>>>
>>>>> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
>>>>> index daf5ca9242..1d3b960305 100644
>>>>> --- a/lib/ethdev/rte_ethdev.c
>>>>> +++ b/lib/ethdev/rte_ethdev.c
>>>>> @@ -2750,24 +2750,24 @@ rte_eth_link_get_nowait(uint16_t port_id,
>>>>> struct rte_eth_link *eth_link)
>>>>> const char *
>>>>> rte_eth_link_speed_to_str(uint32_t link_speed)
>>>>> {
>>>>> - switch (link_speed) {
>>>>> - case ETH_SPEED_NUM_NONE: return "None";
>>>>> - case ETH_SPEED_NUM_10M: return "10 Mbps";
>>>>> - case ETH_SPEED_NUM_100M: return "100 Mbps";
>>>>> - case ETH_SPEED_NUM_1G: return "1 Gbps";
>>>>> - case ETH_SPEED_NUM_2_5G: return "2.5 Gbps";
>>>>> - case ETH_SPEED_NUM_5G: return "5 Gbps";
>>>>> - case ETH_SPEED_NUM_10G: return "10 Gbps";
>>>>> - case ETH_SPEED_NUM_20G: return "20 Gbps";
>>>>> - case ETH_SPEED_NUM_25G: return "25 Gbps";
>>>>> - case ETH_SPEED_NUM_40G: return "40 Gbps";
>>>>> - case ETH_SPEED_NUM_50G: return "50 Gbps";
>>>>> - case ETH_SPEED_NUM_56G: return "56 Gbps";
>>>>> - case ETH_SPEED_NUM_100G: return "100 Gbps";
>>>>> - case ETH_SPEED_NUM_200G: return "200 Gbps";
>>>>> - case ETH_SPEED_NUM_UNKNOWN: return "Unknown";
>>>>> - default: return "Invalid";
>>>>> +#define SPEED_STRING_LEN 16
>>>>> + static char name[SPEED_STRING_LEN];
>>>>
>>>> NACK
>>>>
>>>> Nothing good will happen if you try to use the function to
>>>> print two different link speeds in one log message.
>>> You are right.
>>> And use malloc for "name" will result in memory leakage, which is also
>>> not a good option.
>>>
>>> BTW, do you think if we need to modify the function
>>> "rte_eth_link_speed_to_str"?
>>
>> IMHO it would be more pain than gain in this case.
>>
>> .
>>
> Agree with you. Thanks Andrew
>
It can be option to update the API as following in next ABI break release:
const char *
rte_eth_link_speed_to_str(uint32_t link_speed, char *buf, size_t buf_size);
For this a deprecation notice needs to be sent and approved, not sure
though if it worth.
Meanwhile, what do you think to update string 'Invalid' to something
like 'Irregular' or 'Erratic', does this help to convey the right message?
^ permalink raw reply [relevance 3%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-18 14:12 0% ` Thomas Monjalon
@ 2023-01-19 10:31 0% ` lihuisong (C)
2023-01-19 14:35 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-01-19 10:31 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit
Cc: dev, andrew.rybchenko, liudongdong3, huangdaode, fengchengwen
在 2023/1/18 22:12, Thomas Monjalon 写道:
> 11/01/2023 11:46, Ferruh Yigit:
>> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
>>> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>>>> Hi Huisong,
>>>>>
>>>>> I haven't checked the patch in detail yet, but I can see it gives some
>>>>> ABI compatibility warnings, is this expected:
>>>> This is to be expected. Because we insert a device state,
>>>> RTE_ETH_DEV_ALLOCATED,
>>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>>>> We may have to announce it. What do you think?
>>> If there is an actual ABI break, it can't go in this release, need to
>>> wait LTS release and yes needs deprecation notice in advance.
>>>
>>> But not all enum value change warnings are real break, need to
>>> investigate all warnings one by one.
>>> Need to investigate if old application & new dpdk library may cause any
>>> unexpected behavior for application.
>>>
>> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
>> enum solves the issue, although logically it won't look nice.
>> Perhaps order can be fixed in next LTS, to have more logical order, but
>> not quite sure if order worth the disturbance may cause in application.
> It is a state with a logical order, so it would be nice to be able to do
> if (state > RTE_ETH_DEV_ALLOCATED)
> but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful.
The device state is internel. Applications should not access it
directly, right?
Currently, ethdev layer or PMD use it by enum value instead of the way like
'state > RTE_ETH_DEV_ALLOCATED'.
But, I encapsulated an API, rte_eth_dev_is_used(), for ethdev or PMD to
call.
I'm not sure if it can help to eliminate our concerns.
>
>
> .
^ permalink raw reply [relevance 0%]
* [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition
@ 2023-01-19 3:11 3% ` Rongwei Liu
2023-01-20 9:20 0% ` Andrew Rybchenko
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2023-01-19 3:11 UTC (permalink / raw)
To: matan, viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko, Olivier Matz
Cc: dev, rasland
Add IPv6 routing extension header definition and no
TLV support for now.
At rte_flow layer, there are new items defined for matching
type/nexthdr/segments_left field.
Add command line support for IPv6 routing extension header
matching: type/nexthdr/segment_list.
Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
Acked-by: Ori Kam <orika@nvidia.com>
---
app/test-pmd/cmdline_flow.c | 46 ++++++++++++++++++++++++++
doc/guides/prog_guide/rte_flow.rst | 9 +++++
doc/guides/rel_notes/release_23_03.rst | 10 ++++++
lib/ethdev/rte_flow.c | 16 +++++++++
lib/ethdev/rte_flow.h | 19 +++++++++++
lib/net/rte_ip.h | 21 ++++++++++++
6 files changed, 121 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 88108498e0..7a8516829c 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -298,6 +298,10 @@ enum index {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_ICMP,
ITEM_ICMP_TYPE,
ITEM_ICMP_CODE,
@@ -1326,6 +1330,7 @@ static const enum index next_item[] = {
ITEM_ARP_ETH_IPV4,
ITEM_IPV6_EXT,
ITEM_IPV6_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
ITEM_ICMP6,
ITEM_ICMP6_ND_NS,
ITEM_ICMP6_ND_NA,
@@ -1435,6 +1440,15 @@ static const enum index item_ipv6[] = {
ITEM_IPV6_SRC,
ITEM_IPV6_DST,
ITEM_IPV6_HAS_FRAG_EXT,
+ ITEM_IPV6_ROUTING_EXT,
+ ITEM_NEXT,
+ ZERO,
+};
+
+static const enum index item_ipv6_routing_ext[] = {
+ ITEM_IPV6_ROUTING_EXT_TYPE,
+ ITEM_IPV6_ROUTING_EXT_NEXT_HDR,
+ ITEM_IPV6_ROUTING_EXT_SEG_LEFT,
ITEM_NEXT,
ZERO,
};
@@ -3844,6 +3858,38 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY_BF(struct rte_flow_item_ipv6,
has_frag_ext, 1)),
},
+ [ITEM_IPV6_ROUTING_EXT] = {
+ .name = "ipv6_routing_ext",
+ .help = "match IPv6 routing extension header",
+ .priv = PRIV_ITEM(IPV6_ROUTING_EXT,
+ sizeof(struct rte_flow_item_ipv6_routing_ext)),
+ .next = NEXT(item_ipv6_routing_ext),
+ .call = parse_vc,
+ },
+ [ITEM_IPV6_ROUTING_EXT_TYPE] = {
+ .name = "ext_type",
+ .help = "match IPv6 routing extension header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.type)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_NEXT_HDR] = {
+ .name = "ext_next_hdr",
+ .help = "match IPv6 routing extension header next header type",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.next_hdr)),
+ },
+ [ITEM_IPV6_ROUTING_EXT_SEG_LEFT] = {
+ .name = "ext_seg_left",
+ .help = "match IPv6 routing extension header segment left",
+ .next = NEXT(item_ipv6_routing_ext, NEXT_ENTRY(COMMON_UNSIGNED),
+ item_param),
+ .args = ARGS(ARGS_ENTRY_HTON(struct rte_flow_item_ipv6_routing_ext,
+ hdr.segments_left)),
+ },
[ITEM_ICMP] = {
.name = "icmp",
.help = "match ICMP header",
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 3e6242803d..ae99036be0 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1544,6 +1544,15 @@ Matches Color Marker set by a Meter.
- ``color``: Metering color marker.
+Item: ``IPV6_ROUTING_EXT``
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Matches ipv6 routing extension header.
+
+- ``next_hdr``: Next layer header type.
+- ``type``: IPv6 routing extension header type.
+- ``segments_left``: How many IPv6 destination addresses carries on
+
Actions
~~~~~~~
diff --git a/doc/guides/rel_notes/release_23_03.rst b/doc/guides/rel_notes/release_23_03.rst
index b8c5b68d6c..2a794d598e 100644
--- a/doc/guides/rel_notes/release_23_03.rst
+++ b/doc/guides/rel_notes/release_23_03.rst
@@ -55,6 +55,11 @@ New Features
Also, make sure to start the actual text at the margin.
=======================================================
+* **Added rte_flow support for matching IPv6 routing extension header fields.**
+
+ Added ``ipv6_routing_ext`` items in rte_flow to match IPv6 routing extension
+ header
+
Removed Items
-------------
@@ -84,6 +89,11 @@ API Changes
Also, make sure to start the actual text at the margin.
=======================================================
+* ethdev: added a new structure:
+
+ - IPv6 routing extension header ``rte_flow_item_ipv6_routing_ext`` and
+ ``rte_ipv6_routing_ext``
+
ABI Changes
-----------
diff --git a/lib/ethdev/rte_flow.c b/lib/ethdev/rte_flow.c
index 7d0c24366c..4074b475c8 100644
--- a/lib/ethdev/rte_flow.c
+++ b/lib/ethdev/rte_flow.c
@@ -76,6 +76,20 @@ rte_flow_item_flex_conv(void *buf, const void *data)
return src->length;
}
+static size_t
+rte_flow_item_ipv6_routing_ext_conv(void *buf, const void *data)
+{
+ struct rte_flow_item_ipv6_routing_ext *dst = buf;
+ const struct rte_flow_item_ipv6_routing_ext *src = data;
+ size_t len;
+
+ len = src->hdr.hdr_len ? src->hdr.hdr_len << 3 : src->hdr.segments_left << 4;
+ if (buf)
+ rte_memcpy((void *)((uintptr_t)(dst->hdr.segments)),
+ src->hdr.segments, len);
+ return len;
+}
+
/** Generate flow_item[] entry. */
#define MK_FLOW_ITEM(t, s) \
[RTE_FLOW_ITEM_TYPE_ ## t] = { \
@@ -157,6 +171,8 @@ static const struct rte_flow_desc_data rte_flow_desc_item[] = {
MK_FLOW_ITEM(L2TPV2, sizeof(struct rte_flow_item_l2tpv2)),
MK_FLOW_ITEM(PPP, sizeof(struct rte_flow_item_ppp)),
MK_FLOW_ITEM(METER_COLOR, sizeof(struct rte_flow_item_meter_color)),
+ MK_FLOW_ITEM_FN(IPV6_ROUTING_EXT, sizeof(struct rte_flow_item_ipv6_routing_ext),
+ rte_flow_item_ipv6_routing_ext_conv),
};
/** Generate flow_action[] entry. */
diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h
index b60987db4b..0120d3e7d2 100644
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
@@ -624,6 +624,13 @@ enum rte_flow_item_type {
* See struct rte_flow_item_meter_color.
*/
RTE_FLOW_ITEM_TYPE_METER_COLOR,
+
+ /**
+ * Matches the presence of IPv6 routing extension header.
+ *
+ * See struct rte_flow_item_ipv6_routing_ext.
+ */
+ RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT,
};
/**
@@ -873,6 +880,18 @@ struct rte_flow_item_ipv6 {
uint32_t reserved:23;
};
+/**
+ * @warning
+ * @b EXPERIMENTAL: this structure may change without prior notice
+ *
+ * RTE_FLOW_ITEM_TYPE_IPV6_ROUTING_EXT.
+ *
+ * Matches an IPv6 routing extension header.
+ */
+struct rte_flow_item_ipv6_routing_ext {
+ struct rte_ipv6_routing_ext hdr;
+};
+
/** Default mask for RTE_FLOW_ITEM_TYPE_IPV6. */
#ifndef __cplusplus
static const struct rte_flow_item_ipv6 rte_flow_item_ipv6_mask = {
diff --git a/lib/net/rte_ip.h b/lib/net/rte_ip.h
index 9c8e8206f0..158a2f83ce 100644
--- a/lib/net/rte_ip.h
+++ b/lib/net/rte_ip.h
@@ -539,6 +539,27 @@ struct rte_ipv6_hdr {
uint8_t dst_addr[16]; /**< IP address of destination host(s). */
} __rte_packed;
+/**
+ * IPv6 Routing Extension Header
+ */
+struct rte_ipv6_routing_ext {
+ uint8_t next_hdr; /**< Protocol, next header. */
+ uint8_t hdr_len; /**< Header length. */
+ uint8_t type; /**< Extension header type. */
+ uint8_t segments_left; /**< Valid segments number. */
+ __extension__
+ union {
+ uint32_t flags;
+ struct {
+ uint8_t last_entry; /**< The last_entry field of SRH */
+ uint8_t flag; /**< Packet flag. */
+ uint16_t tag; /**< Packet tag. */
+ };
+ };
+ __extension__
+ uint32_t segments[0]; /**< Each hop IPv6 address. */
+} __rte_packed;
+
/* IPv6 vtc_flow: IPv / TC / flow_label */
#define RTE_IPV6_HDR_FL_SHIFT 0
#define RTE_IPV6_HDR_TC_SHIFT 20
--
2.27.0
^ permalink raw reply [relevance 3%]
* Re: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2023-01-18 14:44 0% ` Jiawei(Jonny) Wang
@ 2023-01-18 16:31 0% ` Thomas Monjalon
2023-01-24 13:32 0% ` Jiawei(Jonny) Wang
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-18 16:31 UTC (permalink / raw)
To: Jiawei(Jonny) Wang
Cc: Slava Ovsiienko, Ori Kam, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, Raslan Darawsheh, jerinj
18/01/2023 15:44, Jiawei(Jonny) Wang:
> > 21/12/2022 11:29, Jiawei Wang:
> > > For the multiple hardware ports connect to a single DPDK port
> > > (mhpsdp), the previous patch introduces the new rte flow item to match
> > > the port affinity of the received packets.
> > >
> > > This patch adds the tx_affinity setting in Tx queue API, the affinity
> > > value reflects packets be sent to which hardware port.
> >
> > I think "affinity" means we would like packet to be sent on a specific hardware
> > port, but it is not mandatory.
> > Is it the meaning you want? Or should it be a mandatory port?
>
> Right, it's optional setting not mandatory.
I think there is a misunderstanding.
I mean that "affinity" with port 0 may suggest that we try
to send to port 0 but sometimes the packet will be sent to port 1.
And I think you want the packet to be always sent to port 0
if affinity is 0, right?
If yes, I think the word "affinity" does not convey the right idea.
And again, the naming should give the idea that we are talking about
multiple ports merged in one DPDK port.
> > > Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> > > structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> > > type for structure change in the ABI check file.
> > >
> > > This patch adds the testpmd command line:
> > > testpmd> port config (port_id) txq (queue_id) affinity (value)
> > >
> > > For example, there're two hardware ports connects to a single DPDK
> >
> > connects -> connected
>
> OK, will fix in next version.
>
> > > port (port id 0), and affinity 1 stood for hard port 1 and affinity
> > > 2 stood for hardware port 2, used the below command to config tx
> > > affinity for each TxQ:
> > > port config 0 txq 0 affinity 1
> > > port config 0 txq 1 affinity 1
> > > port config 0 txq 2 affinity 2
> > > port config 0 txq 3 affinity 2
> > >
> > > These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
> > > uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> > > hardware port 1, and similar with hardware port 2 if sending packets
> > > with TxQ 2 or TxQ 3.
> >
> > [...]
> > > @@ -212,6 +212,10 @@ API Changes
> > > +* ethdev: added a new field:
> > > +
> > > + - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
> >
> > Adding a new field is not an API change because existing applications don't
> > need to update their code if they don't care this new field.
> > I think you can remove this note.
>
> OK, will remove in next version.
>
> > > --- a/lib/ethdev/rte_ethdev.h
> > > +++ b/lib/ethdev/rte_ethdev.h
> > > @@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
> > > less free descriptors than this value. */
> > >
> > > uint8_t tx_deferred_start; /**< Do not start queue with
> > > rte_eth_dev_start(). */
> > > + uint8_t tx_affinity; /**< Drives the setting of affinity per-queue.
> > > +*/
> >
> > Why "Drives"? It is the setting, right?
> > rte_eth_txconf is per-queue so no need to repeat.
> > I think a good comment here would be to mention it is a physical port index for
> > mhpsdp.
> > Another good comment would be to specify how ports are numbered.
>
> OK, will update the comment for this new setting.
>
> Thanks.
^ permalink raw reply [relevance 0%]
* RE: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2023-01-18 11:37 0% ` Thomas Monjalon
@ 2023-01-18 14:44 0% ` Jiawei(Jonny) Wang
2023-01-18 16:31 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Jiawei(Jonny) Wang @ 2023-01-18 14:44 UTC (permalink / raw)
To: NBU-Contact-Thomas Monjalon (EXTERNAL)
Cc: Slava Ovsiienko, Ori Kam, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, Raslan Darawsheh, jerinj
Hi,
>
> 21/12/2022 11:29, Jiawei Wang:
> > For the multiple hardware ports connect to a single DPDK port
> > (mhpsdp), the previous patch introduces the new rte flow item to match
> > the port affinity of the received packets.
> >
> > This patch adds the tx_affinity setting in Tx queue API, the affinity
> > value reflects packets be sent to which hardware port.
>
> I think "affinity" means we would like packet to be sent on a specific hardware
> port, but it is not mandatory.
> Is it the meaning you want? Or should it be a mandatory port?
>
Right, it's optional setting not mandatory.
> > Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> > structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> > type for structure change in the ABI check file.
> >
> > This patch adds the testpmd command line:
> > testpmd> port config (port_id) txq (queue_id) affinity (value)
> >
> > For example, there're two hardware ports connects to a single DPDK
>
> connects -> connected
>
OK, will fix in next version.
> > port (port id 0), and affinity 1 stood for hard port 1 and affinity
> > 2 stood for hardware port 2, used the below command to config tx
> > affinity for each TxQ:
> > port config 0 txq 0 affinity 1
> > port config 0 txq 1 affinity 1
> > port config 0 txq 2 affinity 2
> > port config 0 txq 3 affinity 2
> >
> > These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
> > uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> > hardware port 1, and similar with hardware port 2 if sending packets
> > with TxQ 2 or TxQ 3.
>
> [...]
> > @@ -212,6 +212,10 @@ API Changes
> > +* ethdev: added a new field:
> > +
> > + - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
>
> Adding a new field is not an API change because existing applications don't
> need to update their code if they don't care this new field.
> I think you can remove this note.
>
OK, will remove in next version.
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
> > less free descriptors than this value. */
> >
> > uint8_t tx_deferred_start; /**< Do not start queue with
> > rte_eth_dev_start(). */
> > + uint8_t tx_affinity; /**< Drives the setting of affinity per-queue.
> > +*/
>
> Why "Drives"? It is the setting, right?
> rte_eth_txconf is per-queue so no need to repeat.
> I think a good comment here would be to mention it is a physical port index for
> mhpsdp.
> Another good comment would be to specify how ports are numbered.
>
OK, will update the comment for this new setting.
Thanks.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
2023-01-12 10:53 4% ` David Marchand
@ 2023-01-18 14:29 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: David Marchand @ 2023-01-18 14:29 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, bruce.richardson, Ferruh Yigit
On Wed, Jan 11, 2023 at 8:53 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it.
> POSIX shell does not support function export except using an "eval trick".
> Required variables are also exported.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
Reviewed-by: David Marchand <david.marchand@redhat.com>
Applied, thanks.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-11 10:46 0% ` Ferruh Yigit
2023-01-12 2:26 0% ` lihuisong (C)
@ 2023-01-18 14:12 0% ` Thomas Monjalon
2023-01-19 10:31 0% ` lihuisong (C)
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-18 14:12 UTC (permalink / raw)
To: lihuisong (C), Ferruh Yigit
Cc: dev, andrew.rybchenko, liudongdong3, huangdaode, fengchengwen
11/01/2023 11:46, Ferruh Yigit:
> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
> > On 1/11/2023 12:53 AM, lihuisong (C) wrote:
> >> 在 2023/1/11 0:51, Ferruh Yigit 写道:
> >>> Hi Huisong,
> >>>
> >>> I haven't checked the patch in detail yet, but I can see it gives some
> >>> ABI compatibility warnings, is this expected:
> >> This is to be expected. Because we insert a device state,
> >> RTE_ETH_DEV_ALLOCATED,
> >> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
> >> We may have to announce it. What do you think?
> >
> > If there is an actual ABI break, it can't go in this release, need to
> > wait LTS release and yes needs deprecation notice in advance.
> >
> > But not all enum value change warnings are real break, need to
> > investigate all warnings one by one.
> > Need to investigate if old application & new dpdk library may cause any
> > unexpected behavior for application.
> >
>
> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
> enum solves the issue, although logically it won't look nice.
> Perhaps order can be fixed in next LTS, to have more logical order, but
> not quite sure if order worth the disturbance may cause in application.
It is a state with a logical order, so it would be nice to be able to do
if (state > RTE_ETH_DEV_ALLOCATED)
but given there is RTE_ETH_DEV_REMOVED later in the enum, not sure it is useful.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-18 10:45 4% ` David Marchand
@ 2023-01-18 11:43 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-01-18 11:43 UTC (permalink / raw)
To: David Marchand; +Cc: Thomas Monjalon, dev, bruce.richardson
On 1/18/2023 10:45 AM, David Marchand wrote:
> On Thu, Jan 12, 2023 at 3:15 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>>>> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
>>>> abiret=$?
>>>> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
>>>> - error=1
>>>> - echo
>>>> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
>>>> if [ $(($abiret & 3)) -ne 0 ]; then
>>>> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
>>>> fi
>>>> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
>>>> if [ $(($abiret & 8)) -ne 0 ]; then
>>>> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
>>>> fi
>>>> - echo
>>>> + return 1
>>>> }
>>>> -done
>>>> +}'
>>>> +
>>>> +error=
>>>> +find $refdir -name "*.dump" |
>>>> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
>>>> +error=1
>>>>
>>>> [ -z "$error" ] || [ -n "$warnonly" ]
>>>
>>> For the record, on my system, calling this script is ~5 times faster:
>>> - before
>>> real 0m5,447s
>>> user 0m4,497s
>>> sys 0m0,937s
>>>
>>> - after
>>> real 0m1,202s
>>> user 0m10,784s
>>> sys 0m2,027s
>>>
>>>
>>>> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
>>>> index f15a3b9aaf..61f7510ea1 100755
>>>> --- a/devtools/gen-abi.sh
>>>> +++ b/devtools/gen-abi.sh
>>>> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
>>>> fi
>>>>
>>>> libname=$(basename $f)
>>>> - abidw --out-file $dumpdir/${libname%.so*}.dump $f
>>>> -done
>>>> + echo $dumpdir/${libname%.so*}.dump $f
>>>> +done |
>>>> +xargs -n2 -P0 abidw --out-file
>>>> --
>>>> 2.39.0
>>>>
>>>
>>> - before
>>> real 0m8,237s
>>> user 0m7,704s
>>> sys 0m0,504s
>>>
>>> - after
>>> real 0m2,517s
>>> user 0m14,145s
>>> sys 0m0,766s
>>>
>>>
>>> Ferruh, I am seeing quite different numbers for running those scripts
>>> (clearly not of the minute order).
>>> I switched to testing/building in tmpfs some time ago.
>>> It requires a good amount of memory (I empirically allocated 40G), but
>>> maybe worth a try for you?
>>>
>>
>> I run 'test-meson-builds.sh' script directly and yes I am getting
>> different numbers although there is still improvement, not in scale with
>> what you are getting, with v4 I have following:
>>
>> - before
>> real 10m3.248s
>> user 39m8.664s
>> sys 14m52.870s
>>
>> - after
>> real 7m49.086s
>> user 39m59.507s
>> sys 15m0.598s
>
> Well, yes, I did not realise which apples you were looking at :-).
> The change looks good in any case.
>
Ack
^ permalink raw reply [relevance 4%]
* Re: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2022-12-21 10:29 2% ` [RFC 2/5] ethdev: introduce the affinity field " Jiawei Wang
2023-01-11 16:47 0% ` Ori Kam
@ 2023-01-18 11:37 0% ` Thomas Monjalon
2023-01-18 14:44 0% ` Jiawei(Jonny) Wang
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-18 11:37 UTC (permalink / raw)
To: Jiawei Wang
Cc: viacheslavo, orika, Aman Singh, Yuying Zhang, Ferruh Yigit,
Andrew Rybchenko, dev, rasland, jerinj
21/12/2022 11:29, Jiawei Wang:
> For the multiple hardware ports connect to a single DPDK port (mhpsdp),
> the previous patch introduces the new rte flow item to match the port
> affinity of the received packets.
>
> This patch adds the tx_affinity setting in Tx queue API, the affinity value
> reflects packets be sent to which hardware port.
I think "affinity" means we would like packet to be sent
on a specific hardware port, but it is not mandatory.
Is it the meaning you want? Or should it be a mandatory port?
> Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> type for structure change in the ABI check file.
>
> This patch adds the testpmd command line:
> testpmd> port config (port_id) txq (queue_id) affinity (value)
>
> For example, there're two hardware ports connects to a single DPDK
connects -> connected
> port (port id 0), and affinity 1 stood for hard port 1 and affinity
> 2 stood for hardware port 2, used the below command to config
> tx affinity for each TxQ:
> port config 0 txq 0 affinity 1
> port config 0 txq 1 affinity 1
> port config 0 txq 2 affinity 2
> port config 0 txq 3 affinity 2
>
> These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
> uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> hardware port 1, and similar with hardware port 2 if sending packets
> with TxQ 2 or TxQ 3.
[...]
> @@ -212,6 +212,10 @@ API Changes
> +* ethdev: added a new field:
> +
> + - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
Adding a new field is not an API change because
existing applications don't need to update their code
if they don't care this new field.
I think you can remove this note.
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
> less free descriptors than this value. */
>
> uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
> + uint8_t tx_affinity; /**< Drives the setting of affinity per-queue. */
Why "Drives"? It is the setting, right?
rte_eth_txconf is per-queue so no need to repeat.
I think a good comment here would be to mention it is a physical port index for mhpsdp.
Another good comment would be to specify how ports are numbered.
^ permalink raw reply [relevance 0%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-12 14:14 4% ` Ferruh Yigit
@ 2023-01-18 10:45 4% ` David Marchand
2023-01-18 11:43 4% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2023-01-18 10:45 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Thomas Monjalon, dev, bruce.richardson
On Thu, Jan 12, 2023 at 3:15 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
> >> abiret=$?
> >> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> >> - error=1
> >> - echo
> >> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
> >> if [ $(($abiret & 3)) -ne 0 ]; then
> >> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
> >> fi
> >> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
> >> if [ $(($abiret & 8)) -ne 0 ]; then
> >> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
> >> fi
> >> - echo
> >> + return 1
> >> }
> >> -done
> >> +}'
> >> +
> >> +error=
> >> +find $refdir -name "*.dump" |
> >> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
> >> +error=1
> >>
> >> [ -z "$error" ] || [ -n "$warnonly" ]
> >
> > For the record, on my system, calling this script is ~5 times faster:
> > - before
> > real 0m5,447s
> > user 0m4,497s
> > sys 0m0,937s
> >
> > - after
> > real 0m1,202s
> > user 0m10,784s
> > sys 0m2,027s
> >
> >
> >> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
> >> index f15a3b9aaf..61f7510ea1 100755
> >> --- a/devtools/gen-abi.sh
> >> +++ b/devtools/gen-abi.sh
> >> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
> >> fi
> >>
> >> libname=$(basename $f)
> >> - abidw --out-file $dumpdir/${libname%.so*}.dump $f
> >> -done
> >> + echo $dumpdir/${libname%.so*}.dump $f
> >> +done |
> >> +xargs -n2 -P0 abidw --out-file
> >> --
> >> 2.39.0
> >>
> >
> > - before
> > real 0m8,237s
> > user 0m7,704s
> > sys 0m0,504s
> >
> > - after
> > real 0m2,517s
> > user 0m14,145s
> > sys 0m0,766s
> >
> >
> > Ferruh, I am seeing quite different numbers for running those scripts
> > (clearly not of the minute order).
> > I switched to testing/building in tmpfs some time ago.
> > It requires a good amount of memory (I empirically allocated 40G), but
> > maybe worth a try for you?
> >
>
> I run 'test-meson-builds.sh' script directly and yes I am getting
> different numbers although there is still improvement, not in scale with
> what you are getting, with v4 I have following:
>
> - before
> real 10m3.248s
> user 39m8.664s
> sys 14m52.870s
>
> - after
> real 7m49.086s
> user 39m59.507s
> sys 15m0.598s
Well, yes, I did not realise which apples you were looking at :-).
The change looks good in any case.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [PATCH 1/3] eventdev/eth_rx: add params set/get APIs
@ 2023-01-18 10:22 4% ` Jerin Jacob
2023-01-20 8:58 0% ` Naga Harish K, S V
1 sibling, 1 reply; 200+ results
From: Jerin Jacob @ 2023-01-18 10:22 UTC (permalink / raw)
To: Naga Harish K S V; +Cc: jerinj, abhinandan.gujjar, dev, jay.jayatheerthan
On Sat, Jan 7, 2023 at 9:49 PM Naga Harish K S V
<s.v.naga.harish.k@intel.com> wrote:
>
> The adapter configuration parameters defined in the
> ``struct rte_event_eth_rx_adapter_config_params`` can be configured
> and retrieved using ``rte_event_eth_rx_adapter_set_params`` and
> ``rte_event_eth_tx_adapter_get_params`` respectively.
>
> Signed-off-by: Naga Harish K S V <s.v.naga.harish.k@intel.com>
> ---
>
> +/**
> + * Adapter configuration parameters
> + */
> +struct rte_event_eth_rx_adapter_runtime_params {
> + uint32_t max_nb_rx;
> + /**< The adapter can return early if it has processed at least
> + * max_nb_rx mbufs. This isn't treated as a requirement; batching may
> + * cause the adapter to process more than max_nb_rx mbufs.
This parameter as specific to SW only driver. So future something
added from HW only driver item then it won't work
for SW driver. So we need capability per adapter.
So, I would suggest following theme across _all_ adapters.
1) Introduce RTE_EVENT_ETH_RX_ADAPTER_CAP_RUNTIME_XYZ and associate
each parameter(the one we think, it is not common for all adapters)
2) Add some reserved fields in rte_event_eth_rx_adapter_runtime_params
so that we don't break ABI in future
3) Add rte_event_eth_rx_adapter_runtime_params_init() function just
make structure fill with default to avoid ABI break
4) Add rte_event_eth_rx_adapter_runtime_params_info_get(). Lets
capability flags and other items can be return via this
5) Change rte_event_eth_rx_adapter_set_params as
rte_event_eth_rx_adapter_runtime_set() or
rte_event_eth_rx_adapter_runtime_params_set() to make it runtime
explicit
6) Change rte_event_eth_rx_adapter_get_params as
rte_event_eth_rx_adapter_runtime_get() or
rte_event_eth_rx_adapter_runtime_params_get() to make it runtime
explicit
^ permalink raw reply [relevance 4%]
* RE: [RFC] Fix cryptodev socket id for devices on unknown NUMA node
2023-01-17 10:16 3% [RFC] Fix cryptodev socket id for devices on unknown NUMA node Didier Pallard
@ 2023-01-17 11:32 0% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2023-01-17 11:32 UTC (permalink / raw)
To: Didier Pallard, Akhil Goyal, Fan Zhang, Olivier Matz, thomas; +Cc: dev
> From: Didier Pallard [mailto:didier.pallard@6wind.com]
> Sent: Tuesday, 17 January 2023 11.17
>
> Since DPDK 22.11 and below commit:
> https://git.dpdk.org/dpdk/commit/?id=7dcd73e37965ba0bfa430efeac362fe183
> ed0ae2
> rte_cryptodev_socket_id() could return an incorrect value of 255.
> Problem has been seen during configuration of the qat device
> on an Atom C3000 architecture. On this arch, PCI is not depending on
> any numa socket, causing device numa_node to be equal to SOCKET_ID_ANY.
Disclaimer: I'm not up to speed with this topic or patch, so feel free to ignore my comments here! I'm only speaking up because I fear we are increasing the risk of bugs here. But again, please bear with me, if I have totally misunderstood this!
I was under the impression that single-socket systems used socket_id 0 as default. How can the PCI bus (or QAT device) not depend on any socket? It must be connected somewhere.
Doesn't assigning socket_id = -1 for devices (QAT or anything else) introduce a big risk of bugs, e.g. in comparisons? The special socket_id value -1 should have only two meanings: 1) return value "error", or 2) input value "any". Now it also can mean 3) "unknown"? How do comparison functions work for that... is "any" == "unknown"? And does searching for "0" match "unknown"? It might, or might not, but searching for "any" does match "0". And how about searching for "unknown", if such a value is propagate around in the system.
And if we started considering socket_id == -1 valid with that patch, should the return type of rte_socket_id(void) be signed instead of unsigned?
> Due to incorrect cast to uint8_t, this value is stored as 255
> in cryptodev structure and returned as such by
> rte_cryptodev_socket_id()
> function.
>
> Below patch proposes one way to fix the issue: casting to a signed
> int8_t
> instead of the uint8_t. (it could also be casted to an int, that is the
> usual type for numa_node, but this may break the ABI). This makes the
> SOCKET_ID_ANY being propagated up to the user.
> Another solution could be to always store a valid numa_node in this
> field
> instead of just copying the numa_node field of the device, but this
> requires to fix most crypto PMDs, that are currently just copying the
> device value.
>
> What is the preferred solution?
I prefer that garbage data is not propagated, even if it requires fixing many places.
But as I indicated above, I wonder if part of the root cause stems from considering socket_id == -1 valid data in some structures. (It could be allowed temporarily, e.g. in a template to indicate that the field is uninitialized. But it should not propagate outside the templates when instantiating objects based on the templates.)
>
> ---
> cryptodev: fix numa_node type
>
> Since below commit, numa_node can be set to SOCKET_ID_ANY.
> Do not cast numa_node to an unsigned uint8, else SOCKET_ID_ANY
> is converted to 255, causing rte_cryptodev_socket_id to return
> an incorrect value.
>
> Fixes: 7dcd73e37965 ("drivers/bus: set device NUMA node to unknown by
> default")
> Signed-off-by: Didier Pallard <didier.pallard@6wind.com>
> ---
> lib/cryptodev/cryptodev_pmd.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/cryptodev/cryptodev_pmd.h
> b/lib/cryptodev/cryptodev_pmd.h
> index 0020102eb7db..db4745d620f4 100644
> --- a/lib/cryptodev/cryptodev_pmd.h
> +++ b/lib/cryptodev/cryptodev_pmd.h
> @@ -64,8 +64,8 @@ struct rte_cryptodev_pmd_init_params {
> struct rte_cryptodev_data {
> /** Device ID for this instance */
> uint8_t dev_id;
> - /** Socket ID where memory is allocated */
> - uint8_t socket_id;
> + /** Socket ID of the device */
> + int8_t socket_id;
> /** Unique identifier name */
> char name[RTE_CRYPTODEV_NAME_MAX_LEN];
>
> --
> 2.30.2
>
^ permalink raw reply [relevance 0%]
* [RFC] Fix cryptodev socket id for devices on unknown NUMA node
@ 2023-01-17 10:16 3% Didier Pallard
2023-01-17 11:32 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Didier Pallard @ 2023-01-17 10:16 UTC (permalink / raw)
To: Akhil Goyal, Fan Zhang, Olivier Matz; +Cc: dev
Since DPDK 22.11 and below commit:
https://git.dpdk.org/dpdk/commit/?id=7dcd73e37965ba0bfa430efeac362fe183ed0ae2
rte_cryptodev_socket_id() could return an incorrect value of 255.
Problem has been seen during configuration of the qat device
on an Atom C3000 architecture. On this arch, PCI is not depending on
any numa socket, causing device numa_node to be equal to SOCKET_ID_ANY.
Due to incorrect cast to uint8_t, this value is stored as 255
in cryptodev structure and returned as such by rte_cryptodev_socket_id()
function.
Below patch proposes one way to fix the issue: casting to a signed int8_t
instead of the uint8_t. (it could also be casted to an int, that is the
usual type for numa_node, but this may break the ABI). This makes the
SOCKET_ID_ANY being propagated up to the user.
Another solution could be to always store a valid numa_node in this field
instead of just copying the numa_node field of the device, but this
requires to fix most crypto PMDs, that are currently just copying the
device value.
What is the preferred solution?
---
cryptodev: fix numa_node type
Since below commit, numa_node can be set to SOCKET_ID_ANY.
Do not cast numa_node to an unsigned uint8, else SOCKET_ID_ANY
is converted to 255, causing rte_cryptodev_socket_id to return
an incorrect value.
Fixes: 7dcd73e37965 ("drivers/bus: set device NUMA node to unknown by default")
Signed-off-by: Didier Pallard <didier.pallard@6wind.com>
---
lib/cryptodev/cryptodev_pmd.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/cryptodev/cryptodev_pmd.h b/lib/cryptodev/cryptodev_pmd.h
index 0020102eb7db..db4745d620f4 100644
--- a/lib/cryptodev/cryptodev_pmd.h
+++ b/lib/cryptodev/cryptodev_pmd.h
@@ -64,8 +64,8 @@ struct rte_cryptodev_pmd_init_params {
struct rte_cryptodev_data {
/** Device ID for this instance */
uint8_t dev_id;
- /** Socket ID where memory is allocated */
- uint8_t socket_id;
+ /** Socket ID of the device */
+ int8_t socket_id;
/** Unique identifier name */
char name[RTE_CRYPTODEV_NAME_MAX_LEN];
--
2.30.2
^ permalink raw reply [relevance 3%]
* [PATCH v2 6/6] test/dmadev: add tests for stopping and restarting dev
@ 2023-01-16 17:37 3% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-16 17:37 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Chengwen Feng, Kevin Laatz
Validate device operation when a device is stopped or restarted.
The only complication - and gap in the dmadev ABI specification - is
what happens to the job ids on restart. Some drivers reset them to 0,
while others continue where things left off. Take account of both
possibilities in the test case.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test/test_dmadev.c | 46 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/app/test/test_dmadev.c b/app/test/test_dmadev.c
index de787c14e2..8fb73a41e2 100644
--- a/app/test/test_dmadev.c
+++ b/app/test/test_dmadev.c
@@ -304,6 +304,48 @@ test_enqueue_copies(int16_t dev_id, uint16_t vchan)
|| do_multi_copies(dev_id, vchan, 0, 0, 1);
}
+static int
+test_stop_start(int16_t dev_id, uint16_t vchan)
+{
+ /* device is already started on input, should be (re)started on output */
+
+ uint16_t id = 0;
+ enum rte_dma_status_code status = RTE_DMA_STATUS_SUCCESSFUL;
+
+ /* - test stopping a device works ok,
+ * - then do a start-stop without doing a copy
+ * - finally restart the device
+ * checking for errors at each stage, and validating we can still copy at the end.
+ */
+ if (rte_dma_stop(dev_id) < 0)
+ ERR_RETURN("Error stopping device\n");
+
+ if (rte_dma_start(dev_id) < 0)
+ ERR_RETURN("Error restarting device\n");
+ if (rte_dma_stop(dev_id) < 0)
+ ERR_RETURN("Error stopping device after restart (no jobs executed)\n");
+
+ if (rte_dma_start(dev_id) < 0)
+ ERR_RETURN("Error restarting device after multiple stop-starts\n");
+
+ /* before doing a copy, we need to know what the next id will be it should
+ * either be:
+ * - the last completed job before start if driver does not reset id on stop
+ * - or -1 i.e. next job is 0, if driver does reset the job ids on stop
+ */
+ if (rte_dma_completed_status(dev_id, vchan, 1, &id, &status) != 0)
+ ERR_RETURN("Error with rte_dma_completed_status when no job done\n");
+ id += 1; /* id_count is next job id */
+ if (id != id_count && id != 0)
+ ERR_RETURN("Unexpected next id from device after stop-start. Got %u, expected %u or 0\n",
+ id, id_count);
+
+ id_count = id;
+ if (test_single_copy(dev_id, vchan) < 0)
+ ERR_RETURN("Error performing copy after device restart\n");
+ return 0;
+}
+
/* Failure handling test cases - global macros and variables for those tests*/
#define COMP_BURST_SZ 16
#define OPT_FENCE(idx) ((fence && idx == 8) ? RTE_DMA_OP_FLAG_FENCE : 0)
@@ -819,6 +861,10 @@ test_dmadev_instance(int16_t dev_id)
if (runtest("copy", test_enqueue_copies, 640, dev_id, vchan, CHECK_ERRS) < 0)
goto err;
+ /* run tests stopping/starting devices and check jobs still work after restart */
+ if (runtest("stop-start", test_stop_start, 1, dev_id, vchan, CHECK_ERRS) < 0)
+ goto err;
+
/* run some burst capacity tests */
if (rte_dma_burst_capacity(dev_id, vchan) < 64)
printf("DMA Dev %u: insufficient burst capacity (64 required), skipping tests\n",
--
2.37.2
^ permalink raw reply [relevance 3%]
* [PATCH 5/5] test/dmadev: add tests for stopping and restarting dev
@ 2023-01-16 15:37 3% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-16 15:37 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Chengwen Feng, Kevin Laatz
Validate device operation when a device is stopped or restarted.
The only complication - and gap in the dmadev ABI specification - is
what happens to the job ids on restart. Some drivers reset them to 0,
while others continue where things left off. Take account of both
posibilities in the test case.
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
app/test/test_dmadev.c | 46 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/app/test/test_dmadev.c b/app/test/test_dmadev.c
index de787c14e2..8fb73a41e2 100644
--- a/app/test/test_dmadev.c
+++ b/app/test/test_dmadev.c
@@ -304,6 +304,48 @@ test_enqueue_copies(int16_t dev_id, uint16_t vchan)
|| do_multi_copies(dev_id, vchan, 0, 0, 1);
}
+static int
+test_stop_start(int16_t dev_id, uint16_t vchan)
+{
+ /* device is already started on input, should be (re)started on output */
+
+ uint16_t id = 0;
+ enum rte_dma_status_code status = RTE_DMA_STATUS_SUCCESSFUL;
+
+ /* - test stopping a device works ok,
+ * - then do a start-stop without doing a copy
+ * - finally restart the device
+ * checking for errors at each stage, and validating we can still copy at the end.
+ */
+ if (rte_dma_stop(dev_id) < 0)
+ ERR_RETURN("Error stopping device\n");
+
+ if (rte_dma_start(dev_id) < 0)
+ ERR_RETURN("Error restarting device\n");
+ if (rte_dma_stop(dev_id) < 0)
+ ERR_RETURN("Error stopping device after restart (no jobs executed)\n");
+
+ if (rte_dma_start(dev_id) < 0)
+ ERR_RETURN("Error restarting device after multiple stop-starts\n");
+
+ /* before doing a copy, we need to know what the next id will be it should
+ * either be:
+ * - the last completed job before start if driver does not reset id on stop
+ * - or -1 i.e. next job is 0, if driver does reset the job ids on stop
+ */
+ if (rte_dma_completed_status(dev_id, vchan, 1, &id, &status) != 0)
+ ERR_RETURN("Error with rte_dma_completed_status when no job done\n");
+ id += 1; /* id_count is next job id */
+ if (id != id_count && id != 0)
+ ERR_RETURN("Unexpected next id from device after stop-start. Got %u, expected %u or 0\n",
+ id, id_count);
+
+ id_count = id;
+ if (test_single_copy(dev_id, vchan) < 0)
+ ERR_RETURN("Error performing copy after device restart\n");
+ return 0;
+}
+
/* Failure handling test cases - global macros and variables for those tests*/
#define COMP_BURST_SZ 16
#define OPT_FENCE(idx) ((fence && idx == 8) ? RTE_DMA_OP_FLAG_FENCE : 0)
@@ -819,6 +861,10 @@ test_dmadev_instance(int16_t dev_id)
if (runtest("copy", test_enqueue_copies, 640, dev_id, vchan, CHECK_ERRS) < 0)
goto err;
+ /* run tests stopping/starting devices and check jobs still work after restart */
+ if (runtest("stop-start", test_stop_start, 1, dev_id, vchan, CHECK_ERRS) < 0)
+ goto err;
+
/* run some burst capacity tests */
if (rte_dma_burst_capacity(dev_id, vchan) < 64)
printf("DMA Dev %u: insufficient burst capacity (64 required), skipping tests\n",
--
2.37.2
^ permalink raw reply [relevance 3%]
* Re: [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API
2022-12-19 7:06 3% ` [PATCH V8 " Huisong Li
@ 2023-01-16 12:06 0% ` lihuisong (C)
2023-01-30 10:39 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-01-16 12:06 UTC (permalink / raw)
To: dev, Ferruh Yigit, Andrew Rybchenko
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen
Hi Ferruh and Andrew,
This patch series optimizes some codes and bug.
Can you take a look at this patch series?
If there are no other questions, can it be merged?
Best,
Huisong
在 2022/12/19 15:06, Huisong Li 写道:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation. This patch series uses 'u64' functions to
> do this.
>
> In addition, this patch series introduces two APIs to store unsigned
> integer values as hexadecimal encoded strings in telemetry library.
>
> ---
> -v8: fix the coding style in patch 7/8
> -v7: replace sprintf with snprintf in patch 6/8
> -v6: fix code alignment to keep in line with codes in the file
> -v5:
> - drop a refactor patch.
> - no limit the bit width for xxx_uint_hex API.
> -v4:
> - remove 'u32' value type.merg
> - add padding zero for hexadecimal value
> -v3: fix a misspelling mistake in commit log.
> -v2:
> - fix ABI break warning.
> - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings.
>
> Huisong Li (8):
> telemetry: move to header to controllable range
> ethdev: fix possible data truncation and conversion error
> mempool: fix possible data truncation and conversion error
> cryptodev: fix possible data conversion error
> mem: possible data truncation and conversion error
> telemetry: support adding integer value as hexadecimal
> test: add test cases for adding hex integer value API
> ethdev: display capability values in hexadecimal format
>
> app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
> lib/cryptodev/rte_cryptodev.c | 2 +-
> lib/eal/common/eal_common_memory.c | 10 +-
> lib/ethdev/rte_ethdev.c | 19 ++--
> lib/mempool/rte_mempool.c | 24 ++---
> lib/telemetry/rte_telemetry.h | 52 +++++++++-
> lib/telemetry/telemetry_data.c | 73 ++++++++++++++
> lib/telemetry/version.map | 9 ++
> 8 files changed, 309 insertions(+), 30 deletions(-)
>
^ permalink raw reply [relevance 0%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-26 16:44 4% ` Ori Kam
@ 2023-01-15 22:46 0% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-15 22:46 UTC (permalink / raw)
To: Rongwei Liu, Jerin Jacob, Ori Kam
Cc: dev, Matan Azrad, Slava Ovsiienko, Ferruh Yigit,
Andrew Rybchenko, dev, Raslan Darawsheh, maxime.coquelin
26/12/2022 17:44, Ori Kam:
> From: Rongwei Liu <rongweil@nvidia.com>
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu wrote:
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu wrote:
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu wrote:
> > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu wrote:
> > > > > > > > > >
> > > > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > > > versions
> > > > > > > > >
> > > > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > > > support
> > > > > this?
> > > > > > > > >
> > > > > > > > There is a new member which was introduced into
> > > > > > > > rte_eth_dev_info but it
> > > > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > > > >
> > > > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > > > different ethdev structure and rte_flow structures across
> > > > > > > different DPDK
> > > > > ABI versions.
> > > > > > >
> > > > > > Besides this, there is no other ABI changes dependency.
> > > > > >
> > > > > > Assume there is a DPDK process A running with version v21.11 and
> > > > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > > > >
> > > > > OK. That's a relief. I understand the use case now.
> > > > >
> > > > > Why not simply use standard DPDK multiprocess model then.
> > > > > Primary process act as server for slow path API. Secondary process
> > > > > can come and go(aka can be updated at runtime) and use as client to
> > > > > update rules via primary-secondray communication mechanism.
> > > > >
> > > > Just image if process A and process B have ABI breakage like different
> > > rte_flow_item_*** and rte_flow_action_*** size and members.
> > > > How can we quickly accommodate primary/secondary to be ABI
> > compatible
> > > across different versions?
> > > > It will be very huge effort and difficult to implement, at least in my
> > opinion.
> > > > What do you think?
> > >
> > > Yes. it difficult what ever approach we take, On other hand, ethdev
> > subsystem
> > > has other components like rte_tm and other offload etc, We can not simply
> > > have rte_eth_process_set_active() and things magical works across
> > different
> > > DPDK versions. Example, if rte_flow rule has meter action will depend on
> > > another HW piece in NIC card for doing the metering but set by flow API.
> > > IMO, Customer can simply use standard multiprocess model if version are
> > > compatible without any special intelligence in application.
> > > Otherwise they can reload and start the application again or have special
> > > intelligence in application to cater the specific area of API they need to
> > > leverage based on server and client DPDK versions.
> >
> > Thanks for the message.
> > IMO, we are trying to eliminate the version/ABI dependency with this new
> > added API.
> > For example, if meter action is in the flow rules:
> > 1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
> > 2. Process B starts with "rte_eth_process_set_active(false, flags)"
> >
> > Just give Nvidia' hardware as example (other NIC vendors may not care if
> > group 0 or not)
> > If the process A' rules are in group 0, users should set them one by one to
> > process B.
> > Then either flush process A' rules or quit process A, then process B calls with
> > "rte_eth_process_set_active(true, flags)"
> > All is set.
> > It will avoid complex operations with client/server model and avoid user mis-
> > operation too.
> > We should avoid reload as much as possible since reloading is very time
> > consuming and may take up to few seconds.
> > In this time slot, there is no application to handle the traffic, and everything is
> > lost.
> > For end user especially cloud service providers, they are sensitive to the
> > traffic down time.
>
> From my viewpoint the upgrade has nothing to do with DPDK as a library,
> the upgrade may be because of application upgrade.
> Unless I'm missing something, this API is not meant for API/ABI it is created
> to allow minimum downtime when doing upgrade of the application.
> Unless I'm missing something critical, since the upgrade in any case is not
> only for the DPDK but the entire app, there isn't any ABI/API issue.
Yes we can consider the case of an application upgrade with the same DPDK.
The patch needs to be reworded in this more realistic direction I think.
We can also improve the usage explanations.
That said, another high level question is about the scope of the feature.
In this patch, only ethdev is targetted.
Do you think we need the same migration mechanism in other classes
like vDPA, crypto, etc?
^ permalink raw reply [relevance 0%]
* Re: [RFC] Remove Kernel Network Interface (KNI)
@ 2023-01-14 22:21 3% ` Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2023-01-14 22:21 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Monjalon, dev, Cristian Dumitrescu, Bruce Richardson,
Anatoly Burakov
On Fri, Jan 13, 2023 at 03:25:30PM -0800, Stephen Hemminger wrote:
> On Fri, 13 Jan 2023 19:34:24 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 13/01/2023 18:13, Stephen Hemminger:
> > > On Fri, 13 Jan 2023 09:12:16 +0100
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > > 13/01/2023 06:03, Stephen Hemminger:
> > > > > The Linux special network driver for kernel networking has been
> > > > > a long term problem for DPDK. The performance benefits of KNI
> > > > > are available via virtio-user and XDP, and the simpler kernel
> > > > > interface via TAP is also available.
> > > > >
> > > > > This driver has required lots of effort to keep up with the
> > > > > kernel API changes. And the overall architecture of the driver
> > > > > is fundamentally insecure and has unfixable locking and data
> > > > > race problems. No developer has been willing to do extensive
> > > > > tests or be the maintainer.
> > > > >
> > > > > In short, the time has come to do some early spring cleaning
> > > > > and remove KNI from DPDK 23.03.
> > > >
> > > > In doc/guides/rel_notes/deprecation.rst it is announced
> > > > to be removed in 23.11. Let's keep this RFC for later :)
> > > >
> > > >
> > >
> > > For 23.03 could we add a deprecation log message when library is
> > > used and when kernel module is loaded.
> >
> > We already have a message in the lib:
> >
> > int
> > rte_kni_init(unsigned int max_kni_ifaces __rte_unused)
> > {
> > RTE_LOG(WARNING, KNI, "WARNING: KNI is deprecated and will be removed in DPDK 23.11\n");
> >
> > It is a good idea to add a message in the kernel module loading.
> >
> >
> >
> >
>
> No matter how much we tell users, guarantee someone will still miss it and complain :-)
one of the techniques we use is to remove the headers in advance of
removing the ABI. the warning becomes a lot more clear when you can't
compile anymore but your existing binaries continue to run.
^ permalink raw reply [relevance 3%]
* RE: [PATCH v3 0/9] Standardize telemetry int types
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
@ 2023-01-13 16:39 0% ` Power, Ciara
2 siblings, 0 replies; 200+ results
From: Power, Ciara @ 2023-01-13 16:39 UTC (permalink / raw)
To: Richardson, Bruce, dev; +Cc: Richardson, Bruce
Hi Bruce,
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson@intel.com>
> Sent: Thursday 12 January 2023 17:41
> To: dev@dpdk.org
> Cc: Richardson, Bruce <bruce.richardson@intel.com>
> Subject: [PATCH v3 0/9] Standardize telemetry int types
>
> Rather than having 64-bit unsigned types and 32-bit signed types supported
> by the telemetry lib, we should support 64-bit values for both types. On the
> naming side, since both are 64-bit, we should no longer call the unsigned
> value u64 - "uint" is better.
>
> This patchset implements these changes as far as is possible while still
> keeping API and ABI compatibility.
>
> * Internal structures and functions are updated to use 64-bit ints
> * Internal functions are renamed from u64 to uint
> * Public enum values are renamed from u64 to uint, and a macro is
> added to ensure that older code still compiles
> * The public add_*_int functions are changed to take a 64-bit value
> rather than a 32-bit one. Since this would be an ABI break, we
> use function versioning to ensure older code still calls into
> a wrapper function which takes a 32-bit value.
>
> The patchset also contains a couple of other small cleanups to the telemetry
> code that were seen in passing when making these changes - removing RTE_
> prefix on internal enums, and simplifying the init of the the array of data
> types.
>
> NOTE: the renaming of the u64 functions to uint is split across 3 patches in
> this set - patches 4,5 and 6. This is to make it easier to review and to avoid
> warnings about new functions not being marked initially as experimental.
> Some/all of these 3 can be combined on merge if so desired.
>
> V3:
> - fix build issues due to missing a driver code change
> - fix spelling issue flagged by checkpatch
>
> V2:
> - added additional patches to replace the old function calls within DPDK
> code, something missed in RFC version
> - added new patch to make the renamed/new functions immediately public
> allowing us to mark the original named versions as deprecated
> - re-ordered patches within the sit, so the extra cleanup changes come
> first
>
> Bruce Richardson (9):
> telemetry: remove RTE prefix from internal enum values
> telemetry: make array initialization more robust
> telemetry: rename unsigned 64-bit enum value to uint
> telemetry: add uint type as alias for u64
> global: rename telemetry functions to newer versions
> telemetry: mark old names of renamed fns as deprecated
> telemetry: update json functions to use int/uint in names
> telemetry: make internal int representation 64-bits
> telemetry: change public API to use 64-bit signed values
>
> app/test/test_telemetry_data.c | 22 ++---
> app/test/test_telemetry_json.c | 9 +-
> doc/guides/rel_notes/deprecation.rst | 5 ++
> drivers/common/cnxk/roc_platform.h | 4 +-
> drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 24 ++---
> drivers/net/cnxk/cnxk_ethdev_telemetry.c | 6 +-
> examples/ipsec-secgw/ipsec-secgw.c | 72 +++++++--------
> examples/l3fwd-power/main.c | 4 +-
> lib/cryptodev/rte_cryptodev.c | 6 +-
> lib/dmadev/rte_dmadev.c | 2 +-
> lib/eal/common/eal_common_memory.c | 19 ++--
> lib/ethdev/rte_ethdev.c | 12 +--
> lib/ethdev/sff_telemetry.c | 2 +-
> lib/eventdev/rte_event_eth_rx_adapter.c | 22 ++---
> lib/eventdev/rte_event_timer_adapter.c | 38 ++++----
> lib/eventdev/rte_eventdev.c | 5 +-
> lib/ipsec/ipsec_telemetry.c | 33 +++----
> lib/rawdev/rte_rawdev.c | 4 +-
> lib/security/rte_security.c | 8 +-
> lib/telemetry/meson.build | 1 +
> lib/telemetry/rte_telemetry.h | 51 +++++++++--
> lib/telemetry/telemetry.c | 56 ++++++------
> lib/telemetry/telemetry_data.c | 95 ++++++++++++++------
> lib/telemetry/telemetry_data.h | 24 +++--
> lib/telemetry/telemetry_json.h | 16 ++--
> lib/telemetry/version.map | 9 ++
> 26 files changed, 325 insertions(+), 224 deletions(-)
>
> --
> 2.37.2
Series-Acked-by: Ciara Power <ciara.power@intel.com>
^ permalink raw reply [relevance 0%]
* Re: trace point symbols
@ 2023-01-13 11:22 3% ` Jerin Jacob
0 siblings, 0 replies; 200+ results
From: Jerin Jacob @ 2023-01-13 11:22 UTC (permalink / raw)
To: Morten Brørup
Cc: Thomas Monjalon, Ferruh Yigit, jerinj, bruce.richardson, dev,
Ankur Dwivedi, orika, ferruh.yigit, chas3, humin29, linville,
ciara.loftus, qi.z.zhang, mw, mk, shaibran, evgenys, igorch,
chandu, irusskikh, shepard.siegel, ed.czeck, john.miller,
ajit.khaparde, somnath.kotur, mczekaj, sthotton, srinivasan,
hkalra, rahul.lakkireddy, johndale, hyonkim, liudongdong3,
yisen.zhuang, xuanziyang2, cloud.wangxiaoyun, zhouguoyang,
simei.su, wenjun1.wu, qiming.yang, Yuying.Zhang, beilei.xing,
xiao.w.wang, jingjing.wu, junfeng.guo, rosen.xu, ndabilpuram,
kirankumark, skori, skoteshwar, lironh, zr, radhac, vburru,
sedara, matan, viacheslavo, sthemmin, longli, spinler,
chaoyong.he, niklas.soderlund, hemant.agrawal, sachin.saxena,
g.singh, apeksha.gupta, sachin.saxena, aboyer, rmody, shshaikh,
dsinghrawat, andrew.rybchenko, jiawenwu, jianwang, jbehrens,
maxime.coquelin, chenbo.xia, steven.webster, matt.peters,
mtetsuyah, grive, jasvinder.singh, cristian.dumitrescu, jgrajcia,
david.marchand
On Thu, Jan 12, 2023 at 3:13 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > From: Thomas Monjalon [mailto:thomas@monjalon.net]
> > Sent: Thursday, 12 January 2023 10.11
> >
> >
> > I would like to see a policy regarding trace symbols.
> > If we decide option 1 is not so useful,
> > then we should not export trace symbols at all and document this
> > policy.
> > Also there are some trace symbols which could be cleaned up.
I can send a patch to remove existing exposed symbols for option 1 in
DPDK repo. But, Is n't an ABI break? The only downside, I can think
of, is that a few more entries in version.map file.
I don't have a strong option one way, either. Let me know what you think?
If we decided to remove then, In
https://doc.dpdk.org/guides/prog_guide/trace_lib.html, There is NOTE
section as following, I can remove that as well.
--
The RTE_TRACE_POINT_REGISTER defines the placeholder for the
rte_trace_point_t tracepoint object. The user must export a
__<trace_function_name> symbol in the library .map file for this
tracepoint to be used out of the library, in shared builds. For
example, __app_trace_string will be the exported symbol in the above
example.
---
>
> +1 for not exposing trace point symbols at all.
>
> The trace point symbols are only used internally by DPDK, so they should not be part of DPDK's public API.
>
> It might also make it easier for Bruce to move the trace library out of EAL.
>
> I'm not familiar with the CTF format, but I assume that if we don't expose the trace point symbols, the trace points can still be identified when parsing the trace file.
Yes. It won't impact. The only use case for option 1 is to avoid named lookup.
>
^ permalink raw reply [relevance 3%]
* [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
@ 2023-01-12 17:41 3% ` Bruce Richardson
2023-01-13 16:39 0% ` [PATCH v3 0/9] Standardize telemetry int types Power, Ciara
2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 17:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power
While the unsigned values added to telemetry dicts/arrays were up to
64-bits in size, the sized values were only up to 32-bits. We can
standardize the API by having both int and uint functions take 64-bit
values. For ABI compatibility, we use function versioning to ensure
older binaries can still use the older functions taking a 32-bit
parameter.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 4 ++--
lib/telemetry/telemetry_data.c | 33 +++++++++++++++++++++++++++++----
lib/telemetry/telemetry_data.h | 6 ++++++
lib/telemetry/version.map | 7 +++++++
5 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/lib/telemetry/meson.build b/lib/telemetry/meson.build
index f84c9aa3be..73750d9ef4 100644
--- a/lib/telemetry/meson.build
+++ b/lib/telemetry/meson.build
@@ -6,3 +6,4 @@ includes = [global_inc]
sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
headers = files('rte_telemetry.h')
includes += include_directories('../metrics')
+use_function_versioning = true
diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 4598303d5d..b481c112dd 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -120,7 +120,7 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
* 0 on success, negative errno on error
*/
int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x);
/**
* Add an unsigned value to an array.
@@ -208,7 +208,7 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
* 0 on success, negative errno on error, E2BIG on string truncation of name.
*/
int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val);
/**
* Add an unsigned value to a dictionary.
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 9a180937fd..ac7be795df 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -8,6 +8,7 @@
#undef RTE_USE_LIBBSD
#include <stdbool.h>
+#include <rte_function_versioning.h>
#include <rte_string_fns.h>
#include "telemetry_data.h"
@@ -58,8 +59,8 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
-int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
+int __vsym
+rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t x)
{
if (d->type != TEL_ARRAY_INT)
return -EINVAL;
@@ -69,6 +70,18 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
return 0;
}
+int __vsym
+rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int x)
+{
+ return rte_tel_data_add_array_int_v24(d, x);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
+ int64_t x), rte_tel_data_add_array_int_v24);
+
int
rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
{
@@ -146,8 +159,8 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
return 0;
}
-int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
+int __vsym
+rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val)
{
struct tel_dict_entry *e = &d->data.dict[d->data_len];
if (d->type != TEL_DICT)
@@ -165,6 +178,18 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
+int __vsym
+rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val)
+{
+ return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
+ const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+
int
rte_tel_data_add_dict_uint(struct rte_tel_data *d,
const char *name, uint64_t val)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 205509c5a2..53e4cabea5 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -49,4 +49,10 @@ struct rte_tel_data {
} data; /* data container */
};
+/* versioned functions */
+int rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int val);
+int rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t val);
+int rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val);
+int rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val);
+
#endif
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index d661180317..accfad5011 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -21,6 +21,13 @@ DPDK_23 {
local: *;
};
+DPDK_24 {
+ global:
+
+ rte_tel_data_add_array_int;
+ rte_tel_data_add_dict_int;
+} DPDK_23;
+
INTERNAL {
rte_telemetry_legacy_register;
rte_telemetry_init;
--
2.37.2
^ permalink raw reply [relevance 3%]
* [PATCH v3 8/9] telemetry: make internal int representation 64-bits
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
@ 2023-01-12 17:41 3% ` Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-13 16:39 0% ` [PATCH v3 0/9] Standardize telemetry int types Power, Ciara
2 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 17:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power
The internal storage for int values can be expanded from 32-bit to
64-bit without affecting the external ABI.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
lib/telemetry/telemetry_data.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 8db6875a81..205509c5a2 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -28,7 +28,7 @@ struct container {
*/
union tel_value {
char sval[RTE_TEL_MAX_STRING_LEN];
- int ival;
+ int64_t ival;
uint64_t uval;
struct container container;
};
--
2.37.2
^ permalink raw reply [relevance 3%]
* [PATCH v3 0/9] Standardize telemetry int types
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
` (3 preceding siblings ...)
2023-01-12 10:58 4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
@ 2023-01-12 17:41 4% ` Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
` (2 more replies)
4 siblings, 3 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 17:41 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
Rather than having 64-bit unsigned types and 32-bit signed types
supported by the telemetry lib, we should support 64-bit values
for both types. On the naming side, since both are 64-bit, we
should no longer call the unsigned value u64 - "uint" is better.
This patchset implements these changes as far as is possible while
still keeping API and ABI compatibility.
* Internal structures and functions are updated to use 64-bit ints
* Internal functions are renamed from u64 to uint
* Public enum values are renamed from u64 to uint, and a macro is
added to ensure that older code still compiles
* The public add_*_int functions are changed to take a 64-bit value
rather than a 32-bit one. Since this would be an ABI break, we
use function versioning to ensure older code still calls into
a wrapper function which takes a 32-bit value.
The patchset also contains a couple of other small cleanups to the
telemetry code that were seen in passing when making these changes -
removing RTE_ prefix on internal enums, and simplifying the init of the
the array of data types.
NOTE: the renaming of the u64 functions to uint is split across 3
patches in this set - patches 4,5 and 6. This is to make it easier to
review and to avoid warnings about new functions not being marked
initially as experimental. Some/all of these 3 can be combined on merge
if so desired.
V3:
- fix build issues due to missing a driver code change
- fix spelling issue flagged by checkpatch
V2:
- added additional patches to replace the old function calls within DPDK
code, something missed in RFC version
- added new patch to make the renamed/new functions immediately public
allowing us to mark the original named versions as deprecated
- re-ordered patches within the sit, so the extra cleanup changes come
first
Bruce Richardson (9):
telemetry: remove RTE prefix from internal enum values
telemetry: make array initialization more robust
telemetry: rename unsigned 64-bit enum value to uint
telemetry: add uint type as alias for u64
global: rename telemetry functions to newer versions
telemetry: mark old names of renamed fns as deprecated
telemetry: update json functions to use int/uint in names
telemetry: make internal int representation 64-bits
telemetry: change public API to use 64-bit signed values
app/test/test_telemetry_data.c | 22 ++---
app/test/test_telemetry_json.c | 9 +-
doc/guides/rel_notes/deprecation.rst | 5 ++
drivers/common/cnxk/roc_platform.h | 4 +-
drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 24 ++---
drivers/net/cnxk/cnxk_ethdev_telemetry.c | 6 +-
examples/ipsec-secgw/ipsec-secgw.c | 72 +++++++--------
examples/l3fwd-power/main.c | 4 +-
lib/cryptodev/rte_cryptodev.c | 6 +-
lib/dmadev/rte_dmadev.c | 2 +-
lib/eal/common/eal_common_memory.c | 19 ++--
lib/ethdev/rte_ethdev.c | 12 +--
lib/ethdev/sff_telemetry.c | 2 +-
lib/eventdev/rte_event_eth_rx_adapter.c | 22 ++---
lib/eventdev/rte_event_timer_adapter.c | 38 ++++----
lib/eventdev/rte_eventdev.c | 5 +-
lib/ipsec/ipsec_telemetry.c | 33 +++----
lib/rawdev/rte_rawdev.c | 4 +-
lib/security/rte_security.c | 8 +-
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 51 +++++++++--
lib/telemetry/telemetry.c | 56 ++++++------
lib/telemetry/telemetry_data.c | 95 ++++++++++++++------
lib/telemetry/telemetry_data.h | 24 +++--
lib/telemetry/telemetry_json.h | 16 ++--
lib/telemetry/version.map | 9 ++
26 files changed, 325 insertions(+), 224 deletions(-)
--
2.37.2
^ permalink raw reply [relevance 4%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-12 10:53 4% ` David Marchand
@ 2023-01-12 14:14 4% ` Ferruh Yigit
2023-01-18 10:45 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-12 14:14 UTC (permalink / raw)
To: David Marchand, Thomas Monjalon; +Cc: dev, bruce.richardson
On 1/12/2023 10:53 AM, David Marchand wrote:
> On Wed, Jan 11, 2023 at 8:53 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>>
>> Generation and comparison of ABI dumps are done on multiple cores
>> thanks to xargs -P0.
>> It can accelerate this long step by 5 in my tests.
>>
>> xargs reports a global error if one of the process has an error.
>>
>> Running a shell function with xargs requires to export it.
>> POSIX shell does not support function export except using an "eval trick".
>> Required variables are also exported.
>>
>> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
>> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
>> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
>> index c583eae2fd..31eceb42e6 100755
>> --- a/devtools/check-abi.sh
>> +++ b/devtools/check-abi.sh
>> @@ -34,20 +34,18 @@ else
>> ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
>> fi
>>
>> -error=
>> -for dump in $(find $refdir -name "*.dump"); do
>> +export newdir ABIDIFF_OPTIONS
>> +export diff_func='run_diff() {
>> + dump=$1
>> name=$(basename $dump)
>> dump2=$(find $newdir -name $name)
>> if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
>> echo "Error: cannot find $name in $newdir" >&2
>> - error=1
>> - continue
>> - fi
>> + return 1
>> + fi;
>
> No need for ; here.
> This can be fixed when applying (I tested both your patch and with
> this small fix).
>
>
>> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
>> abiret=$?
>> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
>> - error=1
>> - echo
>> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
>> if [ $(($abiret & 3)) -ne 0 ]; then
>> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
>> fi
>> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
>> if [ $(($abiret & 8)) -ne 0 ]; then
>> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
>> fi
>> - echo
>> + return 1
>> }
>> -done
>> +}'
>> +
>> +error=
>> +find $refdir -name "*.dump" |
>> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
>> +error=1
>>
>> [ -z "$error" ] || [ -n "$warnonly" ]
>
> For the record, on my system, calling this script is ~5 times faster:
> - before
> real 0m5,447s
> user 0m4,497s
> sys 0m0,937s
>
> - after
> real 0m1,202s
> user 0m10,784s
> sys 0m2,027s
>
>
>> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
>> index f15a3b9aaf..61f7510ea1 100755
>> --- a/devtools/gen-abi.sh
>> +++ b/devtools/gen-abi.sh
>> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
>> fi
>>
>> libname=$(basename $f)
>> - abidw --out-file $dumpdir/${libname%.so*}.dump $f
>> -done
>> + echo $dumpdir/${libname%.so*}.dump $f
>> +done |
>> +xargs -n2 -P0 abidw --out-file
>> --
>> 2.39.0
>>
>
> - before
> real 0m8,237s
> user 0m7,704s
> sys 0m0,504s
>
> - after
> real 0m2,517s
> user 0m14,145s
> sys 0m0,766s
>
>
> Ferruh, I am seeing quite different numbers for running those scripts
> (clearly not of the minute order).
> I switched to testing/building in tmpfs some time ago.
> It requires a good amount of memory (I empirically allocated 40G), but
> maybe worth a try for you?
>
I run 'test-meson-builds.sh' script directly and yes I am getting
different numbers although there is still improvement, not in scale with
what you are getting, with v4 I have following:
- before
real 10m3.248s
user 39m8.664s
sys 14m52.870s
- after
real 7m49.086s
user 39m59.507s
sys 15m0.598s
What I am running exactly is:
time DPDK_ABI_REF_VERSION=v22.11.1 DPDK_ABI_REF_DIR=/tmp/dpdk-abiref
DPDK_ABI_REF_SRC=.../dpdk-stable/ ./devtools/test-meson-builds.sh
>
> In any case, this patch lgtm.
> Acked-by: David Marchand <david.marchand@redhat.com>
>
>
^ permalink raw reply [relevance 4%]
* [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values
2023-01-12 10:58 4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
@ 2023-01-12 10:59 3% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 10:59 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power
While the unsigned values added to telemetry dicts/arrays were up to
64-bits in size, the sized values were only up to 32-bits. We can
standardize the API by having both int and uint functions take 64-bit
values. For ABI compatibility, we use function versioning to ensure
older binaries can still use the older functions taking a 32-bit
parameter.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 4 ++--
lib/telemetry/telemetry_data.c | 33 +++++++++++++++++++++++++++++----
lib/telemetry/telemetry_data.h | 6 ++++++
lib/telemetry/version.map | 7 +++++++
5 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/lib/telemetry/meson.build b/lib/telemetry/meson.build
index f84c9aa3be..73750d9ef4 100644
--- a/lib/telemetry/meson.build
+++ b/lib/telemetry/meson.build
@@ -6,3 +6,4 @@ includes = [global_inc]
sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
headers = files('rte_telemetry.h')
includes += include_directories('../metrics')
+use_function_versioning = true
diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 4598303d5d..b481c112dd 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -120,7 +120,7 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
* 0 on success, negative errno on error
*/
int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x);
/**
* Add an unsigned value to an array.
@@ -208,7 +208,7 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
* 0 on success, negative errno on error, E2BIG on string truncation of name.
*/
int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val);
/**
* Add an unsigned value to a dictionary.
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 9a180937fd..ac7be795df 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -8,6 +8,7 @@
#undef RTE_USE_LIBBSD
#include <stdbool.h>
+#include <rte_function_versioning.h>
#include <rte_string_fns.h>
#include "telemetry_data.h"
@@ -58,8 +59,8 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
-int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
+int __vsym
+rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t x)
{
if (d->type != TEL_ARRAY_INT)
return -EINVAL;
@@ -69,6 +70,18 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
return 0;
}
+int __vsym
+rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int x)
+{
+ return rte_tel_data_add_array_int_v24(d, x);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
+ int64_t x), rte_tel_data_add_array_int_v24);
+
int
rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
{
@@ -146,8 +159,8 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
return 0;
}
-int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
+int __vsym
+rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val)
{
struct tel_dict_entry *e = &d->data.dict[d->data_len];
if (d->type != TEL_DICT)
@@ -165,6 +178,18 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
+int __vsym
+rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val)
+{
+ return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
+ const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+
int
rte_tel_data_add_dict_uint(struct rte_tel_data *d,
const char *name, uint64_t val)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 205509c5a2..53e4cabea5 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -49,4 +49,10 @@ struct rte_tel_data {
} data; /* data container */
};
+/* versioned functions */
+int rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int val);
+int rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t val);
+int rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val);
+int rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val);
+
#endif
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index d661180317..accfad5011 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -21,6 +21,13 @@ DPDK_23 {
local: *;
};
+DPDK_24 {
+ global:
+
+ rte_tel_data_add_array_int;
+ rte_tel_data_add_dict_int;
+} DPDK_23;
+
INTERNAL {
rte_telemetry_legacy_register;
rte_telemetry_init;
--
2.37.2
^ permalink raw reply [relevance 3%]
* [PATCH v2 8/9] telemetry: make internal int representation 64-bits
2023-01-12 10:58 4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
@ 2023-01-12 10:59 3% ` Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 10:59 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup, Tyler Retzlaff, Ciara Power
The internal storage for int values can be expanded from 32-bit to
64-bit without affecting the external ABI.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
---
lib/telemetry/telemetry_data.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 8db6875a81..205509c5a2 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -28,7 +28,7 @@ struct container {
*/
union tel_value {
char sval[RTE_TEL_MAX_STRING_LEN];
- int ival;
+ int64_t ival;
uint64_t uval;
struct container container;
};
--
2.37.2
^ permalink raw reply [relevance 3%]
* [PATCH v2 0/9] Standardize telemetry int types
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
` (2 preceding siblings ...)
@ 2023-01-12 10:58 4% ` Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
4 siblings, 2 replies; 200+ results
From: Bruce Richardson @ 2023-01-12 10:58 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
Rather than having 64-bit unsigned types and 32-bit signed types
supported by the telemetry lib, we should support 64-bit values
for both types. On the naming side, since both are 64-bit, we
should no longer call the unsigned value u64 - "uint" is better.
This patchset implements these changes as far as is possible while
still keeping API and ABI compatibility.
* Internal structures and functions are updated to use 64-bit ints
* Internal functions are renamed from u64 to uint
* Public enum values are renamed from u64 to uint, and a macro is
added to ensure that older code still compiles
* The public add_*_int functions are changed to take a 64-bit value
rather than a 32-bit one. Since this would be an ABI break, we
use function versioning to ensure older code still calls into
a wrapper function which takes a 32-bit value.
The patchset also contains a couple of other small cleanups to the
telemetry code that were seen in passing when making these changes -
removing RTE_ prefix on internal enums, and simplifying the init of the
the array of data types.
NOTE: the renaming of the u64 functions to uint is split across 3
patches in this set - patches 4,5 and 6. This is to make it easier to
review and to avoid warnings about new functions not being marked
initially as experimental. Some/all of these 3 can be combined on merge
if so desired.
V2:
- added additional patches to replace the old function calls within DPDK
code, something missed in RFC version
- added new patch to make the renamed/new functions immediately public
allowing us to mark the original named versions as deprecated
- re-ordered patches within the sit, so the extra cleanup changes come
first
Bruce Richardson (9):
telemetry: remove RTE prefix from internal enum values
telemetry: make array initialization more robust
telemetry: rename unsigned 64-bit enum value to uint
telemetry: add uint type as alias for u64
global: rename telemetry functions to newer versions
telemetry: mark old names of renamed fns as deprecated
telemetry: update json functions to use int/uint in names
telemetry: make internal int representation 64-bits
telemetry: change public API to use 64-bit signed values
app/test/test_telemetry_data.c | 22 ++---
app/test/test_telemetry_json.c | 9 +-
doc/guides/rel_notes/deprecation.rst | 5 ++
drivers/common/cnxk/roc_platform.h | 2 +-
drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 24 ++---
drivers/net/cnxk/cnxk_ethdev_telemetry.c | 6 +-
examples/ipsec-secgw/ipsec-secgw.c | 72 +++++++--------
examples/l3fwd-power/main.c | 4 +-
lib/cryptodev/rte_cryptodev.c | 6 +-
lib/dmadev/rte_dmadev.c | 2 +-
lib/eal/common/eal_common_memory.c | 19 ++--
lib/ethdev/rte_ethdev.c | 12 +--
lib/ethdev/sff_telemetry.c | 2 +-
lib/eventdev/rte_event_eth_rx_adapter.c | 22 ++---
lib/eventdev/rte_event_timer_adapter.c | 38 ++++----
lib/eventdev/rte_eventdev.c | 5 +-
lib/ipsec/ipsec_telemetry.c | 32 +++----
lib/rawdev/rte_rawdev.c | 4 +-
lib/security/rte_security.c | 8 +-
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 51 +++++++++--
lib/telemetry/telemetry.c | 56 ++++++------
lib/telemetry/telemetry_data.c | 95 ++++++++++++++------
lib/telemetry/telemetry_data.h | 24 +++--
lib/telemetry/telemetry_json.h | 16 ++--
lib/telemetry/version.map | 9 ++
26 files changed, 323 insertions(+), 223 deletions(-)
--
2.37.2
^ permalink raw reply [relevance 4%]
* Re: [PATCH v4] devtools: parallelize ABI check
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
@ 2023-01-12 10:53 4% ` David Marchand
2023-01-12 14:14 4% ` Ferruh Yigit
2023-01-18 14:29 4% ` David Marchand
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2023-01-12 10:53 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit; +Cc: dev, bruce.richardson
On Wed, Jan 11, 2023 at 8:53 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it.
> POSIX shell does not support function export except using an "eval trick".
> Required variables are also exported.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index c583eae2fd..31eceb42e6 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
> @@ -34,20 +34,18 @@ else
> ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
> fi
>
> -error=
> -for dump in $(find $refdir -name "*.dump"); do
> +export newdir ABIDIFF_OPTIONS
> +export diff_func='run_diff() {
> + dump=$1
> name=$(basename $dump)
> dump2=$(find $newdir -name $name)
> if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
> echo "Error: cannot find $name in $newdir" >&2
> - error=1
> - continue
> - fi
> + return 1
> + fi;
No need for ; here.
This can be fixed when applying (I tested both your patch and with
this small fix).
> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
> abiret=$?
> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> - error=1
> - echo
> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
> if [ $(($abiret & 3)) -ne 0 ]; then
> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
> fi
> @@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
> if [ $(($abiret & 8)) -ne 0 ]; then
> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
> fi
> - echo
> + return 1
> }
> -done
> +}'
> +
> +error=
> +find $refdir -name "*.dump" |
> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
> +error=1
>
> [ -z "$error" ] || [ -n "$warnonly" ]
For the record, on my system, calling this script is ~5 times faster:
- before
real 0m5,447s
user 0m4,497s
sys 0m0,937s
- after
real 0m1,202s
user 0m10,784s
sys 0m2,027s
> diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
> index f15a3b9aaf..61f7510ea1 100755
> --- a/devtools/gen-abi.sh
> +++ b/devtools/gen-abi.sh
> @@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
> fi
>
> libname=$(basename $f)
> - abidw --out-file $dumpdir/${libname%.so*}.dump $f
> -done
> + echo $dumpdir/${libname%.so*}.dump $f
> +done |
> +xargs -n2 -P0 abidw --out-file
> --
> 2.39.0
>
- before
real 0m8,237s
user 0m7,704s
sys 0m0,504s
- after
real 0m2,517s
user 0m14,145s
sys 0m0,766s
Ferruh, I am seeing quite different numbers for running those scripts
(clearly not of the minute order).
I switched to testing/building in tmpfs some time ago.
It requires a good amount of memory (I empirically allocated 40G), but
maybe worth a try for you?
In any case, this patch lgtm.
Acked-by: David Marchand <david.marchand@redhat.com>
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-11 10:46 0% ` Ferruh Yigit
@ 2023-01-12 2:26 0% ` lihuisong (C)
2023-01-18 14:12 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: lihuisong (C) @ 2023-01-12 2:26 UTC (permalink / raw)
To: Ferruh Yigit, dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
在 2023/1/11 18:46, Ferruh Yigit 写道:
> On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
>> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>>> On 12/6/2022 9:26 AM, Huisong Li wrote:
>>>>> This patchset fix some bugs and support attaching and detaching port
>>>>> in primary and secondary.
>>>>>
>>>>> ---
>>>>> -v4: fix a misspelling.
>>>>> -v3:
>>>>> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>>>> modification
>>>>> for other bus type.
>>>>> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>>>> the probelm in patch 2/5.
>>>>> -v2: resend due to CI unexplained failure.
>>>>>
>>>>> Huisong Li (5):
>>>>> drivers/bus: restore driver assignment at front of probing
>>>>> ethdev: fix skip valid port in probing callback
>>>>> app/testpmd: check the validity of the port
>>>>> app/testpmd: add attach and detach port for multiple process
>>>>> app/testpmd: stop forwarding in new or destroy event
>>>>>
>>>> Hi Huisong,
>>>>
>>>> I haven't checked the patch in detail yet, but I can see it gives some
>>>> ABI compatibility warnings, is this expected:
>>> This is to be expected. Because we insert a device state,
>>> RTE_ETH_DEV_ALLOCATED,
>>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>>> We may have to announce it. What do you think?
>> If there is an actual ABI break, it can't go in this release, need to
>> wait LTS release and yes needs deprecation notice in advance.
>>
>> But not all enum value change warnings are real break, need to
>> investigate all warnings one by one.
>> Need to investigate if old application & new dpdk library may cause any
>> unexpected behavior for application.
>>
> OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
> enum solves the issue, although logically it won't look nice.
Thank you for your suggestion, Ferruh. It seems to be ok. I will fix it.
> Perhaps order can be fixed in next LTS, to have more logical order, but
> not quite sure if order worth the disturbance may cause in application.
Probably not worth it.
>>>> 1 function with some indirect sub-type change:
>>>>
>>>> [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
>>>> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
>>>> some indirect sub-type changes:
>>>> parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>>>> in pointed to type 'const rte_eth_dev':
>>>> in unqualified underlying type 'struct rte_eth_dev' at
>>>> ethdev_driver.h:50:1:
>>>> type size hasn't changed
>>>> 1 data member change:
>>>> type of 'rte_eth_dev_state state' changed:
>>>> type size hasn't changed
>>>> 1 enumerator insertion:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>> 2 enumerator changes:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>>> to '2' at rte_ethdev.h:2000:1
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
>>>> to '3' at rte_ethdev.h:2000:1
>>>>
>>>> 1 function with some indirect sub-type change:
>>>>
>>>> [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
>>>> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>>>> parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>>>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>>> type size hasn't changed
>>>> 1 data member change:
>>>> type of 'rte_eth_dev_state state' changed:
>>>> type size hasn't changed
>>>> 1 enumerator insertion:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>> 2 enumerator changes:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>>> to '2' at rte_ethdev.h:2000:1
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>>> '3' at rte_ethdev.h:2000:1
>>>>
>>>> 1 function with some indirect sub-type change:
>>>>
>>>> [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
>>>> ethdev_driver.c:72:1 has some indirect sub-type changes:
>>>> return type changed:
>>>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>>> type size hasn't changed
>>>> 1 data member change:
>>>> type of 'rte_eth_dev_state state' changed:
>>>> type size hasn't changed
>>>> 1 enumerator insertion:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>>> 2 enumerator changes:
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>>> to '2' at rte_ethdev.h:2000:1
>>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>>> '3' at rte_ethdev.h:2000:1
>>>>
>>>> ... there are more warnings for same issue ...
>>>>
>>>> .
> .
^ permalink raw reply [relevance 0%]
* [PATCH v4] devtools: parallelize ABI check
2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
@ 2023-01-11 19:53 33% ` Thomas Monjalon
2023-01-12 10:53 4% ` David Marchand
2023-01-18 14:29 4% ` David Marchand
2 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2023-01-11 19:53 UTC (permalink / raw)
To: David Marchand; +Cc: dev, bruce.richardson, Ferruh Yigit
Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.
xargs reports a global error if one of the process has an error.
Running a shell function with xargs requires to export it.
POSIX shell does not support function export except using an "eval trick".
Required variables are also exported.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
v2:
- find dump2 inside the function
- force bash because of export -f
v3:
- revert to POSIX sh
- use POSIX eval instead of export -f (issues on Ubuntu)
v4:
- export all required variables
- remove useless stdout echo calls
---
devtools/check-abi.sh | 23 +++++++++++++----------
devtools/gen-abi.sh | 5 +++--
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..31eceb42e6 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -34,20 +34,18 @@ else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
-error=
-for dump in $(find $refdir -name "*.dump"); do
+export newdir ABIDIFF_OPTIONS
+export diff_func='run_diff() {
+ dump=$1
name=$(basename $dump)
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
echo "Error: cannot find $name in $newdir" >&2
- error=1
- continue
- fi
+ return 1
+ fi;
abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
abiret=$?
- echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
- error=1
- echo
+ echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
if [ $(($abiret & 3)) -ne 0 ]; then
echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
fi
@@ -57,8 +55,13 @@ for dump in $(find $refdir -name "*.dump"); do
if [ $(($abiret & 8)) -ne 0 ]; then
echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
- echo
+ return 1
}
-done
+}'
+
+error=
+find $refdir -name "*.dump" |
+xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0' ||
+error=1
[ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
fi
libname=$(basename $f)
- abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+ echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
--
2.39.0
^ permalink raw reply [relevance 33%]
* Re: [PATCH v3] devtools: parallelize ABI check
2023-01-11 14:11 4% ` David Marchand
@ 2023-01-11 17:04 4% ` Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2023-01-11 17:04 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Ferruh Yigit
11/01/2023 15:11, David Marchand:
> On Wed, Jan 11, 2023 at 2:16 PM Thomas Monjalon <thomas@monjalon.net> wrote:
> > +find $refdir -name "*.dump" |
> > +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0 '$newdir ||
> > +error=1
>
> Do we need to pass $newdir ?
> Like, for example, ABIDIFF_OPTIONS seems inherited, right?
Actually ABIDIFF_OPTIONS was empty when calling the function.
I'll pass it as well.
^ permalink raw reply [relevance 4%]
* RE: [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
2022-12-21 10:29 2% ` [RFC 2/5] ethdev: introduce the affinity field " Jiawei Wang
@ 2023-01-11 16:47 0% ` Ori Kam
2023-01-18 11:37 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Ori Kam @ 2023-01-11 16:47 UTC (permalink / raw)
To: Jiawei(Jonny) Wang, Slava Ovsiienko,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Aman Singh, Yuying Zhang, Ferruh Yigit, Andrew Rybchenko
Cc: dev, Raslan Darawsheh
Hi Jiawei,
> -----Original Message-----
> From: Jiawei(Jonny) Wang <jiaweiw@nvidia.com>
> Sent: Wednesday, 21 December 2022 12:30
>
> For the multiple hardware ports connect to a single DPDK port (mhpsdp),
> the previous patch introduces the new rte flow item to match the port
> affinity of the received packets.
>
> This patch adds the tx_affinity setting in Tx queue API, the affinity value
> reflects packets be sent to which hardware port.
>
> Adds the new tx_affinity field into the padding hole of rte_eth_txconf
> structure, the size of rte_eth_txconf keeps the same. Adds a suppress
> type for structure change in the ABI check file.
>
> This patch adds the testpmd command line:
> testpmd> port config (port_id) txq (queue_id) affinity (value)
>
> For example, there're two hardware ports connects to a single DPDK
> port (port id 0), and affinity 1 stood for hard port 1 and affinity
> 2 stood for hardware port 2, used the below command to config
> tx affinity for each TxQ:
> port config 0 txq 0 affinity 1
> port config 0 txq 1 affinity 1
> port config 0 txq 2 affinity 2
> port config 0 txq 3 affinity 2
>
> These commands config the TxQ index 0 and TxQ
index 1 with affinity 1,
> uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
> hardware port 1, and similar with hardware port 2 if sending packets
> with TxQ 2 or TxQ 3.
>
> Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
> ---
Acked-by: Ori Kam <orika@nvidia.com>
Best,
Ori
^ permalink raw reply [relevance 0%]
* Re: [PATCH v3] devtools: parallelize ABI check
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
2023-01-11 14:10 4% ` Bruce Richardson
@ 2023-01-11 14:11 4% ` David Marchand
2023-01-11 17:04 4% ` Thomas Monjalon
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2023-01-11 14:11 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Ferruh Yigit
On Wed, Jan 11, 2023 at 2:16 PM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it with -f,
> and that is a specific capability of bash.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> ---
> v2:
> - find dump2 inside the function
> - force bash because of export -f
> v3:
> - revert to POSIX sh
> - use POSIX eval instead of export -f (issues on Ubuntu)
> ---
> devtools/check-abi.sh | 21 +++++++++++++--------
> devtools/gen-abi.sh | 5 +++--
> 2 files changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
> index c583eae2fd..d58c867c60 100755
> --- a/devtools/check-abi.sh
> +++ b/devtools/check-abi.sh
> @@ -34,19 +34,18 @@ else
> ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
> fi
>
> -error=
> -for dump in $(find $refdir -name "*.dump"); do
> +export diff_func='run_diff() {
> + dump=$1
> + newdir=$2
> name=$(basename $dump)
> dump2=$(find $newdir -name $name)
> if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
> echo "Error: cannot find $name in $newdir" >&2
> - error=1
> - continue
> - fi
> + return 1
> + fi;
> abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
> abiret=$?
> - echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
> - error=1
> + echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
> echo
> if [ $(($abiret & 3)) -ne 0 ]; then
> echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
> @@ -58,7 +57,13 @@ for dump in $(find $refdir -name "*.dump"); do
> echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
> fi
> echo
> + return 1
> }
> -done
> +}'
> +
> +error=
> +find $refdir -name "*.dump" |
> +xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0 '$newdir ||
> +error=1
Do we need to pass $newdir ?
Like, for example, ABIDIFF_OPTIONS seems inherited, right?
Otherwise this trick looks to work.
--
David Marchand
^ permalink raw reply [relevance 4%]
* Re: [PATCH v3] devtools: parallelize ABI check
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
@ 2023-01-11 14:10 4% ` Bruce Richardson
2023-01-11 14:11 4% ` David Marchand
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-11 14:10 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: David Marchand, dev, Ferruh Yigit
On Wed, Jan 11, 2023 at 02:16:52PM +0100, Thomas Monjalon wrote:
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it with -f,
> and that is a specific capability of bash.
>
Commit-log needs update based on changes in v3.
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> ---
> v2:
> - find dump2 inside the function
> - force bash because of export -f
> v3:
> - revert to POSIX sh
> - use POSIX eval instead of export -f (issues on Ubuntu)
> ---
> devtools/check-abi.sh | 21 +++++++++++++--------
> devtools/gen-abi.sh | 5 +++--
> 2 files changed, 16 insertions(+), 10 deletions(-)
^ permalink raw reply [relevance 4%]
* [PATCH v3] devtools: parallelize ABI check
2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
@ 2023-01-11 13:16 33% ` Thomas Monjalon
2023-01-11 14:10 4% ` Bruce Richardson
2023-01-11 14:11 4% ` David Marchand
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
2 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2023-01-11 13:16 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Ferruh Yigit
Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.
xargs reports a global error if one of the process has an error.
Running a shell function with xargs requires to export it with -f,
and that is a specific capability of bash.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
v2:
- find dump2 inside the function
- force bash because of export -f
v3:
- revert to POSIX sh
- use POSIX eval instead of export -f (issues on Ubuntu)
---
devtools/check-abi.sh | 21 +++++++++++++--------
devtools/gen-abi.sh | 5 +++--
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..d58c867c60 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -34,19 +34,18 @@ else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
-error=
-for dump in $(find $refdir -name "*.dump"); do
+export diff_func='run_diff() {
+ dump=$1
+ newdir=$2
name=$(basename $dump)
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
echo "Error: cannot find $name in $newdir" >&2
- error=1
- continue
- fi
+ return 1
+ fi;
abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
abiret=$?
- echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
- error=1
+ echo "Error: ABI issue reported for abidiff $ABIDIFF_OPTIONS $dump $dump2" >&2
echo
if [ $(($abiret & 3)) -ne 0 ]; then
echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
@@ -58,7 +57,13 @@ for dump in $(find $refdir -name "*.dump"); do
echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
echo
+ return 1
}
-done
+}'
+
+error=
+find $refdir -name "*.dump" |
+xargs -n1 -P0 sh -c 'eval "$diff_func"; run_diff $0 '$newdir ||
+error=1
[ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
fi
libname=$(basename $f)
- abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+ echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
--
2.39.0
^ permalink raw reply [relevance 33%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-11 10:27 3% ` Ferruh Yigit
@ 2023-01-11 10:46 0% ` Ferruh Yigit
2023-01-12 2:26 0% ` lihuisong (C)
2023-01-18 14:12 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Ferruh Yigit @ 2023-01-11 10:46 UTC (permalink / raw)
To: lihuisong (C), dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
On 1/11/2023 10:27 AM, Ferruh Yigit wrote:
> On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>>
>> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>>> On 12/6/2022 9:26 AM, Huisong Li wrote:
>>>> This patchset fix some bugs and support attaching and detaching port
>>>> in primary and secondary.
>>>>
>>>> ---
>>>> -v4: fix a misspelling.
>>>> -v3:
>>>> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>>> modification
>>>> for other bus type.
>>>> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>>> the probelm in patch 2/5.
>>>> -v2: resend due to CI unexplained failure.
>>>>
>>>> Huisong Li (5):
>>>> drivers/bus: restore driver assignment at front of probing
>>>> ethdev: fix skip valid port in probing callback
>>>> app/testpmd: check the validity of the port
>>>> app/testpmd: add attach and detach port for multiple process
>>>> app/testpmd: stop forwarding in new or destroy event
>>>>
>>> Hi Huisong,
>>>
>>> I haven't checked the patch in detail yet, but I can see it gives some
>>> ABI compatibility warnings, is this expected:
>> This is to be expected. Because we insert a device state,
>> RTE_ETH_DEV_ALLOCATED,
>> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
>> We may have to announce it. What do you think?
>
> If there is an actual ABI break, it can't go in this release, need to
> wait LTS release and yes needs deprecation notice in advance.
>
> But not all enum value change warnings are real break, need to
> investigate all warnings one by one.
> Need to investigate if old application & new dpdk library may cause any
> unexpected behavior for application.
>
OR, appending new enum item, `RTE_ETH_DEV_ALLOCATED`, to the end of the
enum solves the issue, although logically it won't look nice.
Perhaps order can be fixed in next LTS, to have more logical order, but
not quite sure if order worth the disturbance may cause in application.
>>>
>>> 1 function with some indirect sub-type change:
>>>
>>> [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
>>> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
>>> some indirect sub-type changes:
>>> parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>>> in pointed to type 'const rte_eth_dev':
>>> in unqualified underlying type 'struct rte_eth_dev' at
>>> ethdev_driver.h:50:1:
>>> type size hasn't changed
>>> 1 data member change:
>>> type of 'rte_eth_dev_state state' changed:
>>> type size hasn't changed
>>> 1 enumerator insertion:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>> 2 enumerator changes:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>> to '2' at rte_ethdev.h:2000:1
>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
>>> to '3' at rte_ethdev.h:2000:1
>>>
>>> 1 function with some indirect sub-type change:
>>>
>>> [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
>>> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>>> parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>> type size hasn't changed
>>> 1 data member change:
>>> type of 'rte_eth_dev_state state' changed:
>>> type size hasn't changed
>>> 1 enumerator insertion:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>> 2 enumerator changes:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>> to '2' at rte_ethdev.h:2000:1
>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>> '3' at rte_ethdev.h:2000:1
>>>
>>> 1 function with some indirect sub-type change:
>>>
>>> [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
>>> ethdev_driver.c:72:1 has some indirect sub-type changes:
>>> return type changed:
>>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>>> type size hasn't changed
>>> 1 data member change:
>>> type of 'rte_eth_dev_state state' changed:
>>> type size hasn't changed
>>> 1 enumerator insertion:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>>> 2 enumerator changes:
>>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>>> to '2' at rte_ethdev.h:2000:1
>>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>>> '3' at rte_ethdev.h:2000:1
>>>
>>> ... there are more warnings for same issue ...
>>>
>>> .
>
^ permalink raw reply [relevance 0%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-11 0:53 0% ` lihuisong (C)
@ 2023-01-11 10:27 3% ` Ferruh Yigit
2023-01-11 10:46 0% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-11 10:27 UTC (permalink / raw)
To: lihuisong (C), dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
On 1/11/2023 12:53 AM, lihuisong (C) wrote:
>
> 在 2023/1/11 0:51, Ferruh Yigit 写道:
>> On 12/6/2022 9:26 AM, Huisong Li wrote:
>>> This patchset fix some bugs and support attaching and detaching port
>>> in primary and secondary.
>>>
>>> ---
>>> -v4: fix a misspelling.
>>> -v3:
>>> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add
>>> modification
>>> for other bus type.
>>> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>>> the probelm in patch 2/5.
>>> -v2: resend due to CI unexplained failure.
>>>
>>> Huisong Li (5):
>>> drivers/bus: restore driver assignment at front of probing
>>> ethdev: fix skip valid port in probing callback
>>> app/testpmd: check the validity of the port
>>> app/testpmd: add attach and detach port for multiple process
>>> app/testpmd: stop forwarding in new or destroy event
>>>
>> Hi Huisong,
>>
>> I haven't checked the patch in detail yet, but I can see it gives some
>> ABI compatibility warnings, is this expected:
> This is to be expected. Because we insert a device state,
> RTE_ETH_DEV_ALLOCATED,
> before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
> We may have to announce it. What do you think?
If there is an actual ABI break, it can't go in this release, need to
wait LTS release and yes needs deprecation notice in advance.
But not all enum value change warnings are real break, need to
investigate all warnings one by one.
Need to investigate if old application & new dpdk library may cause any
unexpected behavior for application.
>>
>> 1 function with some indirect sub-type change:
>>
>> [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
>> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
>> some indirect sub-type changes:
>> parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
>> in pointed to type 'const rte_eth_dev':
>> in unqualified underlying type 'struct rte_eth_dev' at
>> ethdev_driver.h:50:1:
>> type size hasn't changed
>> 1 data member change:
>> type of 'rte_eth_dev_state state' changed:
>> type size hasn't changed
>> 1 enumerator insertion:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>> 2 enumerator changes:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>> to '2' at rte_ethdev.h:2000:1
>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
>> to '3' at rte_ethdev.h:2000:1
>>
>> 1 function with some indirect sub-type change:
>>
>> [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
>> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
>> parameter 2 of type 'rte_eth_dev*' has sub-type changes:
>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>> type size hasn't changed
>> 1 data member change:
>> type of 'rte_eth_dev_state state' changed:
>> type size hasn't changed
>> 1 enumerator insertion:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>> 2 enumerator changes:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>> to '2' at rte_ethdev.h:2000:1
>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>> '3' at rte_ethdev.h:2000:1
>>
>> 1 function with some indirect sub-type change:
>>
>> [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
>> ethdev_driver.c:72:1 has some indirect sub-type changes:
>> return type changed:
>> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
>> type size hasn't changed
>> 1 data member change:
>> type of 'rte_eth_dev_state state' changed:
>> type size hasn't changed
>> 1 enumerator insertion:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
>> 2 enumerator changes:
>> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
>> to '2' at rte_ethdev.h:2000:1
>> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
>> '3' at rte_ethdev.h:2000:1
>>
>> ... there are more warnings for same issue ...
>>
>> .
^ permalink raw reply [relevance 3%]
* Re: RFC abstracting atomics
2023-01-10 20:10 3% ` Tyler Retzlaff
@ 2023-01-11 10:10 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2023-01-11 10:10 UTC (permalink / raw)
To: Tyler Retzlaff; +Cc: dev
On Tue, Jan 10, 2023 at 12:10:33PM -0800, Tyler Retzlaff wrote:
> On Tue, Jan 10, 2023 at 09:16:48AM +0000, Bruce Richardson wrote:
> > On Mon, Jan 09, 2023 at 02:56:04PM -0800, Tyler Retzlaff wrote:
> > > hi folks,
> > >
> > > i would like to introduce a layer of abstraction that would allow
> > > optional use of standard C11 atomics when the platform / toolchain
> > > combination has them available.
> > >
> > > making the option usable would be a phased approach intended to focus
> > > review and minimize dealing with churn on such a broad change.
> > >
> > > 1. provide an initial series to add the abstraction and the ability
> > > control enablement with a meson option enable_stdatomics=false will
> > > be the default.
> > >
> > > for all existing platform / toolchain combinations the default would
> > > remain false. i.e. i have no plans to enable it for existing platforms
> > > toolchain combinations but leaves a change of default open to the
> > > community as a future discussion if it is desired.
> > >
> > > 2. once the initial abstraction is integrated a series will be introduced to
> > > port the tree to the abstraction with enable_stdatomics=false. the goal
> > > being low or no change to the current use of gcc builtin C++11 memory
> > > model atomics.
> > >
> > > 3. once the tree is ported a final series will be introduced to introduce
> > > the remaining change to allow the use of enable_stdatomics=true.
> > >
> > > would appreciate any assistance / suggestions you can provide to
> > > introduce the abstraction smoothly.
> > >
> >
> > Plan generally sounds ok. However, beyond point #3, would there then be
> > plans to remove the option and always use stdatomics in future?
>
> that is a discussion for the community i think on a per-platform /
> per-toolchain basis. there is likely to be resistance which is why i'm
> favoring the opt-in if you want model.
>
> some potential arguments against switching.
>
> * it's an abi break there is no way around it.
> * old compiler x stdatomics implementation is less optimal than
> old compiler x __atomics (potential argument).
> * there's some "mixed" use of variables in the tree where sometimes we
> operate on them as if they are atomic and sometimes not. the std
> atomics apis doesn't support this sometimes atomic codegen you either
> get atomic or you don't.
> * direct use of atomics default to seq_cst ordering if the strengthening
> of the ordering is not desired each variable needs to be hunted down
> and explicitly returned to relaxed ordering access.
>
> > To slightly expand the scope of the discussion - would it be worthwhile
> > putting these abstractions in a new library in DPDK other than EAL, to
> > start the process of splitting out some of the lower-level material from
> > that library?
>
> the abstraction as i have prototyped it is a set of conditionally
> compiled macros where the macros mirror the standard c atomics for
> naming and have been placed in include/generic/rte_atomics.h
>
> i've no problem splitting it out into a separate library and then have
> EAL depend on it, but it is currently header only so i'm not sure if it
> is worth doing for that.
>
> we can chew on that more in a couple days when i submit the base series
> if you like.
>
Thanks.
One additional point that just became clear to me when I started thinking
about upping our DPDK C-standard-baseline. We need to be careful what we
are considering when we up our C baseline. We can mandate a specific
compiler minimum and C version for compiling up DPDK itself, but I think we
should not mandate that for the end applications.
That means that our header files, such as atomics, should not require C99
or C11 even if the build of DPDK itself does. More specifically, even if we
bump DPDK minimum to C11, we should still allow apps to build using older
compiler settings.
Therefore, we probably need to maintain non-C11 atomics code paths in
headers beyond the point at which DPDK itself uses C11 as a code baseline.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
2023-01-10 16:51 3% ` Ferruh Yigit
@ 2023-01-11 0:53 0% ` lihuisong (C)
2023-01-11 10:27 3% ` Ferruh Yigit
0 siblings, 1 reply; 200+ results
From: lihuisong (C) @ 2023-01-11 0:53 UTC (permalink / raw)
To: Ferruh Yigit, dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
在 2023/1/11 0:51, Ferruh Yigit 写道:
> On 12/6/2022 9:26 AM, Huisong Li wrote:
>> This patchset fix some bugs and support attaching and detaching port
>> in primary and secondary.
>>
>> ---
>> -v4: fix a misspelling.
>> -v3:
>> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
>> for other bus type.
>> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
>> the probelm in patch 2/5.
>> -v2: resend due to CI unexplained failure.
>>
>> Huisong Li (5):
>> drivers/bus: restore driver assignment at front of probing
>> ethdev: fix skip valid port in probing callback
>> app/testpmd: check the validity of the port
>> app/testpmd: add attach and detach port for multiple process
>> app/testpmd: stop forwarding in new or destroy event
>>
> Hi Huisong,
>
> I haven't checked the patch in detail yet, but I can see it gives some
> ABI compatibility warnings, is this expected:
This is to be expected. Because we insert a device state,
RTE_ETH_DEV_ALLOCATED,
before RTE_ETH_DEV_ATTACHED for resolving the issue patch 2/5 mentioned.
We may have to announce it. What do you think?
>
> 1 function with some indirect sub-type change:
>
> [C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
> const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
> some indirect sub-type changes:
> parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
> in pointed to type 'const rte_eth_dev':
> in unqualified underlying type 'struct rte_eth_dev' at
> ethdev_driver.h:50:1:
> type size hasn't changed
> 1 data member change:
> type of 'rte_eth_dev_state state' changed:
> type size hasn't changed
> 1 enumerator insertion:
> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
> 2 enumerator changes:
> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
> to '2' at rte_ethdev.h:2000:1
> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
> to '3' at rte_ethdev.h:2000:1
>
> 1 function with some indirect sub-type change:
>
> [C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
> at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
> parameter 2 of type 'rte_eth_dev*' has sub-type changes:
> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
> type size hasn't changed
> 1 data member change:
> type of 'rte_eth_dev_state state' changed:
> type size hasn't changed
> 1 enumerator insertion:
> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
> 2 enumerator changes:
> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
> to '2' at rte_ethdev.h:2000:1
> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
> '3' at rte_ethdev.h:2000:1
>
> 1 function with some indirect sub-type change:
>
> [C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
> ethdev_driver.c:72:1 has some indirect sub-type changes:
> return type changed:
> in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
> type size hasn't changed
> 1 data member change:
> type of 'rte_eth_dev_state state' changed:
> type size hasn't changed
> 1 enumerator insertion:
> 'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
> 2 enumerator changes:
> 'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
> to '2' at rte_ethdev.h:2000:1
> 'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
> '3' at rte_ethdev.h:2000:1
>
> ... there are more warnings for same issue ...
>
> .
^ permalink raw reply [relevance 0%]
* Re: RFC abstracting atomics
@ 2023-01-10 20:10 3% ` Tyler Retzlaff
2023-01-11 10:10 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2023-01-10 20:10 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev
On Tue, Jan 10, 2023 at 09:16:48AM +0000, Bruce Richardson wrote:
> On Mon, Jan 09, 2023 at 02:56:04PM -0800, Tyler Retzlaff wrote:
> > hi folks,
> >
> > i would like to introduce a layer of abstraction that would allow
> > optional use of standard C11 atomics when the platform / toolchain
> > combination has them available.
> >
> > making the option usable would be a phased approach intended to focus
> > review and minimize dealing with churn on such a broad change.
> >
> > 1. provide an initial series to add the abstraction and the ability
> > control enablement with a meson option enable_stdatomics=false will
> > be the default.
> >
> > for all existing platform / toolchain combinations the default would
> > remain false. i.e. i have no plans to enable it for existing platforms
> > toolchain combinations but leaves a change of default open to the
> > community as a future discussion if it is desired.
> >
> > 2. once the initial abstraction is integrated a series will be introduced to
> > port the tree to the abstraction with enable_stdatomics=false. the goal
> > being low or no change to the current use of gcc builtin C++11 memory
> > model atomics.
> >
> > 3. once the tree is ported a final series will be introduced to introduce
> > the remaining change to allow the use of enable_stdatomics=true.
> >
> > would appreciate any assistance / suggestions you can provide to
> > introduce the abstraction smoothly.
> >
>
> Plan generally sounds ok. However, beyond point #3, would there then be
> plans to remove the option and always use stdatomics in future?
that is a discussion for the community i think on a per-platform /
per-toolchain basis. there is likely to be resistance which is why i'm
favoring the opt-in if you want model.
some potential arguments against switching.
* it's an abi break there is no way around it.
* old compiler x stdatomics implementation is less optimal than
old compiler x __atomics (potential argument).
* there's some "mixed" use of variables in the tree where sometimes we
operate on them as if they are atomic and sometimes not. the std
atomics apis doesn't support this sometimes atomic codegen you either
get atomic or you don't.
* direct use of atomics default to seq_cst ordering if the strengthening
of the ordering is not desired each variable needs to be hunted down
and explicitly returned to relaxed ordering access.
> To slightly expand the scope of the discussion - would it be worthwhile
> putting these abstractions in a new library in DPDK other than EAL, to
> start the process of splitting out some of the lower-level material from
> that library?
the abstraction as i have prototyped it is a set of conditionally
compiled macros where the macros mirror the standard c atomics for
naming and have been placed in include/generic/rte_atomics.h
i've no problem splitting it out into a separate library and then have
EAL depend on it, but it is currently header only so i'm not sure if it
is worth doing for that.
we can chew on that more in a couple days when i submit the base series
if you like.
>
> /Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port
@ 2023-01-10 16:51 3% ` Ferruh Yigit
2023-01-11 0:53 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: Ferruh Yigit @ 2023-01-10 16:51 UTC (permalink / raw)
To: Huisong Li, dev, andrew.rybchenko
Cc: thomas, liudongdong3, huangdaode, fengchengwen
On 12/6/2022 9:26 AM, Huisong Li wrote:
> This patchset fix some bugs and support attaching and detaching port
> in primary and secondary.
>
> ---
> -v4: fix a misspelling.
> -v3:
> 1) merge patch 1/6 and patch 2/6 into patch 1/5, and add modification
> for other bus type.
> 2) add a RTE_ETH_DEV_ALLOCATED state in rte_eth_dev_state to resolve
> the probelm in patch 2/5.
> -v2: resend due to CI unexplained failure.
>
> Huisong Li (5):
> drivers/bus: restore driver assignment at front of probing
> ethdev: fix skip valid port in probing callback
> app/testpmd: check the validity of the port
> app/testpmd: add attach and detach port for multiple process
> app/testpmd: stop forwarding in new or destroy event
>
Hi Huisong,
I haven't checked the patch in detail yet, but I can see it gives some
ABI compatibility warnings, is this expected:
1 function with some indirect sub-type change:
[C] 'function int dpaa_eth_eventq_attach(const rte_eth_dev*, int, u16,
const rte_event_eth_rx_adapter_queue_conf*)' at dpaa_ethdev.c:1149:1 has
some indirect sub-type changes:
parameter 1 of type 'const rte_eth_dev*' has sub-type changes:
in pointed to type 'const rte_eth_dev':
in unqualified underlying type 'struct rte_eth_dev' at
ethdev_driver.h:50:1:
type size hasn't changed
1 data member change:
type of 'rte_eth_dev_state state' changed:
type size hasn't changed
1 enumerator insertion:
'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
2 enumerator changes:
'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
to '2' at rte_ethdev.h:2000:1
'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2'
to '3' at rte_ethdev.h:2000:1
1 function with some indirect sub-type change:
[C] 'function int rte_pmd_i40e_set_switch_dev(uint16_t, rte_eth_dev*)'
at rte_pmd_i40e.c:3266:1 has some indirect sub-type changes:
parameter 2 of type 'rte_eth_dev*' has sub-type changes:
in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
type size hasn't changed
1 data member change:
type of 'rte_eth_dev_state state' changed:
type size hasn't changed
1 enumerator insertion:
'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
2 enumerator changes:
'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
to '2' at rte_ethdev.h:2000:1
'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
'3' at rte_ethdev.h:2000:1
1 function with some indirect sub-type change:
[C] 'function rte_eth_dev* rte_eth_dev_allocate(const char*)' at
ethdev_driver.c:72:1 has some indirect sub-type changes:
return type changed:
in pointed to type 'struct rte_eth_dev' at ethdev_driver.h:50:1:
type size hasn't changed
1 data member change:
type of 'rte_eth_dev_state state' changed:
type size hasn't changed
1 enumerator insertion:
'rte_eth_dev_state::RTE_ETH_DEV_ALLOCATED' value '1'
2 enumerator changes:
'rte_eth_dev_state::RTE_ETH_DEV_ATTACHED' from value '1'
to '2' at rte_ethdev.h:2000:1
'rte_eth_dev_state::RTE_ETH_DEV_REMOVED' from value '2' to
'3' at rte_ethdev.h:2000:1
... there are more warnings for same issue ...
^ permalink raw reply [relevance 3%]
* Re: [PATCH v2] devtools: parallelize ABI check
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
@ 2023-01-10 11:08 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2023-01-10 11:08 UTC (permalink / raw)
To: Thomas Monjalon, David Marchand; +Cc: dev
On 1/9/2023 9:34 AM, Thomas Monjalon wrote:
> Generation and comparison of ABI dumps are done on multiple cores
> thanks to xargs -P0.
> It can accelerate this long step by 5 in my tests.
>
> xargs reports a global error if one of the process has an error.
>
> Running a shell function with xargs requires to export it with -f,
> and that is a specific capability of bash.
>
> Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
> ---
> v2:
> - find dump2 inside the function
> - force bash because of export -f
It reduces script runtime ~2mins in my test.
Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
^ permalink raw reply [relevance 4%]
* [PATCH v2] devtools: parallelize ABI check
2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
@ 2023-01-09 9:34 23% ` Thomas Monjalon
2023-01-10 11:08 4% ` Ferruh Yigit
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
2 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2023-01-09 9:34 UTC (permalink / raw)
To: David Marchand; +Cc: dev
Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.
xargs reports a global error if one of the process has an error.
Running a shell function with xargs requires to export it with -f,
and that is a specific capability of bash.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
v2:
- find dump2 inside the function
- force bash because of export -f
---
devtools/check-abi.sh | 20 +++++++++++++-------
devtools/gen-abi.sh | 5 +++--
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..4409f65ccd 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -1,4 +1,4 @@
-#!/bin/sh -e
+#!/bin/bash -e
# SPDX-License-Identifier: BSD-3-Clause
# Copyright (c) 2019 Red Hat, Inc.
@@ -34,19 +34,18 @@ else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
-error=
-for dump in $(find $refdir -name "*.dump"); do
+run_diff() { # <dump1> <dir2>
+ dump=$1
+ newdir=$2
name=$(basename $dump)
dump2=$(find $newdir -name $name)
if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
echo "Error: cannot find $name in $newdir" >&2
- error=1
- continue
+ return 1
fi
abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
abiret=$?
echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
- error=1
echo
if [ $(($abiret & 3)) -ne 0 ]; then
echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
@@ -58,7 +57,14 @@ for dump in $(find $refdir -name "*.dump"); do
echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
echo
+ return 1
}
-done
+}
+export -f run_diff
+
+error=
+find $refdir -name "*.dump" |
+xargs -n1 -P0 sh -c 'run_diff $0 '$newdir ||
+error=1
[ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
fi
libname=$(basename $f)
- abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+ echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
--
2.39.0
^ permalink raw reply [relevance 23%]
* [PATCH] devtools: parallelize ABI check
@ 2023-01-07 13:39 33% Thomas Monjalon
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Thomas Monjalon @ 2023-01-07 13:39 UTC (permalink / raw)
Cc: dev, David Marchand
Generation and comparison of ABI dumps are done on multiple cores
thanks to xargs -P0.
It can accelerate this long step by 5 in my tests.
xargs reports a global error if one of the process has an error.
Running a shell function with xargs requires to export it with -f.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
devtools/check-abi.sh | 33 ++++++++++++++++++++-------------
devtools/gen-abi.sh | 5 +++--
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/devtools/check-abi.sh b/devtools/check-abi.sh
index c583eae2fd..e2fa49217d 100755
--- a/devtools/check-abi.sh
+++ b/devtools/check-abi.sh
@@ -34,19 +34,10 @@ else
ABIDIFF_OPTIONS="$ABIDIFF_OPTIONS --headers-dir2 $incdir2"
fi
-error=
-for dump in $(find $refdir -name "*.dump"); do
- name=$(basename $dump)
- dump2=$(find $newdir -name $name)
- if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
- echo "Error: cannot find $name in $newdir" >&2
- error=1
- continue
- fi
- abidiff $ABIDIFF_OPTIONS $dump $dump2 || {
+run_diff() { # <dump1> <dump2>
+ abidiff $ABIDIFF_OPTIONS $1 $2 || {
abiret=$?
- echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $dump $dump2'" >&2
- error=1
+ echo "Error: ABI issue reported for 'abidiff $ABIDIFF_OPTIONS $1 $2'" >&2
echo
if [ $(($abiret & 3)) -ne 0 ]; then
echo "ABIDIFF_ERROR|ABIDIFF_USAGE_ERROR, this could be a script or environment issue." >&2
@@ -58,7 +49,23 @@ for dump in $(find $refdir -name "*.dump"); do
echo "ABIDIFF_ABI_INCOMPATIBLE_CHANGE, this change breaks the ABI." >&2
fi
echo
+ return $abiret
}
-done
+}
+export -f run_diff
+
+error=
+for dump in $(find $refdir -name "*.dump"); do
+ name=$(basename $dump)
+ dump2=$(find $newdir -name $name)
+ if [ -z "$dump2" ] || [ ! -e "$dump2" ]; then
+ echo "Error: cannot find $name in $newdir" >&2
+ error=1
+ continue
+ fi
+ echo $dump $dump2
+done |
+xargs -n2 -P0 sh -c 'run_diff $0 $1' ||
+error=1
[ -z "$error" ] || [ -n "$warnonly" ]
diff --git a/devtools/gen-abi.sh b/devtools/gen-abi.sh
index f15a3b9aaf..61f7510ea1 100755
--- a/devtools/gen-abi.sh
+++ b/devtools/gen-abi.sh
@@ -22,5 +22,6 @@ for f in $(find $installdir -name "*.so.*"); do
fi
libname=$(basename $f)
- abidw --out-file $dumpdir/${libname%.so*}.dump $f
-done
+ echo $dumpdir/${libname%.so*}.dump $f
+done |
+xargs -n2 -P0 abidw --out-file
--
2.39.0
^ permalink raw reply [relevance 33%]
* RE: [PATCH v2] cryptodev: add algo enums to string conversion APIs
2023-01-04 6:18 2% ` [PATCH v2] " Akhil Goyal
@ 2023-01-05 10:56 0% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2023-01-05 10:56 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, ruifeng.wang, Anoob Joseph,
radu.nicolau, Volodymyr Fialko, ktraynor, david.marchand, thomas
> Subject: [PATCH v2] cryptodev: add algo enums to string conversion APIs
>
> Symmetric/Asymmetric algorithm strings are accessed by application
> using arrays in cryptodev lib, which hampers new algorithms addition
> in the array due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> Acked-by: Anoob Joseph <anoobj@marvell.com>
> Acked-by: Ciara Power <ciara.power@intel.com>
> Acked-by: Fan Zhang <fanzhang.oss@gmail.com>
> ---
Applied to dpdk-next-crypto
^ permalink raw reply [relevance 0%]
* RE: [PATCH v3 1/3] ethdev: enable direct rearm with separate API
@ 2023-01-04 10:11 4% ` Morten Brørup
0 siblings, 0 replies; 200+ results
From: Morten Brørup @ 2023-01-04 10:11 UTC (permalink / raw)
To: Feifei Wang, thomas, Ferruh Yigit, Andrew Rybchenko
Cc: dev, konstantin.v.ananyev, nd, Honnappa Nagarahalli, Ruifeng Wang, nd
> From: Feifei Wang [mailto:Feifei.Wang2@arm.com]
> Sent: Wednesday, 4 January 2023 09.51
>
> Hi, Morten
>
> > 发件人: Morten Brørup <mb@smartsharesystems.com>
> > 发送时间: Wednesday, January 4, 2023 4:22 PM
> >
> > > From: Feifei Wang [mailto:feifei.wang2@arm.com]
> > > Sent: Wednesday, 4 January 2023 08.31
> > >
> > > Add 'tx_fill_sw_ring' and 'rx_flush_descriptor' API into direct
> rearm
> > > mode for separate Rx and Tx Operation. And this can support
> different
> > > multiple sources in direct rearm mode. For examples, Rx driver is
> > > ixgbe, and Tx driver is i40e.
> > >
> > > Suggested-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > Suggested-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > Signed-off-by: Feifei Wang <feifei.wang2@arm.com>
> > > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > > ---
> >
> > This feature looks very promising for performance. I am pleased to
> see
> > progress on it.
> >
> Thanks very much for your reviewing.
>
> > Please confirm that the fast path functions are still thread safe,
> i.e. one EAL
> > thread may be calling rte_eth_rx_burst() while another EAL thread is
> calling
> > rte_eth_tx_burst().
> >
> For the multiple threads safe, like we say in cover letter, current
> direct-rearm support
> Rx and Tx in the same thread. If we consider multiple threads like
> 'pipeline model', there
> need to add 'lock' in the data path which can decrease the performance.
> Thus, the first step we do is try to enable direct-rearm in the single
> thread, and then we will consider
> to enable direct rearm in multiple threads and improve the performance.
OK, doing it in steps is a good idea for a feature like this - makes it easier to understand and review.
When proceeding to add support for the "pipeline model", perhaps the lockless principles from the rte_ring can be used in this feature too.
From a high level perspective, I'm somewhat worried that releasing a "work-in-progress" version of this feature in some DPDK version will cause API/ABI breakage discussions when progressing to the next steps of the implementation to make the feature more complete. Not only support for thread safety across simultaneous RX and TX, but also support for multiple mbuf pools per RX queue [1]. Marking the functions experimental should alleviate such discussions, but there is a risk of pushback to not break the API/ABI anyway.
[1]: https://elixir.bootlin.com/dpdk/v22.11.1/source/lib/ethdev/rte_ethdev.h#L1105
[...]
> > > --- a/lib/ethdev/ethdev_driver.h
> > > +++ b/lib/ethdev/ethdev_driver.h
> > > @@ -59,6 +59,10 @@ struct rte_eth_dev {
> > > eth_rx_descriptor_status_t rx_descriptor_status;
> > > /** Check the status of a Tx descriptor */
> > > eth_tx_descriptor_status_t tx_descriptor_status;
> > > + /** Fill Rx sw-ring with Tx buffers in direct rearm mode */
> > > + eth_tx_fill_sw_ring_t tx_fill_sw_ring;
> >
> > What is "Rx sw-ring"? Please confirm that this is not an Intel PMD
> specific
> > term and/or implementation detail, e.g. by providing a conceptual
> > implementation for a non-Intel PMD, e.g. mlx5.
> Rx sw_ring is used to store mbufs in intel PMD. This is the same as
> 'rxq->elts'
> in mlx5.
Sounds good.
Then all we need is consensus on a generic name for this, unless "Rx sw-ring" already is the generic name. (I'm not a PMD developer, so I might be completely off track here.) Naming is often debatable, so I'll stop talking about it now - I only wanted to highlight that we should avoid vendor-specific terms in public APIs intended to be implemented by multiple vendors. On the other hand... if no other vendors raise their voices before merging into the DPDK main repository, they forfeit their right to complain about it. ;-)
> Agree with that we need to providing a conceptual
> implementation for all PMDs.
My main point is that we should ensure that the feature is not too tightly coupled with the way Intel PMDs implement mbuf handling. Providing a conceptual implementation for a non-Intel PMD is one way of checking this.
The actual implementation in other PMDs could be left up to the various NIC vendors.
^ permalink raw reply [relevance 4%]
* [PATCH v2] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 3% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
` (3 preceding siblings ...)
2022-12-14 9:32 0% ` Zhang, Fan
@ 2023-01-04 6:18 2% ` Akhil Goyal
2023-01-05 10:56 0% ` Akhil Goyal
4 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2023-01-04 6:18 UTC (permalink / raw)
To: dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, ruifeng.wang, anoobj,
radu.nicolau, vfialko, ktraynor, david.marchand, thomas,
Akhil Goyal
Symmetric/Asymmetric algorithm strings are accessed by application
using arrays in cryptodev lib, which hampers new algorithms addition
in the array due to ABI breakage.
These arrays are now deprecated and will be removed in next ABI break
release.
New APIs are added for getting the algorithm strings based on enum values.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
Acked-by: Ciara Power <ciara.power@intel.com>
Acked-by: Fan Zhang <fanzhang.oss@gmail.com>
---
Changes in v2: fixed Windows compilation
app/test-crypto-perf/cperf_options_parsing.c | 6 +-
app/test/test_cryptodev_asym.c | 2 +-
app/test/test_cryptodev_security_ipsec.c | 8 +-
doc/guides/rel_notes/deprecation.rst | 7 +
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
drivers/crypto/qat/qat_sym_session.c | 7 +-
examples/l2fwd-crypto/main.c | 12 +-
lib/cryptodev/cryptodev_trace_points.c | 12 ++
lib/cryptodev/rte_crypto_asym.h | 1 +
lib/cryptodev/rte_crypto_sym.h | 3 +
lib/cryptodev/rte_cryptodev.c | 183 ++++++++++++++++++-
lib/cryptodev/rte_cryptodev.h | 52 ++++++
lib/cryptodev/rte_cryptodev_trace.h | 32 ++++
lib/cryptodev/version.map | 10 +
14 files changed, 310 insertions(+), 27 deletions(-)
diff --git a/app/test-crypto-perf/cperf_options_parsing.c b/app/test-crypto-perf/cperf_options_parsing.c
index bc5e312c81..f8ddb6ac56 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c
@@ -1373,7 +1373,7 @@ cperf_options_dump(struct cperf_options *opts)
opts->op_type == CPERF_CIPHER_THEN_AUTH ||
opts->op_type == CPERF_AUTH_THEN_CIPHER) {
printf("# auth algorithm: %s\n",
- rte_crypto_auth_algorithm_strings[opts->auth_algo]);
+ rte_cryptodev_get_auth_algo_string(opts->auth_algo));
printf("# auth operation: %s\n",
rte_crypto_auth_operation_strings[opts->auth_op]);
printf("# auth key size: %u\n", opts->auth_key_sz);
@@ -1386,7 +1386,7 @@ cperf_options_dump(struct cperf_options *opts)
opts->op_type == CPERF_CIPHER_THEN_AUTH ||
opts->op_type == CPERF_AUTH_THEN_CIPHER) {
printf("# cipher algorithm: %s\n",
- rte_crypto_cipher_algorithm_strings[opts->cipher_algo]);
+ rte_cryptodev_get_cipher_algo_string(opts->cipher_algo));
printf("# cipher operation: %s\n",
rte_crypto_cipher_operation_strings[opts->cipher_op]);
printf("# cipher key size: %u\n", opts->cipher_key_sz);
@@ -1396,7 +1396,7 @@ cperf_options_dump(struct cperf_options *opts)
if (opts->op_type == CPERF_AEAD) {
printf("# aead algorithm: %s\n",
- rte_crypto_aead_algorithm_strings[opts->aead_algo]);
+ rte_cryptodev_get_aead_algo_string(opts->aead_algo));
printf("# aead operation: %s\n",
rte_crypto_aead_operation_strings[opts->aead_op]);
printf("# aead key size: %u\n", opts->aead_key_sz);
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index c58c7f488b..5b16dcab56 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -974,7 +974,7 @@ static inline void print_asym_capa(
int i = 0;
printf("\nxform type: %s\n===================\n",
- rte_crypto_asym_xform_strings[capa->xform_type]);
+ rte_cryptodev_asym_get_xform_string(capa->xform_type));
printf("operation supported -");
for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
diff --git a/app/test/test_cryptodev_security_ipsec.c b/app/test/test_cryptodev_security_ipsec.c
index 833be94c09..417ff10a1b 100644
--- a/app/test/test_cryptodev_security_ipsec.c
+++ b/app/test/test_cryptodev_security_ipsec.c
@@ -625,20 +625,20 @@ test_ipsec_display_alg(const struct crypto_param *param1,
{
if (param1->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
printf("\t%s [%d]",
- rte_crypto_aead_algorithm_strings[param1->alg.aead],
+ rte_cryptodev_get_aead_algo_string(param1->alg.aead),
param1->key_length * 8);
} else if (param1->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
printf("\t%s",
- rte_crypto_auth_algorithm_strings[param1->alg.auth]);
+ rte_cryptodev_get_auth_algo_string(param1->alg.auth));
if (param1->alg.auth != RTE_CRYPTO_AUTH_NULL)
printf(" [%dB ICV]", param1->digest_length);
} else {
printf("\t%s",
- rte_crypto_cipher_algorithm_strings[param1->alg.cipher]);
+ rte_cryptodev_get_cipher_algo_string(param1->alg.cipher));
if (param1->alg.cipher != RTE_CRYPTO_CIPHER_NULL)
printf(" [%d]", param1->key_length * 8);
printf(" %s",
- rte_crypto_auth_algorithm_strings[param2->alg.auth]);
+ rte_cryptodev_get_auth_algo_string(param2->alg.auth));
if (param2->alg.auth != RTE_CRYPTO_AUTH_NULL)
printf(" [%dB ICV]", param2->digest_length);
}
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b9b02dcef0..e18ac344ef 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -114,6 +114,13 @@ Deprecation Notices
which got error interrupt to the application,
so that application can reset that particular queue pair.
+* cryptodev: The arrays of algorithm strings ``rte_crypto_cipher_algorithm_strings``,
+ ``rte_crypto_auth_algorithm_strings``, ``rte_crypto_aead_algorithm_strings`` and
+ ``rte_crypto_asym_xform_strings`` are deprecated and will be removed in DPDK 23.11.
+ Application can use the new APIs ``rte_cryptodev_get_cipher_algo_string``,
+ ``rte_cryptodev_get_auth_algo_string``, ``rte_cryptodev_get_aead_algo_string`` and
+ ``rte_cryptodev_asym_get_xform_string`` respectively.
+
* flow_classify: The flow_classify library and example have no maintainer.
The library is experimental and, as such, it could be removed from DPDK.
Its removal has been postponed to let potential users report interest
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index defed4429e..29ad1b9505 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -823,7 +823,7 @@ static int openssl_set_asym_session_parameters(
if ((xform->xform_type != RTE_CRYPTO_ASYM_XFORM_DH) &&
(xform->next != NULL)) {
OPENSSL_LOG(ERR, "chained xfrms are not supported on %s",
- rte_crypto_asym_xform_strings[xform->xform_type]);
+ rte_cryptodev_asym_get_xform_string(xform->xform_type));
return ret;
}
diff --git a/drivers/crypto/qat/qat_sym_session.c b/drivers/crypto/qat/qat_sym_session.c
index 0ebc66f89e..714002dce3 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -436,8 +436,8 @@ qat_sym_session_configure_cipher(struct rte_cryptodev *dev,
if (!qat_is_cipher_alg_supported(
cipher_xform->algo, internals)) {
QAT_LOG(ERR, "%s not supported on this device",
- rte_crypto_cipher_algorithm_strings
- [cipher_xform->algo]);
+ rte_cryptodev_get_cipher_algo_string(
+ cipher_xform->algo));
ret = -ENOTSUP;
goto error_out;
}
@@ -772,8 +772,7 @@ qat_sym_session_configure_auth(struct rte_cryptodev *dev,
case RTE_CRYPTO_AUTH_ZUC_EIA3:
if (!qat_is_auth_alg_supported(auth_xform->algo, internals)) {
QAT_LOG(ERR, "%s not supported on this device",
- rte_crypto_auth_algorithm_strings
- [auth_xform->algo]);
+ rte_cryptodev_get_auth_algo_string(auth_xform->algo));
return -ENOTSUP;
}
session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_ZUC_3G_128_EIA3;
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index b13e5c526e..efe7eea2a7 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1536,7 +1536,7 @@ display_cipher_info(struct l2fwd_crypto_options *options)
{
printf("\n---- Cipher information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_cipher_algorithm_strings[options->cipher_xform.cipher.algo]);
+ rte_cryptodev_get_cipher_algo_string(options->cipher_xform.cipher.algo));
rte_hexdump(stdout, "Cipher key:",
options->cipher_xform.cipher.key.data,
options->cipher_xform.cipher.key.length);
@@ -1548,7 +1548,7 @@ display_auth_info(struct l2fwd_crypto_options *options)
{
printf("\n---- Authentication information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_auth_algorithm_strings[options->auth_xform.auth.algo]);
+ rte_cryptodev_get_auth_algo_string(options->auth_xform.auth.algo));
rte_hexdump(stdout, "Auth key:",
options->auth_xform.auth.key.data,
options->auth_xform.auth.key.length);
@@ -1560,7 +1560,7 @@ display_aead_info(struct l2fwd_crypto_options *options)
{
printf("\n---- AEAD information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_aead_algorithm_strings[options->aead_xform.aead.algo]);
+ rte_cryptodev_get_aead_algo_string(options->aead_xform.aead.algo));
rte_hexdump(stdout, "AEAD key:",
options->aead_xform.aead.key.data,
options->aead_xform.aead.key.length);
@@ -1864,7 +1864,7 @@ check_device_support_cipher_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_cipher_algorithm_strings[opt_cipher_algo],
+ rte_cryptodev_get_cipher_algo_string(opt_cipher_algo),
cdev_id,
options->string_type);
return NULL;
@@ -1898,7 +1898,7 @@ check_device_support_auth_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_auth_algorithm_strings[opt_auth_algo],
+ rte_cryptodev_get_auth_algo_string(opt_auth_algo),
cdev_id,
options->string_type);
return NULL;
@@ -1932,7 +1932,7 @@ check_device_support_aead_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_aead_algorithm_strings[opt_aead_algo],
+ rte_cryptodev_get_aead_algo_string(opt_aead_algo),
cdev_id,
options->string_type);
return NULL;
diff --git a/lib/cryptodev/cryptodev_trace_points.c b/lib/cryptodev/cryptodev_trace_points.c
index 63a81511a9..4980bcc9be 100644
--- a/lib/cryptodev/cryptodev_trace_points.c
+++ b/lib/cryptodev/cryptodev_trace_points.c
@@ -72,6 +72,15 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_enum,
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_enum,
lib.cryptodev.get.cipher.algo.enum)
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_aead_algo_string,
+ lib.cryptodev.get.aead.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_string,
+ lib.cryptodev.get.auth.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_string,
+ lib.cryptodev.get.cipher.algo.string)
+
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_dev_id,
lib.cryptodev.get.dev.id)
@@ -126,6 +135,9 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_private_session_size,
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_enum,
lib.cryptodev.asym.get.xform.enum)
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_string,
+ lib.cryptodev.asym.get.xform.string)
+
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_xform_capability_check_modlen,
lib.cryptodev.asym.xform.capability.check.modlen)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 38c8b60779..989f38323f 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -30,6 +30,7 @@ extern "C" {
struct rte_cryptodev_asym_session;
/** asym xform type name strings */
+__rte_deprecated
extern const char *
rte_crypto_asym_xform_strings[];
diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
index 33b4966e16..dc847da7b8 100644
--- a/lib/cryptodev/rte_crypto_sym.h
+++ b/lib/cryptodev/rte_crypto_sym.h
@@ -177,6 +177,7 @@ enum rte_crypto_cipher_algorithm {
};
/** Cipher algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_cipher_algorithm_strings[];
@@ -378,6 +379,7 @@ enum rte_crypto_auth_algorithm {
};
/** Authentication algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_auth_algorithm_strings[];
@@ -482,6 +484,7 @@ enum rte_crypto_aead_algorithm {
};
/** AEAD algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_aead_algorithm_strings[];
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..742a4c512e 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -64,9 +64,11 @@ struct rte_cryptodev_callback {
};
/**
+ * @deprecated
* The crypto cipher algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_cipher_algorithm_strings[] = {
[RTE_CRYPTO_CIPHER_3DES_CBC] = "3des-cbc",
@@ -95,6 +97,39 @@ rte_crypto_cipher_algorithm_strings[] = {
[RTE_CRYPTO_CIPHER_SM4_CTR] = "sm4-ctr"
};
+/**
+ * The crypto cipher algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_cipher_algo_string().
+ */
+static const char *
+crypto_cipher_algorithm_strings[] = {
+ [RTE_CRYPTO_CIPHER_3DES_CBC] = "3des-cbc",
+ [RTE_CRYPTO_CIPHER_3DES_ECB] = "3des-ecb",
+ [RTE_CRYPTO_CIPHER_3DES_CTR] = "3des-ctr",
+
+ [RTE_CRYPTO_CIPHER_AES_CBC] = "aes-cbc",
+ [RTE_CRYPTO_CIPHER_AES_CTR] = "aes-ctr",
+ [RTE_CRYPTO_CIPHER_AES_DOCSISBPI] = "aes-docsisbpi",
+ [RTE_CRYPTO_CIPHER_AES_ECB] = "aes-ecb",
+ [RTE_CRYPTO_CIPHER_AES_F8] = "aes-f8",
+ [RTE_CRYPTO_CIPHER_AES_XTS] = "aes-xts",
+
+ [RTE_CRYPTO_CIPHER_ARC4] = "arc4",
+
+ [RTE_CRYPTO_CIPHER_DES_CBC] = "des-cbc",
+ [RTE_CRYPTO_CIPHER_DES_DOCSISBPI] = "des-docsisbpi",
+
+ [RTE_CRYPTO_CIPHER_NULL] = "null",
+
+ [RTE_CRYPTO_CIPHER_KASUMI_F8] = "kasumi-f8",
+ [RTE_CRYPTO_CIPHER_SNOW3G_UEA2] = "snow3g-uea2",
+ [RTE_CRYPTO_CIPHER_ZUC_EEA3] = "zuc-eea3",
+ [RTE_CRYPTO_CIPHER_SM4_ECB] = "sm4-ecb",
+ [RTE_CRYPTO_CIPHER_SM4_CBC] = "sm4-cbc",
+ [RTE_CRYPTO_CIPHER_SM4_CTR] = "sm4-ctr"
+};
+
/**
* The crypto cipher operation strings identifiers.
* It could be used in application command line.
@@ -106,9 +141,11 @@ rte_crypto_cipher_operation_strings[] = {
};
/**
+ * @deprecated
* The crypto auth algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_auth_algorithm_strings[] = {
[RTE_CRYPTO_AUTH_AES_CBC_MAC] = "aes-cbc-mac",
@@ -149,9 +186,55 @@ rte_crypto_auth_algorithm_strings[] = {
};
/**
+ * The crypto auth algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_auth_algo_string().
+ */
+static const char *
+crypto_auth_algorithm_strings[] = {
+ [RTE_CRYPTO_AUTH_AES_CBC_MAC] = "aes-cbc-mac",
+ [RTE_CRYPTO_AUTH_AES_CMAC] = "aes-cmac",
+ [RTE_CRYPTO_AUTH_AES_GMAC] = "aes-gmac",
+ [RTE_CRYPTO_AUTH_AES_XCBC_MAC] = "aes-xcbc-mac",
+
+ [RTE_CRYPTO_AUTH_MD5] = "md5",
+ [RTE_CRYPTO_AUTH_MD5_HMAC] = "md5-hmac",
+
+ [RTE_CRYPTO_AUTH_NULL] = "null",
+
+ [RTE_CRYPTO_AUTH_SHA1] = "sha1",
+ [RTE_CRYPTO_AUTH_SHA1_HMAC] = "sha1-hmac",
+
+ [RTE_CRYPTO_AUTH_SHA224] = "sha2-224",
+ [RTE_CRYPTO_AUTH_SHA224_HMAC] = "sha2-224-hmac",
+ [RTE_CRYPTO_AUTH_SHA256] = "sha2-256",
+ [RTE_CRYPTO_AUTH_SHA256_HMAC] = "sha2-256-hmac",
+ [RTE_CRYPTO_AUTH_SHA384] = "sha2-384",
+ [RTE_CRYPTO_AUTH_SHA384_HMAC] = "sha2-384-hmac",
+ [RTE_CRYPTO_AUTH_SHA512] = "sha2-512",
+ [RTE_CRYPTO_AUTH_SHA512_HMAC] = "sha2-512-hmac",
+
+ [RTE_CRYPTO_AUTH_SHA3_224] = "sha3-224",
+ [RTE_CRYPTO_AUTH_SHA3_224_HMAC] = "sha3-224-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_256] = "sha3-256",
+ [RTE_CRYPTO_AUTH_SHA3_256_HMAC] = "sha3-256-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_384] = "sha3-384",
+ [RTE_CRYPTO_AUTH_SHA3_384_HMAC] = "sha3-384-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_512] = "sha3-512",
+ [RTE_CRYPTO_AUTH_SHA3_512_HMAC] = "sha3-512-hmac",
+
+ [RTE_CRYPTO_AUTH_KASUMI_F9] = "kasumi-f9",
+ [RTE_CRYPTO_AUTH_SNOW3G_UIA2] = "snow3g-uia2",
+ [RTE_CRYPTO_AUTH_ZUC_EIA3] = "zuc-eia3",
+ [RTE_CRYPTO_AUTH_SM3] = "sm3"
+};
+
+/**
+ * @deprecated
* The crypto AEAD algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_aead_algorithm_strings[] = {
[RTE_CRYPTO_AEAD_AES_CCM] = "aes-ccm",
@@ -159,6 +242,19 @@ rte_crypto_aead_algorithm_strings[] = {
[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
};
+/**
+ * The crypto AEAD algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_aead_algo_string().
+ */
+static const char *
+crypto_aead_algorithm_strings[] = {
+ [RTE_CRYPTO_AEAD_AES_CCM] = "aes-ccm",
+ [RTE_CRYPTO_AEAD_AES_GCM] = "aes-gcm",
+ [RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
+};
+
+
/**
* The crypto AEAD operation strings identifiers.
* It could be used in application command line.
@@ -170,8 +266,10 @@ rte_crypto_aead_operation_strings[] = {
};
/**
+ * @deprecated
* Asymmetric crypto transform operation strings identifiers.
*/
+__rte_deprecated
const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_NONE] = "none",
[RTE_CRYPTO_ASYM_XFORM_RSA] = "rsa",
@@ -183,6 +281,23 @@ const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
};
+/**
+ * Asymmetric crypto transform operation strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_asym_get_xform_string().
+ */
+static const char *
+crypto_asym_xform_strings[] = {
+ [RTE_CRYPTO_ASYM_XFORM_NONE] = "none",
+ [RTE_CRYPTO_ASYM_XFORM_RSA] = "rsa",
+ [RTE_CRYPTO_ASYM_XFORM_MODEX] = "modexp",
+ [RTE_CRYPTO_ASYM_XFORM_MODINV] = "modinv",
+ [RTE_CRYPTO_ASYM_XFORM_DH] = "dh",
+ [RTE_CRYPTO_ASYM_XFORM_DSA] = "dsa",
+ [RTE_CRYPTO_ASYM_XFORM_ECDSA] = "ecdsa",
+ [RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
+};
+
/**
* Asymmetric crypto operation strings identifiers.
*/
@@ -227,8 +342,8 @@ rte_cryptodev_get_cipher_algo_enum(enum rte_crypto_cipher_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_cipher_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_cipher_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_cipher_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_cipher_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_cipher_algorithm) i;
ret = 0;
break;
@@ -247,8 +362,8 @@ rte_cryptodev_get_auth_algo_enum(enum rte_crypto_auth_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_auth_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_auth_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_auth_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_auth_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_auth_algorithm) i;
ret = 0;
break;
@@ -267,8 +382,8 @@ rte_cryptodev_get_aead_algo_enum(enum rte_crypto_aead_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_aead_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_aead_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_aead_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_aead_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_aead_algorithm) i;
ret = 0;
break;
@@ -287,9 +402,9 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_asym_xform_strings); i++) {
+ for (i = 1; i < RTE_DIM(crypto_asym_xform_strings); i++) {
if (strcmp(xform_string,
- rte_crypto_asym_xform_strings[i]) == 0) {
+ crypto_asym_xform_strings[i]) == 0) {
*xform_enum = (enum rte_crypto_asym_xform_type) i;
ret = 0;
break;
@@ -301,6 +416,58 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
return ret;
}
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if ((unsigned int)algo_enum < RTE_DIM(crypto_cipher_algorithm_strings))
+ alg_str = crypto_cipher_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_cipher_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if ((unsigned int)algo_enum < RTE_DIM(crypto_auth_algorithm_strings))
+ alg_str = crypto_auth_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_auth_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if ((unsigned int)algo_enum < RTE_DIM(crypto_aead_algorithm_strings))
+ alg_str = crypto_aead_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_aead_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum)
+{
+ const char *xform_str = NULL;
+
+ if ((unsigned int)xform_enum < RTE_DIM(crypto_asym_xform_strings))
+ xform_str = crypto_asym_xform_strings[xform_enum];
+
+ rte_cryptodev_trace_asym_get_xform_string(xform_enum, xform_str);
+
+ return xform_str;
+}
+
/**
* The crypto auth operation strings identifiers.
* It could be used in application command line.
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 86d792e2e7..8f41a009e3 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -406,6 +406,58 @@ int
rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
const char *xform_string);
+/**
+ * Provide the cipher algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum cipher algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum);
+
+/**
+ * Provide the authentication algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum auth algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum);
+
+/**
+ * Provide the AEAD algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum AEAD algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum);
+
+/**
+ * Provide the Asymmetric xform string, given an xform enum.
+ *
+ * @param xform_enum xform type enum
+ *
+ * @return
+ * - Return NULL, if enum is not valid.
+ * - Return xform string, for valid enum.
+ */
+__rte_experimental
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum);
+
/** Macro used at end of crypto PMD list */
#define RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() \
diff --git a/lib/cryptodev/rte_cryptodev_trace.h b/lib/cryptodev/rte_cryptodev_trace.h
index 6c214ce6ea..5e694379b1 100644
--- a/lib/cryptodev/rte_cryptodev_trace.h
+++ b/lib/cryptodev/rte_cryptodev_trace.h
@@ -189,6 +189,30 @@ RTE_TRACE_POINT(
rte_trace_point_emit_int(ret);
)
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_aead_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_aead_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_auth_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_auth_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_cipher_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_cipher_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
RTE_TRACE_POINT(
rte_cryptodev_trace_get_dev_id,
RTE_TRACE_POINT_ARGS(const char *name, int ret),
@@ -351,6 +375,14 @@ RTE_TRACE_POINT(
rte_trace_point_emit_int(ret);
)
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_asym_get_xform_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_asym_xform_type xform_enum,
+ const char *xform_string),
+ rte_trace_point_emit_int(xform_enum);
+ rte_trace_point_emit_string(xform_string);
+)
+
RTE_TRACE_POINT(
rte_cryptodev_trace_asym_xform_capability_check_modlen,
RTE_TRACE_POINT_ARGS(const void *capability, uint16_t modlen, int ret),
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index 00c99fb45c..372d042931 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -150,11 +150,21 @@ EXPERIMENTAL {
__rte_cryptodev_trace_sym_session_get_user_data;
__rte_cryptodev_trace_sym_session_set_user_data;
__rte_cryptodev_trace_count;
+
+ # added 23.03
+ rte_cryptodev_asym_get_xform_string;
+ rte_cryptodev_get_aead_algo_string;
+ rte_cryptodev_get_auth_algo_string;
+ rte_cryptodev_get_cipher_algo_string;
};
INTERNAL {
global:
+ __rte_cryptodev_trace_asym_get_xform_string;
+ __rte_cryptodev_trace_get_aead_algo_string;
+ __rte_cryptodev_trace_get_auth_algo_string;
+ __rte_cryptodev_trace_get_cipher_algo_string;
cryptodev_fp_ops_reset;
cryptodev_fp_ops_set;
rte_cryptodev_allocate_driver;
--
2.25.1
^ permalink raw reply [relevance 2%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 14:33 3% ` Rongwei Liu
@ 2022-12-26 16:44 4% ` Ori Kam
2023-01-15 22:46 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Ori Kam @ 2022-12-26 16:44 UTC (permalink / raw)
To: Rongwei Liu, Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
Hi Rongwei and Jerin,
> -----Original Message-----
> From: Rongwei Liu <rongweil@nvidia.com>
> Sent: Wednesday, 21 December 2022 16:33
>
> HI Jerin:
>
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 21:12
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or
> standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > >
> > > HI Jerin:
> > >
> > > BR
> > > Rongwei
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, December 21, 2022 20:45
> > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-
> Contact-
> > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > <rasland@nvidia.com>
> > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > > or standby
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com>
> > wrote:
> > > > >
> > > > > Hi Jerin:
> > > > >
> > > > > BR
> > > > > Rongwei
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > Sent: Wednesday, December 21, 2022 19:00
> > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL)
> <thomas@monjalon.net>;
> > > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan
> Darawsheh
> > > > > > <rasland@nvidia.com>
> > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > active or standby
> > > > > >
> > > > > > External email: Use caution opening links or attachments
> > > > > >
> > > > > >
> > > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu
> > > > > > <rongweil@nvidia.com>
> > > > wrote:
> > > > > > >
> > > > > > > HI Jerin:
> > > > > > >
> > > > > >
> > > > > > Hi Rongwei
> > > > > >
> > > > > > > BR
> > > > > > > Rongwei
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL)
> > > > > > > > <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>;
> > > > > > > > Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> > > > > > > > dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> > > > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > > > active or standby
> > > > > > > >
> > > > > > > > External email: Use caution opening links or attachments
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > > > > <rongweil@nvidia.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > > versions
> > > > > > > >
> > > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > > support
> > > > this?
> > > > > > > >
> > > > > > > There is a new member which was introduced into
> > > > > > > rte_eth_dev_info but it
> > > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > > >
> > > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > > different ethdev structure and rte_flow structures across
> > > > > > different DPDK
> > > > ABI versions.
> > > > > >
> > > > > Besides this, there is no other ABI changes dependency.
> > > > >
> > > > > Assume there is a DPDK process A running with version v21.11 and
> > > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > > >
> > > > OK. That's a relief. I understand the use case now.
> > > >
> > > > Why not simply use standard DPDK multiprocess model then.
> > > > Primary process act as server for slow path API. Secondary process
> > > > can come and go(aka can be updated at runtime) and use as client to
> > > > update rules via primary-secondray communication mechanism.
> > > >
> > > Just image if process A and process B have ABI breakage like different
> > rte_flow_item_*** and rte_flow_action_*** size and members.
> > > How can we quickly accommodate primary/secondary to be ABI
> compatible
> > across different versions?
> > > It will be very huge effort and difficult to implement, at least in my
> opinion.
> > > What do you think?
> >
> > Yes. it difficult what ever approach we take, On other hand, ethdev
> subsystem
> > has other components like rte_tm and other offload etc, We can not simply
> > have rte_eth_process_set_active() and things magical works across
> different
> > DPDK versions. Example, if rte_flow rule has meter action will depend on
> > another HW piece in NIC card for doing the metering but set by flow API.
> > IMO, Customer can simply use standard multiprocess model if version are
> > compatible without any special intelligence in application.
> > Otherwise they can reload and start the application again or have special
> > intelligence in application to cater the specific area of API they need to
> > leverage based on server and client DPDK versions.
>
> Thanks for the message.
> IMO, we are trying to eliminate the version/ABI dependency with this new
> added API.
> For example, if meter action is in the flow rules:
> 1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
> 2. Process B starts with "rte_eth_process_set_active(false, flags)"
>
> Just give Nvidia' hardware as example (other NIC vendors may not care if
> group 0 or not)
> If the process A' rules are in group 0, users should set them one by one to
> process B.
> Then either flush process A' rules or quit process A, then process B calls with
> "rte_eth_process_set_active(true, flags)"
> All is set.
> It will avoid complex operations with client/server model and avoid user mis-
> operation too.
> We should avoid reload as much as possible since reloading is very time
> consuming and may take up to few seconds.
> In this time slot, there is no application to handle the traffic, and everything is
> lost.
> For end user especially cloud service providers, they are sensitive to the
> traffic down time.
From my viewpoint the upgrade has nothing to do with DPDK as a library,
the upgrade may be because of application upgrade.
Unless I'm missing something, this API is not meant for API/ABI it is created
to allow minimum downtime when doing upgrade of the application.
Unless I'm missing something critical, since the upgrade in any case is not
only for the DPDK but the entire app, there isn't any ABI/API issue.
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 2/2] devtools: configure source repo to use as ABI reference
2022-12-09 9:02 13% ` [PATCH v2 2/2] devtools: configure source repo to use as ABI reference David Marchand
@ 2022-12-21 15:02 4% ` David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-21 15:02 UTC (permalink / raw)
To: dev; +Cc: thomas, bruce.richardson, gakhil, Ferruh Yigit
On Fri, Dec 9, 2022 at 10:02 AM David Marchand
<david.marchand@redhat.com> wrote:
>
> From: Ferruh Yigit <ferruh.yigit@amd.com>
>
> By default 'test-meson-builds.sh' script clones the repository which the
> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> as a reference for ABI check.
>
> This patch enables selecting different repository to clone for reference
> using 'DPDK_ABI_REF_SRC' environment variable.
> 'DPDK_ABI_REF_SRC' may refer to a directory containing a cloned git
> repository, or a remote git repository.
>
> It is possible to put these variables to 'devel.config' config file, or
> provide via command line, like:
> `
> DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable \
> DPDK_ABI_REF_VERSION=v22.11.1 \
> DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> ./devtools/test-meson-builds.sh
> `
>
> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> previously.
>
> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> other repo as a new 'remote' to the exiting git repository.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> Acked-by: Akhil Goyal <gakhil@marvell.com>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> ---
> Changes since v1:
> - expanded DPDK_ABI_REF_SRC usage to "non-local" sources,
Series applied, thanks.
--
David Marchand
^ permalink raw reply [relevance 4%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 13:12 0% ` Jerin Jacob
@ 2022-12-21 14:33 3% ` Rongwei Liu
2022-12-26 16:44 4% ` Ori Kam
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 14:33 UTC (permalink / raw)
To: Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
HI Jerin:
BR
Rongwei
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 21:12
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > HI Jerin:
> >
> > BR
> > Rongwei
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, December 21, 2022 20:45
> > > To: Rongwei Liu <rongweil@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > <rasland@nvidia.com>
> > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > or standby
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > > >
> > > > Hi Jerin:
> > > >
> > > > BR
> > > > Rongwei
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Wednesday, December 21, 2022 19:00
> > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > NBU-Contact- Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > > <rasland@nvidia.com>
> > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > active or standby
> > > > >
> > > > > External email: Use caution opening links or attachments
> > > > >
> > > > >
> > > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu
> > > > > <rongweil@nvidia.com>
> > > wrote:
> > > > > >
> > > > > > HI Jerin:
> > > > > >
> > > > >
> > > > > Hi Rongwei
> > > > >
> > > > > > BR
> > > > > > Rongwei
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL)
> > > > > > > <thomas@monjalon.net>; Ferruh Yigit <ferruh.yigit@amd.com>;
> > > > > > > Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> > > > > > > dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>
> > > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > > active or standby
> > > > > > >
> > > > > > > External email: Use caution opening links or attachments
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > > > <rongweil@nvidia.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Users may want to change the DPDK process to different
> > > > > > > > versions
> > > > > > >
> > > > > > > Different version of DPDK? If there is any ABI change how to
> > > > > > > support
> > > this?
> > > > > > >
> > > > > > There is a new member which was introduced into
> > > > > > rte_eth_dev_info but it
> > > > > shouldn’t be ABI breaking since using reserved fields.
> > > > >
> > > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > > different ethdev structure and rte_flow structures across
> > > > > different DPDK
> > > ABI versions.
> > > > >
> > > > Besides this, there is no other ABI changes dependency.
> > > >
> > > > Assume there is a DPDK process A running with version v21.11 and
> > > > plan to upgrade to version v22.11. Let' call v22.11 as process B.
> > >
> > > OK. That's a relief. I understand the use case now.
> > >
> > > Why not simply use standard DPDK multiprocess model then.
> > > Primary process act as server for slow path API. Secondary process
> > > can come and go(aka can be updated at runtime) and use as client to
> > > update rules via primary-secondray communication mechanism.
> > >
> > Just image if process A and process B have ABI breakage like different
> rte_flow_item_*** and rte_flow_action_*** size and members.
> > How can we quickly accommodate primary/secondary to be ABI compatible
> across different versions?
> > It will be very huge effort and difficult to implement, at least in my opinion.
> > What do you think?
>
> Yes. it difficult what ever approach we take, On other hand, ethdev subsystem
> has other components like rte_tm and other offload etc, We can not simply
> have rte_eth_process_set_active() and things magical works across different
> DPDK versions. Example, if rte_flow rule has meter action will depend on
> another HW piece in NIC card for doing the metering but set by flow API.
> IMO, Customer can simply use standard multiprocess model if version are
> compatible without any special intelligence in application.
> Otherwise they can reload and start the application again or have special
> intelligence in application to cater the specific area of API they need to
> leverage based on server and client DPDK versions.
Thanks for the message.
IMO, we are trying to eliminate the version/ABI dependency with this new added API.
For example, if meter action is in the flow rules:
1. Process A have rules like "eth / ipv4 src 1.1.1.1 / meter / queue / end"
2. Process B starts with "rte_eth_process_set_active(false, flags)"
Just give Nvidia' hardware as example (other NIC vendors may not care if group 0 or not)
If the process A' rules are in group 0, users should set them one by one to process B.
Then either flush process A' rules or quit process A, then process B calls with "rte_eth_process_set_active(true, flags)"
All is set.
It will avoid complex operations with client/server model and avoid user mis-operation too.
We should avoid reload as much as possible since reloading is very time consuming and may take up to few seconds.
In this time slot, there is no application to handle the traffic, and everything is lost.
For end user especially cloud service providers, they are sensitive to the traffic down time.
>
>
> > >
> > > >
> > > > Now, process A has been running for long time and has lot of rules
> > > configured. It' "active" role per this API definition.
> > > > Process B starts and it should call this API and set itself to
> > > > "standby" role and user can program the flow rules as they want
> > > > and
> > > different NIC vendors may have different recommendations. Nvidia
> > > suggests only program process B with group 0' rules now.
> > > >
> > > > The user should sync all desired configurations from process A to
> > > > process B, and process A starts to yield traffic like "delete all
> > > > group 0 rules
> > > for Nvidia' NICs" or quit.
> > > > After that process B calls this API and set itself to "active"
> > > > role, now the hot-
> > > upgrade finishes.
> > > >
> > > > > > > > such as hot upgrade.
> > > > > > > > There is a strong requirement to simplify the logic and
> > > > > > > > shorten the traffic downtime as much as possible.
> > > > > > > >
> > > > > > > > This update introduces new rte_eth process role definitions:
> > > > > > > > active or standby.
> > > > > > > >
> > > > > > > > The active role means rules are programmed to HW
> > > > > > > > immediately, and no
> > > > > > >
> > > > > > > Why it has to be specific only to rte_flow rule? If it
> > > > > > > spedieic to rte_flow, why it is in rte_eth_process_ name space?
> > > > > > For now, this design focuses on the flow rule offloading and
> > > > > > traffic
> > > > > redirection.
> > > > > > When switching process version, it' important to make sure
> > > > > > which
> > > > > application receives and handles the traffic.
> > > > >
> > > > > Changing the DPDK version runtime is just beyond rte_flow driver.
> > > >
> > > > It' not about changing DPDK version but upgrading DPDK from one
> > > > PMD
> > > version to another one.
> > > > Does the preceding example answer your question?
> > > > >
> > > > > > The changing should be effective across all probing eth
> > > > > > devices, that' why it
> > > > > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > > > > >
> > > > > > > Also, if we are moving the standby, What about the rule
> > > > > > > whose ABI is changed between versions?
> > > > > >
> > > > > > Like the comments mentioned: " Before role transition, all the
> > > > > > rules set by
> > > > > the active process should be flushed first. "
> > > > >
> > > > > What happens to rte_flow flow handles for existing ones which
> > > > > is created with version X?
> > > > > Also What if new version Y has ABI change in rte_flow_pattern
> > > > > and rte_flow_action structure?
> > > > >
> > > > > For me, If DPDK version change is needed, simply reload the
> > > > > application. This API will soon bloat, and it will be a mess if
> > > > > to start handling Different DPDK version which is not ABI compatible at
> all.
> > > > >
> > > > Yes, you are right. Reloading the application is the easiest way
> > > > but it may have a long time Window that traffic is lost. No
> > > > traffic arrives at
> > > process A or process B.
> > > > We are trying to simplify the reloading logic and minimize the
> > > > traffic down
> > > time as much as possible.
> > > > The approach may differentiate hugely between different NIC
> > > > vendors, so I think it should be better if DPDK can provide an abstract API.
> > > >
> > > > If process A and process B are ABI different, it doesn't matter.
> > > > 1. Call this API with process A means older ABI.
> > > > 2. Call this API with process B means newer ABI.
> > > > It' have process concept and working scope.
> > > >
> > > > >
> > > > >
> > > > >
> > > > > > > > behavior changed. This is the default state.
> > > > > > > > The standby role means rules are queued in the HW. If no
> > > > > > > > active roles alive or back to active, the rules are
> > > > > > > > effective
> > > immediately.
> > > > > > > >
> > > > > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 3%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 12:50 4% ` Rongwei Liu
@ 2022-12-21 13:12 0% ` Jerin Jacob
2022-12-21 14:33 3% ` Rongwei Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 13:12 UTC (permalink / raw)
To: Rongwei Liu
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
On Wed, Dec 21, 2022 at 6:20 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> HI Jerin:
>
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 20:45
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> > >
> > > Hi Jerin:
> > >
> > > BR
> > > Rongwei
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, December 21, 2022 19:00
> > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > <rasland@nvidia.com>
> > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > > or standby
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com>
> > wrote:
> > > > >
> > > > > HI Jerin:
> > > > >
> > > >
> > > > Hi Rongwei
> > > >
> > > > > BR
> > > > > Rongwei
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > > NBU-Contact- Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > > > <rasland@nvidia.com>
> > > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > > active or standby
> > > > > >
> > > > > > External email: Use caution opening links or attachments
> > > > > >
> > > > > >
> > > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > > <rongweil@nvidia.com>
> > > > wrote:
> > > > > > >
> > > > > > > Users may want to change the DPDK process to different
> > > > > > > versions
> > > > > >
> > > > > > Different version of DPDK? If there is any ABI change how to support
> > this?
> > > > > >
> > > > > There is a new member which was introduced into rte_eth_dev_info
> > > > > but it
> > > > shouldn’t be ABI breaking since using reserved fields.
> > > >
> > > > That is just for rte_eth_dev_info. What about the ABI change in
> > > > different ethdev structure and rte_flow structures across different DPDK
> > ABI versions.
> > > >
> > > Besides this, there is no other ABI changes dependency.
> > >
> > > Assume there is a DPDK process A running with version v21.11 and plan
> > > to upgrade to version v22.11. Let' call v22.11 as process B.
> >
> > OK. That's a relief. I understand the use case now.
> >
> > Why not simply use standard DPDK multiprocess model then.
> > Primary process act as server for slow path API. Secondary process can come
> > and go(aka can be updated at runtime) and use as client to update rules via
> > primary-secondray communication mechanism.
> >
> Just image if process A and process B have ABI breakage like different rte_flow_item_*** and rte_flow_action_*** size and members.
> How can we quickly accommodate primary/secondary to be ABI compatible across different versions?
> It will be very huge effort and difficult to implement, at least in my opinion.
> What do you think?
Yes. it difficult what ever approach we take,
On other hand, ethdev subsystem has other components like rte_tm and
other offload etc, We can not simply have rte_eth_process_set_active()
and things magical works across different DPDK versions. Example, if
rte_flow rule has meter action will depend on another HW piece in NIC
card for doing the metering but set by flow API.
IMO, Customer can simply use standard multiprocess model if version
are compatible without any special intelligence in application.
Otherwise they can reload and start the application again
or have special intelligence in application to cater the specific area
of API they need to leverage based on server and client DPDK versions.
> >
> > >
> > > Now, process A has been running for long time and has lot of rules
> > configured. It' "active" role per this API definition.
> > > Process B starts and it should call this API and set itself to
> > > "standby" role and user can program the flow rules as they want and
> > different NIC vendors may have different recommendations. Nvidia suggests
> > only program process B with group 0' rules now.
> > >
> > > The user should sync all desired configurations from process A to
> > > process B, and process A starts to yield traffic like "delete all group 0 rules
> > for Nvidia' NICs" or quit.
> > > After that process B calls this API and set itself to "active" role, now the hot-
> > upgrade finishes.
> > >
> > > > > > > such as hot upgrade.
> > > > > > > There is a strong requirement to simplify the logic and
> > > > > > > shorten the traffic downtime as much as possible.
> > > > > > >
> > > > > > > This update introduces new rte_eth process role definitions:
> > > > > > > active or standby.
> > > > > > >
> > > > > > > The active role means rules are programmed to HW immediately,
> > > > > > > and no
> > > > > >
> > > > > > Why it has to be specific only to rte_flow rule? If it spedieic
> > > > > > to rte_flow, why it is in rte_eth_process_ name space?
> > > > > For now, this design focuses on the flow rule offloading and
> > > > > traffic
> > > > redirection.
> > > > > When switching process version, it' important to make sure which
> > > > application receives and handles the traffic.
> > > >
> > > > Changing the DPDK version runtime is just beyond rte_flow driver.
> > >
> > > It' not about changing DPDK version but upgrading DPDK from one PMD
> > version to another one.
> > > Does the preceding example answer your question?
> > > >
> > > > > The changing should be effective across all probing eth devices,
> > > > > that' why it
> > > > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > > > >
> > > > > > Also, if we are moving the standby, What about the rule whose
> > > > > > ABI is changed between versions?
> > > > >
> > > > > Like the comments mentioned: " Before role transition, all the
> > > > > rules set by
> > > > the active process should be flushed first. "
> > > >
> > > > What happens to rte_flow flow handles for existing ones which is
> > > > created with version X?
> > > > Also What if new version Y has ABI change in rte_flow_pattern and
> > > > rte_flow_action structure?
> > > >
> > > > For me, If DPDK version change is needed, simply reload the
> > > > application. This API will soon bloat, and it will be a mess if to
> > > > start handling Different DPDK version which is not ABI compatible at all.
> > > >
> > > Yes, you are right. Reloading the application is the easiest way but
> > > it may have a long time Window that traffic is lost. No traffic arrives at
> > process A or process B.
> > > We are trying to simplify the reloading logic and minimize the traffic down
> > time as much as possible.
> > > The approach may differentiate hugely between different NIC vendors,
> > > so I think it should be better if DPDK can provide an abstract API.
> > >
> > > If process A and process B are ABI different, it doesn't matter.
> > > 1. Call this API with process A means older ABI.
> > > 2. Call this API with process B means newer ABI.
> > > It' have process concept and working scope.
> > >
> > > >
> > > >
> > > >
> > > > > > > behavior changed. This is the default state.
> > > > > > > The standby role means rules are queued in the HW. If no
> > > > > > > active roles alive or back to active, the rules are effective
> > immediately.
> > > > > > >
> > > > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 0%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 12:44 0% ` Jerin Jacob
@ 2022-12-21 12:50 4% ` Rongwei Liu
2022-12-21 13:12 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 12:50 UTC (permalink / raw)
To: Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
HI Jerin:
BR
Rongwei
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 20:45
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > Hi Jerin:
> >
> > BR
> > Rongwei
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, December 21, 2022 19:00
> > > To: Rongwei Liu <rongweil@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > <rasland@nvidia.com>
> > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > or standby
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > > >
> > > > HI Jerin:
> > > >
> > >
> > > Hi Rongwei
> > >
> > > > BR
> > > > Rongwei
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > > Sent: Wednesday, December 21, 2022 17:13
> > > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> > > > > NBU-Contact- Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>;
> > > > > Ferruh Yigit <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > > <rasland@nvidia.com>
> > > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to
> > > > > active or standby
> > > > >
> > > > > External email: Use caution opening links or attachments
> > > > >
> > > > >
> > > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu
> > > > > <rongweil@nvidia.com>
> > > wrote:
> > > > > >
> > > > > > Users may want to change the DPDK process to different
> > > > > > versions
> > > > >
> > > > > Different version of DPDK? If there is any ABI change how to support
> this?
> > > > >
> > > > There is a new member which was introduced into rte_eth_dev_info
> > > > but it
> > > shouldn’t be ABI breaking since using reserved fields.
> > >
> > > That is just for rte_eth_dev_info. What about the ABI change in
> > > different ethdev structure and rte_flow structures across different DPDK
> ABI versions.
> > >
> > Besides this, there is no other ABI changes dependency.
> >
> > Assume there is a DPDK process A running with version v21.11 and plan
> > to upgrade to version v22.11. Let' call v22.11 as process B.
>
> OK. That's a relief. I understand the use case now.
>
> Why not simply use standard DPDK multiprocess model then.
> Primary process act as server for slow path API. Secondary process can come
> and go(aka can be updated at runtime) and use as client to update rules via
> primary-secondray communication mechanism.
>
Just image if process A and process B have ABI breakage like different rte_flow_item_*** and rte_flow_action_*** size and members.
How can we quickly accommodate primary/secondary to be ABI compatible across different versions?
It will be very huge effort and difficult to implement, at least in my opinion.
What do you think?
>
> >
> > Now, process A has been running for long time and has lot of rules
> configured. It' "active" role per this API definition.
> > Process B starts and it should call this API and set itself to
> > "standby" role and user can program the flow rules as they want and
> different NIC vendors may have different recommendations. Nvidia suggests
> only program process B with group 0' rules now.
> >
> > The user should sync all desired configurations from process A to
> > process B, and process A starts to yield traffic like "delete all group 0 rules
> for Nvidia' NICs" or quit.
> > After that process B calls this API and set itself to "active" role, now the hot-
> upgrade finishes.
> >
> > > > > > such as hot upgrade.
> > > > > > There is a strong requirement to simplify the logic and
> > > > > > shorten the traffic downtime as much as possible.
> > > > > >
> > > > > > This update introduces new rte_eth process role definitions:
> > > > > > active or standby.
> > > > > >
> > > > > > The active role means rules are programmed to HW immediately,
> > > > > > and no
> > > > >
> > > > > Why it has to be specific only to rte_flow rule? If it spedieic
> > > > > to rte_flow, why it is in rte_eth_process_ name space?
> > > > For now, this design focuses on the flow rule offloading and
> > > > traffic
> > > redirection.
> > > > When switching process version, it' important to make sure which
> > > application receives and handles the traffic.
> > >
> > > Changing the DPDK version runtime is just beyond rte_flow driver.
> >
> > It' not about changing DPDK version but upgrading DPDK from one PMD
> version to another one.
> > Does the preceding example answer your question?
> > >
> > > > The changing should be effective across all probing eth devices,
> > > > that' why it
> > > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > > >
> > > > > Also, if we are moving the standby, What about the rule whose
> > > > > ABI is changed between versions?
> > > >
> > > > Like the comments mentioned: " Before role transition, all the
> > > > rules set by
> > > the active process should be flushed first. "
> > >
> > > What happens to rte_flow flow handles for existing ones which is
> > > created with version X?
> > > Also What if new version Y has ABI change in rte_flow_pattern and
> > > rte_flow_action structure?
> > >
> > > For me, If DPDK version change is needed, simply reload the
> > > application. This API will soon bloat, and it will be a mess if to
> > > start handling Different DPDK version which is not ABI compatible at all.
> > >
> > Yes, you are right. Reloading the application is the easiest way but
> > it may have a long time Window that traffic is lost. No traffic arrives at
> process A or process B.
> > We are trying to simplify the reloading logic and minimize the traffic down
> time as much as possible.
> > The approach may differentiate hugely between different NIC vendors,
> > so I think it should be better if DPDK can provide an abstract API.
> >
> > If process A and process B are ABI different, it doesn't matter.
> > 1. Call this API with process A means older ABI.
> > 2. Call this API with process B means newer ABI.
> > It' have process concept and working scope.
> >
> > >
> > >
> > >
> > > > > > behavior changed. This is the default state.
> > > > > > The standby role means rules are queued in the HW. If no
> > > > > > active roles alive or back to active, the rules are effective
> immediately.
> > > > > >
> > > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 4%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 12:05 5% ` Rongwei Liu
@ 2022-12-21 12:44 0% ` Jerin Jacob
2022-12-21 12:50 4% ` Rongwei Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 12:44 UTC (permalink / raw)
To: Rongwei Liu
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
On Wed, Dec 21, 2022 at 5:35 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> Hi Jerin:
>
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 19:00
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> > >
> > > HI Jerin:
> > >
> >
> > Hi Rongwei
> >
> > > BR
> > > Rongwei
> > >
> > > > -----Original Message-----
> > > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > Sent: Wednesday, December 21, 2022 17:13
> > > > To: Rongwei Liu <rongweil@nvidia.com>
> > > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > > <rasland@nvidia.com>
> > > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > > or standby
> > > >
> > > > External email: Use caution opening links or attachments
> > > >
> > > >
> > > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com>
> > wrote:
> > > > >
> > > > > Users may want to change the DPDK process to different versions
> > > >
> > > > Different version of DPDK? If there is any ABI change how to support this?
> > > >
> > > There is a new member which was introduced into rte_eth_dev_info but it
> > shouldn’t be ABI breaking since using reserved fields.
> >
> > That is just for rte_eth_dev_info. What about the ABI change in different
> > ethdev structure and rte_flow structures across different DPDK ABI versions.
> >
> Besides this, there is no other ABI changes dependency.
>
> Assume there is a DPDK process A running with version v21.11 and plan to upgrade to
> version v22.11. Let' call v22.11 as process B.
OK. That's a relief. I understand the use case now.
Why not simply use standard DPDK multiprocess model then.
Primary process act as server for slow path API. Secondary process can
come and go(aka can be updated at runtime)
and use as client to update rules via primary-secondray communication mechanism.
>
> Now, process A has been running for long time and has lot of rules configured. It' "active" role per this API definition.
> Process B starts and it should call this API and set itself to "standby" role and user can program the flow rules as they want
> and different NIC vendors may have different recommendations. Nvidia suggests only program process B with group 0' rules now.
>
> The user should sync all desired configurations from process A to process B, and process A starts to yield traffic like "delete all group 0
> rules for Nvidia' NICs" or quit.
> After that process B calls this API and set itself to "active" role, now the hot-upgrade finishes.
>
> > > > > such as hot upgrade.
> > > > > There is a strong requirement to simplify the logic and shorten
> > > > > the traffic downtime as much as possible.
> > > > >
> > > > > This update introduces new rte_eth process role definitions:
> > > > > active or standby.
> > > > >
> > > > > The active role means rules are programmed to HW immediately, and
> > > > > no
> > > >
> > > > Why it has to be specific only to rte_flow rule? If it spedieic to
> > > > rte_flow, why it is in rte_eth_process_ name space?
> > > For now, this design focuses on the flow rule offloading and traffic
> > redirection.
> > > When switching process version, it' important to make sure which
> > application receives and handles the traffic.
> >
> > Changing the DPDK version runtime is just beyond rte_flow driver.
>
> It' not about changing DPDK version but upgrading DPDK from one PMD version to another one.
> Does the preceding example answer your question?
> >
> > > The changing should be effective across all probing eth devices, that' why it
> > was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > > >
> > > > Also, if we are moving the standby, What about the rule whose ABI is
> > > > changed between versions?
> > >
> > > Like the comments mentioned: " Before role transition, all the rules set by
> > the active process should be flushed first. "
> >
> > What happens to rte_flow flow handles for existing ones which is created with
> > version X?
> > Also What if new version Y has ABI change in rte_flow_pattern and
> > rte_flow_action structure?
> >
> > For me, If DPDK version change is needed, simply reload the application. This
> > API will soon bloat, and it will be a mess if to start handling Different DPDK
> > version which is not ABI compatible at all.
> >
> Yes, you are right. Reloading the application is the easiest way but it may have a long time
> Window that traffic is lost. No traffic arrives at process A or process B.
> We are trying to simplify the reloading logic and minimize the traffic down time as much as possible.
> The approach may differentiate hugely between different NIC vendors, so I think it should be better if
> DPDK can provide an abstract API.
>
> If process A and process B are ABI different, it doesn't matter.
> 1. Call this API with process A means older ABI.
> 2. Call this API with process B means newer ABI.
> It' have process concept and working scope.
>
> >
> >
> >
> > > > > behavior changed. This is the default state.
> > > > > The standby role means rules are queued in the HW. If no active
> > > > > roles alive or back to active, the rules are effective immediately.
> > > > >
> > > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 0%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 10:59 5% ` Jerin Jacob
@ 2022-12-21 12:05 5% ` Rongwei Liu
2022-12-21 12:44 0% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 12:05 UTC (permalink / raw)
To: Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
Hi Jerin:
BR
Rongwei
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 19:00
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > HI Jerin:
> >
>
> Hi Rongwei
>
> > BR
> > Rongwei
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Wednesday, December 21, 2022 17:13
> > > To: Rongwei Liu <rongweil@nvidia.com>
> > > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > > <rasland@nvidia.com>
> > > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active
> > > or standby
> > >
> > > External email: Use caution opening links or attachments
> > >
> > >
> > > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com>
> wrote:
> > > >
> > > > Users may want to change the DPDK process to different versions
> > >
> > > Different version of DPDK? If there is any ABI change how to support this?
> > >
> > There is a new member which was introduced into rte_eth_dev_info but it
> shouldn’t be ABI breaking since using reserved fields.
>
> That is just for rte_eth_dev_info. What about the ABI change in different
> ethdev structure and rte_flow structures across different DPDK ABI versions.
>
Besides this, there is no other ABI changes dependency.
Assume there is a DPDK process A running with version v21.11 and plan to upgrade to
version v22.11. Let' call v22.11 as process B.
Now, process A has been running for long time and has lot of rules configured. It' "active" role per this API definition.
Process B starts and it should call this API and set itself to "standby" role and user can program the flow rules as they want
and different NIC vendors may have different recommendations. Nvidia suggests only program process B with group 0' rules now.
The user should sync all desired configurations from process A to process B, and process A starts to yield traffic like "delete all group 0
rules for Nvidia' NICs" or quit.
After that process B calls this API and set itself to "active" role, now the hot-upgrade finishes.
> > > > such as hot upgrade.
> > > > There is a strong requirement to simplify the logic and shorten
> > > > the traffic downtime as much as possible.
> > > >
> > > > This update introduces new rte_eth process role definitions:
> > > > active or standby.
> > > >
> > > > The active role means rules are programmed to HW immediately, and
> > > > no
> > >
> > > Why it has to be specific only to rte_flow rule? If it spedieic to
> > > rte_flow, why it is in rte_eth_process_ name space?
> > For now, this design focuses on the flow rule offloading and traffic
> redirection.
> > When switching process version, it' important to make sure which
> application receives and handles the traffic.
>
> Changing the DPDK version runtime is just beyond rte_flow driver.
It' not about changing DPDK version but upgrading DPDK from one PMD version to another one.
Does the preceding example answer your question?
>
> > The changing should be effective across all probing eth devices, that' why it
> was put under rte_eth_process_ (for all rte_eth_dev) name space.
> > >
> > > Also, if we are moving the standby, What about the rule whose ABI is
> > > changed between versions?
> >
> > Like the comments mentioned: " Before role transition, all the rules set by
> the active process should be flushed first. "
>
> What happens to rte_flow flow handles for existing ones which is created with
> version X?
> Also What if new version Y has ABI change in rte_flow_pattern and
> rte_flow_action structure?
>
> For me, If DPDK version change is needed, simply reload the application. This
> API will soon bloat, and it will be a mess if to start handling Different DPDK
> version which is not ABI compatible at all.
>
Yes, you are right. Reloading the application is the easiest way but it may have a long time
Window that traffic is lost. No traffic arrives at process A or process B.
We are trying to simplify the reloading logic and minimize the traffic down time as much as possible.
The approach may differentiate hugely between different NIC vendors, so I think it should be better if
DPDK can provide an abstract API.
If process A and process B are ABI different, it doesn't matter.
1. Call this API with process A means older ABI.
2. Call this API with process B means newer ABI.
It' have process concept and working scope.
>
>
>
> > > > behavior changed. This is the default state.
> > > > The standby role means rules are queued in the HW. If no active
> > > > roles alive or back to active, the rules are effective immediately.
> > > >
> > > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 5%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 9:32 3% ` Rongwei Liu
@ 2022-12-21 10:59 5% ` Jerin Jacob
2022-12-21 12:05 5% ` Rongwei Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 10:59 UTC (permalink / raw)
To: Rongwei Liu
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
On Wed, Dec 21, 2022 at 3:02 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> HI Jerin:
>
Hi Rongwei
> BR
> Rongwei
>
> > -----Original Message-----
> > From: Jerin Jacob <jerinjacobk@gmail.com>
> > Sent: Wednesday, December 21, 2022 17:13
> > To: Rongwei Liu <rongweil@nvidia.com>
> > Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> > <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> > Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> > <ferruh.yigit@amd.com>; Andrew Rybchenko
> > <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> > <rasland@nvidia.com>
> > Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> > >
> > > Users may want to change the DPDK process to different versions
> >
> > Different version of DPDK? If there is any ABI change how to support this?
> >
> There is a new member which was introduced into rte_eth_dev_info but it shouldn’t be ABI breaking since using reserved fields.
That is just for rte_eth_dev_info. What about the ABI change in
different ethdev structure and rte_flow structures across different
DPDK ABI versions.
> > > such as hot upgrade.
> > > There is a strong requirement to simplify the logic and shorten the
> > > traffic downtime as much as possible.
> > >
> > > This update introduces new rte_eth process role definitions: active or
> > > standby.
> > >
> > > The active role means rules are programmed to HW immediately, and no
> >
> > Why it has to be specific only to rte_flow rule? If it spedieic to rte_flow, why it
> > is in rte_eth_process_ name space?
> For now, this design focuses on the flow rule offloading and traffic redirection.
> When switching process version, it' important to make sure which application receives and handles the traffic.
Changing the DPDK version runtime is just beyond rte_flow driver.
> The changing should be effective across all probing eth devices, that' why it was put under rte_eth_process_ (for all rte_eth_dev) name space.
> >
> > Also, if we are moving the standby, What about the rule whose ABI is changed
> > between versions?
>
> Like the comments mentioned: " Before role transition, all the rules set by the active process should be flushed first. "
What happens to rte_flow flow handles for existing ones which is
created with version X?
Also What if new version Y has ABI change in rte_flow_pattern and
rte_flow_action structure?
For me, If DPDK version change is needed, simply reload the
application. This API will soon bloat, and it will be a mess if to
start handling
Different DPDK version which is not ABI compatible at all.
> > > behavior changed. This is the default state.
> > > The standby role means rules are queued in the HW. If no active roles
> > > alive or back to active, the rules are effective immediately.
> > >
> > > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
^ permalink raw reply [relevance 5%]
* [RFC 2/5] ethdev: introduce the affinity field in Tx queue API
@ 2022-12-21 10:29 2% ` Jiawei Wang
2023-01-11 16:47 0% ` Ori Kam
2023-01-18 11:37 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Jiawei Wang @ 2022-12-21 10:29 UTC (permalink / raw)
To: viacheslavo, orika, thomas, Aman Singh, Yuying Zhang,
Ferruh Yigit, Andrew Rybchenko
Cc: dev, rasland
For the multiple hardware ports connect to a single DPDK port (mhpsdp),
the previous patch introduces the new rte flow item to match the port
affinity of the received packets.
This patch adds the tx_affinity setting in Tx queue API, the affinity value
reflects packets be sent to which hardware port.
Adds the new tx_affinity field into the padding hole of rte_eth_txconf
structure, the size of rte_eth_txconf keeps the same. Adds a suppress
type for structure change in the ABI check file.
This patch adds the testpmd command line:
testpmd> port config (port_id) txq (queue_id) affinity (value)
For example, there're two hardware ports connects to a single DPDK
port (port id 0), and affinity 1 stood for hard port 1 and affinity
2 stood for hardware port 2, used the below command to config
tx affinity for each TxQ:
port config 0 txq 0 affinity 1
port config 0 txq 1 affinity 1
port config 0 txq 2 affinity 2
port config 0 txq 3 affinity 2
These commands config the TxQ index 0 and TxQ index 1 with affinity 1,
uses TxQ 0 or TxQ 1 send packets, these packets will be sent from the
hardware port 1, and similar with hardware port 2 if sending packets
with TxQ 2 or TxQ 3.
Signed-off-by: Jiawei Wang <jiaweiw@nvidia.com>
---
app/test-pmd/cmdline.c | 84 +++++++++++++++++++++
devtools/libabigail.abignore | 5 ++
doc/guides/rel_notes/release_22_03.rst | 4 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 ++++
lib/ethdev/rte_ethdev.h | 1 +
5 files changed, 107 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index b32dc8bfd4..683cae1cab 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -764,6 +764,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"port cleanup (port_id) txq (queue_id) (free_cnt)\n"
" Cleanup txq mbufs for a specific Tx queue\n\n"
+
+ "port config <port_id> txq <queue_id> affinity <value>\n"
+ " Set the port affinity value "
+ "on a specific Tx queue\n\n"
);
}
@@ -12621,6 +12625,85 @@ static cmdline_parse_inst_t cmd_show_port_flow_transfer_proxy = {
}
};
+/* *** configure port txq affinity value *** */
+struct cmd_config_tx_affinity {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t config;
+ portid_t portid;
+ cmdline_fixed_string_t txq;
+ uint16_t qid;
+ cmdline_fixed_string_t affinity;
+ uint16_t value;
+};
+
+static void
+cmd_config_tx_affinity_parsed(void *parsed_result,
+ __rte_unused struct cmdline *cl,
+ __rte_unused void *data)
+{
+ struct cmd_config_tx_affinity *res = parsed_result;
+ struct rte_port *port;
+
+ if (port_id_is_invalid(res->portid, ENABLED_WARN))
+ return;
+
+ if (res->portid == (portid_t)RTE_PORT_ALL) {
+ printf("Invalid port id\n");
+ return;
+ }
+
+ port = &ports[res->portid];
+
+ if (strcmp(res->txq, "txq")) {
+ printf("Unknown parameter\n");
+ return;
+ }
+ if (tx_queue_id_is_invalid(res->qid))
+ return;
+
+ port->txq[res->qid].conf.tx_affinity = res->value;
+
+ cmd_reconfig_device_queue(res->portid, 0, 1);
+}
+
+cmdline_parse_token_string_t cmd_config_tx_affinity_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+ port, "port");
+cmdline_parse_token_string_t cmd_config_tx_affinity_config =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+ config, "config");
+cmdline_parse_token_num_t cmd_config_tx_affinity_portid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_affinity,
+ portid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_affinity_txq =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+ txq, "txq");
+cmdline_parse_token_num_t cmd_config_tx_affinity_qid =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_affinity,
+ qid, RTE_UINT16);
+cmdline_parse_token_string_t cmd_config_tx_affinity_affine =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_tx_affinity,
+ affinity, "affinity");
+cmdline_parse_token_num_t cmd_config_tx_affinity_value =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_tx_affinity,
+ value, RTE_UINT16);
+
+static cmdline_parse_inst_t cmd_config_tx_affinity = {
+ .f = cmd_config_tx_affinity_parsed,
+ .data = (void *)0,
+ .help_str = "port config <port_id> txq <queue_id> affinity <value>",
+ .tokens = {
+ (void *)&cmd_config_tx_affinity_port,
+ (void *)&cmd_config_tx_affinity_config,
+ (void *)&cmd_config_tx_affinity_portid,
+ (void *)&cmd_config_tx_affinity_txq,
+ (void *)&cmd_config_tx_affinity_qid,
+ (void *)&cmd_config_tx_affinity_affine,
+ (void *)&cmd_config_tx_affinity_value,
+ NULL,
+ },
+};
+
/* ******************************************************************************** */
/* list of instructions */
@@ -12851,6 +12934,7 @@ static cmdline_parse_ctx_t builtin_ctx[] = {
(cmdline_parse_inst_t *)&cmd_show_capability,
(cmdline_parse_inst_t *)&cmd_set_flex_is_pattern,
(cmdline_parse_inst_t *)&cmd_set_flex_spec_pattern,
+ (cmdline_parse_inst_t *)&cmd_config_tx_affinity,
NULL,
};
diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
index 7a93de3ba1..cbbde4ef05 100644
--- a/devtools/libabigail.abignore
+++ b/devtools/libabigail.abignore
@@ -20,6 +20,11 @@
[suppress_file]
soname_regexp = ^librte_.*mlx.*glue\.
+; Ignore fields inserted in middle padding of rte_eth_txconf
+[suppress_type]
+ name = rte_eth_txconf
+ has_data_member_inserted_between = {offset_after(tx_deferred_start), offset_of(offloads)}
+
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Experimental APIs exceptions ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
diff --git a/doc/guides/rel_notes/release_22_03.rst b/doc/guides/rel_notes/release_22_03.rst
index 8acd3174f6..0d81ae7bc3 100644
--- a/doc/guides/rel_notes/release_22_03.rst
+++ b/doc/guides/rel_notes/release_22_03.rst
@@ -212,6 +212,10 @@ API Changes
* ethdev: Old public macros and enumeration constants without ``RTE_ETH_`` prefix,
which are kept for backward compatibility, are marked as deprecated.
+* ethdev: added a new field:
+
+ - Tx affinity per-queue ``rte_eth_txconf.tx_affinity``
+
* cryptodev: The asymmetric session handling was modified to use a single
mempool object. An API ``rte_cryptodev_asym_session_pool_create`` was added
to create a mempool with element size big enough to hold the generic asymmetric
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index c0ace56c1f..0c3317ee06 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1605,6 +1605,19 @@ Enable or disable a per queue Tx offloading only on a specific Tx queue::
This command should be run when the port is stopped, or else it will fail.
+config per queue Tx affinity
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Configure a affinity value per queue Tx offloading only on a specific Tx queue::
+
+ testpmd> port (port_id) txq (queue_id) affinity (value)
+
+* ``affinity``: reflects packet can be sent to which hardware port.
+ uses it on multiple hardware ports connect to
+ a single DPDK port (mhpsdp).
+
+This command should be run when the port is stopped, or else it will fail.
+
Config VXLAN Encap outer layers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 882ca585f2..813dbb34b5 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -1138,6 +1138,7 @@ struct rte_eth_txconf {
less free descriptors than this value. */
uint8_t tx_deferred_start; /**< Do not start queue with rte_eth_dev_start(). */
+ uint8_t tx_affinity; /**< Drives the setting of affinity per-queue. */
/**
* Per-queue Tx offloads to be set using RTE_ETH_TX_OFFLOAD_* flags.
* Only offloads set on tx_queue_offload_capa or tx_offload_capa
--
2.18.1
^ permalink raw reply [relevance 2%]
* RE: [RFC v3 2/2] ethdev: add API to set process to active or standby
2022-12-21 9:12 4% ` Jerin Jacob
@ 2022-12-21 9:32 3% ` Rongwei Liu
2022-12-21 10:59 5% ` Jerin Jacob
0 siblings, 1 reply; 200+ results
From: Rongwei Liu @ 2022-12-21 9:32 UTC (permalink / raw)
To: Jerin Jacob
Cc: Matan Azrad, Slava Ovsiienko, Ori Kam,
NBU-Contact-Thomas Monjalon (EXTERNAL),
Ferruh Yigit, Andrew Rybchenko, dev, Raslan Darawsheh
HI Jerin:
BR
Rongwei
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Wednesday, December 21, 2022 17:13
> To: Rongwei Liu <rongweil@nvidia.com>
> Cc: Matan Azrad <matan@nvidia.com>; Slava Ovsiienko
> <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>; NBU-Contact-
> Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>; Ferruh Yigit
> <ferruh.yigit@amd.com>; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; dev@dpdk.org; Raslan Darawsheh
> <rasland@nvidia.com>
> Subject: Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
>
> External email: Use caution opening links or attachments
>
>
> On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com> wrote:
> >
> > Users may want to change the DPDK process to different versions
>
> Different version of DPDK? If there is any ABI change how to support this?
>
There is a new member which was introduced into rte_eth_dev_info but it shouldn’t be ABI breaking since using reserved fields.
> > such as hot upgrade.
> > There is a strong requirement to simplify the logic and shorten the
> > traffic downtime as much as possible.
> >
> > This update introduces new rte_eth process role definitions: active or
> > standby.
> >
> > The active role means rules are programmed to HW immediately, and no
>
> Why it has to be specific only to rte_flow rule? If it spedieic to rte_flow, why it
> is in rte_eth_process_ name space?
For now, this design focuses on the flow rule offloading and traffic redirection.
When switching process version, it' important to make sure which application receives and handles the traffic.
The changing should be effective across all probing eth devices, that' why it was put under rte_eth_process_ (for all rte_eth_dev) name space.
>
> Also, if we are moving the standby, What about the rule whose ABI is changed
> between versions?
Like the comments mentioned: " Before role transition, all the rules set by the active process should be flushed first. "
> > behavior changed. This is the default state.
> > The standby role means rules are queued in the HW. If no active roles
> > alive or back to active, the rules are effective immediately.
> >
> > Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> > ---
> > doc/guides/nics/mlx5.rst | 10 ++++
> > doc/guides/rel_notes/release_22_03.rst | 5 ++
> > lib/ethdev/ethdev_driver.h | 63 ++++++++++++++++++++++++++
> > lib/ethdev/rte_ethdev.c | 41 +++++++++++++++++
> > lib/ethdev/rte_ethdev.h | 7 ++-
> > lib/ethdev/version.map | 3 ++
> > 6 files changed, 128 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index
> > 51f51259e3..de1fdac0a1 100644
> > --- a/doc/guides/nics/mlx5.rst
> > +++ b/doc/guides/nics/mlx5.rst
> > @@ -2001,3 +2001,13 @@ where:
> > * ``sw_queue_id``: queue index in range [64536, 65535].
> > This range is the highest 1000 numbers.
> > * ``hw_queue_id``: queue index given by HW in queue creation.
> > +
> > +ethdev set process active or standby
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +User should only program group 0 (fdb_def_rule_en=0) when
> > +``rte_eth_process_set_active`` has been called and set to a standby role.
> > +Group 0 is shared across different DPDK processes while the other
> > +groups are limited to the current process scope.
> > +The process can't move from active to standby role if preceding
> > +active application's rules are still present and vice versa.
> > diff --git a/doc/guides/rel_notes/release_22_03.rst
> > b/doc/guides/rel_notes/release_22_03.rst
> > index 0923707cb8..6fa48106c4 100644
> > --- a/doc/guides/rel_notes/release_22_03.rst
> > +++ b/doc/guides/rel_notes/release_22_03.rst
> > @@ -207,6 +207,11 @@ API Changes
> > * ethdev: Old public macros and enumeration constants without
> ``RTE_ETH_`` prefix,
> > which are kept for backward compatibility, are marked as deprecated.
> >
> > +* ethdev: added a new experimental api:
> > +
> > + The new API ``rte_eth_process_set_active()`` was added.
> > + If ``RTE_ETH_CAPA_PROCESS_SET_ROLE`` is not advertised, this new api
> is not supported.
> > +
> > * cryptodev: The asymmetric session handling was modified to use a single
> > mempool object. An API ``rte_cryptodev_asym_session_pool_create`` was
> added
> > to create a mempool with element size big enough to hold the
> > generic asymmetric diff --git a/lib/ethdev/ethdev_driver.h
> > b/lib/ethdev/ethdev_driver.h index 6a550cfc83..3c583bc39d 100644
> > --- a/lib/ethdev/ethdev_driver.h
> > +++ b/lib/ethdev/ethdev_driver.h
> > @@ -179,6 +179,16 @@ struct rte_eth_dev_data {
> > pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex */ }
> > __rte_cache_aligned;
> >
> > +/**@{@name Different rte_eth role flag definitions which will be used
> > + * when miagrating DPDK to a different version.
> > + */
> > +/*
> > + * Traffic coming from NIC domain rules will reach
> > + * both active and standby processes.
> > + */
> > +#define RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY RTE_BIT32(0),
> /**@}*/
> > +
> > /**
> > * @internal
> > * The pool of *rte_eth_dev* structures. The size of the pool @@
> > -1087,6 +1097,22 @@ typedef const uint32_t
> *(*eth_buffer_split_supported_hdr_ptypes_get_t)(struct rt
> > */
> > typedef int (*eth_dev_priv_dump_t)(struct rte_eth_dev *dev, FILE
> > *file);
> >
> > +/**
> > + * @internal
> > + * Set rte_eth process to active or standby role.
> > + *
> > + * @param dev
> > + * Port (ethdev) handle.
> > + * @param active
> > + * Device (role) active or not (standby).
> > + * @param flag
> > + * Role specific flag.
> > + *
> > + * @return
> > + * Negative value on error, 0 on success.
> > + */
> > +typedef int (*eth_process_set_active_t)(struct rte_eth_dev *dev, bool
> > +active, uint32_t flag);
> > +
> > /**
> > * @internal Set Rx queue available descriptors threshold.
> > * @see rte_eth_rx_avail_thresh_set() @@ -1403,6 +1429,8 @@ struct
> > eth_dev_ops {
> > eth_cman_config_set_t cman_config_set;
> > /** Retrieve congestion management configuration */
> > eth_cman_config_get_t cman_config_get;
> > + /** Set the whole rte_eth process to active or standby role. */
> > + eth_process_set_active_t eth_process_set_active;
> > };
> >
> > /**
> > @@ -2046,6 +2074,41 @@ struct rte_eth_fdir_conf {
> > struct rte_eth_fdir_flex_conf flex_conf; };
> >
> > +/**
> > + * @warning
> > + * @b EXPERIMENTAL: this API may change without prior notice
> > + *
> > + * Set the rte_eth process to the active or standby role which
> > +affects
> > + * the flow rules offloading. It doesn't allow multiple processes to
> > +be the
> > + * same role unless no offload rules are set.
> > + * The active process flow rules are effective immediately while the
> > +standby
> > + * process rules will be matched (active) when the process becomes
> > +active or
> > + * when the traffic is not matched by the active process rules.
> > + * The active application will always receive traffic while the
> > +standby
> > + * application will receive traffic when no matching rules are
> > +present from
> > + * the active application.
> > + *
> > + * The application is active by default if this API is not called.
> > + *
> > + * When a process transforms from a standby to a active role, all
> > +preceding
> > + * flow rules which are queued by hardware will be effective immediately.
> > + * Before role transition, all the rules set by the active process
> > +should be
> > + * flushed first.
> > + *
> > + * When role flag "RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY" is set,
> NIC
> > +domain
> > + * flow rules are effective immediately even if a process is standby role.
> > + *
> > + * @param active
> > + * Process active (role) or not (standby).
> > + * @param flag
> > + * The role flag.
> > + * @return
> > + * - (>=0) Number of rte devices which have been switched successfully.
> > + * - (-EINVAL) if bad parameter.
> > + */
> > +__rte_experimental
> > +int rte_eth_process_set_active(bool active, uint32_t flag);
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> > diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c index
> > 5d5e18db1e..f19da75bfe 100644
> > --- a/lib/ethdev/rte_ethdev.c
> > +++ b/lib/ethdev/rte_ethdev.c
> > @@ -6318,6 +6318,47 @@
> rte_eth_buffer_split_get_supported_hdr_ptypes(uint16_t port_id, uint32_t
> *ptypes
> > return j;
> > }
> >
> > +int rte_eth_process_set_active(bool active, uint32_t flag) {
> > + struct rte_eth_dev_info dev_info = {0};
> > + uint32_t flags[RTE_MAX_ETHPORTS];
> > + struct rte_eth_dev *dev;
> > + uint16_t port_id;
> > + int ret = 0;
> > +
> > + /* Check if all devices support. */
> > + RTE_ETH_FOREACH_DEV(port_id) {
> > + dev = &rte_eth_devices[port_id];
> > + if (*dev->dev_ops->dev_infos_get == NULL ||
> > + *dev->dev_ops->eth_process_set_active == NULL)
> > + return -ENOTSUP;
> > + if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> > + return -EINVAL;
> > + if (!(dev_info.dev_capa & RTE_ETH_CAPA_PROCESS_SET_ROLE))
> > + return -ENOTSUP;
> > + }
> > + RTE_ETH_FOREACH_DEV(port_id) {
> > + dev = &rte_eth_devices[port_id];
> > + if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> > + goto err;
> > + flags[port_id] = dev_info.eth_process_flag;
> > + if ((*dev->dev_ops->eth_process_set_active)(dev, active, flag) < 0)
> > + goto err;
> > + ret++;
> > + }
> > + return ret;
> > +err:
> > + if (!ret)
> > + return 0;
> > + RTE_ETH_FOREACH_DEV(port_id) {
> > + dev = &rte_eth_devices[port_id];
> > + (*dev->dev_ops->eth_process_set_active)(dev, !active,
> flags[port_id]);
> > + if (--ret == 0)
> > + break;
> > + }
> > + return 0;
> > +}
> > +
> > RTE_LOG_REGISTER_DEFAULT(rte_eth_dev_logtype, INFO);
> >
> > RTE_INIT(ethdev_init_telemetry)
> > diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h index
> > c129ca1eaf..d29f051d6f 100644
> > --- a/lib/ethdev/rte_ethdev.h
> > +++ b/lib/ethdev/rte_ethdev.h
> > @@ -1606,6 +1606,8 @@ struct rte_eth_conf {
> > #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3)
> > /** Device supports keeping shared flow objects across restart. */
> > #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4)
> > +/**Device supports "rte_eth_process_set_active" callback. */ #define
> > +RTE_ETH_CAPA_PROCESS_SET_ROLE RTE_BIT64(5)
> > /**@}*/
> >
> > /*
> > @@ -1777,8 +1779,11 @@ struct rte_eth_dev_info {
> > struct rte_eth_switch_info switch_info;
> > /** Supported error handling mode. */
> > enum rte_eth_err_handle_mode err_handle_mode;
> > + /** Process specific role flag. */
> > + uint32_t eth_process_flag;
> >
> > - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> > + uint32_t reserved_32s[1]; /**< Reserved for future fields */
> > + uint64_t reserved_64s[1]; /**< Reserved for future fields */
> > void *reserved_ptrs[2]; /**< Reserved for future fields */
> > };
> >
> > diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map index
> > 17201fbe0f..a5503f6fde 100644
> > --- a/lib/ethdev/version.map
> > +++ b/lib/ethdev/version.map
> > @@ -298,6 +298,9 @@ EXPERIMENTAL {
> > rte_flow_get_q_aged_flows;
> > rte_mtr_meter_policy_get;
> > rte_mtr_meter_profile_get;
> > +
> > + # added in 23.03
> > + rte_eth_process_set_active;
> > };
> >
> > INTERNAL {
> > --
> > 2.27.0
> >
^ permalink raw reply [relevance 3%]
* Re: [RFC v3 2/2] ethdev: add API to set process to active or standby
@ 2022-12-21 9:12 4% ` Jerin Jacob
2022-12-21 9:32 3% ` Rongwei Liu
0 siblings, 1 reply; 200+ results
From: Jerin Jacob @ 2022-12-21 9:12 UTC (permalink / raw)
To: Rongwei Liu
Cc: matan, viacheslavo, orika, thomas, Ferruh Yigit,
Andrew Rybchenko, dev, rasland
On Wed, Dec 21, 2022 at 2:31 PM Rongwei Liu <rongweil@nvidia.com> wrote:
>
> Users may want to change the DPDK process to different versions
Different version of DPDK? If there is any ABI change how to support this?
> such as hot upgrade.
> There is a strong requirement to simplify the logic and shorten the
> traffic downtime as much as possible.
>
> This update introduces new rte_eth process role definitions: active
> or standby.
>
> The active role means rules are programmed to HW immediately, and no
Why it has to be specific only to rte_flow rule? If it spedieic to
rte_flow, why it is in rte_eth_process_ name space?
Also, if we are moving the standby, What about the rule whose ABI is
changed between versions?
> behavior changed. This is the default state.
> The standby role means rules are queued in the HW. If no active roles
> alive or back to active, the rules are effective immediately.
>
> Signed-off-by: Rongwei Liu <rongweil@nvidia.com>
> ---
> doc/guides/nics/mlx5.rst | 10 ++++
> doc/guides/rel_notes/release_22_03.rst | 5 ++
> lib/ethdev/ethdev_driver.h | 63 ++++++++++++++++++++++++++
> lib/ethdev/rte_ethdev.c | 41 +++++++++++++++++
> lib/ethdev/rte_ethdev.h | 7 ++-
> lib/ethdev/version.map | 3 ++
> 6 files changed, 128 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst
> index 51f51259e3..de1fdac0a1 100644
> --- a/doc/guides/nics/mlx5.rst
> +++ b/doc/guides/nics/mlx5.rst
> @@ -2001,3 +2001,13 @@ where:
> * ``sw_queue_id``: queue index in range [64536, 65535].
> This range is the highest 1000 numbers.
> * ``hw_queue_id``: queue index given by HW in queue creation.
> +
> +ethdev set process active or standby
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +User should only program group 0 (fdb_def_rule_en=0) when ``rte_eth_process_set_active``
> +has been called and set to a standby role.
> +Group 0 is shared across different DPDK processes while the other groups are limited
> +to the current process scope.
> +The process can't move from active to standby role if preceding active application's
> +rules are still present and vice versa.
> diff --git a/doc/guides/rel_notes/release_22_03.rst b/doc/guides/rel_notes/release_22_03.rst
> index 0923707cb8..6fa48106c4 100644
> --- a/doc/guides/rel_notes/release_22_03.rst
> +++ b/doc/guides/rel_notes/release_22_03.rst
> @@ -207,6 +207,11 @@ API Changes
> * ethdev: Old public macros and enumeration constants without ``RTE_ETH_`` prefix,
> which are kept for backward compatibility, are marked as deprecated.
>
> +* ethdev: added a new experimental api:
> +
> + The new API ``rte_eth_process_set_active()`` was added.
> + If ``RTE_ETH_CAPA_PROCESS_SET_ROLE`` is not advertised, this new api is not supported.
> +
> * cryptodev: The asymmetric session handling was modified to use a single
> mempool object. An API ``rte_cryptodev_asym_session_pool_create`` was added
> to create a mempool with element size big enough to hold the generic asymmetric
> diff --git a/lib/ethdev/ethdev_driver.h b/lib/ethdev/ethdev_driver.h
> index 6a550cfc83..3c583bc39d 100644
> --- a/lib/ethdev/ethdev_driver.h
> +++ b/lib/ethdev/ethdev_driver.h
> @@ -179,6 +179,16 @@ struct rte_eth_dev_data {
> pthread_mutex_t flow_ops_mutex; /**< rte_flow ops mutex */
> } __rte_cache_aligned;
>
> +/**@{@name Different rte_eth role flag definitions which will be used
> + * when miagrating DPDK to a different version.
> + */
> +/*
> + * Traffic coming from NIC domain rules will reach
> + * both active and standby processes.
> + */
> +#define RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY RTE_BIT32(0),
> +/**@}*/
> +
> /**
> * @internal
> * The pool of *rte_eth_dev* structures. The size of the pool
> @@ -1087,6 +1097,22 @@ typedef const uint32_t *(*eth_buffer_split_supported_hdr_ptypes_get_t)(struct rt
> */
> typedef int (*eth_dev_priv_dump_t)(struct rte_eth_dev *dev, FILE *file);
>
> +/**
> + * @internal
> + * Set rte_eth process to active or standby role.
> + *
> + * @param dev
> + * Port (ethdev) handle.
> + * @param active
> + * Device (role) active or not (standby).
> + * @param flag
> + * Role specific flag.
> + *
> + * @return
> + * Negative value on error, 0 on success.
> + */
> +typedef int (*eth_process_set_active_t)(struct rte_eth_dev *dev, bool active, uint32_t flag);
> +
> /**
> * @internal Set Rx queue available descriptors threshold.
> * @see rte_eth_rx_avail_thresh_set()
> @@ -1403,6 +1429,8 @@ struct eth_dev_ops {
> eth_cman_config_set_t cman_config_set;
> /** Retrieve congestion management configuration */
> eth_cman_config_get_t cman_config_get;
> + /** Set the whole rte_eth process to active or standby role. */
> + eth_process_set_active_t eth_process_set_active;
> };
>
> /**
> @@ -2046,6 +2074,41 @@ struct rte_eth_fdir_conf {
> struct rte_eth_fdir_flex_conf flex_conf;
> };
>
> +/**
> + * @warning
> + * @b EXPERIMENTAL: this API may change without prior notice
> + *
> + * Set the rte_eth process to the active or standby role which affects
> + * the flow rules offloading. It doesn't allow multiple processes to be the
> + * same role unless no offload rules are set.
> + * The active process flow rules are effective immediately while the standby
> + * process rules will be matched (active) when the process becomes active or
> + * when the traffic is not matched by the active process rules.
> + * The active application will always receive traffic while the standby
> + * application will receive traffic when no matching rules are present from
> + * the active application.
> + *
> + * The application is active by default if this API is not called.
> + *
> + * When a process transforms from a standby to a active role, all preceding
> + * flow rules which are queued by hardware will be effective immediately.
> + * Before role transition, all the rules set by the active process should be
> + * flushed first.
> + *
> + * When role flag "RTE_ETH_PROCESS_NIC_DUP_WITH_STANDBY" is set, NIC domain
> + * flow rules are effective immediately even if a process is standby role.
> + *
> + * @param active
> + * Process active (role) or not (standby).
> + * @param flag
> + * The role flag.
> + * @return
> + * - (>=0) Number of rte devices which have been switched successfully.
> + * - (-EINVAL) if bad parameter.
> + */
> +__rte_experimental
> +int rte_eth_process_set_active(bool active, uint32_t flag);
> +
> #ifdef __cplusplus
> }
> #endif
> diff --git a/lib/ethdev/rte_ethdev.c b/lib/ethdev/rte_ethdev.c
> index 5d5e18db1e..f19da75bfe 100644
> --- a/lib/ethdev/rte_ethdev.c
> +++ b/lib/ethdev/rte_ethdev.c
> @@ -6318,6 +6318,47 @@ rte_eth_buffer_split_get_supported_hdr_ptypes(uint16_t port_id, uint32_t *ptypes
> return j;
> }
>
> +int rte_eth_process_set_active(bool active, uint32_t flag)
> +{
> + struct rte_eth_dev_info dev_info = {0};
> + uint32_t flags[RTE_MAX_ETHPORTS];
> + struct rte_eth_dev *dev;
> + uint16_t port_id;
> + int ret = 0;
> +
> + /* Check if all devices support. */
> + RTE_ETH_FOREACH_DEV(port_id) {
> + dev = &rte_eth_devices[port_id];
> + if (*dev->dev_ops->dev_infos_get == NULL ||
> + *dev->dev_ops->eth_process_set_active == NULL)
> + return -ENOTSUP;
> + if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> + return -EINVAL;
> + if (!(dev_info.dev_capa & RTE_ETH_CAPA_PROCESS_SET_ROLE))
> + return -ENOTSUP;
> + }
> + RTE_ETH_FOREACH_DEV(port_id) {
> + dev = &rte_eth_devices[port_id];
> + if ((*dev->dev_ops->dev_infos_get)(dev, &dev_info))
> + goto err;
> + flags[port_id] = dev_info.eth_process_flag;
> + if ((*dev->dev_ops->eth_process_set_active)(dev, active, flag) < 0)
> + goto err;
> + ret++;
> + }
> + return ret;
> +err:
> + if (!ret)
> + return 0;
> + RTE_ETH_FOREACH_DEV(port_id) {
> + dev = &rte_eth_devices[port_id];
> + (*dev->dev_ops->eth_process_set_active)(dev, !active, flags[port_id]);
> + if (--ret == 0)
> + break;
> + }
> + return 0;
> +}
> +
> RTE_LOG_REGISTER_DEFAULT(rte_eth_dev_logtype, INFO);
>
> RTE_INIT(ethdev_init_telemetry)
> diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
> index c129ca1eaf..d29f051d6f 100644
> --- a/lib/ethdev/rte_ethdev.h
> +++ b/lib/ethdev/rte_ethdev.h
> @@ -1606,6 +1606,8 @@ struct rte_eth_conf {
> #define RTE_ETH_DEV_CAPA_FLOW_RULE_KEEP RTE_BIT64(3)
> /** Device supports keeping shared flow objects across restart. */
> #define RTE_ETH_DEV_CAPA_FLOW_SHARED_OBJECT_KEEP RTE_BIT64(4)
> +/**Device supports "rte_eth_process_set_active" callback. */
> +#define RTE_ETH_CAPA_PROCESS_SET_ROLE RTE_BIT64(5)
> /**@}*/
>
> /*
> @@ -1777,8 +1779,11 @@ struct rte_eth_dev_info {
> struct rte_eth_switch_info switch_info;
> /** Supported error handling mode. */
> enum rte_eth_err_handle_mode err_handle_mode;
> + /** Process specific role flag. */
> + uint32_t eth_process_flag;
>
> - uint64_t reserved_64s[2]; /**< Reserved for future fields */
> + uint32_t reserved_32s[1]; /**< Reserved for future fields */
> + uint64_t reserved_64s[1]; /**< Reserved for future fields */
> void *reserved_ptrs[2]; /**< Reserved for future fields */
> };
>
> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map
> index 17201fbe0f..a5503f6fde 100644
> --- a/lib/ethdev/version.map
> +++ b/lib/ethdev/version.map
> @@ -298,6 +298,9 @@ EXPERIMENTAL {
> rte_flow_get_q_aged_flows;
> rte_mtr_meter_policy_get;
> rte_mtr_meter_profile_get;
> +
> + # added in 23.03
> + rte_eth_process_set_active;
> };
>
> INTERNAL {
> --
> 2.27.0
>
^ permalink raw reply [relevance 4%]
* DPDK 21.11.3 released
@ 2022-12-20 16:22 1% Kevin Traynor
0 siblings, 0 replies; 200+ results
From: Kevin Traynor @ 2022-12-20 16:22 UTC (permalink / raw)
To: ktraynor, kevin, announce
Hi all,
Here is a new stable release:
https://fast.dpdk.org/rel/dpdk-21.11.3.tar.xz
The git tree is at:
https://dpdk.org/browse/dpdk-stable/?h=21.11
Release notes can be found here:
http://doc.dpdk.org/guides-21.11/rel_notes/release_21_11.html#id5
This LTS release contains ~300 fixes from main branch
up to DPDK 22.11.
Thanks to the authors who helped with backports and to the
following who helped with validation:
Ubuntu, Intel, Nvidia and Red Hat.
Kevin.
---
.github/workflows/build.yml | 23 +-
VERSION | 2 +-
app/dumpcap/main.c | 10 +-
app/test-eventdev/test_pipeline_common.c | 4 +-
app/test-pmd/cmdline.c | 62 +++-
app/test-pmd/config.c | 4 -
app/test-pmd/csumonly.c | 6 +
app/test-pmd/meson.build | 1 +
app/test-pmd/noisy_vnf.c | 2 +-
app/test-pmd/testpmd.c | 25 +-
app/test-pmd/testpmd.h | 4 +-
app/test/test_common.c | 56 ++-
app/test/test_cryptodev.c | 20 +-
app/test/test_cryptodev_asym.c | 4 +-
.../test_cryptodev_security_pdcp_test_vectors.h | 280 +++++++--------
app/test/test_efd_perf.c | 1 -
app/test/test_event_timer_adapter.c | 2 -
app/test/test_hash_perf.c | 11 +-
app/test/test_hash_readwrite_lf_perf.c | 1 -
app/test/test_ipsec.c | 9 +-
app/test/test_member.c | 1 -
app/test/test_member_perf.c | 1 -
app/test/test_pcapng.c | 42 ++-
app/test/test_trace.c | 55 +--
app/test/test_trace.h | 2 +
buildtools/get-numa-count.py | 3 +-
devtools/checkpatches.sh | 37 +-
doc/guides/contributing/abi_policy.rst | 2 +-
doc/guides/contributing/abi_versioning.rst | 2 +-
doc/guides/cryptodevs/armv8.rst | 2 +-
doc/guides/cryptodevs/bcmfs.rst | 2 +-
doc/guides/freebsd_gsg/build_dpdk.rst | 2 +-
doc/guides/gpus/cuda.rst | 4 +-
doc/guides/howto/openwrt.rst | 2 +-
doc/guides/linux_gsg/build_dpdk.rst | 8 +-
.../linux_gsg/cross_build_dpdk_for_arm64.rst | 12 +-
doc/guides/nics/ark.rst | 2 +-
doc/guides/nics/features.rst | 2 +-
doc/guides/nics/features/bnxt.ini | 4 +-
doc/guides/nics/features/cxgbe.ini | 4 +-
doc/guides/nics/features/default.ini | 1 +
doc/guides/nics/features/dpaa2.ini | 4 +-
doc/guides/nics/features/e1000.ini | 2 +-
doc/guides/nics/features/enic.ini | 4 +-
doc/guides/nics/features/hinic.ini | 2 +-
doc/guides/nics/features/hns3.ini | 4 +-
doc/guides/nics/features/i40e.ini | 4 +-
doc/guides/nics/features/iavf.ini | 4 +-
doc/guides/nics/features/ice.ini | 4 +-
doc/guides/nics/features/igc.ini | 2 +-
doc/guides/nics/features/ipn3ke.ini | 4 +-
doc/guides/nics/features/ixgbe.ini | 4 +-
doc/guides/nics/features/mlx4.ini | 4 +-
doc/guides/nics/features/mlx5.ini | 1 +
doc/guides/nics/features/mvpp2.ini | 4 +-
doc/guides/nics/features/tap.ini | 4 +-
doc/guides/nics/features/txgbe.ini | 4 +-
doc/guides/nics/intel_vf.rst | 17 +
doc/guides/nics/mlx5.rst | 2 +
doc/guides/nics/mvneta.rst | 2 +-
doc/guides/nics/mvpp2.rst | 2 +-
doc/guides/nics/virtio.rst | 2 +-
doc/guides/platform/bluefield.rst | 4 +-
doc/guides/platform/cnxk.rst | 4 +-
doc/guides/platform/octeontx.rst | 8 +-
doc/guides/prog_guide/build-sdk-meson.rst | 39 +-
doc/guides/prog_guide/event_timer_adapter.rst | 15 +-
doc/guides/prog_guide/lto.rst | 2 +-
doc/guides/prog_guide/profile_app.rst | 4 +-
doc/guides/prog_guide/ring_lib.rst | 2 +-
doc/guides/prog_guide/trace_lib.rst | 14 +-
doc/guides/prog_guide/vhost_lib.rst | 6 +
doc/guides/rel_notes/release_21_11.rst | 391 +++++++++++++++++++++
doc/guides/sample_app_ug/dma.rst | 2 +-
doc/guides/sample_app_ug/vm_power_management.rst | 4 +-
doc/guides/testpmd_app_ug/run_app.rst | 1 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 12 +-
doc/guides/tools/dumpcap.rst | 4 +-
doc/guides/tools/proc_info.rst | 22 +-
doc/guides/windows_gsg/build_dpdk.rst | 4 +-
drivers/baseband/acc100/rte_acc100_pmd.c | 324 +++++++++++------
drivers/baseband/acc100/rte_acc100_pmd.h | 2 +
drivers/bus/auxiliary/auxiliary_common.c | 6 +
drivers/bus/dpaa/base/qbman/bman.h | 4 +-
drivers/common/cnxk/roc_nix_tm_ops.c | 60 ++--
drivers/common/cnxk/roc_npc_mcam.c | 4 +-
drivers/common/cnxk/roc_npc_mcam_dump.c | 6 +-
drivers/common/cnxk/roc_npc_utils.c | 2 +-
drivers/common/iavf/iavf_adminq.c | 3 +-
drivers/common/mlx5/mlx5_common.c | 21 +-
drivers/common/mlx5/mlx5_common_mr.c | 1 -
drivers/common/mlx5/mlx5_common_mr.h | 1 -
drivers/common/qat/qat_pf2vf.c | 4 +-
drivers/common/sfc_efx/base/ef10_nic.c | 2 +-
drivers/common/sfc_efx/base/rhead_virtio.c | 12 +-
drivers/compress/mlx5/meson.build | 1 -
drivers/crypto/mlx5/meson.build | 1 -
drivers/crypto/qat/qat_sym_session.c | 23 +-
drivers/dma/idxd/idxd_bus.c | 4 +
drivers/event/cnxk/cn10k_eventdev.c | 4 +
drivers/event/cnxk/cn9k_eventdev.c | 4 +
drivers/event/cnxk/cnxk_tim_worker.h | 1 +
drivers/event/dlb2/dlb2.c | 8 +-
drivers/event/dsw/dsw_evdev.h | 8 +-
drivers/event/dsw/dsw_event.c | 315 ++++++++++++-----
drivers/event/sw/sw_evdev.c | 4 +-
drivers/event/sw/sw_evdev_selftest.c | 7 +-
drivers/mempool/cnxk/cnxk_mempool_ops.c | 8 +
drivers/net/atlantic/atl_rxtx.c | 5 +-
drivers/net/axgbe/axgbe_rxtx.c | 133 ++++---
drivers/net/axgbe/axgbe_rxtx.h | 6 +
drivers/net/bnxt/bnxt_ethdev.c | 7 +-
drivers/net/bnxt/bnxt_hwrm.c | 2 +-
drivers/net/bnxt/tf_ulp/ulp_flow_db.h | 4 +-
drivers/net/bonding/rte_eth_bond_api.c | 5 +
drivers/net/bonding/rte_eth_bond_pmd.c | 102 +++---
drivers/net/cnxk/cn10k_rx.h | 12 +-
drivers/net/cnxk/cn10k_tx.h | 8 +-
drivers/net/cnxk/cn9k_tx.h | 8 +-
drivers/net/cnxk/cnxk_ethdev.c | 2 +-
drivers/net/dpaa/dpaa_ethdev.c | 23 +-
drivers/net/dpaa/dpaa_ethdev.h | 19 +
drivers/net/dpaa/dpaa_flow.c | 13 +-
drivers/net/dpaa/dpaa_flow.h | 5 +-
drivers/net/dpaa/dpaa_rxtx.c | 87 +++--
drivers/net/dpaa2/dpaa2_ethdev.c | 19 +
drivers/net/dpaa2/dpaa2_ethdev.h | 21 ++
drivers/net/dpaa2/dpaa2_mux.c | 2 +-
drivers/net/dpaa2/dpaa2_rxtx.c | 111 ++++--
drivers/net/enetfec/enet_ethdev.c | 4 +
drivers/net/enetfec/enet_rxtx.c | 29 +-
drivers/net/failsafe/failsafe_ops.c | 32 +-
drivers/net/hns3/hns3_cmd.h | 6 +
drivers/net/hns3/hns3_ethdev.c | 30 +-
drivers/net/hns3/hns3_ethdev.h | 3 +-
drivers/net/hns3/hns3_ethdev_vf.c | 25 +-
drivers/net/hns3/hns3_fdir.c | 3 +
drivers/net/hns3/hns3_flow.c | 259 ++++++++------
drivers/net/hns3/hns3_flow.h | 1 +
drivers/net/hns3/hns3_mbx.c | 8 +-
drivers/net/hns3/hns3_ptp.c | 1 -
drivers/net/hns3/hns3_rss.c | 291 ++++++++++-----
drivers/net/hns3/hns3_rss.h | 3 +-
drivers/net/hns3/hns3_rxtx.c | 125 +++----
drivers/net/hns3/hns3_rxtx_vec.c | 20 +-
drivers/net/hns3/hns3_rxtx_vec_sve.c | 13 +-
drivers/net/hns3/hns3_stats.c | 26 +-
drivers/net/i40e/i40e_ethdev.c | 45 +--
drivers/net/i40e/i40e_hash.c | 10 +-
drivers/net/i40e/i40e_vf_representor.c | 4 +-
drivers/net/iavf/iavf_ethdev.c | 1 +
drivers/net/iavf/iavf_fdir.c | 32 ++
drivers/net/iavf/iavf_ipsec_crypto.c | 29 +-
drivers/net/iavf/iavf_rxtx.c | 58 ++-
drivers/net/iavf/iavf_rxtx.h | 2 +
drivers/net/iavf/iavf_rxtx_vec_avx2.c | 118 +++++--
drivers/net/iavf/iavf_rxtx_vec_avx512.c | 133 +++++--
drivers/net/iavf/iavf_rxtx_vec_sse.c | 170 +++++++--
drivers/net/ice/base/ice_bst_tcam.c | 6 +-
drivers/net/ice/base/ice_common.c | 12 +-
drivers/net/ice/base/ice_dcb.c | 2 +-
drivers/net/ice/base/ice_flg_rd.c | 4 +-
drivers/net/ice/base/ice_flow.c | 16 +-
drivers/net/ice/base/ice_imem.c | 4 +-
drivers/net/ice/base/ice_metainit.c | 4 +-
drivers/net/ice/base/ice_mk_grp.c | 4 +-
drivers/net/ice/base/ice_parser.c | 7 +-
drivers/net/ice/base/ice_pg_cam.c | 12 +-
drivers/net/ice/base/ice_proto_grp.c | 4 +-
drivers/net/ice/base/ice_ptp_hw.c | 56 +--
drivers/net/ice/base/ice_ptype_mk.c | 4 +-
drivers/net/ice/base/ice_sched.c | 24 +-
drivers/net/ice/base/ice_switch.c | 15 +-
drivers/net/ice/base/ice_type.h | 30 +-
drivers/net/ice/base/ice_xlt_kb.c | 10 +-
drivers/net/ice/ice_ethdev.c | 19 +-
drivers/net/ice/ice_rxtx.c | 44 ++-
drivers/net/ice/ice_rxtx.h | 2 +
drivers/net/ionic/ionic_dev.c | 5 +-
drivers/net/ionic/ionic_lif.c | 6 +-
drivers/net/ionic/ionic_rx_filter.c | 2 +-
drivers/net/ionic/ionic_rxtx.c | 29 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 12 +-
drivers/net/ixgbe/ixgbe_pf.c | 8 +-
drivers/net/memif/rte_eth_memif.c | 8 +-
drivers/net/mlx4/mlx4.c | 9 +-
drivers/net/mlx4/mlx4_mp.c | 7 +-
drivers/net/mlx5/linux/mlx5_ethdev_os.c | 22 +-
drivers/net/mlx5/linux/mlx5_mp_os.c | 6 +-
drivers/net/mlx5/linux/mlx5_os.c | 13 +-
drivers/net/mlx5/mlx5.c | 32 +-
drivers/net/mlx5/mlx5.h | 7 +-
drivers/net/mlx5/mlx5_devx.c | 3 +-
drivers/net/mlx5/mlx5_flow.c | 101 ++++--
drivers/net/mlx5/mlx5_flow.h | 82 +++--
drivers/net/mlx5/mlx5_flow_dv.c | 193 +++++-----
drivers/net/mlx5/mlx5_flow_meter.c | 3 +-
drivers/net/mlx5/mlx5_flow_verbs.c | 23 +-
drivers/net/mlx5/mlx5_rxq.c | 15 +-
drivers/net/mlx5/mlx5_trigger.c | 16 +
drivers/net/mlx5/mlx5_tx.h | 108 +++---
drivers/net/mlx5/mlx5_utils.c | 2 +-
drivers/net/mlx5/windows/mlx5_flow_os.c | 2 +-
drivers/net/mvneta/mvneta_rxtx.c | 4 +
drivers/net/nfp/nfp_common.c | 6 +-
drivers/net/nfp/nfp_ethdev.c | 12 +-
drivers/net/nfp/nfp_ethdev_vf.c | 1 -
drivers/net/nfp/nfp_rxtx.c | 12 +-
drivers/net/nfp/nfpcore/nfp_hwinfo.c | 2 +-
drivers/net/ngbe/base/ngbe_eeprom.c | 32 --
drivers/net/ngbe/base/ngbe_regs.h | 2 +-
drivers/net/ngbe/base/ngbe_type.h | 7 +-
drivers/net/ngbe/ngbe_ethdev.c | 20 +-
drivers/net/qede/base/ecore_init_fw_funcs.c | 2 +-
drivers/net/qede/base/ecore_int.c | 4 +-
drivers/net/tap/tap_flow.c | 2 +-
drivers/net/tap/tap_tcmsgs.c | 18 +-
drivers/net/tap/tap_tcmsgs.h | 16 +-
drivers/net/txgbe/base/txgbe_eeprom.c | 32 --
drivers/net/txgbe/base/txgbe_type.h | 4 +-
drivers/net/txgbe/txgbe_ethdev.c | 11 +-
drivers/net/txgbe/txgbe_flow.c | 33 +-
drivers/net/virtio/virtio_ethdev.c | 7 +
drivers/vdpa/ifc/ifcvf_vdpa.c | 27 +-
drivers/vdpa/sfc/meson.build | 1 -
examples/fips_validation/main.c | 4 +-
examples/ipsec-secgw/ipsec-secgw.c | 21 +-
examples/ipsec-secgw/sa.c | 52 ++-
examples/l2fwd-crypto/main.c | 2 +-
examples/l3fwd/l3fwd.h | 5 +
examples/l3fwd/l3fwd_event.c | 6 +
examples/l3fwd/main.c | 4 +-
examples/qos_sched/cfg_file.c | 2 +-
examples/qos_sched/profile.cfg | 2 -
examples/vhost/main.c | 21 +-
examples/vm_power_manager/channel_manager.c | 19 +-
lib/cryptodev/cryptodev_pmd.c | 4 +-
lib/cryptodev/cryptodev_pmd.h | 2 +-
lib/cryptodev/rte_cryptodev.c | 20 +-
lib/eal/common/eal_common_proc.c | 17 +-
lib/eal/common/eal_common_trace.c | 69 ++--
lib/eal/common/eal_common_trace_ctf.c | 3 -
lib/eal/common/eal_common_trace_utils.c | 11 +-
lib/eal/common/eal_trace.h | 3 +-
lib/eal/common/malloc_heap.c | 2 +-
lib/eal/common/malloc_mp.c | 2 +-
lib/eal/common/rte_service.c | 13 +-
lib/eal/include/rte_bitmap.h | 2 -
lib/eal/include/rte_common.h | 4 +-
lib/eal/include/rte_hexdump.h | 4 -
lib/eal/include/rte_memzone.h | 3 -
lib/eal/include/rte_uuid.h | 4 +-
lib/eventdev/rte_event_crypto_adapter.c | 30 +-
lib/eventdev/rte_event_eth_rx_adapter.h | 2 +-
lib/eventdev/rte_event_eth_tx_adapter.c | 15 +-
lib/fib/rte_fib.h | 2 -
lib/fib/rte_fib6.h | 2 -
lib/graph/rte_graph_worker.h | 4 +-
lib/gro/gro_tcp4.c | 8 +-
lib/gro/gro_udp4.c | 6 +-
lib/hash/rte_cuckoo_hash.c | 1 +
lib/hash/rte_thash.h | 2 -
lib/ipsec/esp_outb.c | 8 +-
lib/ipsec/rte_ipsec_sad.h | 2 -
lib/kni/rte_kni.h | 4 +-
lib/lpm/rte_lpm.h | 2 -
lib/lpm/rte_lpm6.h | 2 -
lib/mbuf/rte_mbuf.h | 3 -
lib/mempool/rte_mempool.c | 55 +--
lib/mempool/rte_mempool.h | 3 +-
lib/net/rte_ip.h | 17 +-
lib/node/ethdev_ctrl.c | 2 +
lib/pcapng/rte_pcapng.c | 47 ++-
lib/pdump/rte_pdump.c | 6 +
lib/power/rte_power.h | 55 ---
lib/reorder/rte_reorder.h | 2 -
lib/rib/rte_rib.h | 2 -
lib/rib/rte_rib6.h | 2 -
lib/ring/rte_ring.h | 15 +-
lib/ring/rte_ring_core.h | 4 +-
lib/ring/rte_ring_elem.h | 1 -
lib/ring/rte_ring_elem_pvt.h | 10 +
lib/sched/rte_sched.c | 2 -
lib/timer/rte_timer.c | 13 +-
lib/vhost/rte_vhost.h | 15 +
lib/vhost/rte_vhost_async.h | 18 +-
lib/vhost/version.map | 1 +
lib/vhost/vhost.c | 30 ++
lib/vhost/vhost_user.c | 1 +
lib/vhost/virtio_net.c | 12 +-
meson.build | 2 +-
291 files changed, 3988 insertions(+), 2219 deletions(-)
Abdullah Sevincer (1):
event/dlb2: handle enqueuing more than maximum depth
Abhimanyu Saini (1):
common/sfc_efx/base: remove VQ index check during VQ start
Aleksandr Miloshenko (1):
net/iavf: fix Tx done descriptors cleanup
Alex Kiselev (1):
net/tap: fix overflow of network interface index
Alexander Chernavin (1):
net/virtio: fix crash when configured twice
Alexander Kozyrev (3):
net/mlx5: fix shared Rx queue config reuse
net/mlx5: fix first segment inline length
net/mlx5: fix indexed pool local cache crash
Ali Alnubani (2):
examples/l2fwd-crypto: fix typo in error message
lib: remove empty return types from doxygen comments
Amit Prakash Shukla (6):
net/mvneta: fix build with GCC 12
test/ipsec: fix build with GCC 12
ipsec: fix build with GCC 12
crypto/qat: fix build with GCC 12
net/i40e: fix build with MinGW GCC 12
net/qede/base: fix 32-bit build with GCC 12
Andrew Boyer (5):
net/ionic: fix endianness for Rx and Tx
net/ionic: fix endianness for RSS
net/ionic: fix adapter name for logging
net/ionic: fix Rx filter save
net/ionic: fix reported error stats
Anoob Joseph (1):
test/crypto: fix PDCP vectors
Apeksha Gupta (2):
net/enetfec: fix restart
net/enetfec: fix buffer leak
Arek Kusztal (1):
common/qat: fix VF to PF answer
Ashwin Sekhar T K (1):
mempool/cnxk: fix destroying empty pool
Ben Magistro (1):
doc: fix dumpcap interface parameter option
Benjamin Le Berre (1):
net/bnxt: fix error code during MTU change
Bhagyada Modali (9):
net/axgbe: fix scattered Rx
net/axgbe: fix mbuf lengths in scattered Rx
net/axgbe: fix length of each segment in scattered Rx
net/axgbe: fix checksum and RSS in scattered Rx
net/axgbe: optimise scattered Rx
net/axgbe: remove freeing buffer in scattered Rx
net/axgbe: reset end of packet in scattered Rx
net/axgbe: clear buffer on scattered Rx chaining failure
net/axgbe: save segment data in scattered Rx
Bing Zhao (2):
net/mlx5: fix build with recent compilers
bus/auxiliary: prevent device from being probed again
Brian Dooley (1):
crypto/qat: fix null hash algorithm digest size
Changpeng Liu (1):
vhost: add non-blocking API for posting interrupt
Chaoyong He (1):
net/nfp: fix Rx descriptor DMA address
Chengwen Feng (8):
net/hns3: fix crash in SVE Tx
net/hns3: fix next-to-use overflow in SVE Tx
net/hns3: fix next-to-use overflow in simple Tx
net/hns3: fix crash when secondary process access FW
net/hns3: revert Tx performance optimization
net/hns3: revert fix mailbox communication with HW
net/hns3: fix VF mailbox message handling
app/testpmd: remove jumbo offload
Ciara Power (1):
test/crypto: fix wireless auth digest segment
Conor Walsh (1):
doc: fix reference to dma application example
Dariusz Sosnowski (1):
net/mlx5: fix hairpin split with set VLAN VID action
David Marchand (23):
vhost: fix virtqueue use after free on NUMA reallocation
app/testpmd: restore ixgbe bypass commands
net/failsafe: fix interrupt handle leak
net/bnxt: fix build with GCC 13
trace: fix mode for new trace point
trace: fix mode change
trace: fix leak with regexp
trace: fix dynamically enabling trace points
trace: fix race in debug dump
ci: bump versions of actions in GHA
ci: update to new API for step outputs in GHA
service: fix build with clang 15
vhost: fix build with clang 15
bus/dpaa: fix build with clang 15
net/atlantic: fix build with clang 15
net/dpaa2: fix build with clang 15
app/testpmd: fix build with clang 15
app/testpmd: fix build with clang 15 in flow code
test/efd: fix build with clang 15
test/member: fix build with clang 15
test/event: fix build with clang 15
ci: enable ABI check in GHA
trace: fix metadata dump
Dmitry Kozlyuk (4):
build: enable developer mode for all working trees
eal: fix side effect in some pointer arithmetic macros
mempool: make event callbacks process-private
common/mlx5: fix multi-process mempool registration
Dong Zhou (1):
net/mlx5: fix thread workspace memory leak
Dongdong Liu (2):
doc: fix application name in procinfo guide
doc: document device dump in procinfo guide
Erik Gabriel Carrillo (1):
service: fix early move to inactive status
Fidaullah Noonari (1):
malloc: fix storage size for some allocations
Frank Du (1):
net/ice: fix interrupt handler unregister
Gagandeep Singh (5):
net/dpaa: fix buffer freeing in slow path
net/dpaa: use internal mempool for SG table
net/dpaa: fix buffer freeing on SG Tx
net/dpaa2: use internal mempool for SG table
net/dpaa2: fix buffer freeing on SG Tx
Ganapati Kundapura (1):
eventdev/crypto: fix multi-process
Gregory Etelson (6):
net/mlx5: fix RSS expansion buffer size
app/testpmd: fix MAC header in checksum forward engine
common/mlx5: fix shared mempool subscription
net/mlx5: fix port initialization with small LRO
net/mlx5: fix maximum LRO message size
doc: add LRO size limitation in mlx5 guide
Haiyue Wang (1):
ring: fix description
Hamza Khan (1):
examples/vm_power_manager: use safe list iterator
Hanumanth Pothula (1):
net/cnxk: fix DF bit in vector mode
Hernan Vargas (14):
baseband/acc100: fix memory leak
baseband/acc100: check turbo dec/enc input
baseband/acc100: add null checks
baseband/acc100: fix input length for CRC24B
baseband/acc100: fix clearing PF IR outside handler
baseband/acc100: fix device minimum alignment
baseband/acc100: fix close cleanup
baseband/acc100: add LDPC encoder padding function
baseband/acc100: check AQ availability
baseband/acc100: fix ring availability calculation
baseband/acc100: enforce additional check on FCW
baseband/acc100: fix null HARQ input case
baseband/acc100: fix ring/queue allocation
baseband/acc100: fix double MSI intr in TB mode
Huisong Li (18):
net/hns3: fix Rx with PTP
net/hns3: delete unused markup
net/hns3: fix clearing hardware MAC statistics
net/hns3: fix RSS filter restore
net/hns3: fix RSS flow rule restore
net/hns3: move flow direction rule recovery
net/hns3: fix packet type for GENEVE
net/hns3: fix IPv4 and IPv6 RSS
net/hns3: fix typos in IPv6 SCTP fields
net/hns3: fix IPv4 RSS
net/hns3: add L3 and L4 RSS types
net/bonding: fix slave device Rx/Tx offload configuration
net/bonding: fix dropping valid MAC packets
net/bonding: fix mbuf fast free handling
net/hns3: extract functions to create RSS and FDIR flow rule
net/hns3: fix RSS rule restore
net/hns3: fix lock protection of RSS flow rule
net/hns3: fix restore filter function input
Huzaifa Rahman (1):
net/memif: fix crash with different number of Rx/Tx queues
Ilya Maximets (1):
doc: fix support table for Ethernet/VLAN flow items
Ivan Malov (4):
common/sfc_efx/base: fix maximum Tx data count
net/bonding: fix descriptor limit reporting
net/bonding: fix flow flush order on close
net/bonding: set initial value of descriptor count alignment
James Hershaw (1):
net/nfp: improve HW info header log readability
Jeremy Spewock (1):
test/ipsec: skip if no compatible device
Jerin Jacob (2):
eal: fix doxygen comments for UUID
power: fix some doxygen comments
Jiawei Wang (4):
net/mlx5: fix modify action with tunnel decapsulation
net/mlx5: fix tunnel header with IPIP offload
net/mlx5: fix source port checking in sample flow rule
net/mlx5: fix mirror flow validation with ASO action
Jiawen Wu (6):
net/txgbe: fix IPv6 flow rule
net/txgbe: remove semaphore between SW/FW
net/txgbe: rename some extended statistics
net/ngbe: rename some extended statistics
net/ngbe: remove semaphore between SW/FW
net/ngbe: fix maximum frame size
Jie Hai (1):
net/hns3: fix minimum Tx frame length
Jie Wang (1):
net/i40e: fix jumbo frame Rx with X722
Jun Qiu (3):
gro: trim tail padding bytes
net/bonding: fix Tx hash for TCP
hash: fix RCU configuration memory leak
Kai Ji (1):
test/crypto: fix bitwise operator in a SNOW3G case
Kalesh AP (2):
net/bnxt: remove unnecessary check
net/bnxt: fix representor info freeing
Ke Zhang (2):
net/i40e: fix VF representor release
net/iavf: fix L3 checksum Tx offload flag
Kevin Liu (2):
net/iavf: check illegal packet sizes
net/ice: check illegal packet sizes
Kevin Traynor (9):
Revert "cryptodev: fix missing SHA3 algorithm strings"
version: 21.11.3-rc1
Revert "net/i40e: fix jumbo frame Rx with X722"
Revert "net/i40e: fix max frame size config at port level"
Revert "net/i40e: enable maximum frame size at port level"
Revert "net/iavf: add thread for event callbacks"
vhost: fix doxygen warnings
ring: squash gcc 12.2.1 warnings
version: 21.11.3
Kumara Parameshwaran (1):
gro: check payload length after trim
Long Li (2):
net/mlx4: fix Verbs FD leak in secondary process
net/mlx5: fix Verbs FD leak in secondary process
Long Wu (1):
net/nfp: fix memory leak in Rx
Luca Boccassi (1):
drivers: fix typos found by Lintian
Mao YingMing (1):
net/bnxt: fix null pointer dereference in LED config
Mattias Rönnblom (3):
net: accept unaligned data in checksum routines
event/dsw: fix flow migration
doc: fix event timer adapter guide
Maxime Coquelin (1):
vhost: fix build with GCC 12
Megha Ajmera (2):
sched: fix subport profile configuration
examples/qos_sched: fix number of subport profiles
Michael Baum (5):
net/mlx5: fix null check in devargs parsing
doc: fix underlines in testpmd guide
doc: fix colons in testpmd aged flow rules
net/mlx5: fix race condition in counter pool resizing
net/mlx5: fix port event cleaning order
Mingjin Ye (4):
net/ice: support VXLAN-GPE tunnel offload
net/i40e: fix pctype configuration for X722
net/ice: fix scalar Rx path segment
net/ice: fix scalar Tx path segment
Mário Kuka (1):
pcapng: fix write more packets than IOV_MAX limit
Naga Harish K S V (4):
eventdev/eth_tx: add spinlock for adapter start/stop
eventdev/eth_tx: fix adapter stop
timer: fix stopping all timers
eventdev/eth_tx: fix queue delete
Nithin Dabilpuram (3):
examples/ipsec-secgw: use Tx checksum offload conditionally
examples/l3fwd: fix MTU configuration with event mode
net/cnxk: fix later skip to include mbuf private data
Olivier Matz (8):
cryptodev: fix unduly newlines in logs
mem: fix API doc about allocation on secondary processes
event/sw: fix flow ID init in self test
event/sw: fix log in self test
net/ixgbe: fix broadcast Rx on VF after promisc removal
net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
net/ixgbevf: fix promiscuous and allmulti
devtools: fix checkpatch header retrieval from stdin
Pablo de Lara (1):
examples/fips_validation: fix typo in error log
Pavan Nikhilesh (3):
event/cnxk: fix missing xstats operations
event/cnxk: fix mbuf offset calculation
event/cnxk: fix missing mempool cookie marking
Peng Zhang (3):
net/nfp: compose firmware file name with new hwinfo
buildtools: fix NUMA nodes count
net/nfp: fix internal buffer size and MTU check
Qi Zhang (12):
net/ice/base: fix division during E822 PTP init
net/ice/base: fix 100M speed capability
net/ice/base: fix DSCP PFC TLV creation
net/ice/base: fix media type of PHY 10G SFI C2C
net/ice/base: fix function descriptions for parser
net/ice/base: fix endian format
net/ice/base: fix array overflow in add switch recipe
net/ice/base: fix bit finding range over ptype bitmap
net/ice/base: fix add MAC rule
net/ice/base: fix double VLAN in promiscuous mode
net/ice/base: ignore promiscuous already exist
net/ice/base: fix input set of GTPoGRE
Qiming Yang (1):
app/testpmd: skip port reset in secondary process
Radu Nicolau (6):
net/iavf: update IPsec ESN values when updating session
net/iavf: fix IPsec flow create error check
net/iavf: fix SPI check
net/iavf: fix queue stop for large VF
examples/ipsec-secgw: fix Tx checksum offload flag
examples/ipsec-secgw: fix Tx checksum offload flag
Raja Zidane (1):
net/mlx5: fix Tx check for hardware descriptor length
Rohit Raj (1):
net/dpaa: fix jumbo packet Rx in case of VSP
Satha Rao (1):
common/cnxk: fix schedule weight update
Satheesh Paul (3):
common/cnxk: fix log level during MCAM allocation
common/cnxk: fix missing flow counter reset
common/cnxk: fix printing disabled MKEX registers
Shiqi Liu (2):
node: check Rx element allocation
dma/idxd: check DSA device allocation
Shun Hao (4):
net/mlx5: fix meter profile delete after disable
net/mlx5: fix action flag data type
net/mlx5: fix drop action validation
net/mlx5: fix assert when creating meter policy
Stephen Coleman (1):
doc: fix typo depreciated instead of deprecated
Stephen Hemminger (8):
event/sw: fix device name in dump
eal: fix data race in multi-process support
pdump: do not allow enable/disable in primary process
app/dumpcap: fix crash on cleanup
app/dumpcap: fix pathname for output file
app/testpmd: make quit flag volatile
ring: remove leftover comment about watermark
doc: avoid meson deprecation in setup
Steve Yang (1):
net/iavf: fix pattern check for flow director parser
Steven Zou (1):
common/iavf: avoid copy in async mode
Sunyang Wu (1):
test/crypto: fix debug messages
Taekyung Kim (1):
vdpa/ifc: handle data path update failure
Tal Shnaiderman (1):
net/mlx5: fix thread termination check on Windows
Thomas Monjalon (2):
drivers: remove unused build variable
doc: add Rx buffer split capability for mlx5
Ting Xu (1):
net/ice/base: fix inner symmetric RSS hash in raw flow
Tomasz Jonak (1):
net/ice: fix null function pointer call
Vanshika Shukla (1):
net/dpaa2: fix DPDMUX error behaviour
Viacheslav Ovsiienko (3):
net/mlx5: fix check for orphan wait descriptor
net/mlx5: fix single not inline packet storing
net/mlx5: fix inline length exceeding descriptor limit
Vladimir Medvedkin (2):
test/hash: remove dead code in extendable bucket test
test/hash: fix bulk lookup check
Volodymyr Fialko (3):
cryptodev: fix missing SHA3 algorithm strings
eventdev: fix name of Rx conf type in documentation
app/eventdev: fix limits in error message
Wenwu Ma (1):
examples/vhost: fix use after free
Wenzhuo Lu (1):
net/iavf: fix VLAN offload
Yi Li (1):
doc: fix maximum packet size of virtio driver
Yiding Zhou (4):
net/iavf: fix VLAN insertion
net/iavf: revert VLAN insertion fix
net/ice/base: fix duplicate flow rules
net/iavf: add thread for event callbacks
Yunjian Wang (2):
net/bonding: fix array overflow in Rx burst
net/bonding: fix double slave link status query
Zhichao Zeng (3):
net/ice: fix RSS hash update
net/iavf: fix processing VLAN TCI in SSE path
net/iavf: fix outer checksum flags
Zhirun Yan (1):
graph: fix node objects allocation
^ permalink raw reply [relevance 1%]
* Re: [RFC PATCH 2/7] telemetry: add uint type as alias for u64
2022-12-19 10:37 0% ` Thomas Monjalon
@ 2022-12-19 13:22 0% ` Bruce Richardson
0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-12-19 13:22 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Tyler Retzlaff, dev, Morten Brørup, david.marchand
On Mon, Dec 19, 2022 at 11:37:19AM +0100, Thomas Monjalon wrote:
> 15/12/2022 14:58, Bruce Richardson:
> > On Thu, Dec 15, 2022 at 02:36:51PM +0100, Thomas Monjalon wrote:
> > > 15/12/2022 10:44, Bruce Richardson:
> > > > On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > > > > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > > > > For future standardization on the "uint" name for unsigned values rather
> > > > > > than the existing "u64" one, we can for now:
> > > > > > * rename all internal values to use uint rather than u64
> > > > > > * add new function names to alias the existing u64 ones
> > > > > >
> > > > > > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > >
> > > > > when adding __rte_experimental api i have been asked to add the
> > > > > following boilerplate documentation block. i'm not pushing it, just
> > > > > recalling it is what i get asked for, so in case it's something we do?
> > > > > see lib/eal/include/rte_thread.h as an example
> > > > >
> > > > >
> > > > > ```
> > > > > * @warning
> > > > > * @b EXPERIMENTAL: this API may change without prior notice.
> > > > > ```
> > > > >
> > > >
> > > > Ok, thanks for the notice.
> > > >
> > > > Actually, related to this, since we are adding these functions as aliases
> > > > for existing stable functions, I would like to see these being added not as
> > > > experimental. The reason for that, is that while they are experimental, we
> > > > cannot feasibly mark the old function names as deprecated. :-(
> > > >
> > > > Adding Thomas and David on CC for their thoughts.
> > >
> > > Is it related to telemetry?
> > >
> > > In general, yes we cannot deprecate something if there is no stable replacement.
> > > The recommended step is to introduce a new experimental API
> > > and deprecate the old one when the new API is stable.
> > >
> > Yes, understood.
> > What we are really trying to do here is to rename an API, by process of
> > adding the new API and then marking the old one as deprecated. The small
> > issue is that adding the new one it is by default experimental, meaning we
> > need to wait for deprecating old one. Ideally, as soon as the new API is
> > added, we would like to point people to use that, but can't really do so
> > while it is experimental.
> >
> > ---
> >
> > By way of explicit detail, Morten pointed out the inconsistency in the
> > telemetry APIs and types:
> >
> > * we have add_*_int, which takes a 32-bit signed value
> > * we have add_*_u64 which takes 64-bit unsigned (as name suggests).
> >
> > The ideal end-state is to always use 64-bit values (since there is no space
> > saving from 32-bit as a union is used), and just name everything as "int"
> > or "uint" for signed/unsigned. The two big steps here are:
> >
> > * expanding type of the "int" functions to take 64-bit parameters - this is
> > ABI change but not API one, since existing code will happily promote
> > values on compile. Therefore, we just use ABI versioning to have a 32-bit
> > version for older linked binaries.
> > * the rename of the rte_tel_data_add_array_u64 and
> > rte_tel_data_add_dict_u64 to *_uint variants. Though keeping
> > compatibility is easier, as we can just add new functions, the overall
> > process is slower since the new functions technically should be added as
> > experimental - hence the email. For the case of function renaming, do we
> > still need to have the "renamed" versions as experimental initially?
>
> If a function is simply renamed, I think there is no need for the experimental step.
> Would we keep an alias with the old name for some time?
>
Yes, the old name should go through the deprecation process. No
hurry with removal.
/Bruce
^ permalink raw reply [relevance 0%]
* Re: [RFC PATCH 2/7] telemetry: add uint type as alias for u64
2022-12-15 13:58 4% ` Bruce Richardson
@ 2022-12-19 10:37 0% ` Thomas Monjalon
2022-12-19 13:22 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-19 10:37 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Tyler Retzlaff, dev, Morten Brørup, david.marchand
15/12/2022 14:58, Bruce Richardson:
> On Thu, Dec 15, 2022 at 02:36:51PM +0100, Thomas Monjalon wrote:
> > 15/12/2022 10:44, Bruce Richardson:
> > > On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > > > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > > > For future standardization on the "uint" name for unsigned values rather
> > > > > than the existing "u64" one, we can for now:
> > > > > * rename all internal values to use uint rather than u64
> > > > > * add new function names to alias the existing u64 ones
> > > > >
> > > > > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > >
> > > > when adding __rte_experimental api i have been asked to add the
> > > > following boilerplate documentation block. i'm not pushing it, just
> > > > recalling it is what i get asked for, so in case it's something we do?
> > > > see lib/eal/include/rte_thread.h as an example
> > > >
> > > >
> > > > ```
> > > > * @warning
> > > > * @b EXPERIMENTAL: this API may change without prior notice.
> > > > ```
> > > >
> > >
> > > Ok, thanks for the notice.
> > >
> > > Actually, related to this, since we are adding these functions as aliases
> > > for existing stable functions, I would like to see these being added not as
> > > experimental. The reason for that, is that while they are experimental, we
> > > cannot feasibly mark the old function names as deprecated. :-(
> > >
> > > Adding Thomas and David on CC for their thoughts.
> >
> > Is it related to telemetry?
> >
> > In general, yes we cannot deprecate something if there is no stable replacement.
> > The recommended step is to introduce a new experimental API
> > and deprecate the old one when the new API is stable.
> >
> Yes, understood.
> What we are really trying to do here is to rename an API, by process of
> adding the new API and then marking the old one as deprecated. The small
> issue is that adding the new one it is by default experimental, meaning we
> need to wait for deprecating old one. Ideally, as soon as the new API is
> added, we would like to point people to use that, but can't really do so
> while it is experimental.
>
> ---
>
> By way of explicit detail, Morten pointed out the inconsistency in the
> telemetry APIs and types:
>
> * we have add_*_int, which takes a 32-bit signed value
> * we have add_*_u64 which takes 64-bit unsigned (as name suggests).
>
> The ideal end-state is to always use 64-bit values (since there is no space
> saving from 32-bit as a union is used), and just name everything as "int"
> or "uint" for signed/unsigned. The two big steps here are:
>
> * expanding type of the "int" functions to take 64-bit parameters - this is
> ABI change but not API one, since existing code will happily promote
> values on compile. Therefore, we just use ABI versioning to have a 32-bit
> version for older linked binaries.
> * the rename of the rte_tel_data_add_array_u64 and
> rte_tel_data_add_dict_u64 to *_uint variants. Though keeping
> compatibility is easier, as we can just add new functions, the overall
> process is slower since the new functions technically should be added as
> experimental - hence the email. For the case of function renaming, do we
> still need to have the "renamed" versions as experimental initially?
If a function is simply renamed, I think there is no need for the experimental step.
Would we keep an alias with the old name for some time?
^ permalink raw reply [relevance 0%]
* [PATCH V8 0/8] telemetry: fix data truncation and conversion error and add hex integer API
` (5 preceding siblings ...)
2022-12-16 1:54 3% ` [PATCH V7 " Huisong Li
@ 2022-12-19 7:06 3% ` Huisong Li
2023-01-16 12:06 0% ` lihuisong (C)
6 siblings, 1 reply; 200+ results
From: Huisong Li @ 2022-12-19 7:06 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v8: fix the coding style in patch 7/8
-v7: replace sprintf with snprintf in patch 6/8
-v6: fix code alignment to keep in line with codes in the file
-v5:
- drop a refactor patch.
- no limit the bit width for xxx_uint_hex API.
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (8):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 52 +++++++++-
lib/telemetry/telemetry_data.c | 73 ++++++++++++++
lib/telemetry/version.map | 9 ++
8 files changed, 309 insertions(+), 30 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: 21.11.3 patches review and test
2022-12-06 11:29 1% 21.11.3 patches review and test Kevin Traynor
2022-12-13 11:48 0% ` Christian Ehrhardt
@ 2022-12-16 7:55 0% ` YangHang Liu
1 sibling, 0 replies; 200+ results
From: YangHang Liu @ 2022-12-16 7:55 UTC (permalink / raw)
To: Kevin Traynor
Cc: stable, dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
David Christensen, Hemant Agrawal, Ian Stokes, Jerin Jacob,
John McNamara, Ju-Hyoung Lee, Luca Boccassi, Pei Zhang,
qian.q.xu, Raslan Darawsheh, Thomas Monjalon, yuan.peng,
zhaoyan.chen, Chao Yang
[-- Attachment #1: Type: text/plain, Size: 19006 bytes --]
Hi Kevin,
RedHat QE does not find new issues about the 21.11.3 dpdk during the tests.
We tested below 17 scenarios and all got PASS on RHEL8:
- Guest with device assignment(PF) throughput testing(1G hugepage size):
PASS
- Guest with device assignment(PF) throughput testing(2M hugepage size)
: PASS
- Guest with device assignment(VF) throughput testing: PASS
- PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS
- PVP vhost-user 2Q throughput testing: PASS
- PVP vhost-user 1Q - cross numa node throughput testing: PASS
- Guest with vhost-user 2 queues throughput testing: PASS
- vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect:
PASS
- vhost-user reconnect with dpdk-client, qemu-server: ovs reconnect: PASS
- PVP 1Q live migration testing: PASS
- PVP 1Q cross numa node live migration testing: PASS
- Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS
- Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS
- Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS
- Guest with ovs+dpdk+vhost-user 4Q live migration testing: PASS
- Host PF + DPDK testing: PASS
- Host VF + DPDK testing: PASS
Versions:
- kernel 4.18
- qemu-kvm-6.2
- DPDK
- commit 0bb6905a88784306878d9fceb0aa1c1ec68d1397 (tag: v21.11.3-rc1)
Author: Kevin Traynor <ktraynor@redhat.com>
Date: Mon Dec 5 11:53:33 2022 +0000
version: 21.11.3-rc1
Signed-off-by: Kevin Traynor <ktraynor@redhat.com>
NICs: X540-AT2 NIC(ixgbe, 10G)
Best Regards,
YangHang Liu
On Tue, Dec 6, 2022 at 7:29 PM Kevin Traynor <ktraynor@redhat.com> wrote:
> Hi all,
>
> Here is a list of patches targeted for stable release 21.11.3.
>
> The planned date for the final release is 19th December.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.3-rc1
>
> These patches are located at branch 21.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
>
> Thanks.
>
> Kevin
>
> ---
> Abdullah Sevincer (1):
> event/dlb2: handle enqueuing more than maximum depth
>
> Abhimanyu Saini (1):
> common/sfc_efx/base: remove VQ index check during VQ start
>
> Aleksandr Miloshenko (1):
> net/iavf: fix Tx done descriptors cleanup
>
> Alex Kiselev (1):
> net/tap: fix overflow of network interface index
>
> Alexander Chernavin (1):
> net/virtio: fix crash when configured twice
>
> Alexander Kozyrev (3):
> net/mlx5: fix shared Rx queue config reuse
> net/mlx5: fix first segment inline length
> net/mlx5: fix indexed pool local cache crash
>
> Ali Alnubani (1):
> examples/l2fwd-crypto: fix typo in error message
>
> Amit Prakash Shukla (6):
> net/mvneta: fix build with GCC 12
> test/ipsec: fix build with GCC 12
> ipsec: fix build with GCC 12
> crypto/qat: fix build with GCC 12
> net/i40e: fix build with MinGW GCC 12
> net/qede/base: fix 32-bit build with GCC 12
>
> Andrew Boyer (5):
> net/ionic: fix endianness for Rx and Tx
> net/ionic: fix endianness for RSS
> net/ionic: fix adapter name for logging
> net/ionic: fix Rx filter save
> net/ionic: fix reported error stats
>
> Anoob Joseph (1):
> test/crypto: fix PDCP vectors
>
> Apeksha Gupta (2):
> net/enetfec: fix restart
> net/enetfec: fix buffer leak
>
> Arek Kusztal (1):
> common/qat: fix VF to PF answer
>
> Ashwin Sekhar T K (1):
> mempool/cnxk: fix destroying empty pool
>
> Ben Magistro (1):
> doc: fix dumpcap interface parameter option
>
> Benjamin Le Berre (1):
> net/bnxt: fix error code during MTU change
>
> Bhagyada Modali (9):
> net/axgbe: fix scattered Rx
> net/axgbe: fix mbuf lengths in scattered Rx
> net/axgbe: fix length of each segment in scattered Rx
> net/axgbe: fix checksum and RSS in scattered Rx
> net/axgbe: optimise scattered Rx
> net/axgbe: remove freeing buffer in scattered Rx
> net/axgbe: reset end of packet in scattered Rx
> net/axgbe: clear buffer on scattered Rx chaining failure
> net/axgbe: save segment data in scattered Rx
>
> Bing Zhao (2):
> net/mlx5: fix build with recent compilers
> bus/auxiliary: prevent device from being probed again
>
> Brian Dooley (1):
> crypto/qat: fix null hash algorithm digest size
>
> Changpeng Liu (1):
> vhost: add non-blocking API for posting interrupt
>
> Chaoyong He (1):
> net/nfp: fix Rx descriptor DMA address
>
> Chengwen Feng (8):
> net/hns3: fix crash in SVE Tx
> net/hns3: fix next-to-use overflow in SVE Tx
> net/hns3: fix next-to-use overflow in simple Tx
> net/hns3: fix crash when secondary process access FW
> net/hns3: revert Tx performance optimization
> net/hns3: revert fix mailbox communication with HW
> net/hns3: fix VF mailbox message handling
> app/testpmd: remove jumbo offload
>
> Ciara Power (1):
> test/crypto: fix wireless auth digest segment
>
> Conor Walsh (1):
> doc: fix reference to dma application example
>
> Dariusz Sosnowski (1):
> net/mlx5: fix hairpin split with set VLAN VID action
>
> David Marchand (23):
> vhost: fix virtqueue use after free on NUMA reallocation
> app/testpmd: restore ixgbe bypass commands
> net/failsafe: fix interrupt handle leak
> net/bnxt: fix build with GCC 13
> trace: fix mode for new trace point
> trace: fix mode change
> trace: fix leak with regexp
> trace: fix dynamically enabling trace points
> trace: fix race in debug dump
> ci: bump versions of actions in GHA
> ci: update to new API for step outputs in GHA
> service: fix build with clang 15
> vhost: fix build with clang 15
> bus/dpaa: fix build with clang 15
> net/atlantic: fix build with clang 15
> net/dpaa2: fix build with clang 15
> app/testpmd: fix build with clang 15
> app/testpmd: fix build with clang 15 in flow code
> test/efd: fix build with clang 15
> test/member: fix build with clang 15
> test/event: fix build with clang 15
> ci: enable ABI check in GHA
> trace: fix metadata dump
>
> Dmitry Kozlyuk (4):
> build: enable developer mode for all working trees
> eal: fix side effect in some pointer arithmetic macros
> mempool: make event callbacks process-private
> common/mlx5: fix multi-process mempool registration
>
> Dong Zhou (1):
> net/mlx5: fix thread workspace memory leak
>
> Dongdong Liu (2):
> doc: fix application name in procinfo guide
> doc: document device dump in procinfo guide
>
> Erik Gabriel Carrillo (1):
> service: fix early move to inactive status
>
> Fidaullah Noonari (1):
> malloc: fix storage size for some allocations
>
> Frank Du (1):
> net/ice: fix interrupt handler unregister
>
> Gagandeep Singh (5):
> net/dpaa: fix buffer freeing in slow path
> net/dpaa: use internal mempool for SG table
> net/dpaa: fix buffer freeing on SG Tx
> net/dpaa2: use internal mempool for SG table
> net/dpaa2: fix buffer freeing on SG Tx
>
> Ganapati Kundapura (1):
> eventdev/crypto: fix multi-process
>
> Gregory Etelson (6):
> net/mlx5: fix RSS expansion buffer size
> app/testpmd: fix MAC header in checksum forward engine
> common/mlx5: fix shared mempool subscription
> net/mlx5: fix port initialization with small LRO
> net/mlx5: fix maximum LRO message size
> doc: add LRO size limitation in mlx5 guide
>
> Haiyue Wang (1):
> ring: fix description
>
> Hamza Khan (1):
> examples/vm_power_manager: use safe list iterator
>
> Hanumanth Pothula (1):
> net/cnxk: fix DF bit in vector mode
>
> Hernan Vargas (14):
> baseband/acc100: fix memory leak
> baseband/acc100: check turbo dec/enc input
> baseband/acc100: add null checks
> baseband/acc100: fix input length for CRC24B
> baseband/acc100: fix clearing PF IR outside handler
> baseband/acc100: fix device minimum alignment
> baseband/acc100: fix close cleanup
> baseband/acc100: add LDPC encoder padding function
> baseband/acc100: check AQ availability
> baseband/acc100: fix ring availability calculation
> baseband/acc100: enforce additional check on FCW
> baseband/acc100: fix null HARQ input case
> baseband/acc100: fix ring/queue allocation
> baseband/acc100: fix double MSI intr in TB mode
>
> Huisong Li (18):
> net/hns3: fix Rx with PTP
> net/hns3: delete unused markup
> net/hns3: fix clearing hardware MAC statistics
> net/hns3: fix RSS filter restore
> net/hns3: fix RSS flow rule restore
> net/hns3: move flow direction rule recovery
> net/hns3: fix packet type for GENEVE
> net/hns3: fix IPv4 and IPv6 RSS
> net/hns3: fix typos in IPv6 SCTP fields
> net/hns3: fix IPv4 RSS
> net/hns3: add L3 and L4 RSS types
> net/bonding: fix slave device Rx/Tx offload configuration
> net/bonding: fix dropping valid MAC packets
> net/bonding: fix mbuf fast free handling
> net/hns3: extract functions to create RSS and FDIR flow rule
> net/hns3: fix RSS rule restore
> net/hns3: fix lock protection of RSS flow rule
> net/hns3: fix restore filter function input
>
> Huzaifa Rahman (1):
> net/memif: fix crash with different number of Rx/Tx queues
>
> Ilya Maximets (1):
> doc: fix support table for Ethernet/VLAN flow items
>
> Ivan Malov (3):
> common/sfc_efx/base: fix maximum Tx data count
> net/bonding: fix descriptor limit reporting
> net/bonding: fix flow flush order on close
>
> James Hershaw (1):
> net/nfp: improve HW info header log readability
>
> Jeremy Spewock (1):
> test/ipsec: skip if no compatible device
>
> Jerin Jacob (2):
> eal: fix doxygen comments for UUID
> power: fix some doxygen comments
>
> Jiawei Wang (4):
> net/mlx5: fix modify action with tunnel decapsulation
> net/mlx5: fix tunnel header with IPIP offload
> net/mlx5: fix source port checking in sample flow rule
> net/mlx5: fix mirror flow validation with ASO action
>
> Jiawen Wu (6):
> net/txgbe: fix IPv6 flow rule
> net/txgbe: remove semaphore between SW/FW
> net/txgbe: rename some extended statistics
> net/ngbe: rename some extended statistics
> net/ngbe: remove semaphore between SW/FW
> net/ngbe: fix maximum frame size
>
> Jie Hai (1):
> net/hns3: fix minimum Tx frame length
>
> Jie Wang (1):
> net/i40e: fix jumbo frame Rx with X722
>
> Jun Qiu (3):
> gro: trim tail padding bytes
> net/bonding: fix Tx hash for TCP
> hash: fix RCU configuration memory leak
>
> Kai Ji (1):
> test/crypto: fix bitwise operator in a SNOW3G case
>
> Kalesh AP (2):
> net/bnxt: remove unnecessary check
> net/bnxt: fix representor info freeing
>
> Ke Zhang (2):
> net/i40e: fix VF representor release
> net/iavf: fix L3 checksum Tx offload flag
>
> Kevin Liu (2):
> net/iavf: check illegal packet sizes
> net/ice: check illegal packet sizes
>
> Kevin Traynor (1):
> Revert "cryptodev: fix missing SHA3 algorithm strings"
>
> Kumara Parameshwaran (1):
> gro: check payload length after trim
>
> Long Li (2):
> net/mlx4: fix Verbs FD leak in secondary process
> net/mlx5: fix Verbs FD leak in secondary process
>
> Long Wu (1):
> net/nfp: fix memory leak in Rx
>
> Luca Boccassi (1):
> drivers: fix typos found by Lintian
>
> Mao YingMing (1):
> net/bnxt: fix null pointer dereference in LED config
>
> Mattias Rönnblom (3):
> net: accept unaligned data in checksum routines
> event/dsw: fix flow migration
> doc: fix event timer adapter guide
>
> Maxime Coquelin (1):
> vhost: fix build with GCC 12
>
> Megha Ajmera (2):
> sched: fix subport profile configuration
> examples/qos_sched: fix number of subport profiles
>
> Michael Baum (5):
> net/mlx5: fix null check in devargs parsing
> doc: fix underlines in testpmd guide
> doc: fix colons in testpmd aged flow rules
> net/mlx5: fix race condition in counter pool resizing
> net/mlx5: fix port event cleaning order
>
> Mingjin Ye (4):
> net/ice: support VXLAN-GPE tunnel offload
> net/i40e: fix pctype configuration for X722
> net/ice: fix scalar Rx path segment
> net/ice: fix scalar Tx path segment
>
> Mário Kuka (1):
> pcapng: fix write more packets than IOV_MAX limit
>
> Naga Harish K S V (4):
> eventdev/eth_tx: add spinlock for adapter start/stop
> eventdev/eth_tx: fix adapter stop
> timer: fix stopping all timers
> eventdev/eth_tx: fix queue delete
>
> Nithin Dabilpuram (3):
> examples/ipsec-secgw: use Tx checksum offload conditionally
> examples/l3fwd: fix MTU configuration with event mode
> net/cnxk: fix later skip to include mbuf private data
>
> Olivier Matz (7):
> cryptodev: fix unduly newlines in logs
> mem: fix API doc about allocation on secondary processes
> event/sw: fix flow ID init in self test
> event/sw: fix log in self test
> net/ixgbe: fix broadcast Rx on VF after promisc removal
> net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
> net/ixgbevf: fix promiscuous and allmulti
>
> Pablo de Lara (1):
> examples/fips_validation: fix typo in error log
>
> Pavan Nikhilesh (3):
> event/cnxk: fix missing xstats operations
> event/cnxk: fix mbuf offset calculation
> event/cnxk: fix missing mempool cookie marking
>
> Peng Zhang (3):
> net/nfp: compose firmware file name with new hwinfo
> buildtools: fix NUMA nodes count
> net/nfp: fix internal buffer size and MTU check
>
> Qi Zhang (12):
> net/ice/base: fix division during E822 PTP init
> net/ice/base: fix 100M speed capability
> net/ice/base: fix DSCP PFC TLV creation
> net/ice/base: fix media type of PHY 10G SFI C2C
> net/ice/base: fix function descriptions for parser
> net/ice/base: fix endian format
> net/ice/base: fix array overflow in add switch recipe
> net/ice/base: fix bit finding range over ptype bitmap
> net/ice/base: fix add MAC rule
> net/ice/base: fix double VLAN in promiscuous mode
> net/ice/base: ignore promiscuous already exist
> net/ice/base: fix input set of GTPoGRE
>
> Qiming Yang (1):
> app/testpmd: skip port reset in secondary process
>
> Radu Nicolau (5):
> net/iavf: update IPsec ESN values when updating session
> net/iavf: fix IPsec flow create error check
> net/iavf: fix SPI check
> net/iavf: fix queue stop for large VF
> examples/ipsec-secgw: fix Tx checksum offload flag
>
> Raja Zidane (1):
> net/mlx5: fix Tx check for hardware descriptor length
>
> Rohit Raj (1):
> net/dpaa: fix jumbo packet Rx in case of VSP
>
> Satha Rao (1):
> common/cnxk: fix schedule weight update
>
> Satheesh Paul (3):
> common/cnxk: fix log level during MCAM allocation
> common/cnxk: fix missing flow counter reset
> common/cnxk: fix printing disabled MKEX registers
>
> Shiqi Liu (2):
> node: check Rx element allocation
> dma/idxd: check DSA device allocation
>
> Shun Hao (4):
> net/mlx5: fix meter profile delete after disable
> net/mlx5: fix action flag data type
> net/mlx5: fix drop action validation
> net/mlx5: fix assert when creating meter policy
>
> Stephen Coleman (1):
> doc: fix typo depreciated instead of deprecated
>
> Stephen Hemminger (8):
> event/sw: fix device name in dump
> eal: fix data race in multi-process support
> pdump: do not allow enable/disable in primary process
> app/dumpcap: fix crash on cleanup
> app/dumpcap: fix pathname for output file
> app/testpmd: make quit flag volatile
> ring: remove leftover comment about watermark
> doc: avoid meson deprecation in setup
>
> Steve Yang (1):
> net/iavf: fix pattern check for flow director parser
>
> Steven Zou (1):
> common/iavf: avoid copy in async mode
>
> Sunyang Wu (1):
> test/crypto: fix debug messages
>
> Taekyung Kim (1):
> vdpa/ifc: handle data path update failure
>
> Tal Shnaiderman (1):
> net/mlx5: fix thread termination check on Windows
>
> Thomas Monjalon (2):
> drivers: remove unused build variable
> doc: add Rx buffer split capability for mlx5
>
> Ting Xu (1):
> net/ice/base: fix inner symmetric RSS hash in raw flow
>
> Tomasz Jonak (1):
> net/ice: fix null function pointer call
>
> Vanshika Shukla (1):
> net/dpaa2: fix DPDMUX error behaviour
>
> Viacheslav Ovsiienko (3):
> net/mlx5: fix check for orphan wait descriptor
> net/mlx5: fix single not inline packet storing
> net/mlx5: fix inline length exceeding descriptor limit
>
> Vladimir Medvedkin (2):
> test/hash: remove dead code in extendable bucket test
> test/hash: fix bulk lookup check
>
> Volodymyr Fialko (3):
> cryptodev: fix missing SHA3 algorithm strings
> eventdev: fix name of Rx conf type in documentation
> app/eventdev: fix limits in error message
>
> Wenwu Ma (1):
> examples/vhost: fix use after free
>
> Wenzhuo Lu (1):
> net/iavf: fix VLAN offload
>
> Yi Li (1):
> doc: fix maximum packet size of virtio driver
>
> Yiding Zhou (4):
> net/iavf: fix VLAN insertion
> net/iavf: revert VLAN insertion fix
> net/ice/base: fix duplicate flow rules
> net/iavf: add thread for event callbacks
>
> Yunjian Wang (2):
> net/bonding: fix array overflow in Rx burst
> net/bonding: fix double slave link status query
>
> Zhichao Zeng (3):
> net/ice: fix RSS hash update
> net/iavf: fix processing VLAN TCI in SSE path
> net/iavf: fix outer checksum flags
>
> Zhirun Yan (1):
> graph: fix node objects allocation
>
>
[-- Attachment #2: Type: text/html, Size: 22341 bytes --]
^ permalink raw reply [relevance 0%]
* [PATCH V7 0/8] telemetry: fix data truncation and conversion error and add hex integer API
` (4 preceding siblings ...)
2022-12-15 10:31 3% ` [PATCH V6 " Huisong Li
@ 2022-12-16 1:54 3% ` Huisong Li
2022-12-19 7:06 3% ` [PATCH V8 " Huisong Li
6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-16 1:54 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v7: replace sprintf with snprintf in patch 6/8
-v6: fix code alignment to keep in line with codes in the file
-v5:
- drop a refactor patch.
- no limit the bit width for xxx_uint_hex API.
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (8):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 52 +++++++++-
lib/telemetry/telemetry_data.c | 73 ++++++++++++++
lib/telemetry/version.map | 9 ++
8 files changed, 309 insertions(+), 30 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: [RFC PATCH 2/7] telemetry: add uint type as alias for u64
@ 2022-12-15 13:58 4% ` Bruce Richardson
2022-12-19 10:37 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-15 13:58 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Tyler Retzlaff, dev, Morten Brørup, david.marchand
On Thu, Dec 15, 2022 at 02:36:51PM +0100, Thomas Monjalon wrote:
> 15/12/2022 10:44, Bruce Richardson:
> > On Wed, Dec 14, 2022 at 09:38:45AM -0800, Tyler Retzlaff wrote:
> > > On Tue, Dec 13, 2022 at 06:27:25PM +0000, Bruce Richardson wrote:
> > > > For future standardization on the "uint" name for unsigned values rather
> > > > than the existing "u64" one, we can for now:
> > > > * rename all internal values to use uint rather than u64
> > > > * add new function names to alias the existing u64 ones
> > > >
> > > > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > > > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > > > ---
> > > > lib/telemetry/rte_telemetry.h | 36 ++++++++++++++++++++++++++++++++++
> > > > lib/telemetry/telemetry.c | 16 +++++++--------
> > > > lib/telemetry/telemetry_data.c | 28 ++++++++++++++++++--------
> > > > lib/telemetry/telemetry_data.h | 4 ++--
> > > > lib/telemetry/version.map | 7 +++++++
> > > > 5 files changed, 73 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
> > > > index c2ad65effe..60877dae0a 100644
> > > > --- a/lib/telemetry/rte_telemetry.h
> > > > +++ b/lib/telemetry/rte_telemetry.h
> > > > @@ -8,6 +8,8 @@
> > > > #ifndef _RTE_TELEMETRY_H_
> > > > #define _RTE_TELEMETRY_H_
> > > >
> > > > +#include <rte_compat.h>
> > > > +
> > > > #ifdef __cplusplus
> > > > extern "C" {
> > > > #endif
> > > > @@ -121,6 +123,22 @@ int
> > > > rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
> > > >
> > > > /**
> > >
> > > when adding __rte_experimental api i have been asked to add the
> > > following boilerplate documentation block. i'm not pushing it, just
> > > recalling it is what i get asked for, so in case it's something we do?
> > > see lib/eal/include/rte_thread.h as an example
> > >
> > >
> > > ```
> > > * @warning
> > > * @b EXPERIMENTAL: this API may change without prior notice.
> > > ```
> > >
> >
> > Ok, thanks for the notice.
> >
> > Actually, related to this, since we are adding these functions as aliases
> > for existing stable functions, I would like to see these being added not as
> > experimental. The reason for that, is that while they are experimental, we
> > cannot feasibly mark the old function names as deprecated. :-(
> >
> > Adding Thomas and David on CC for their thoughts.
>
> Is it related to telemetry?
>
> In general, yes we cannot deprecate something if there is no stable replacement.
> The recommended step is to introduce a new experimental API
> and deprecate the old one when the new API is stable.
>
Yes, understood.
What we are really trying to do here is to rename an API, by process of
adding the new API and then marking the old one as deprecated. The small
issue is that adding the new one it is by default experimental, meaning we
need to wait for deprecating old one. Ideally, as soon as the new API is
added, we would like to point people to use that, but can't really do so
while it is experimental.
---
By way of explicit detail, Morten pointed out the inconsistency in the
telemetry APIs and types:
* we have add_*_int, which takes a 32-bit signed value
* we have add_*_u64 which takes 64-bit unsigned (as name suggests).
The ideal end-state is to always use 64-bit values (since there is no space
saving from 32-bit as a union is used), and just name everything as "int"
or "uint" for signed/unsigned. The two big steps here are:
* expanding type of the "int" functions to take 64-bit parameters - this is
ABI change but not API one, since existing code will happily promote
values on compile. Therefore, we just use ABI versioning to have a 32-bit
version for older linked binaries.
* the rename of the rte_tel_data_add_array_u64 and
rte_tel_data_add_dict_u64 to *_uint variants. Though keeping
compatibility is easier, as we can just add new functions, the overall
process is slower since the new functions technically should be added as
experimental - hence the email. For the case of function renaming, do we
still need to have the "renamed" versions as experimental initially?
Given where we are in the overall DPDK releases cycle, it's not a major
issue either way, I just would like some clarity. My main concern with
having it spread over a couple of releases, is that it's more likely a step
will be missed/forgotten somewhere along the way!
/Bruce
^ permalink raw reply [relevance 4%]
* [PATCH V6 0/8] telemetry: fix data truncation and conversion error and add hex integer API
` (3 preceding siblings ...)
2022-12-14 12:32 3% ` [PATCH V5 0/8] " Huisong Li
@ 2022-12-15 10:31 3% ` Huisong Li
2022-12-16 1:54 3% ` [PATCH V7 " Huisong Li
2022-12-19 7:06 3% ` [PATCH V8 " Huisong Li
6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-15 10:31 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v6: fix code alignment to keep in line with codes in the file
-v5:
- drop a refactor patch.
- no limit the bit width for xxx_uint_hex API.
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (8):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 52 +++++++++-
lib/telemetry/telemetry_data.c | 72 ++++++++++++++
lib/telemetry/version.map | 9 ++
8 files changed, 308 insertions(+), 30 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
2022-12-14 17:53 0% ` Tyler Retzlaff
@ 2022-12-15 2:39 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2022-12-15 2:39 UTC (permalink / raw)
To: dev
在 2022/12/15 1:53, Tyler Retzlaff 写道:
> On Tue, Dec 13, 2022 at 09:19:45PM +0100, Morten Brørup wrote:
>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>>> Sent: Tuesday, 13 December 2022 19.28
>>>
>>> While the unsigned values added to telemetry dicts/arrays were up to
>>> 64-bits in size, the sized values were only up to 32-bits. We can
>>> standardize the API by having both int and uint functions take 64-bit
>>> values. For ABI compatibility, we use function versioning to ensure
>>> older binaries can still use the older functions taking a 32-bit
>>> parameter.
>>>
>>> Suggested-by: Morten Brørup <mb@smartsharesystems.com>
>>> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>>> ---
>> Excellent example of how to use function versioning for ABI compatibility.
>>
>> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
>>
> minor comments that can be optionally addressed. lgtm
>
> Series-acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> .
LGTM
Series-acked-by: Huisong Li <lihuisong@huawei.com>
But I feel this patchset needs to be applied after the following patchset:
http://patches.dpdk.org/project/dpdk/list/?series=26124
The above patchset fixes some problems about possible data truncation and
conversion error, and will backport to stable branch.
^ permalink raw reply [relevance 0%]
* Re: [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
2022-12-13 20:19 3% ` Morten Brørup
@ 2022-12-14 17:53 0% ` Tyler Retzlaff
2022-12-15 2:39 0% ` lihuisong (C)
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-12-14 17:53 UTC (permalink / raw)
To: Morten Brørup; +Cc: Bruce Richardson, dev
On Tue, Dec 13, 2022 at 09:19:45PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Tuesday, 13 December 2022 19.28
> >
> > While the unsigned values added to telemetry dicts/arrays were up to
> > 64-bits in size, the sized values were only up to 32-bits. We can
> > standardize the API by having both int and uint functions take 64-bit
> > values. For ABI compatibility, we use function versioning to ensure
> > older binaries can still use the older functions taking a 32-bit
> > parameter.
> >
> > Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
>
> Excellent example of how to use function versioning for ABI compatibility.
>
> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
>
minor comments that can be optionally addressed. lgtm
Series-acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
^ permalink raw reply [relevance 0%]
* [PATCH V5 0/8] telemetry: fix data truncation and conversion error and add hex integer API
` (2 preceding siblings ...)
2022-12-13 10:15 3% ` [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API Huisong Li
@ 2022-12-14 12:32 3% ` Huisong Li
2022-12-15 10:31 3% ` [PATCH V6 " Huisong Li
` (2 subsequent siblings)
6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-14 12:32 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v5:
- drop a refactor patch.
- no limit the bit width for xxx_uint_hex API.
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (8):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 150 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 52 +++++++++-
lib/telemetry/telemetry_data.c | 74 ++++++++++++++
lib/telemetry/version.map | 9 ++
8 files changed, 310 insertions(+), 30 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: [PATCH] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 3% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
` (2 preceding siblings ...)
2022-12-13 8:22 0% ` Power, Ciara
@ 2022-12-14 9:32 0% ` Zhang, Fan
2023-01-04 6:18 2% ` [PATCH v2] " Akhil Goyal
4 siblings, 0 replies; 200+ results
From: Zhang, Fan @ 2022-12-14 9:32 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: ciara.power, kai.ji, pablo.de.lara.guarch, hemant.agrawal, matan,
g.singh, ruifeng.wang, anoobj, radu.nicolau, vfialko, ktraynor,
david.marchand, thomas
On 12/12/2022 3:10 PM, Akhil Goyal wrote:
> Symmetric/Asymmetric algorithm strings are accessed by application
> using arrays in cryptodev lib, which hampers new algorithms addition
> in the array due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> app/test-crypto-perf/cperf_options_parsing.c | 6 +-
> app/test/test_cryptodev_asym.c | 2 +-
> app/test/test_cryptodev_security_ipsec.c | 8 +-
> doc/guides/rel_notes/deprecation.rst | 7 +
> drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
> drivers/crypto/qat/qat_sym_session.c | 7 +-
> examples/l2fwd-crypto/main.c | 12 +-
> lib/cryptodev/cryptodev_trace_points.c | 12 ++
> lib/cryptodev/rte_crypto_asym.h | 1 +
> lib/cryptodev/rte_crypto_sym.h | 3 +
> lib/cryptodev/rte_cryptodev.c | 182 ++++++++++++++++++-
> lib/cryptodev/rte_cryptodev.h | 52 ++++++
> lib/cryptodev/rte_cryptodev_trace.h | 32 ++++
> lib/cryptodev/version.map | 10 +
> 14 files changed, 309 insertions(+), 27 deletions(-)
Acked-by: Fan Zhang <fanzhang.oss@gmail.com>
^ permalink raw reply [relevance 0%]
* RE: [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
2022-12-13 18:27 3% ` [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values Bruce Richardson
@ 2022-12-13 20:19 3% ` Morten Brørup
2022-12-14 17:53 0% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-13 20:19 UTC (permalink / raw)
To: Bruce Richardson, dev
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 13 December 2022 19.28
>
> While the unsigned values added to telemetry dicts/arrays were up to
> 64-bits in size, the sized values were only up to 32-bits. We can
> standardize the API by having both int and uint functions take 64-bit
> values. For ABI compatibility, we use function versioning to ensure
> older binaries can still use the older functions taking a 32-bit
> parameter.
>
> Suggested-by: Morten Brørup <mb@smartsharesystems.com>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
Excellent example of how to use function versioning for ABI compatibility.
Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply [relevance 3%]
* [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 6/7] telemetry: make internal int representation 64-bits Bruce Richardson
@ 2022-12-13 18:27 3% ` Bruce Richardson
2022-12-13 20:19 3% ` Morten Brørup
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-13 18:27 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup
While the unsigned values added to telemetry dicts/arrays were up to
64-bits in size, the sized values were only up to 32-bits. We can
standardize the API by having both int and uint functions take 64-bit
values. For ABI compatibility, we use function versioning to ensure
older binaries can still use the older functions taking a 32-bit
parameter.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 4 ++--
lib/telemetry/telemetry_data.c | 33 +++++++++++++++++++++++++++++----
lib/telemetry/telemetry_data.h | 6 ++++++
lib/telemetry/version.map | 7 +++++++
5 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/lib/telemetry/meson.build b/lib/telemetry/meson.build
index f84c9aa3be..73750d9ef4 100644
--- a/lib/telemetry/meson.build
+++ b/lib/telemetry/meson.build
@@ -6,3 +6,4 @@ includes = [global_inc]
sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
headers = files('rte_telemetry.h')
includes += include_directories('../metrics')
+use_function_versioning = true
diff --git a/lib/telemetry/rte_telemetry.h b/lib/telemetry/rte_telemetry.h
index 60877dae0a..baa7b21f6b 100644
--- a/lib/telemetry/rte_telemetry.h
+++ b/lib/telemetry/rte_telemetry.h
@@ -120,7 +120,7 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str);
* 0 on success, negative errno on error
*/
int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x);
+rte_tel_data_add_array_int(struct rte_tel_data *d, int64_t x);
/**
* Add an unsigned value to an array.
@@ -208,7 +208,7 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
* 0 on success, negative errno on error, E2BIG on string truncation of name.
*/
int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val);
+rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int64_t val);
/**
* Add an unsigned value to a dictionary.
diff --git a/lib/telemetry/telemetry_data.c b/lib/telemetry/telemetry_data.c
index 9a180937fd..ac7be795df 100644
--- a/lib/telemetry/telemetry_data.c
+++ b/lib/telemetry/telemetry_data.c
@@ -8,6 +8,7 @@
#undef RTE_USE_LIBBSD
#include <stdbool.h>
+#include <rte_function_versioning.h>
#include <rte_string_fns.h>
#include "telemetry_data.h"
@@ -58,8 +59,8 @@ rte_tel_data_add_array_string(struct rte_tel_data *d, const char *str)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
-int
-rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
+int __vsym
+rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t x)
{
if (d->type != TEL_ARRAY_INT)
return -EINVAL;
@@ -69,6 +70,18 @@ rte_tel_data_add_array_int(struct rte_tel_data *d, int x)
return 0;
}
+int __vsym
+rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int x)
+{
+ return rte_tel_data_add_array_int_v24(d, x);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_array_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_array_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_array_int(struct rte_tel_data *d,
+ int64_t x), rte_tel_data_add_array_int_v24);
+
int
rte_tel_data_add_array_uint(struct rte_tel_data *d, uint64_t x)
{
@@ -146,8 +159,8 @@ rte_tel_data_add_dict_string(struct rte_tel_data *d, const char *name,
return 0;
}
-int
-rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
+int __vsym
+rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val)
{
struct tel_dict_entry *e = &d->data.dict[d->data_len];
if (d->type != TEL_DICT)
@@ -165,6 +178,18 @@ rte_tel_data_add_dict_int(struct rte_tel_data *d, const char *name, int val)
return bytes < RTE_TEL_MAX_STRING_LEN ? 0 : E2BIG;
}
+int __vsym
+rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val)
+{
+ return rte_tel_data_add_dict_int_v24(d, name, val);
+}
+
+/* mark the v23 function as the older version, and v24 as the default version */
+VERSION_SYMBOL(rte_tel_data_add_dict_int, _v23, 23);
+BIND_DEFAULT_SYMBOL(rte_tel_data_add_dict_int, _v24, 24);
+MAP_STATIC_SYMBOL(int rte_tel_data_add_dict_int(struct rte_tel_data *d,
+ const char *name, int64_t val), rte_tel_data_add_dict_int_v24);
+
int
rte_tel_data_add_dict_uint(struct rte_tel_data *d,
const char *name, uint64_t val)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 205509c5a2..53e4cabea5 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -49,4 +49,10 @@ struct rte_tel_data {
} data; /* data container */
};
+/* versioned functions */
+int rte_tel_data_add_array_int_v23(struct rte_tel_data *d, int val);
+int rte_tel_data_add_array_int_v24(struct rte_tel_data *d, int64_t val);
+int rte_tel_data_add_dict_int_v23(struct rte_tel_data *d, const char *name, int val);
+int rte_tel_data_add_dict_int_v24(struct rte_tel_data *d, const char *name, int64_t val);
+
#endif
diff --git a/lib/telemetry/version.map b/lib/telemetry/version.map
index 0f70d82dfc..85df19c4d8 100644
--- a/lib/telemetry/version.map
+++ b/lib/telemetry/version.map
@@ -19,6 +19,13 @@ DPDK_23 {
local: *;
};
+DPDK_24 {
+ global:
+
+ rte_tel_data_add_array_int;
+ rte_tel_data_add_dict_int;
+} DPDK_23;
+
EXPERIMENTAL {
global:
--
2.34.1
^ permalink raw reply [relevance 3%]
* [RFC PATCH 6/7] telemetry: make internal int representation 64-bits
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
@ 2022-12-13 18:27 3% ` Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values Bruce Richardson
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2022-12-13 18:27 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Morten Brørup
The internal storage for int values can be expanded from 32-bit to
64-bit without affecting the external ABI.
Suggested-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/telemetry/telemetry_data.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/telemetry/telemetry_data.h b/lib/telemetry/telemetry_data.h
index 8db6875a81..205509c5a2 100644
--- a/lib/telemetry/telemetry_data.h
+++ b/lib/telemetry/telemetry_data.h
@@ -28,7 +28,7 @@ struct container {
*/
union tel_value {
char sval[RTE_TEL_MAX_STRING_LEN];
- int ival;
+ int64_t ival;
uint64_t uval;
struct container container;
};
--
2.34.1
^ permalink raw reply [relevance 3%]
* [RFC PATCH 0/7] Standardize telemetry int types
@ 2022-12-13 18:27 4% Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 6/7] telemetry: make internal int representation 64-bits Bruce Richardson
` (4 more replies)
0 siblings, 5 replies; 200+ results
From: Bruce Richardson @ 2022-12-13 18:27 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson
Rather than having 64-bit unsigned types and 32-bit signed types
supported by the telemetry lib, we should support 64-bit values
for both types. On the naming side, since both are 64-bit, we
should no longer call the unsigned value u64 - "uint" is better.
This patchset implements these changes as far as is possible while
still keeping API and ABI compatibility.
* Internal structures and functions are updated to use 64-bit ints
* Internal functions are renamed from u64 to uint
* Public enum values are renamed from u64 to uint, and a macro is
added to ensure that older code still compiles
* The public add_*_int functions are changed to take a 64-bit value
rather than a 32-bit one. Since this would be an ABI break, we
use function versioning to ensure older code still calls into
a wrapper function which takes a 32-bit value.
Finally, the patchset also contains a couple of other small cleanups
to the telemetry code that were seen in passing when making these
changes.
Bruce Richardson (7):
telemetry: rename unsigned 64-bit enum value to uint
telemetry: add uint type as alias for u64
telemetry: remove RTE prefix from internal enum values
telemetry: make array initialization more robust
telemetry: update json functions to use int/uint in names
telemetry: make internal int representation 64-bits
telemetry: change public API to use 64-bit signed values
app/test/test_telemetry_data.c | 10 +--
app/test/test_telemetry_json.c | 9 +-
drivers/net/cnxk/cnxk_ethdev_sec_telemetry.c | 4 +-
drivers/net/cnxk/cnxk_ethdev_telemetry.c | 2 +-
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/ethdev/rte_ethdev.c | 2 +-
lib/ethdev/sff_telemetry.c | 2 +-
lib/ipsec/ipsec_telemetry.c | 2 +-
lib/security/rte_security.c | 4 +-
lib/telemetry/meson.build | 1 +
lib/telemetry/rte_telemetry.h | 46 +++++++++-
lib/telemetry/telemetry.c | 56 ++++++------
lib/telemetry/telemetry_data.c | 95 ++++++++++++++------
lib/telemetry/telemetry_data.h | 24 +++--
lib/telemetry/telemetry_json.h | 16 ++--
lib/telemetry/version.map | 14 +++
16 files changed, 192 insertions(+), 97 deletions(-)
--
2.34.1
^ permalink raw reply [relevance 4%]
* Re: [PATCH 2/4] eal: allow applications to report their cpu usage
2022-12-13 15:49 3% ` Robin Jarry
2022-12-13 16:39 0% ` Morten Brørup
@ 2022-12-13 17:45 0% ` Tyler Retzlaff
1 sibling, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-13 17:45 UTC (permalink / raw)
To: Robin Jarry; +Cc: dev, Morten Brørup, Kevin Laatz
On Tue, Dec 13, 2022 at 04:49:31PM +0100, Robin Jarry wrote:
> Robin Jarry, Dec 07, 2022 at 17:21:
> > Allow applications to register a callback that will be invoked in
> > rte_lcore_dump() and when requesting lcore info in the telemetry API.
> >
> > The callback is expected to return the number of TSC cycles that have
> > passed since application start and the number of these cycles that were
> > spent doing busy work.
> >
> > Signed-off-by: Robin Jarry <rjarry@redhat.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> > v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles
>
> As you may have noticed, I forgot to add -v4 for that iteration...
>
> > diff --git a/lib/eal/include/rte_lcore.h b/lib/eal/include/rte_lcore.h
> > index 6938c3fd7b81..df7f0a8e07c6 100644
> > --- a/lib/eal/include/rte_lcore.h
> > +++ b/lib/eal/include/rte_lcore.h
> > @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int lcore_id, void *arg);
> > int
> > rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
> >
> > +/**
> > + * Callback to allow applications to report CPU usage.
> > + *
> > + * @param [in] lcore_id
> > + * The lcore to consider.
> > + * @param [out] busy_cycles
> > + * The amount of busy time since application start, in TSC cycles.
> > + * @param [out] total_cycles
> > + * The total amount of time since application start, in TSC cycles.
> > + * @return
> > + * - 0 if both busy and total were set correctly.
> > + * - a negative value if the information is not available or if any error occurred.
> > + */
> > +typedef int (*rte_lcore_usage_cb)(
> > + unsigned int lcore_id, uint64_t *busy_cycles, uint64_t *total_cycles);
>
> Instead of two uint64_t pointers, I was thinking a better approach would
> be to pass a pointer to a struct containing these two fields. That way
> it leaves room for adding more counters if need be. And do so without
> breaking the ABI.
>
> Thoughts?
yes, please.
^ permalink raw reply [relevance 0%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 12:16 3% ` Bruce Richardson
2022-12-13 11:00 0% ` Morten Brørup
@ 2022-12-13 17:12 3% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Bruce Richardson @ 2022-12-13 17:12 UTC (permalink / raw)
To: Morten Brørup
Cc: Huisong Li, dev, ciara.power, liudongdong3, huangdaode, fengchengwen
On Mon, Dec 12, 2022 at 12:16:07PM +0000, Bruce Richardson wrote:
> On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 12.21
> > >
> > > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Monday, 12 December 2022 11.32
> > > > >
> > > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > > conversion
> > > > > error
> > > > > > or data truncation.
> > > > > >
> > > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > > However,
> > > > > > assigning to u64 is very wasteful, after all, the buffer capacity
> > > of
> > > > > each
> > > > > > transfer is limited. So it is necessary for 'u32' data to add
> > > usigned
> > > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > > >
> > > > > > This patchset uses the new 'u32' API to resolve the problem of
> > > data
> > > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > > >
> > > > > > In addition, this patchset introduces two APIs to store u32 and
> > > u64
> > > > > > values as hexadecimal encoded strings in telemetry library.
> > > > > >
> > > > > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> > > > > break
> > > > > > warning. - introduce two APIs to store u32 and u64 values as
> > > > > hexadecimal
> > > > > > encoded strings.
> > > > > >
> > > > > I'm not convinced about adding the u32 value generically to the
> > > > > telemetry
> > > > > lib - except in the case of having explicit function calls for u32
> > > vs
> > > > > u64
> > > > > hex strings. Having a u32 type doesn't gain us any space internally
> > > > > over a
> > > > > u64 value, since all values are in a union type. Also, for output
> > > as
> > > > > json,
> > > > > the numeric values are all output as decimal values, meaning that
> > > the
> > > > > value
> > > > > 1 appears as the same size in the output string whether it is a u32
> > > or
> > > > > u64
> > > > > type. Now, it may save space in a future binary output format, but
> > > even
> > > > > then it still may not do so.
> > > >
> > > > I agree that a u32 doesn't gain any space internally.
> > > >
> > > > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> > > around as such.
> > > >
> > > > So I suppose the u32 type might be useful for SNMP, if obtained
> > > through the telemetry library.
> > > >
> > > > Alternatively, we could somehow reuse the u64 type and require the
> > > application to pass (value & UINT32_MAX) to the u64 functions. To make
> > > this easy to use, we should add some wrappers to do it for the
> > > application. And eventually we would probably end up with something
> > > very similar to this patch.
> > > >
> > >
> > > I think just using the u64 functions is probably simplest and best
> > > right
> > > now. If we add support for something like snmp then yes, it would make
> > > sense to explicitly add it, but it seems like a lot of extra code for
> > > little or no benefit until we support something like that.
> >
> > <rant>
> > If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> > </rant>
>
> Yes, not making "int" an "i64" type was a poor design decision on my part
> in the earlier versions. Thankfully negative values are rarely needed
> beyond the range of 32-bits, but we should probably look to update this as
> you suggest at the next ABI break window.
>
Actually, most of the work for this can be done without affecting ABI, I
believe, and for the two functions that would be affected, function
versioning could be used to cover those. I think it's better to make the
change now using versioning rather than waiting, as it's likely to be
forgotten if we wait.
I'll work up a patchset for this so we can review and discuss...
/Bruce
^ permalink raw reply [relevance 3%]
* RE: [PATCH 2/4] eal: allow applications to report their cpu usage
2022-12-13 15:49 3% ` Robin Jarry
@ 2022-12-13 16:39 0% ` Morten Brørup
2022-12-13 17:45 0% ` Tyler Retzlaff
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-12-13 16:39 UTC (permalink / raw)
To: Robin Jarry, dev; +Cc: Kevin Laatz, mattias.ronnblom
> From: Robin Jarry [mailto:rjarry@redhat.com]
> Sent: Tuesday, 13 December 2022 16.50
>
> Robin Jarry, Dec 07, 2022 at 17:21:
> > Allow applications to register a callback that will be invoked in
> > rte_lcore_dump() and when requesting lcore info in the telemetry API.
> >
> > The callback is expected to return the number of TSC cycles that have
> > passed since application start and the number of these cycles that
> were
> > spent doing busy work.
> >
> > Signed-off-by: Robin Jarry <rjarry@redhat.com>
> > Acked-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> > v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles
>
> As you may have noticed, I forgot to add -v4 for that iteration...
>
> > diff --git a/lib/eal/include/rte_lcore.h
> b/lib/eal/include/rte_lcore.h
> > index 6938c3fd7b81..df7f0a8e07c6 100644
> > --- a/lib/eal/include/rte_lcore.h
> > +++ b/lib/eal/include/rte_lcore.h
> > @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int
> lcore_id, void *arg);
> > int
> > rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
> >
> > +/**
> > + * Callback to allow applications to report CPU usage.
> > + *
> > + * @param [in] lcore_id
> > + * The lcore to consider.
> > + * @param [out] busy_cycles
> > + * The amount of busy time since application start, in TSC cycles.
> > + * @param [out] total_cycles
> > + * The total amount of time since application start, in TSC
> cycles.
> > + * @return
> > + * - 0 if both busy and total were set correctly.
> > + * - a negative value if the information is not available or if
> any error occurred.
> > + */
> > +typedef int (*rte_lcore_usage_cb)(
> > + unsigned int lcore_id, uint64_t *busy_cycles, uint64_t
> *total_cycles);
>
> Instead of two uint64_t pointers, I was thinking a better approach
> would
> be to pass a pointer to a struct containing these two fields. That way
> it leaves room for adding more counters if need be. And do so without
> breaking the ABI.
>
> Thoughts?
I like the idea.
For compatibility between newer DPDK libraries (with more fields) and older applications, the callback should return an indication of how much of the structure it has filled, so DPDK knows that some fields are unfilled.
The simplest method would be that the callback returns the number of bytes of the structure filled instead of 0 on success. However, that would not allow for holes in the returned structure.
Alternatively, a bitfield can be the first field in the structure, each bit representing a data field in the structure. That would allow flexibility to fill any of up to 64 fields. So with total_cycles and busy_cycles as data fields, the returned structure would contain e.g. {3, 1000, 900}. (As a personal preference, I would put total_cycles before busy_cycles in such a structure.)
And I'm not saying that fields must be uint64_t; they can be any size.
On the other hand, I might be suggesting too much flexibility with the bitfield proposal. Perhaps the simple method suffices. And perhaps only uint64_t fields suffice.
-Morten
^ permalink raw reply [relevance 0%]
* Re: [PATCH 2/4] eal: allow applications to report their cpu usage
@ 2022-12-13 15:49 3% ` Robin Jarry
2022-12-13 16:39 0% ` Morten Brørup
2022-12-13 17:45 0% ` Tyler Retzlaff
0 siblings, 2 replies; 200+ results
From: Robin Jarry @ 2022-12-13 15:49 UTC (permalink / raw)
To: dev; +Cc: Morten Brørup, Kevin Laatz
Robin Jarry, Dec 07, 2022 at 17:21:
> Allow applications to register a callback that will be invoked in
> rte_lcore_dump() and when requesting lcore info in the telemetry API.
>
> The callback is expected to return the number of TSC cycles that have
> passed since application start and the number of these cycles that were
> spent doing busy work.
>
> Signed-off-by: Robin Jarry <rjarry@redhat.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---
> v3 -> v4: Changed nomenclature: CPU cycles -> TSC cycles
As you may have noticed, I forgot to add -v4 for that iteration...
> diff --git a/lib/eal/include/rte_lcore.h b/lib/eal/include/rte_lcore.h
> index 6938c3fd7b81..df7f0a8e07c6 100644
> --- a/lib/eal/include/rte_lcore.h
> +++ b/lib/eal/include/rte_lcore.h
> @@ -328,6 +328,35 @@ typedef int (*rte_lcore_iterate_cb)(unsigned int lcore_id, void *arg);
> int
> rte_lcore_iterate(rte_lcore_iterate_cb cb, void *arg);
>
> +/**
> + * Callback to allow applications to report CPU usage.
> + *
> + * @param [in] lcore_id
> + * The lcore to consider.
> + * @param [out] busy_cycles
> + * The amount of busy time since application start, in TSC cycles.
> + * @param [out] total_cycles
> + * The total amount of time since application start, in TSC cycles.
> + * @return
> + * - 0 if both busy and total were set correctly.
> + * - a negative value if the information is not available or if any error occurred.
> + */
> +typedef int (*rte_lcore_usage_cb)(
> + unsigned int lcore_id, uint64_t *busy_cycles, uint64_t *total_cycles);
Instead of two uint64_t pointers, I was thinking a better approach would
be to pass a pointer to a struct containing these two fields. That way
it leaves room for adding more counters if need be. And do so without
breaking the ABI.
Thoughts?
^ permalink raw reply [relevance 3%]
* [PATCH] ci: drop Travis configuration
@ 2022-12-13 15:07 3% David Marchand
0 siblings, 0 replies; 200+ results
From: David Marchand @ 2022-12-13 15:07 UTC (permalink / raw)
To: dev; +Cc: Honnappa.Nagarahalli, thomas, Aaron Conole, Michael Santana
We stopped using Travis in the main branch and in the public CI in favor
of GHA more than a year ago.
The UNH community lab now covers testing native compilation and unit
tests for ARM platforms.
We decided to stop maintaining the configuration in our repository with
the argument that "if it is not tested, it is broken".
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
.ci/linux-build.sh | 19 ---
.travis.yml | 172 ----------------------------
MAINTAINERS | 1 -
devtools/check-spdx-tag.sh | 2 +-
doc/guides/contributing/patches.rst | 4 -
5 files changed, 1 insertion(+), 197 deletions(-)
delete mode 100644 .travis.yml
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index 5225dc71c4..ab0994388a 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -9,25 +9,6 @@ fi
# Builds are run as root in containers, no need for sudo
[ "$(id -u)" != '0' ] || alias sudo=
-on_error() {
- if [ $? = 0 ]; then
- exit
- fi
- FILES_TO_PRINT="build/meson-logs/testlog.txt"
- FILES_TO_PRINT="$FILES_TO_PRINT build/.ninja_log"
- FILES_TO_PRINT="$FILES_TO_PRINT build/meson-logs/meson-log.txt"
- FILES_TO_PRINT="$FILES_TO_PRINT build/gdb.log"
-
- for pr_file in $FILES_TO_PRINT; do
- if [ -e "$pr_file" ]; then
- cat "$pr_file"
- fi
- done
-}
-# We capture the error logs as artifacts in Github Actions, no need to dump
-# them via a EXIT handler.
-[ -n "$GITHUB_WORKFLOW" ] || trap on_error EXIT
-
install_libabigail() {
version=$1
instdir=$2
diff --git a/.travis.yml b/.travis.yml
deleted file mode 100644
index 0936788dc7..0000000000
--- a/.travis.yml
+++ /dev/null
@@ -1,172 +0,0 @@
-# default values for all jobs
-language: c
-cache:
- ccache: true
- directories:
- - libabigail
- - reference
-
-dist: bionic
-
-os: linux
-
-addons:
- apt:
- update: true
- packages: &required_packages
- - [libnuma-dev, python3-setuptools, python3-wheel, python3-pip, python3-pyelftools, ninja-build]
- - [libbsd-dev, libpcap-dev, libibverbs-dev, libcrypto++-dev, libfdt-dev, libjansson-dev]
- - [libarchive-dev]
-
-_aarch64_packages: &aarch64_packages
- - *required_packages
- - [gcc-aarch64-linux-gnu, libc6-dev-arm64-cross, pkg-config-aarch64-linux-gnu]
-
-_aarch64_clang_packages: &aarch64_clang_packages
- - *required_packages
- - [libgcc-7-dev-arm64-cross, libatomic1-arm64-cross, libc6-dev-arm64-cross, pkg-config-aarch64-linux-gnu]
-
-_libabigail_build_packages: &libabigail_build_packages
- - [autoconf, automake, libtool, pkg-config, libxml2-dev, libdw-dev]
-
-_build_32b_packages: &build_32b_packages
- - *required_packages
- - [gcc-multilib]
-
-_doc_packages: &doc_packages
- - [doxygen, graphviz, python3-sphinx]
-
-before_install: ./.ci/${TRAVIS_OS_NAME}-setup.sh
-script: ./.ci/${TRAVIS_OS_NAME}-build.sh
-
-env:
- global:
- - LIBABIGAIL_VERSION=libabigail-2.1
- - REF_GIT_REPO=https://dpdk.org/git/dpdk-stable
- - REF_GIT_TAG=v22.11.1
-
-jobs:
- include:
- # x86_64 gcc jobs
- - env: DEF_LIB="static"
- arch: amd64
- compiler: gcc
- - env: DEF_LIB="shared" RUN_TESTS=true
- arch: amd64
- compiler: gcc
- - env: DEF_LIB="shared" BUILD_DOCS=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *required_packages
- - *doc_packages
- - env: DEF_LIB="shared" ABI_CHECKS=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *required_packages
- - *libabigail_build_packages
- # x86_64 clang jobs
- - env: DEF_LIB="static"
- arch: amd64
- compiler: clang
- - env: DEF_LIB="shared" RUN_TESTS=true
- arch: amd64
- compiler: clang
- - env: DEF_LIB="shared" BUILD_DOCS=true
- arch: amd64
- compiler: clang
- addons:
- apt:
- packages:
- - *required_packages
- - *doc_packages
- # x86_64 cross-compiling 32-bits jobs
- - env: DEF_LIB="static" BUILD_32BIT=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *build_32b_packages
- # x86_64 cross-compiling aarch64 jobs
- - env: DEF_LIB="static" AARCH64=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *aarch64_packages
- - env: DEF_LIB="shared" AARCH64=true
- arch: amd64
- compiler: gcc
- addons:
- apt:
- packages:
- - *aarch64_packages
- - env: DEF_LIB="static" AARCH64=true
- arch: amd64
- compiler: clang
- addons:
- apt:
- packages:
- - *aarch64_clang_packages
- - env: DEF_LIB="shared" AARCH64=true
- arch: amd64
- compiler: clang
- addons:
- apt:
- packages:
- - *aarch64_clang_packages
- # aarch64 gcc jobs
- - env: DEF_LIB="static"
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: gcc
- - env: DEF_LIB="shared" RUN_TESTS=true
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: gcc
- - env: DEF_LIB="shared" BUILD_DOCS=true
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: gcc
- addons:
- apt:
- packages:
- - *required_packages
- - *doc_packages
- - env: DEF_LIB="shared" ABI_CHECKS=true
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: gcc
- addons:
- apt:
- packages:
- - *required_packages
- - *libabigail_build_packages
- # aarch64 clang jobs
- - env: DEF_LIB="static"
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: clang
- - env: DEF_LIB="shared" RUN_TESTS=true
- dist: focal
- arch: arm64-graviton2
- virt: vm
- group: edge
- compiler: clang
diff --git a/MAINTAINERS b/MAINTAINERS
index 3dc3f5b348..9a0f416d2e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -131,7 +131,6 @@ F: devtools/check-meson.py
Public CI
M: Aaron Conole <aconole@redhat.com>
M: Michael Santana <maicolgabriel@hotmail.com>
-F: .travis.yml
F: .github/workflows/build.yml
F: .ci/
diff --git a/devtools/check-spdx-tag.sh b/devtools/check-spdx-tag.sh
index 89b2d643a4..7624778a8c 100755
--- a/devtools/check-spdx-tag.sh
+++ b/devtools/check-spdx-tag.sh
@@ -20,7 +20,7 @@ check_spdx() {
echo "--------------------------"
fi
git grep -L SPDX-License-Identifier -- \
- ':^.git*' ':^.mailmap' ':^.ci/*' ':^.travis.yml' \
+ ':^.git*' ':^.mailmap' ':^.ci/*' \
':^README' ':^MAINTAINERS' ':^VERSION' ':^ABI_VERSION' \
':^*/Kbuild' ':^*/README' \
':^license/' ':^config/' ':^buildtools/' ':^*/poetry.lock' \
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index b3eaf7df03..e286d9e6d5 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -35,10 +35,6 @@ It is also worth registering for the DPDK `Patchwork <https://patches.dpdk.org/p
If you are using the GitHub service, pushing to a branch will trigger GitHub
Actions to automatically build your changes and run unit tests and ABI checks.
-Additionally, a Travis configuration is available in DPDK but Travis free usage
-is limited to a few builds.
-You can link your repository to the ``travis-ci.com`` build service.
-
The development process requires some familiarity with the ``git`` version control system.
Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information.
--
2.38.1
^ permalink raw reply [relevance 3%]
* Re: 21.11.3 patches review and test
2022-12-06 11:29 1% 21.11.3 patches review and test Kevin Traynor
@ 2022-12-13 11:48 0% ` Christian Ehrhardt
2022-12-16 7:55 0% ` YangHang Liu
1 sibling, 0 replies; 200+ results
From: Christian Ehrhardt @ 2022-12-13 11:48 UTC (permalink / raw)
To: Kevin Traynor
Cc: stable, dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
David Christensen, Hemant Agrawal, Ian Stokes, Jerin Jacob,
John McNamara, Ju-Hyoung Lee, Luca Boccassi, Pei Zhang,
qian.q.xu, Raslan Darawsheh, Thomas Monjalon, yanghliu,
yuan.peng, zhaoyan.chen
On Tue, Dec 6, 2022 at 12:30 PM Kevin Traynor <ktraynor@redhat.com> wrote:
>
> Hi all,
>
> Here is a list of patches targeted for stable release 21.11.3.
>
> The planned date for the final release is 19th December.
>
> Please help with testing and validation of your use cases and report
> any issues/results with reply-all to this mail. For the final release
> the fixes and reported validations will be added to the release notes.
>
> A release candidate tarball can be found at:
>
> https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.3-rc1
>
> These patches are located at branch 21.11 of dpdk-stable repo:
> https://dpdk.org/browse/dpdk-stable/
Hi Kevin,
testing 22.11.3 builds and a bunch of workloads and stressing things
under Ubuntu 22.04.
TL;DR: for what I ran all LGTM, no regressions found (but I only have
a small subset of HW and use cases, I hope others will reply as well
later this week).
V: 21.11.3~rc1-0ubuntu0.22.04.1~jammyppa1
1.0.0 (08:19:13): phys (BM) tests
1.1.0 (08:19:13): initialize environment
1.1.1 (08:21:02): testpmd => Pass
1.1.2 (08:23:07): check testpmd output => Pass
2.0.0 (08:23:07): prep virtual test environment
1.0.0 (08:25:37): virt tests
1.1.0 (08:25:37): initialize environment
3.0.0 (08:27:02): performance tests
3.1.0 (08:27:02): prep benchmarks
3.2.0 (08:27:24): performance tests
3.2.1 (08:27:32): test guest-openvswitch for OVS-5CPU => Pass
3.2.2 (08:46:45): test guest-dpdk-vhost-user-client-multiq for
OVSDPDK-VUC => Pass
4.0.0 (09:06:10): VUC endurance checks
4.1.0 (09:06:10): prep VUC endurance tests
4.1.1 (09:18:48): start stop guests (client) => Pass
4.1.2 (10:31:22): add/remove ports (client) => Pass
4.2.0 (10:40:52): Final cleanup
> Thanks.
>
> Kevin
>
> ---
> Abdullah Sevincer (1):
> event/dlb2: handle enqueuing more than maximum depth
>
> Abhimanyu Saini (1):
> common/sfc_efx/base: remove VQ index check during VQ start
>
> Aleksandr Miloshenko (1):
> net/iavf: fix Tx done descriptors cleanup
>
> Alex Kiselev (1):
> net/tap: fix overflow of network interface index
>
> Alexander Chernavin (1):
> net/virtio: fix crash when configured twice
>
> Alexander Kozyrev (3):
> net/mlx5: fix shared Rx queue config reuse
> net/mlx5: fix first segment inline length
> net/mlx5: fix indexed pool local cache crash
>
> Ali Alnubani (1):
> examples/l2fwd-crypto: fix typo in error message
>
> Amit Prakash Shukla (6):
> net/mvneta: fix build with GCC 12
> test/ipsec: fix build with GCC 12
> ipsec: fix build with GCC 12
> crypto/qat: fix build with GCC 12
> net/i40e: fix build with MinGW GCC 12
> net/qede/base: fix 32-bit build with GCC 12
>
> Andrew Boyer (5):
> net/ionic: fix endianness for Rx and Tx
> net/ionic: fix endianness for RSS
> net/ionic: fix adapter name for logging
> net/ionic: fix Rx filter save
> net/ionic: fix reported error stats
>
> Anoob Joseph (1):
> test/crypto: fix PDCP vectors
>
> Apeksha Gupta (2):
> net/enetfec: fix restart
> net/enetfec: fix buffer leak
>
> Arek Kusztal (1):
> common/qat: fix VF to PF answer
>
> Ashwin Sekhar T K (1):
> mempool/cnxk: fix destroying empty pool
>
> Ben Magistro (1):
> doc: fix dumpcap interface parameter option
>
> Benjamin Le Berre (1):
> net/bnxt: fix error code during MTU change
>
> Bhagyada Modali (9):
> net/axgbe: fix scattered Rx
> net/axgbe: fix mbuf lengths in scattered Rx
> net/axgbe: fix length of each segment in scattered Rx
> net/axgbe: fix checksum and RSS in scattered Rx
> net/axgbe: optimise scattered Rx
> net/axgbe: remove freeing buffer in scattered Rx
> net/axgbe: reset end of packet in scattered Rx
> net/axgbe: clear buffer on scattered Rx chaining failure
> net/axgbe: save segment data in scattered Rx
>
> Bing Zhao (2):
> net/mlx5: fix build with recent compilers
> bus/auxiliary: prevent device from being probed again
>
> Brian Dooley (1):
> crypto/qat: fix null hash algorithm digest size
>
> Changpeng Liu (1):
> vhost: add non-blocking API for posting interrupt
>
> Chaoyong He (1):
> net/nfp: fix Rx descriptor DMA address
>
> Chengwen Feng (8):
> net/hns3: fix crash in SVE Tx
> net/hns3: fix next-to-use overflow in SVE Tx
> net/hns3: fix next-to-use overflow in simple Tx
> net/hns3: fix crash when secondary process access FW
> net/hns3: revert Tx performance optimization
> net/hns3: revert fix mailbox communication with HW
> net/hns3: fix VF mailbox message handling
> app/testpmd: remove jumbo offload
>
> Ciara Power (1):
> test/crypto: fix wireless auth digest segment
>
> Conor Walsh (1):
> doc: fix reference to dma application example
>
> Dariusz Sosnowski (1):
> net/mlx5: fix hairpin split with set VLAN VID action
>
> David Marchand (23):
> vhost: fix virtqueue use after free on NUMA reallocation
> app/testpmd: restore ixgbe bypass commands
> net/failsafe: fix interrupt handle leak
> net/bnxt: fix build with GCC 13
> trace: fix mode for new trace point
> trace: fix mode change
> trace: fix leak with regexp
> trace: fix dynamically enabling trace points
> trace: fix race in debug dump
> ci: bump versions of actions in GHA
> ci: update to new API for step outputs in GHA
> service: fix build with clang 15
> vhost: fix build with clang 15
> bus/dpaa: fix build with clang 15
> net/atlantic: fix build with clang 15
> net/dpaa2: fix build with clang 15
> app/testpmd: fix build with clang 15
> app/testpmd: fix build with clang 15 in flow code
> test/efd: fix build with clang 15
> test/member: fix build with clang 15
> test/event: fix build with clang 15
> ci: enable ABI check in GHA
> trace: fix metadata dump
>
> Dmitry Kozlyuk (4):
> build: enable developer mode for all working trees
> eal: fix side effect in some pointer arithmetic macros
> mempool: make event callbacks process-private
> common/mlx5: fix multi-process mempool registration
>
> Dong Zhou (1):
> net/mlx5: fix thread workspace memory leak
>
> Dongdong Liu (2):
> doc: fix application name in procinfo guide
> doc: document device dump in procinfo guide
>
> Erik Gabriel Carrillo (1):
> service: fix early move to inactive status
>
> Fidaullah Noonari (1):
> malloc: fix storage size for some allocations
>
> Frank Du (1):
> net/ice: fix interrupt handler unregister
>
> Gagandeep Singh (5):
> net/dpaa: fix buffer freeing in slow path
> net/dpaa: use internal mempool for SG table
> net/dpaa: fix buffer freeing on SG Tx
> net/dpaa2: use internal mempool for SG table
> net/dpaa2: fix buffer freeing on SG Tx
>
> Ganapati Kundapura (1):
> eventdev/crypto: fix multi-process
>
> Gregory Etelson (6):
> net/mlx5: fix RSS expansion buffer size
> app/testpmd: fix MAC header in checksum forward engine
> common/mlx5: fix shared mempool subscription
> net/mlx5: fix port initialization with small LRO
> net/mlx5: fix maximum LRO message size
> doc: add LRO size limitation in mlx5 guide
>
> Haiyue Wang (1):
> ring: fix description
>
> Hamza Khan (1):
> examples/vm_power_manager: use safe list iterator
>
> Hanumanth Pothula (1):
> net/cnxk: fix DF bit in vector mode
>
> Hernan Vargas (14):
> baseband/acc100: fix memory leak
> baseband/acc100: check turbo dec/enc input
> baseband/acc100: add null checks
> baseband/acc100: fix input length for CRC24B
> baseband/acc100: fix clearing PF IR outside handler
> baseband/acc100: fix device minimum alignment
> baseband/acc100: fix close cleanup
> baseband/acc100: add LDPC encoder padding function
> baseband/acc100: check AQ availability
> baseband/acc100: fix ring availability calculation
> baseband/acc100: enforce additional check on FCW
> baseband/acc100: fix null HARQ input case
> baseband/acc100: fix ring/queue allocation
> baseband/acc100: fix double MSI intr in TB mode
>
> Huisong Li (18):
> net/hns3: fix Rx with PTP
> net/hns3: delete unused markup
> net/hns3: fix clearing hardware MAC statistics
> net/hns3: fix RSS filter restore
> net/hns3: fix RSS flow rule restore
> net/hns3: move flow direction rule recovery
> net/hns3: fix packet type for GENEVE
> net/hns3: fix IPv4 and IPv6 RSS
> net/hns3: fix typos in IPv6 SCTP fields
> net/hns3: fix IPv4 RSS
> net/hns3: add L3 and L4 RSS types
> net/bonding: fix slave device Rx/Tx offload configuration
> net/bonding: fix dropping valid MAC packets
> net/bonding: fix mbuf fast free handling
> net/hns3: extract functions to create RSS and FDIR flow rule
> net/hns3: fix RSS rule restore
> net/hns3: fix lock protection of RSS flow rule
> net/hns3: fix restore filter function input
>
> Huzaifa Rahman (1):
> net/memif: fix crash with different number of Rx/Tx queues
>
> Ilya Maximets (1):
> doc: fix support table for Ethernet/VLAN flow items
>
> Ivan Malov (3):
> common/sfc_efx/base: fix maximum Tx data count
> net/bonding: fix descriptor limit reporting
> net/bonding: fix flow flush order on close
>
> James Hershaw (1):
> net/nfp: improve HW info header log readability
>
> Jeremy Spewock (1):
> test/ipsec: skip if no compatible device
>
> Jerin Jacob (2):
> eal: fix doxygen comments for UUID
> power: fix some doxygen comments
>
> Jiawei Wang (4):
> net/mlx5: fix modify action with tunnel decapsulation
> net/mlx5: fix tunnel header with IPIP offload
> net/mlx5: fix source port checking in sample flow rule
> net/mlx5: fix mirror flow validation with ASO action
>
> Jiawen Wu (6):
> net/txgbe: fix IPv6 flow rule
> net/txgbe: remove semaphore between SW/FW
> net/txgbe: rename some extended statistics
> net/ngbe: rename some extended statistics
> net/ngbe: remove semaphore between SW/FW
> net/ngbe: fix maximum frame size
>
> Jie Hai (1):
> net/hns3: fix minimum Tx frame length
>
> Jie Wang (1):
> net/i40e: fix jumbo frame Rx with X722
>
> Jun Qiu (3):
> gro: trim tail padding bytes
> net/bonding: fix Tx hash for TCP
> hash: fix RCU configuration memory leak
>
> Kai Ji (1):
> test/crypto: fix bitwise operator in a SNOW3G case
>
> Kalesh AP (2):
> net/bnxt: remove unnecessary check
> net/bnxt: fix representor info freeing
>
> Ke Zhang (2):
> net/i40e: fix VF representor release
> net/iavf: fix L3 checksum Tx offload flag
>
> Kevin Liu (2):
> net/iavf: check illegal packet sizes
> net/ice: check illegal packet sizes
>
> Kevin Traynor (1):
> Revert "cryptodev: fix missing SHA3 algorithm strings"
>
> Kumara Parameshwaran (1):
> gro: check payload length after trim
>
> Long Li (2):
> net/mlx4: fix Verbs FD leak in secondary process
> net/mlx5: fix Verbs FD leak in secondary process
>
> Long Wu (1):
> net/nfp: fix memory leak in Rx
>
> Luca Boccassi (1):
> drivers: fix typos found by Lintian
>
> Mao YingMing (1):
> net/bnxt: fix null pointer dereference in LED config
>
> Mattias Rönnblom (3):
> net: accept unaligned data in checksum routines
> event/dsw: fix flow migration
> doc: fix event timer adapter guide
>
> Maxime Coquelin (1):
> vhost: fix build with GCC 12
>
> Megha Ajmera (2):
> sched: fix subport profile configuration
> examples/qos_sched: fix number of subport profiles
>
> Michael Baum (5):
> net/mlx5: fix null check in devargs parsing
> doc: fix underlines in testpmd guide
> doc: fix colons in testpmd aged flow rules
> net/mlx5: fix race condition in counter pool resizing
> net/mlx5: fix port event cleaning order
>
> Mingjin Ye (4):
> net/ice: support VXLAN-GPE tunnel offload
> net/i40e: fix pctype configuration for X722
> net/ice: fix scalar Rx path segment
> net/ice: fix scalar Tx path segment
>
> Mário Kuka (1):
> pcapng: fix write more packets than IOV_MAX limit
>
> Naga Harish K S V (4):
> eventdev/eth_tx: add spinlock for adapter start/stop
> eventdev/eth_tx: fix adapter stop
> timer: fix stopping all timers
> eventdev/eth_tx: fix queue delete
>
> Nithin Dabilpuram (3):
> examples/ipsec-secgw: use Tx checksum offload conditionally
> examples/l3fwd: fix MTU configuration with event mode
> net/cnxk: fix later skip to include mbuf private data
>
> Olivier Matz (7):
> cryptodev: fix unduly newlines in logs
> mem: fix API doc about allocation on secondary processes
> event/sw: fix flow ID init in self test
> event/sw: fix log in self test
> net/ixgbe: fix broadcast Rx on VF after promisc removal
> net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
> net/ixgbevf: fix promiscuous and allmulti
>
> Pablo de Lara (1):
> examples/fips_validation: fix typo in error log
>
> Pavan Nikhilesh (3):
> event/cnxk: fix missing xstats operations
> event/cnxk: fix mbuf offset calculation
> event/cnxk: fix missing mempool cookie marking
>
> Peng Zhang (3):
> net/nfp: compose firmware file name with new hwinfo
> buildtools: fix NUMA nodes count
> net/nfp: fix internal buffer size and MTU check
>
> Qi Zhang (12):
> net/ice/base: fix division during E822 PTP init
> net/ice/base: fix 100M speed capability
> net/ice/base: fix DSCP PFC TLV creation
> net/ice/base: fix media type of PHY 10G SFI C2C
> net/ice/base: fix function descriptions for parser
> net/ice/base: fix endian format
> net/ice/base: fix array overflow in add switch recipe
> net/ice/base: fix bit finding range over ptype bitmap
> net/ice/base: fix add MAC rule
> net/ice/base: fix double VLAN in promiscuous mode
> net/ice/base: ignore promiscuous already exist
> net/ice/base: fix input set of GTPoGRE
>
> Qiming Yang (1):
> app/testpmd: skip port reset in secondary process
>
> Radu Nicolau (5):
> net/iavf: update IPsec ESN values when updating session
> net/iavf: fix IPsec flow create error check
> net/iavf: fix SPI check
> net/iavf: fix queue stop for large VF
> examples/ipsec-secgw: fix Tx checksum offload flag
>
> Raja Zidane (1):
> net/mlx5: fix Tx check for hardware descriptor length
>
> Rohit Raj (1):
> net/dpaa: fix jumbo packet Rx in case of VSP
>
> Satha Rao (1):
> common/cnxk: fix schedule weight update
>
> Satheesh Paul (3):
> common/cnxk: fix log level during MCAM allocation
> common/cnxk: fix missing flow counter reset
> common/cnxk: fix printing disabled MKEX registers
>
> Shiqi Liu (2):
> node: check Rx element allocation
> dma/idxd: check DSA device allocation
>
> Shun Hao (4):
> net/mlx5: fix meter profile delete after disable
> net/mlx5: fix action flag data type
> net/mlx5: fix drop action validation
> net/mlx5: fix assert when creating meter policy
>
> Stephen Coleman (1):
> doc: fix typo depreciated instead of deprecated
>
> Stephen Hemminger (8):
> event/sw: fix device name in dump
> eal: fix data race in multi-process support
> pdump: do not allow enable/disable in primary process
> app/dumpcap: fix crash on cleanup
> app/dumpcap: fix pathname for output file
> app/testpmd: make quit flag volatile
> ring: remove leftover comment about watermark
> doc: avoid meson deprecation in setup
>
> Steve Yang (1):
> net/iavf: fix pattern check for flow director parser
>
> Steven Zou (1):
> common/iavf: avoid copy in async mode
>
> Sunyang Wu (1):
> test/crypto: fix debug messages
>
> Taekyung Kim (1):
> vdpa/ifc: handle data path update failure
>
> Tal Shnaiderman (1):
> net/mlx5: fix thread termination check on Windows
>
> Thomas Monjalon (2):
> drivers: remove unused build variable
> doc: add Rx buffer split capability for mlx5
>
> Ting Xu (1):
> net/ice/base: fix inner symmetric RSS hash in raw flow
>
> Tomasz Jonak (1):
> net/ice: fix null function pointer call
>
> Vanshika Shukla (1):
> net/dpaa2: fix DPDMUX error behaviour
>
> Viacheslav Ovsiienko (3):
> net/mlx5: fix check for orphan wait descriptor
> net/mlx5: fix single not inline packet storing
> net/mlx5: fix inline length exceeding descriptor limit
>
> Vladimir Medvedkin (2):
> test/hash: remove dead code in extendable bucket test
> test/hash: fix bulk lookup check
>
> Volodymyr Fialko (3):
> cryptodev: fix missing SHA3 algorithm strings
> eventdev: fix name of Rx conf type in documentation
> app/eventdev: fix limits in error message
>
> Wenwu Ma (1):
> examples/vhost: fix use after free
>
> Wenzhuo Lu (1):
> net/iavf: fix VLAN offload
>
> Yi Li (1):
> doc: fix maximum packet size of virtio driver
>
> Yiding Zhou (4):
> net/iavf: fix VLAN insertion
> net/iavf: revert VLAN insertion fix
> net/ice/base: fix duplicate flow rules
> net/iavf: add thread for event callbacks
>
> Yunjian Wang (2):
> net/bonding: fix array overflow in Rx burst
> net/bonding: fix double slave link status query
>
> Zhichao Zeng (3):
> net/ice: fix RSS hash update
> net/iavf: fix processing VLAN TCI in SSE path
> net/iavf: fix outer checksum flags
>
> Zhirun Yan (1):
> graph: fix node objects allocation
>
--
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd
^ permalink raw reply [relevance 0%]
* RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 12:16 3% ` Bruce Richardson
@ 2022-12-13 11:00 0% ` Morten Brørup
2022-12-13 17:12 3% ` Bruce Richardson
1 sibling, 0 replies; 200+ results
From: Morten Brørup @ 2022-12-13 11:00 UTC (permalink / raw)
To: Bruce Richardson, Huisong Li
Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen
Med venlig hilsen / Kind regards,
-Morten Brørup
> -----Original Message-----
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 13.16
> To: Morten Brørup
> Cc: Huisong Li; dev@dpdk.org; ciara.power@intel.com;
> liudongdong3@huawei.com; huangdaode@huawei.com; fengchengwen@huawei.com
> Subject: Re: [PATCH V3 00/11] telemetry: add u32 value type and hex
> integer string API
>
> On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 12.21
> > >
> > > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > > Sent: Monday, 12 December 2022 11.32
> > > > >
> > > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by
> the
> > > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > > conversion
> > > > > error
> > > > > > or data truncation.
> > > > > >
> > > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > > However,
> > > > > > assigning to u64 is very wasteful, after all, the buffer
> capacity
> > > of
> > > > > each
> > > > > > transfer is limited. So it is necessary for 'u32' data to add
> > > usigned
> > > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > > >
> > > > > > This patchset uses the new 'u32' API to resolve the problem
> of
> > > data
> > > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > > >
> > > > > > In addition, this patchset introduces two APIs to store u32
> and
> > > u64
> > > > > > values as hexadecimal encoded strings in telemetry library.
> > > > > >
> > > > > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix
> ABI
> > > > > break
> > > > > > warning. - introduce two APIs to store u32 and u64 values as
> > > > > hexadecimal
> > > > > > encoded strings.
> > > > > >
> > > > > I'm not convinced about adding the u32 value generically to the
> > > > > telemetry
> > > > > lib - except in the case of having explicit function calls for
> u32
> > > vs
> > > > > u64
> > > > > hex strings. Having a u32 type doesn't gain us any space
> internally
> > > > > over a
> > > > > u64 value, since all values are in a union type. Also, for
> output
> > > as
> > > > > json,
> > > > > the numeric values are all output as decimal values, meaning
> that
> > > the
> > > > > value
> > > > > 1 appears as the same size in the output string whether it is a
> u32
> > > or
> > > > > u64
> > > > > type. Now, it may save space in a future binary output format,
> but
> > > even
> > > > > then it still may not do so.
> > > >
> > > > I agree that a u32 doesn't gain any space internally.
> > > >
> > > > However, many SNMP counters are unsigned 32 bit, and expected to
> wrap
> > > around as such.
> > > >
> > > > So I suppose the u32 type might be useful for SNMP, if obtained
> > > through the telemetry library.
> > > >
> > > > Alternatively, we could somehow reuse the u64 type and require
> the
> > > application to pass (value & UINT32_MAX) to the u64 functions. To
> make
> > > this easy to use, we should add some wrappers to do it for the
> > > application. And eventually we would probably end up with something
> > > very similar to this patch.
> > > >
> > >
> > > I think just using the u64 functions is probably simplest and best
> > > right
> > > now. If we add support for something like snmp then yes, it would
> make
> > > sense to explicitly add it, but it seems like a lot of extra code
> for
> > > little or no benefit until we support something like that.
> >
> > <rant>
> > If we wanted to fix this generally, we should rely on type promotion,
> so the existing _int function should be updated to take an int64_t
> value, and the _u64 function should be renamed to _uint (and still take
> an uint64_t value). However, that would break the ABI, and would need
> to go through some process for that. So let's not change this now.
> > </rant>
>
> Yes, not making "int" an "i64" type was a poor design decision on my
> part
> in the earlier versions. Thankfully negative values are rarely needed
> beyond the range of 32-bits, but we should probably look to update this
> as
> you suggest at the next ABI break window.
>
> >
> > I tend to agree with Bruce on this: Let's get rid of the new u32
> functions, and rely on the u64 functions for that instead.
> >
> > >
> > > > >
> > > > > Therefore, I'd tend to keep the existing u64 type as-is, and
> > > instead
> > > > > only
> > > > > add the functions for outputting hex values. Those hex output
> > > functions
> > > > > could take an additional parameter indicating the desired hex
> > > output
> > > > > length, as there could well be cases where we want just 16-bit
> hex
> > > > > value
> > > > > too.
> > > >
> > > > The way I read the patch series, the hex output length is not
> fixed,
> > > but an u64 value of 5 will be output as 0x5, not
> 0x0000000000000005.
> > > >
> > > > So the only benefit of having both u32_hex and u64_hex functions
> is
> > > to avoid type promotion from uint32_t to uint64_t on input for 32
> bit
> > > values.
> > > >
> > > > Instead of passing a 3rd parameter or adding u16_hex functions,
> we
> > > could consider just having one set of hex functions using uint64_t
> for
> > > the value, and rely on type promotion for 32 and 16 bit values.
> > > >
> > >
> > > +1 to having only a single hex function, and I think type promotion
> > > should
> > > work fine.
> > >
> > > However, I still think it might be worthwhile allowing the user to
> pass
> > > in
> > > a min output length parameter too. I find for many hex strings
> having
> > > the
> > > leading zeros to explicitly show the length can be useful. The
> value
> > > "0"
> > > could cover the current behaviour of no-padding, otherwise the
> > > parameter
> > > should indicate the number of bits to be displayed. (If we want to
> lock
> > > it
> > > down we can use an enum parameter rather than int to limit it to 0,
> 8,
> > > 16,
> > > 32 or 64 bit displayed values).
> >
> > An extra parameter for minimum output length (in number of input
> bits) would be very nice, and makes avoids a set of functions for each
> bit width.
> >
> > (I don't think it should be lock it down to some special bit lengths;
> there is no need to prevent 24 bit or other exotic bit widths.)
> >
> > Something like this:
> >
> > char str[64]; // Big enough length.
> > if (bits != 0) {
> > char format[16]; // Big enough length.
> > sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
> > sprintf(str, format, value);
> > } else {
> > sprintf(str, "0x%" PRIx64, value);
> > }
> >
>
> LGTM.
From a higher level perspective, I'm wondering why passing an uint32_t as x to rte_tel_data_add_{dict|array}_int(struct rte_tel_data *d, int x) doesn't produce a compiler warning about risky type conversion. And similarly passing a signed value to the _u64 functions.
Wouldn't it make sense to wrap these functions in a macro, so -Wconversion could be enabled when they are used? (I guess -Wconversion is default disabled when building DPDK.)
-Morten
^ permalink raw reply [relevance 0%]
* [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
2022-12-12 6:42 3% ` [PATCH V3 " Huisong Li
@ 2022-12-13 10:15 3% ` Huisong Li
2022-12-14 12:32 3% ` [PATCH V5 0/8] " Huisong Li
` (3 subsequent siblings)
6 siblings, 0 replies; 200+ results
From: Huisong Li @ 2022-12-13 10:15 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, andrew.rybchenko, huangdaode, liudongdong3,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation. This patch series uses 'u64' functions to
do this.
In addition, this patch series introduces two APIs to store unsigned
integer values as hexadecimal encoded strings in telemetry library.
---
-v4:
- remove 'u32' value type.
- add padding zero for hexadecimal value
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (9):
telemetry: move to header to controllable range
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: refactor mapping between value and array type
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer value API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 158 +++++++++++++++++++++++++++++
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 10 +-
lib/ethdev/rte_ethdev.c | 19 ++--
lib/mempool/rte_mempool.c | 24 ++---
lib/telemetry/rte_telemetry.h | 55 +++++++++-
lib/telemetry/telemetry_data.c | 86 ++++++++++++++--
lib/telemetry/version.map | 9 ++
8 files changed, 327 insertions(+), 36 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* RE: [PATCH] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 3% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
2022-12-13 7:31 0% ` Ruifeng Wang
2022-12-13 7:37 0% ` Anoob Joseph
@ 2022-12-13 8:22 0% ` Power, Ciara
2022-12-14 9:32 0% ` Zhang, Fan
2023-01-04 6:18 2% ` [PATCH v2] " Akhil Goyal
4 siblings, 0 replies; 200+ results
From: Power, Ciara @ 2022-12-13 8:22 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: fanzhang.oss, Ji, Kai, De Lara Guarch, Pablo, hemant.agrawal,
matan, g.singh, ruifeng.wang, anoobj, Nicolau, Radu, vfialko,
ktraynor, david.marchand, thomas
Hi Akhil,
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday 12 December 2022 15:10
> To: dev@dpdk.org
> Cc: Power, Ciara <ciara.power@intel.com>; fanzhang.oss@gmail.com; Ji, Kai
> <kai.ji@intel.com>; De Lara Guarch, Pablo
> <pablo.de.lara.guarch@intel.com>; hemant.agrawal@nxp.com;
> matan@nvidia.com; g.singh@nxp.com; ruifeng.wang@arm.com;
> anoobj@marvell.com; Nicolau, Radu <radu.nicolau@intel.com>;
> vfialko@marvell.com; ktraynor@redhat.com; david.marchand@redhat.com;
> thomas@monjalon.net; Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH] cryptodev: add algo enums to string conversion APIs
>
> Symmetric/Asymmetric algorithm strings are accessed by application using
> arrays in cryptodev lib, which hampers new algorithms addition in the array
> due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
<snip>
Acked-by: Ciara Power <ciara.power@intel.com>
^ permalink raw reply [relevance 0%]
* RE: [PATCH] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 3% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
2022-12-13 7:31 0% ` Ruifeng Wang
@ 2022-12-13 7:37 0% ` Anoob Joseph
2022-12-13 8:22 0% ` Power, Ciara
` (2 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Anoob Joseph @ 2022-12-13 7:37 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, ruifeng.wang, radu.nicolau,
Volodymyr Fialko, ktraynor, david.marchand, thomas, Akhil Goyal
>
> Symmetric/Asymmetric algorithm strings are accessed by application using
> arrays in cryptodev lib, which hampers new algorithms addition in the array
> due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break
> release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
Acked-by: Anoob Joseph <anoobj@marvell.com>
^ permalink raw reply [relevance 0%]
* RE: [PATCH] cryptodev: add algo enums to string conversion APIs
2022-12-12 15:10 3% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
@ 2022-12-13 7:31 0% ` Ruifeng Wang
2022-12-13 7:37 0% ` Anoob Joseph
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Ruifeng Wang @ 2022-12-13 7:31 UTC (permalink / raw)
To: Akhil Goyal, dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, anoobj, radu.nicolau, vfialko,
ktraynor, david.marchand, thomas, nd
> -----Original Message-----
> From: Akhil Goyal <gakhil@marvell.com>
> Sent: Monday, December 12, 2022 11:10 PM
> To: dev@dpdk.org
> Cc: ciara.power@intel.com; fanzhang.oss@gmail.com; kai.ji@intel.com;
> pablo.de.lara.guarch@intel.com; hemant.agrawal@nxp.com; matan@nvidia.com; g.singh@nxp.com;
> Ruifeng Wang <Ruifeng.Wang@arm.com>; anoobj@marvell.com; radu.nicolau@intel.com;
> vfialko@marvell.com; ktraynor@redhat.com; david.marchand@redhat.com; thomas@monjalon.net;
> Akhil Goyal <gakhil@marvell.com>
> Subject: [PATCH] cryptodev: add algo enums to string conversion APIs
>
> Symmetric/Asymmetric algorithm strings are accessed by application using arrays in
> cryptodev lib, which hampers new algorithms addition in the array due to ABI breakage.
> These arrays are now deprecated and will be removed in next ABI break release.
> New APIs are added for getting the algorithm strings based on enum values.
>
> Signed-off-by: Akhil Goyal <gakhil@marvell.com>
> ---
> app/test-crypto-perf/cperf_options_parsing.c | 6 +-
> app/test/test_cryptodev_asym.c | 2 +-
> app/test/test_cryptodev_security_ipsec.c | 8 +-
> doc/guides/rel_notes/deprecation.rst | 7 +
> drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
> drivers/crypto/qat/qat_sym_session.c | 7 +-
> examples/l2fwd-crypto/main.c | 12 +-
> lib/cryptodev/cryptodev_trace_points.c | 12 ++
> lib/cryptodev/rte_crypto_asym.h | 1 +
> lib/cryptodev/rte_crypto_sym.h | 3 +
> lib/cryptodev/rte_cryptodev.c | 182 ++++++++++++++++++-
> lib/cryptodev/rte_cryptodev.h | 52 ++++++
> lib/cryptodev/rte_cryptodev_trace.h | 32 ++++
> lib/cryptodev/version.map | 10 +
> 14 files changed, 309 insertions(+), 27 deletions(-)
>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
^ permalink raw reply [relevance 0%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 12:03 3% ` Morten Brørup
2022-12-12 12:16 3% ` Bruce Richardson
@ 2022-12-13 3:02 0% ` lihuisong (C)
1 sibling, 0 replies; 200+ results
From: lihuisong (C) @ 2022-12-13 3:02 UTC (permalink / raw)
To: Morten Brørup, Bruce Richardson
Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen
在 2022/12/12 20:03, Morten Brørup 写道:
>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>> Sent: Monday, 12 December 2022 12.21
>>
>> On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
>>>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>>>> Sent: Monday, 12 December 2022 11.32
>>>>
>>>> On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
>>>>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>>>>> rte_tel_data_add_dict/array_int API. This may cause data
>> conversion
>>>> error
>>>>> or data truncation.
>>>>>
>>>>> The 'u32' data can not be assigned to signed 32-bit integer.
>> However,
>>>>> assigning to u64 is very wasteful, after all, the buffer capacity
>> of
>>>> each
>>>>> transfer is limited. So it is necessary for 'u32' data to add
>> usigned
>>>>> 32-bit integer type and a series of 'u32' operation APIs.
>>>>>
>>>>> This patchset uses the new 'u32' API to resolve the problem of
>> data
>>>>> conversion error, and use the 'u64' API to add 'u64' data.
>>>>>
>>>>> In addition, this patchset introduces two APIs to store u32 and
>> u64
>>>>> values as hexadecimal encoded strings in telemetry library.
>>>>>
>>>>> --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
>>>> break
>>>>> warning. - introduce two APIs to store u32 and u64 values as
>>>> hexadecimal
>>>>> encoded strings.
>>>>>
>>>> I'm not convinced about adding the u32 value generically to the
>>>> telemetry
>>>> lib - except in the case of having explicit function calls for u32
>> vs
>>>> u64
>>>> hex strings. Having a u32 type doesn't gain us any space internally
>>>> over a
>>>> u64 value, since all values are in a union type. Also, for output
>> as
>>>> json,
>>>> the numeric values are all output as decimal values, meaning that
>> the
>>>> value
>>>> 1 appears as the same size in the output string whether it is a u32
>> or
>>>> u64
>>>> type. Now, it may save space in a future binary output format, but
>> even
>>>> then it still may not do so.
>>> I agree that a u32 doesn't gain any space internally.
>>>
>>> However, many SNMP counters are unsigned 32 bit, and expected to wrap
>> around as such.
>>> So I suppose the u32 type might be useful for SNMP, if obtained
>> through the telemetry library.
>>> Alternatively, we could somehow reuse the u64 type and require the
>> application to pass (value & UINT32_MAX) to the u64 functions. To make
>> this easy to use, we should add some wrappers to do it for the
>> application. And eventually we would probably end up with something
>> very similar to this patch.
>> I think just using the u64 functions is probably simplest and best
>> right
>> now. If we add support for something like snmp then yes, it would make
>> sense to explicitly add it, but it seems like a lot of extra code for
>> little or no benefit until we support something like that.
> <rant>
> If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> </rant>
>
> I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
All right. Let's drop the new u32 functions.
>
>>>> Therefore, I'd tend to keep the existing u64 type as-is, and
>> instead
>>>> only
>>>> add the functions for outputting hex values. Those hex output
>> functions
>>>> could take an additional parameter indicating the desired hex
>> output
>>>> length, as there could well be cases where we want just 16-bit hex
>>>> value
>>>> too.
>>> The way I read the patch series, the hex output length is not fixed,
>> but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
>>> So the only benefit of having both u32_hex and u64_hex functions is
>> to avoid type promotion from uint32_t to uint64_t on input for 32 bit
>> values.
>>> Instead of passing a 3rd parameter or adding u16_hex functions, we
>> could consider just having one set of hex functions using uint64_t for
>> the value, and rely on type promotion for 32 and 16 bit values.
>> +1 to having only a single hex function, and I think type promotion
>> should
>> work fine.
>>
>> However, I still think it might be worthwhile allowing the user to pass
>> in
>> a min output length parameter too. I find for many hex strings having
>> the
>> leading zeros to explicitly show the length can be useful. The value
>> "0"
>> could cover the current behaviour of no-padding, otherwise the
>> parameter
>> should indicate the number of bits to be displayed. (If we want to lock
>> it
>> down we can use an enum parameter rather than int to limit it to 0, 8,
>> 16,
>> 32 or 64 bit displayed values).
> An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
>
> (I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
>
> Something like this:
>
> char str[64]; // Big enough length.
> if (bits != 0) {
> char format[16]; // Big enough length.
> sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
> sprintf(str, format, value);
> } else {
> sprintf(str, "0x%" PRIx64, value);
> }
Fix it in v4.
>> All that said, I'm not massively concerned if we want to just keep the
>> current approach of always just printing without any leading zeros.
>> It's a
>> nice-to-have only for me.
>>
>> /Bruce
>
> .
^ permalink raw reply [relevance 0%]
* [PATCH] cryptodev: add algo enums to string conversion APIs
@ 2022-12-12 15:10 3% Akhil Goyal
2022-12-13 7:31 0% ` Ruifeng Wang
` (4 more replies)
0 siblings, 5 replies; 200+ results
From: Akhil Goyal @ 2022-12-12 15:10 UTC (permalink / raw)
To: dev
Cc: ciara.power, fanzhang.oss, kai.ji, pablo.de.lara.guarch,
hemant.agrawal, matan, g.singh, ruifeng.wang, anoobj,
radu.nicolau, vfialko, ktraynor, david.marchand, thomas,
Akhil Goyal
Symmetric/Asymmetric algorithm strings are accessed by application
using arrays in cryptodev lib, which hampers new algorithms addition
in the array due to ABI breakage.
These arrays are now deprecated and will be removed in next ABI break
release.
New APIs are added for getting the algorithm strings based on enum values.
Signed-off-by: Akhil Goyal <gakhil@marvell.com>
---
app/test-crypto-perf/cperf_options_parsing.c | 6 +-
app/test/test_cryptodev_asym.c | 2 +-
app/test/test_cryptodev_security_ipsec.c | 8 +-
doc/guides/rel_notes/deprecation.rst | 7 +
drivers/crypto/openssl/rte_openssl_pmd_ops.c | 2 +-
drivers/crypto/qat/qat_sym_session.c | 7 +-
examples/l2fwd-crypto/main.c | 12 +-
lib/cryptodev/cryptodev_trace_points.c | 12 ++
lib/cryptodev/rte_crypto_asym.h | 1 +
lib/cryptodev/rte_crypto_sym.h | 3 +
lib/cryptodev/rte_cryptodev.c | 182 ++++++++++++++++++-
lib/cryptodev/rte_cryptodev.h | 52 ++++++
lib/cryptodev/rte_cryptodev_trace.h | 32 ++++
lib/cryptodev/version.map | 10 +
14 files changed, 309 insertions(+), 27 deletions(-)
diff --git a/app/test-crypto-perf/cperf_options_parsing.c b/app/test-crypto-perf/cperf_options_parsing.c
index bc5e312c81..f8ddb6ac56 100644
--- a/app/test-crypto-perf/cperf_options_parsing.c
+++ b/app/test-crypto-perf/cperf_options_parsing.c
@@ -1373,7 +1373,7 @@ cperf_options_dump(struct cperf_options *opts)
opts->op_type == CPERF_CIPHER_THEN_AUTH ||
opts->op_type == CPERF_AUTH_THEN_CIPHER) {
printf("# auth algorithm: %s\n",
- rte_crypto_auth_algorithm_strings[opts->auth_algo]);
+ rte_cryptodev_get_auth_algo_string(opts->auth_algo));
printf("# auth operation: %s\n",
rte_crypto_auth_operation_strings[opts->auth_op]);
printf("# auth key size: %u\n", opts->auth_key_sz);
@@ -1386,7 +1386,7 @@ cperf_options_dump(struct cperf_options *opts)
opts->op_type == CPERF_CIPHER_THEN_AUTH ||
opts->op_type == CPERF_AUTH_THEN_CIPHER) {
printf("# cipher algorithm: %s\n",
- rte_crypto_cipher_algorithm_strings[opts->cipher_algo]);
+ rte_cryptodev_get_cipher_algo_string(opts->cipher_algo));
printf("# cipher operation: %s\n",
rte_crypto_cipher_operation_strings[opts->cipher_op]);
printf("# cipher key size: %u\n", opts->cipher_key_sz);
@@ -1396,7 +1396,7 @@ cperf_options_dump(struct cperf_options *opts)
if (opts->op_type == CPERF_AEAD) {
printf("# aead algorithm: %s\n",
- rte_crypto_aead_algorithm_strings[opts->aead_algo]);
+ rte_cryptodev_get_aead_algo_string(opts->aead_algo));
printf("# aead operation: %s\n",
rte_crypto_aead_operation_strings[opts->aead_op]);
printf("# aead key size: %u\n", opts->aead_key_sz);
diff --git a/app/test/test_cryptodev_asym.c b/app/test/test_cryptodev_asym.c
index c58c7f488b..5b16dcab56 100644
--- a/app/test/test_cryptodev_asym.c
+++ b/app/test/test_cryptodev_asym.c
@@ -974,7 +974,7 @@ static inline void print_asym_capa(
int i = 0;
printf("\nxform type: %s\n===================\n",
- rte_crypto_asym_xform_strings[capa->xform_type]);
+ rte_cryptodev_asym_get_xform_string(capa->xform_type));
printf("operation supported -");
for (i = 0; i < RTE_CRYPTO_ASYM_OP_LIST_END; i++) {
diff --git a/app/test/test_cryptodev_security_ipsec.c b/app/test/test_cryptodev_security_ipsec.c
index 833be94c09..417ff10a1b 100644
--- a/app/test/test_cryptodev_security_ipsec.c
+++ b/app/test/test_cryptodev_security_ipsec.c
@@ -625,20 +625,20 @@ test_ipsec_display_alg(const struct crypto_param *param1,
{
if (param1->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
printf("\t%s [%d]",
- rte_crypto_aead_algorithm_strings[param1->alg.aead],
+ rte_cryptodev_get_aead_algo_string(param1->alg.aead),
param1->key_length * 8);
} else if (param1->type == RTE_CRYPTO_SYM_XFORM_AUTH) {
printf("\t%s",
- rte_crypto_auth_algorithm_strings[param1->alg.auth]);
+ rte_cryptodev_get_auth_algo_string(param1->alg.auth));
if (param1->alg.auth != RTE_CRYPTO_AUTH_NULL)
printf(" [%dB ICV]", param1->digest_length);
} else {
printf("\t%s",
- rte_crypto_cipher_algorithm_strings[param1->alg.cipher]);
+ rte_cryptodev_get_cipher_algo_string(param1->alg.cipher));
if (param1->alg.cipher != RTE_CRYPTO_CIPHER_NULL)
printf(" [%d]", param1->key_length * 8);
printf(" %s",
- rte_crypto_auth_algorithm_strings[param2->alg.auth]);
+ rte_cryptodev_get_auth_algo_string(param2->alg.auth));
if (param2->alg.auth != RTE_CRYPTO_AUTH_NULL)
printf(" [%dB ICV]", param2->digest_length);
}
diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
index b9b02dcef0..e18ac344ef 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -114,6 +114,13 @@ Deprecation Notices
which got error interrupt to the application,
so that application can reset that particular queue pair.
+* cryptodev: The arrays of algorithm strings ``rte_crypto_cipher_algorithm_strings``,
+ ``rte_crypto_auth_algorithm_strings``, ``rte_crypto_aead_algorithm_strings`` and
+ ``rte_crypto_asym_xform_strings`` are deprecated and will be removed in DPDK 23.11.
+ Application can use the new APIs ``rte_cryptodev_get_cipher_algo_string``,
+ ``rte_cryptodev_get_auth_algo_string``, ``rte_cryptodev_get_aead_algo_string`` and
+ ``rte_cryptodev_asym_get_xform_string`` respectively.
+
* flow_classify: The flow_classify library and example have no maintainer.
The library is experimental and, as such, it could be removed from DPDK.
Its removal has been postponed to let potential users report interest
diff --git a/drivers/crypto/openssl/rte_openssl_pmd_ops.c b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
index defed4429e..29ad1b9505 100644
--- a/drivers/crypto/openssl/rte_openssl_pmd_ops.c
+++ b/drivers/crypto/openssl/rte_openssl_pmd_ops.c
@@ -823,7 +823,7 @@ static int openssl_set_asym_session_parameters(
if ((xform->xform_type != RTE_CRYPTO_ASYM_XFORM_DH) &&
(xform->next != NULL)) {
OPENSSL_LOG(ERR, "chained xfrms are not supported on %s",
- rte_crypto_asym_xform_strings[xform->xform_type]);
+ rte_cryptodev_asym_get_xform_string(xform->xform_type));
return ret;
}
diff --git a/drivers/crypto/qat/qat_sym_session.c b/drivers/crypto/qat/qat_sym_session.c
index 0ebc66f89e..714002dce3 100644
--- a/drivers/crypto/qat/qat_sym_session.c
+++ b/drivers/crypto/qat/qat_sym_session.c
@@ -436,8 +436,8 @@ qat_sym_session_configure_cipher(struct rte_cryptodev *dev,
if (!qat_is_cipher_alg_supported(
cipher_xform->algo, internals)) {
QAT_LOG(ERR, "%s not supported on this device",
- rte_crypto_cipher_algorithm_strings
- [cipher_xform->algo]);
+ rte_cryptodev_get_cipher_algo_string(
+ cipher_xform->algo));
ret = -ENOTSUP;
goto error_out;
}
@@ -772,8 +772,7 @@ qat_sym_session_configure_auth(struct rte_cryptodev *dev,
case RTE_CRYPTO_AUTH_ZUC_EIA3:
if (!qat_is_auth_alg_supported(auth_xform->algo, internals)) {
QAT_LOG(ERR, "%s not supported on this device",
- rte_crypto_auth_algorithm_strings
- [auth_xform->algo]);
+ rte_cryptodev_get_auth_algo_string(auth_xform->algo));
return -ENOTSUP;
}
session->qat_hash_alg = ICP_QAT_HW_AUTH_ALGO_ZUC_3G_128_EIA3;
diff --git a/examples/l2fwd-crypto/main.c b/examples/l2fwd-crypto/main.c
index b13e5c526e..efe7eea2a7 100644
--- a/examples/l2fwd-crypto/main.c
+++ b/examples/l2fwd-crypto/main.c
@@ -1536,7 +1536,7 @@ display_cipher_info(struct l2fwd_crypto_options *options)
{
printf("\n---- Cipher information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_cipher_algorithm_strings[options->cipher_xform.cipher.algo]);
+ rte_cryptodev_get_cipher_algo_string(options->cipher_xform.cipher.algo));
rte_hexdump(stdout, "Cipher key:",
options->cipher_xform.cipher.key.data,
options->cipher_xform.cipher.key.length);
@@ -1548,7 +1548,7 @@ display_auth_info(struct l2fwd_crypto_options *options)
{
printf("\n---- Authentication information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_auth_algorithm_strings[options->auth_xform.auth.algo]);
+ rte_cryptodev_get_auth_algo_string(options->auth_xform.auth.algo));
rte_hexdump(stdout, "Auth key:",
options->auth_xform.auth.key.data,
options->auth_xform.auth.key.length);
@@ -1560,7 +1560,7 @@ display_aead_info(struct l2fwd_crypto_options *options)
{
printf("\n---- AEAD information ---\n");
printf("Algorithm: %s\n",
- rte_crypto_aead_algorithm_strings[options->aead_xform.aead.algo]);
+ rte_cryptodev_get_aead_algo_string(options->aead_xform.aead.algo));
rte_hexdump(stdout, "AEAD key:",
options->aead_xform.aead.key.data,
options->aead_xform.aead.key.length);
@@ -1864,7 +1864,7 @@ check_device_support_cipher_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_cipher_algorithm_strings[opt_cipher_algo],
+ rte_cryptodev_get_cipher_algo_string(opt_cipher_algo),
cdev_id,
options->string_type);
return NULL;
@@ -1898,7 +1898,7 @@ check_device_support_auth_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_auth_algorithm_strings[opt_auth_algo],
+ rte_cryptodev_get_auth_algo_string(opt_auth_algo),
cdev_id,
options->string_type);
return NULL;
@@ -1932,7 +1932,7 @@ check_device_support_aead_algo(const struct l2fwd_crypto_options *options,
if (cap->op == RTE_CRYPTO_OP_TYPE_UNDEFINED) {
printf("Algorithm %s not supported by cryptodev %u"
" or device not of preferred type (%s)\n",
- rte_crypto_aead_algorithm_strings[opt_aead_algo],
+ rte_cryptodev_get_aead_algo_string(opt_aead_algo),
cdev_id,
options->string_type);
return NULL;
diff --git a/lib/cryptodev/cryptodev_trace_points.c b/lib/cryptodev/cryptodev_trace_points.c
index 63a81511a9..4980bcc9be 100644
--- a/lib/cryptodev/cryptodev_trace_points.c
+++ b/lib/cryptodev/cryptodev_trace_points.c
@@ -72,6 +72,15 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_enum,
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_enum,
lib.cryptodev.get.cipher.algo.enum)
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_aead_algo_string,
+ lib.cryptodev.get.aead.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_auth_algo_string,
+ lib.cryptodev.get.auth.algo.string)
+
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_cipher_algo_string,
+ lib.cryptodev.get.cipher.algo.string)
+
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_get_dev_id,
lib.cryptodev.get.dev.id)
@@ -126,6 +135,9 @@ RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_private_session_size,
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_enum,
lib.cryptodev.asym.get.xform.enum)
+RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_get_xform_string,
+ lib.cryptodev.asym.get.xform.string)
+
RTE_TRACE_POINT_REGISTER(rte_cryptodev_trace_asym_xform_capability_check_modlen,
lib.cryptodev.asym.xform.capability.check.modlen)
diff --git a/lib/cryptodev/rte_crypto_asym.h b/lib/cryptodev/rte_crypto_asym.h
index 38c8b60779..989f38323f 100644
--- a/lib/cryptodev/rte_crypto_asym.h
+++ b/lib/cryptodev/rte_crypto_asym.h
@@ -30,6 +30,7 @@ extern "C" {
struct rte_cryptodev_asym_session;
/** asym xform type name strings */
+__rte_deprecated
extern const char *
rte_crypto_asym_xform_strings[];
diff --git a/lib/cryptodev/rte_crypto_sym.h b/lib/cryptodev/rte_crypto_sym.h
index 33b4966e16..dc847da7b8 100644
--- a/lib/cryptodev/rte_crypto_sym.h
+++ b/lib/cryptodev/rte_crypto_sym.h
@@ -177,6 +177,7 @@ enum rte_crypto_cipher_algorithm {
};
/** Cipher algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_cipher_algorithm_strings[];
@@ -378,6 +379,7 @@ enum rte_crypto_auth_algorithm {
};
/** Authentication algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_auth_algorithm_strings[];
@@ -482,6 +484,7 @@ enum rte_crypto_aead_algorithm {
};
/** AEAD algorithm name strings */
+__rte_deprecated
extern const char *
rte_crypto_aead_algorithm_strings[];
diff --git a/lib/cryptodev/rte_cryptodev.c b/lib/cryptodev/rte_cryptodev.c
index 2165a0688c..1e98f13dac 100644
--- a/lib/cryptodev/rte_cryptodev.c
+++ b/lib/cryptodev/rte_cryptodev.c
@@ -64,9 +64,11 @@ struct rte_cryptodev_callback {
};
/**
+ * @deprecated
* The crypto cipher algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_cipher_algorithm_strings[] = {
[RTE_CRYPTO_CIPHER_3DES_CBC] = "3des-cbc",
@@ -95,6 +97,39 @@ rte_crypto_cipher_algorithm_strings[] = {
[RTE_CRYPTO_CIPHER_SM4_CTR] = "sm4-ctr"
};
+/**
+ * The crypto cipher algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_cipher_algo_string().
+ */
+static const char *
+crypto_cipher_algorithm_strings[] = {
+ [RTE_CRYPTO_CIPHER_3DES_CBC] = "3des-cbc",
+ [RTE_CRYPTO_CIPHER_3DES_ECB] = "3des-ecb",
+ [RTE_CRYPTO_CIPHER_3DES_CTR] = "3des-ctr",
+
+ [RTE_CRYPTO_CIPHER_AES_CBC] = "aes-cbc",
+ [RTE_CRYPTO_CIPHER_AES_CTR] = "aes-ctr",
+ [RTE_CRYPTO_CIPHER_AES_DOCSISBPI] = "aes-docsisbpi",
+ [RTE_CRYPTO_CIPHER_AES_ECB] = "aes-ecb",
+ [RTE_CRYPTO_CIPHER_AES_F8] = "aes-f8",
+ [RTE_CRYPTO_CIPHER_AES_XTS] = "aes-xts",
+
+ [RTE_CRYPTO_CIPHER_ARC4] = "arc4",
+
+ [RTE_CRYPTO_CIPHER_DES_CBC] = "des-cbc",
+ [RTE_CRYPTO_CIPHER_DES_DOCSISBPI] = "des-docsisbpi",
+
+ [RTE_CRYPTO_CIPHER_NULL] = "null",
+
+ [RTE_CRYPTO_CIPHER_KASUMI_F8] = "kasumi-f8",
+ [RTE_CRYPTO_CIPHER_SNOW3G_UEA2] = "snow3g-uea2",
+ [RTE_CRYPTO_CIPHER_ZUC_EEA3] = "zuc-eea3",
+ [RTE_CRYPTO_CIPHER_SM4_ECB] = "sm4-ecb",
+ [RTE_CRYPTO_CIPHER_SM4_CBC] = "sm4-cbc",
+ [RTE_CRYPTO_CIPHER_SM4_CTR] = "sm4-ctr"
+};
+
/**
* The crypto cipher operation strings identifiers.
* It could be used in application command line.
@@ -106,9 +141,11 @@ rte_crypto_cipher_operation_strings[] = {
};
/**
+ * @deprecated
* The crypto auth algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_auth_algorithm_strings[] = {
[RTE_CRYPTO_AUTH_AES_CBC_MAC] = "aes-cbc-mac",
@@ -149,9 +186,55 @@ rte_crypto_auth_algorithm_strings[] = {
};
/**
+ * The crypto auth algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_auth_algo_string().
+ */
+static const char *
+crypto_auth_algorithm_strings[] = {
+ [RTE_CRYPTO_AUTH_AES_CBC_MAC] = "aes-cbc-mac",
+ [RTE_CRYPTO_AUTH_AES_CMAC] = "aes-cmac",
+ [RTE_CRYPTO_AUTH_AES_GMAC] = "aes-gmac",
+ [RTE_CRYPTO_AUTH_AES_XCBC_MAC] = "aes-xcbc-mac",
+
+ [RTE_CRYPTO_AUTH_MD5] = "md5",
+ [RTE_CRYPTO_AUTH_MD5_HMAC] = "md5-hmac",
+
+ [RTE_CRYPTO_AUTH_NULL] = "null",
+
+ [RTE_CRYPTO_AUTH_SHA1] = "sha1",
+ [RTE_CRYPTO_AUTH_SHA1_HMAC] = "sha1-hmac",
+
+ [RTE_CRYPTO_AUTH_SHA224] = "sha2-224",
+ [RTE_CRYPTO_AUTH_SHA224_HMAC] = "sha2-224-hmac",
+ [RTE_CRYPTO_AUTH_SHA256] = "sha2-256",
+ [RTE_CRYPTO_AUTH_SHA256_HMAC] = "sha2-256-hmac",
+ [RTE_CRYPTO_AUTH_SHA384] = "sha2-384",
+ [RTE_CRYPTO_AUTH_SHA384_HMAC] = "sha2-384-hmac",
+ [RTE_CRYPTO_AUTH_SHA512] = "sha2-512",
+ [RTE_CRYPTO_AUTH_SHA512_HMAC] = "sha2-512-hmac",
+
+ [RTE_CRYPTO_AUTH_SHA3_224] = "sha3-224",
+ [RTE_CRYPTO_AUTH_SHA3_224_HMAC] = "sha3-224-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_256] = "sha3-256",
+ [RTE_CRYPTO_AUTH_SHA3_256_HMAC] = "sha3-256-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_384] = "sha3-384",
+ [RTE_CRYPTO_AUTH_SHA3_384_HMAC] = "sha3-384-hmac",
+ [RTE_CRYPTO_AUTH_SHA3_512] = "sha3-512",
+ [RTE_CRYPTO_AUTH_SHA3_512_HMAC] = "sha3-512-hmac",
+
+ [RTE_CRYPTO_AUTH_KASUMI_F9] = "kasumi-f9",
+ [RTE_CRYPTO_AUTH_SNOW3G_UIA2] = "snow3g-uia2",
+ [RTE_CRYPTO_AUTH_ZUC_EIA3] = "zuc-eia3",
+ [RTE_CRYPTO_AUTH_SM3] = "sm3"
+};
+
+/**
+ * @deprecated
* The crypto AEAD algorithm strings identifiers.
* It could be used in application command line.
*/
+__rte_deprecated
const char *
rte_crypto_aead_algorithm_strings[] = {
[RTE_CRYPTO_AEAD_AES_CCM] = "aes-ccm",
@@ -159,6 +242,19 @@ rte_crypto_aead_algorithm_strings[] = {
[RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
};
+/**
+ * The crypto AEAD algorithm strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_get_aead_algo_string().
+ */
+static const char *
+crypto_aead_algorithm_strings[] = {
+ [RTE_CRYPTO_AEAD_AES_CCM] = "aes-ccm",
+ [RTE_CRYPTO_AEAD_AES_GCM] = "aes-gcm",
+ [RTE_CRYPTO_AEAD_CHACHA20_POLY1305] = "chacha20-poly1305"
+};
+
+
/**
* The crypto AEAD operation strings identifiers.
* It could be used in application command line.
@@ -170,8 +266,10 @@ rte_crypto_aead_operation_strings[] = {
};
/**
+ * @deprecated
* Asymmetric crypto transform operation strings identifiers.
*/
+__rte_deprecated
const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_NONE] = "none",
[RTE_CRYPTO_ASYM_XFORM_RSA] = "rsa",
@@ -183,6 +281,22 @@ const char *rte_crypto_asym_xform_strings[] = {
[RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
};
+/**
+ * Asymmetric crypto transform operation strings identifiers.
+ * Not to be used in application directly.
+ * Application can use rte_cryptodev_asym_get_xform_string().
+ */
+static const char *crypto_asym_xform_strings[] = {
+ [RTE_CRYPTO_ASYM_XFORM_NONE] = "none",
+ [RTE_CRYPTO_ASYM_XFORM_RSA] = "rsa",
+ [RTE_CRYPTO_ASYM_XFORM_MODEX] = "modexp",
+ [RTE_CRYPTO_ASYM_XFORM_MODINV] = "modinv",
+ [RTE_CRYPTO_ASYM_XFORM_DH] = "dh",
+ [RTE_CRYPTO_ASYM_XFORM_DSA] = "dsa",
+ [RTE_CRYPTO_ASYM_XFORM_ECDSA] = "ecdsa",
+ [RTE_CRYPTO_ASYM_XFORM_ECPM] = "ecpm",
+};
+
/**
* Asymmetric crypto operation strings identifiers.
*/
@@ -227,8 +341,8 @@ rte_cryptodev_get_cipher_algo_enum(enum rte_crypto_cipher_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_cipher_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_cipher_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_cipher_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_cipher_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_cipher_algorithm) i;
ret = 0;
break;
@@ -247,8 +361,8 @@ rte_cryptodev_get_auth_algo_enum(enum rte_crypto_auth_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_auth_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_auth_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_auth_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_auth_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_auth_algorithm) i;
ret = 0;
break;
@@ -267,8 +381,8 @@ rte_cryptodev_get_aead_algo_enum(enum rte_crypto_aead_algorithm *algo_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_aead_algorithm_strings); i++) {
- if (strcmp(algo_string, rte_crypto_aead_algorithm_strings[i]) == 0) {
+ for (i = 1; i < RTE_DIM(crypto_aead_algorithm_strings); i++) {
+ if (strcmp(algo_string, crypto_aead_algorithm_strings[i]) == 0) {
*algo_enum = (enum rte_crypto_aead_algorithm) i;
ret = 0;
break;
@@ -287,9 +401,9 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
unsigned int i;
int ret = -1; /* Invalid string */
- for (i = 1; i < RTE_DIM(rte_crypto_asym_xform_strings); i++) {
+ for (i = 1; i < RTE_DIM(crypto_asym_xform_strings); i++) {
if (strcmp(xform_string,
- rte_crypto_asym_xform_strings[i]) == 0) {
+ crypto_asym_xform_strings[i]) == 0) {
*xform_enum = (enum rte_crypto_asym_xform_type) i;
ret = 0;
break;
@@ -301,6 +415,58 @@ rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
return ret;
}
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if (algo_enum < RTE_DIM(crypto_cipher_algorithm_strings))
+ alg_str = crypto_cipher_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_cipher_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if (algo_enum < RTE_DIM(crypto_auth_algorithm_strings))
+ alg_str = crypto_auth_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_auth_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum)
+{
+ const char *alg_str = NULL;
+
+ if (algo_enum < RTE_DIM(crypto_aead_algorithm_strings))
+ alg_str = crypto_aead_algorithm_strings[algo_enum];
+
+ rte_cryptodev_trace_get_aead_algo_string(algo_enum, alg_str);
+
+ return alg_str;
+}
+
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum)
+{
+ const char *xform_str = NULL;
+
+ if (xform_enum < RTE_DIM(crypto_asym_xform_strings))
+ xform_str = crypto_asym_xform_strings[xform_enum];
+
+ rte_cryptodev_trace_asym_get_xform_string(xform_enum, xform_str);
+
+ return xform_str;
+}
+
/**
* The crypto auth operation strings identifiers.
* It could be used in application command line.
diff --git a/lib/cryptodev/rte_cryptodev.h b/lib/cryptodev/rte_cryptodev.h
index 86d792e2e7..8f41a009e3 100644
--- a/lib/cryptodev/rte_cryptodev.h
+++ b/lib/cryptodev/rte_cryptodev.h
@@ -406,6 +406,58 @@ int
rte_cryptodev_asym_get_xform_enum(enum rte_crypto_asym_xform_type *xform_enum,
const char *xform_string);
+/**
+ * Provide the cipher algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum cipher algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_cipher_algo_string(enum rte_crypto_cipher_algorithm algo_enum);
+
+/**
+ * Provide the authentication algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum auth algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_auth_algo_string(enum rte_crypto_auth_algorithm algo_enum);
+
+/**
+ * Provide the AEAD algorithm string, given an algorithm enum.
+ *
+ * @param algo_enum AEAD algorithm enum
+ *
+ * @return
+ * - Return NULL if enum is not valid
+ * - Return algo_string corresponding to enum
+ */
+__rte_experimental
+const char *
+rte_cryptodev_get_aead_algo_string(enum rte_crypto_aead_algorithm algo_enum);
+
+/**
+ * Provide the Asymmetric xform string, given an xform enum.
+ *
+ * @param xform_enum xform type enum
+ *
+ * @return
+ * - Return NULL, if enum is not valid.
+ * - Return xform string, for valid enum.
+ */
+__rte_experimental
+const char *
+rte_cryptodev_asym_get_xform_string(enum rte_crypto_asym_xform_type xform_enum);
+
/** Macro used at end of crypto PMD list */
#define RTE_CRYPTODEV_END_OF_CAPABILITIES_LIST() \
diff --git a/lib/cryptodev/rte_cryptodev_trace.h b/lib/cryptodev/rte_cryptodev_trace.h
index 6c214ce6ea..5e694379b1 100644
--- a/lib/cryptodev/rte_cryptodev_trace.h
+++ b/lib/cryptodev/rte_cryptodev_trace.h
@@ -189,6 +189,30 @@ RTE_TRACE_POINT(
rte_trace_point_emit_int(ret);
)
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_aead_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_aead_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_auth_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_auth_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_get_cipher_algo_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_cipher_algorithm algo_enum,
+ const char *algo_string),
+ rte_trace_point_emit_int(algo_enum);
+ rte_trace_point_emit_string(algo_string);
+)
+
RTE_TRACE_POINT(
rte_cryptodev_trace_get_dev_id,
RTE_TRACE_POINT_ARGS(const char *name, int ret),
@@ -351,6 +375,14 @@ RTE_TRACE_POINT(
rte_trace_point_emit_int(ret);
)
+RTE_TRACE_POINT(
+ rte_cryptodev_trace_asym_get_xform_string,
+ RTE_TRACE_POINT_ARGS(enum rte_crypto_asym_xform_type xform_enum,
+ const char *xform_string),
+ rte_trace_point_emit_int(xform_enum);
+ rte_trace_point_emit_string(xform_string);
+)
+
RTE_TRACE_POINT(
rte_cryptodev_trace_asym_xform_capability_check_modlen,
RTE_TRACE_POINT_ARGS(const void *capability, uint16_t modlen, int ret),
diff --git a/lib/cryptodev/version.map b/lib/cryptodev/version.map
index 00c99fb45c..372d042931 100644
--- a/lib/cryptodev/version.map
+++ b/lib/cryptodev/version.map
@@ -150,11 +150,21 @@ EXPERIMENTAL {
__rte_cryptodev_trace_sym_session_get_user_data;
__rte_cryptodev_trace_sym_session_set_user_data;
__rte_cryptodev_trace_count;
+
+ # added 23.03
+ rte_cryptodev_asym_get_xform_string;
+ rte_cryptodev_get_aead_algo_string;
+ rte_cryptodev_get_auth_algo_string;
+ rte_cryptodev_get_cipher_algo_string;
};
INTERNAL {
global:
+ __rte_cryptodev_trace_asym_get_xform_string;
+ __rte_cryptodev_trace_get_aead_algo_string;
+ __rte_cryptodev_trace_get_auth_algo_string;
+ __rte_cryptodev_trace_get_cipher_algo_string;
cryptodev_fp_ops_reset;
cryptodev_fp_ops_set;
rte_cryptodev_allocate_driver;
--
2.25.1
^ permalink raw reply [relevance 3%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 12:03 3% ` Morten Brørup
@ 2022-12-12 12:16 3% ` Bruce Richardson
2022-12-13 11:00 0% ` Morten Brørup
2022-12-13 17:12 3% ` Bruce Richardson
2022-12-13 3:02 0% ` lihuisong (C)
1 sibling, 2 replies; 200+ results
From: Bruce Richardson @ 2022-12-12 12:16 UTC (permalink / raw)
To: Morten Brørup
Cc: Huisong Li, dev, ciara.power, liudongdong3, huangdaode, fengchengwen
On Mon, Dec 12, 2022 at 01:03:52PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Monday, 12 December 2022 12.21
> >
> > On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > > Sent: Monday, 12 December 2022 11.32
> > > >
> > > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > > rte_tel_data_add_dict/array_int API. This may cause data
> > conversion
> > > > error
> > > > > or data truncation.
> > > > >
> > > > > The 'u32' data can not be assigned to signed 32-bit integer.
> > However,
> > > > > assigning to u64 is very wasteful, after all, the buffer capacity
> > of
> > > > each
> > > > > transfer is limited. So it is necessary for 'u32' data to add
> > usigned
> > > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > > >
> > > > > This patchset uses the new 'u32' API to resolve the problem of
> > data
> > > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > > >
> > > > > In addition, this patchset introduces two APIs to store u32 and
> > u64
> > > > > values as hexadecimal encoded strings in telemetry library.
> > > > >
> > > > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> > > > break
> > > > > warning. - introduce two APIs to store u32 and u64 values as
> > > > hexadecimal
> > > > > encoded strings.
> > > > >
> > > > I'm not convinced about adding the u32 value generically to the
> > > > telemetry
> > > > lib - except in the case of having explicit function calls for u32
> > vs
> > > > u64
> > > > hex strings. Having a u32 type doesn't gain us any space internally
> > > > over a
> > > > u64 value, since all values are in a union type. Also, for output
> > as
> > > > json,
> > > > the numeric values are all output as decimal values, meaning that
> > the
> > > > value
> > > > 1 appears as the same size in the output string whether it is a u32
> > or
> > > > u64
> > > > type. Now, it may save space in a future binary output format, but
> > even
> > > > then it still may not do so.
> > >
> > > I agree that a u32 doesn't gain any space internally.
> > >
> > > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> > around as such.
> > >
> > > So I suppose the u32 type might be useful for SNMP, if obtained
> > through the telemetry library.
> > >
> > > Alternatively, we could somehow reuse the u64 type and require the
> > application to pass (value & UINT32_MAX) to the u64 functions. To make
> > this easy to use, we should add some wrappers to do it for the
> > application. And eventually we would probably end up with something
> > very similar to this patch.
> > >
> >
> > I think just using the u64 functions is probably simplest and best
> > right
> > now. If we add support for something like snmp then yes, it would make
> > sense to explicitly add it, but it seems like a lot of extra code for
> > little or no benefit until we support something like that.
>
> <rant>
> If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
> </rant>
Yes, not making "int" an "i64" type was a poor design decision on my part
in the earlier versions. Thankfully negative values are rarely needed
beyond the range of 32-bits, but we should probably look to update this as
you suggest at the next ABI break window.
>
> I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
>
> >
> > > >
> > > > Therefore, I'd tend to keep the existing u64 type as-is, and
> > instead
> > > > only
> > > > add the functions for outputting hex values. Those hex output
> > functions
> > > > could take an additional parameter indicating the desired hex
> > output
> > > > length, as there could well be cases where we want just 16-bit hex
> > > > value
> > > > too.
> > >
> > > The way I read the patch series, the hex output length is not fixed,
> > but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> > >
> > > So the only benefit of having both u32_hex and u64_hex functions is
> > to avoid type promotion from uint32_t to uint64_t on input for 32 bit
> > values.
> > >
> > > Instead of passing a 3rd parameter or adding u16_hex functions, we
> > could consider just having one set of hex functions using uint64_t for
> > the value, and rely on type promotion for 32 and 16 bit values.
> > >
> >
> > +1 to having only a single hex function, and I think type promotion
> > should
> > work fine.
> >
> > However, I still think it might be worthwhile allowing the user to pass
> > in
> > a min output length parameter too. I find for many hex strings having
> > the
> > leading zeros to explicitly show the length can be useful. The value
> > "0"
> > could cover the current behaviour of no-padding, otherwise the
> > parameter
> > should indicate the number of bits to be displayed. (If we want to lock
> > it
> > down we can use an enum parameter rather than int to limit it to 0, 8,
> > 16,
> > 32 or 64 bit displayed values).
>
> An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
>
> (I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
>
> Something like this:
>
> char str[64]; // Big enough length.
> if (bits != 0) {
> char format[16]; // Big enough length.
> sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
> sprintf(str, format, value);
> } else {
> sprintf(str, "0x%" PRIx64, value);
> }
>
LGTM.
^ permalink raw reply [relevance 3%]
* RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 11:20 0% ` Bruce Richardson
@ 2022-12-12 12:03 3% ` Morten Brørup
2022-12-12 12:16 3% ` Bruce Richardson
2022-12-13 3:02 0% ` lihuisong (C)
0 siblings, 2 replies; 200+ results
From: Morten Brørup @ 2022-12-12 12:03 UTC (permalink / raw)
To: Bruce Richardson, Huisong Li
Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 12.21
>
> On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Monday, 12 December 2022 11.32
> > >
> > > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > > rte_tel_data_add_dict/array_int API. This may cause data
> conversion
> > > error
> > > > or data truncation.
> > > >
> > > > The 'u32' data can not be assigned to signed 32-bit integer.
> However,
> > > > assigning to u64 is very wasteful, after all, the buffer capacity
> of
> > > each
> > > > transfer is limited. So it is necessary for 'u32' data to add
> usigned
> > > > 32-bit integer type and a series of 'u32' operation APIs.
> > > >
> > > > This patchset uses the new 'u32' API to resolve the problem of
> data
> > > > conversion error, and use the 'u64' API to add 'u64' data.
> > > >
> > > > In addition, this patchset introduces two APIs to store u32 and
> u64
> > > > values as hexadecimal encoded strings in telemetry library.
> > > >
> > > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> > > break
> > > > warning. - introduce two APIs to store u32 and u64 values as
> > > hexadecimal
> > > > encoded strings.
> > > >
> > > I'm not convinced about adding the u32 value generically to the
> > > telemetry
> > > lib - except in the case of having explicit function calls for u32
> vs
> > > u64
> > > hex strings. Having a u32 type doesn't gain us any space internally
> > > over a
> > > u64 value, since all values are in a union type. Also, for output
> as
> > > json,
> > > the numeric values are all output as decimal values, meaning that
> the
> > > value
> > > 1 appears as the same size in the output string whether it is a u32
> or
> > > u64
> > > type. Now, it may save space in a future binary output format, but
> even
> > > then it still may not do so.
> >
> > I agree that a u32 doesn't gain any space internally.
> >
> > However, many SNMP counters are unsigned 32 bit, and expected to wrap
> around as such.
> >
> > So I suppose the u32 type might be useful for SNMP, if obtained
> through the telemetry library.
> >
> > Alternatively, we could somehow reuse the u64 type and require the
> application to pass (value & UINT32_MAX) to the u64 functions. To make
> this easy to use, we should add some wrappers to do it for the
> application. And eventually we would probably end up with something
> very similar to this patch.
> >
>
> I think just using the u64 functions is probably simplest and best
> right
> now. If we add support for something like snmp then yes, it would make
> sense to explicitly add it, but it seems like a lot of extra code for
> little or no benefit until we support something like that.
<rant>
If we wanted to fix this generally, we should rely on type promotion, so the existing _int function should be updated to take an int64_t value, and the _u64 function should be renamed to _uint (and still take an uint64_t value). However, that would break the ABI, and would need to go through some process for that. So let's not change this now.
</rant>
I tend to agree with Bruce on this: Let's get rid of the new u32 functions, and rely on the u64 functions for that instead.
>
> > >
> > > Therefore, I'd tend to keep the existing u64 type as-is, and
> instead
> > > only
> > > add the functions for outputting hex values. Those hex output
> functions
> > > could take an additional parameter indicating the desired hex
> output
> > > length, as there could well be cases where we want just 16-bit hex
> > > value
> > > too.
> >
> > The way I read the patch series, the hex output length is not fixed,
> but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
> >
> > So the only benefit of having both u32_hex and u64_hex functions is
> to avoid type promotion from uint32_t to uint64_t on input for 32 bit
> values.
> >
> > Instead of passing a 3rd parameter or adding u16_hex functions, we
> could consider just having one set of hex functions using uint64_t for
> the value, and rely on type promotion for 32 and 16 bit values.
> >
>
> +1 to having only a single hex function, and I think type promotion
> should
> work fine.
>
> However, I still think it might be worthwhile allowing the user to pass
> in
> a min output length parameter too. I find for many hex strings having
> the
> leading zeros to explicitly show the length can be useful. The value
> "0"
> could cover the current behaviour of no-padding, otherwise the
> parameter
> should indicate the number of bits to be displayed. (If we want to lock
> it
> down we can use an enum parameter rather than int to limit it to 0, 8,
> 16,
> 32 or 64 bit displayed values).
An extra parameter for minimum output length (in number of input bits) would be very nice, and makes avoids a set of functions for each bit width.
(I don't think it should be lock it down to some special bit lengths; there is no need to prevent 24 bit or other exotic bit widths.)
Something like this:
char str[64]; // Big enough length.
if (bits != 0) {
char format[16]; // Big enough length.
sprintf(format, "0x0%u%" PRIx64, (bits + 3) / 4);
sprintf(str, format, value);
} else {
sprintf(str, "0x%" PRIx64, value);
}
>
> All that said, I'm not massively concerned if we want to just keep the
> current approach of always just printing without any leading zeros.
> It's a
> nice-to-have only for me.
>
> /Bruce
^ permalink raw reply [relevance 3%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 11:02 0% ` Morten Brørup
@ 2022-12-12 11:20 0% ` Bruce Richardson
2022-12-12 12:03 3% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-12 11:20 UTC (permalink / raw)
To: Morten Brørup
Cc: Huisong Li, dev, ciara.power, liudongdong3, huangdaode, fengchengwen
On Mon, Dec 12, 2022 at 12:02:32PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Monday, 12 December 2022 11.32
> >
> > On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > > rte_tel_data_add_dict/array_int API. This may cause data conversion
> > error
> > > or data truncation.
> > >
> > > The 'u32' data can not be assigned to signed 32-bit integer. However,
> > > assigning to u64 is very wasteful, after all, the buffer capacity of
> > each
> > > transfer is limited. So it is necessary for 'u32' data to add usigned
> > > 32-bit integer type and a series of 'u32' operation APIs.
> > >
> > > This patchset uses the new 'u32' API to resolve the problem of data
> > > conversion error, and use the 'u64' API to add 'u64' data.
> > >
> > > In addition, this patchset introduces two APIs to store u32 and u64
> > > values as hexadecimal encoded strings in telemetry library.
> > >
> > > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> > break
> > > warning. - introduce two APIs to store u32 and u64 values as
> > hexadecimal
> > > encoded strings.
> > >
> > I'm not convinced about adding the u32 value generically to the
> > telemetry
> > lib - except in the case of having explicit function calls for u32 vs
> > u64
> > hex strings. Having a u32 type doesn't gain us any space internally
> > over a
> > u64 value, since all values are in a union type. Also, for output as
> > json,
> > the numeric values are all output as decimal values, meaning that the
> > value
> > 1 appears as the same size in the output string whether it is a u32 or
> > u64
> > type. Now, it may save space in a future binary output format, but even
> > then it still may not do so.
>
> I agree that a u32 doesn't gain any space internally.
>
> However, many SNMP counters are unsigned 32 bit, and expected to wrap around as such.
>
> So I suppose the u32 type might be useful for SNMP, if obtained through the telemetry library.
>
> Alternatively, we could somehow reuse the u64 type and require the application to pass (value & UINT32_MAX) to the u64 functions. To make this easy to use, we should add some wrappers to do it for the application. And eventually we would probably end up with something very similar to this patch.
>
I think just using the u64 functions is probably simplest and best right
now. If we add support for something like snmp then yes, it would make
sense to explicitly add it, but it seems like a lot of extra code for
little or no benefit until we support something like that.
> >
> > Therefore, I'd tend to keep the existing u64 type as-is, and instead
> > only
> > add the functions for outputting hex values. Those hex output functions
> > could take an additional parameter indicating the desired hex output
> > length, as there could well be cases where we want just 16-bit hex
> > value
> > too.
>
> The way I read the patch series, the hex output length is not fixed, but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
>
> So the only benefit of having both u32_hex and u64_hex functions is to avoid type promotion from uint32_t to uint64_t on input for 32 bit values.
>
> Instead of passing a 3rd parameter or adding u16_hex functions, we could consider just having one set of hex functions using uint64_t for the value, and rely on type promotion for 32 and 16 bit values.
>
+1 to having only a single hex function, and I think type promotion should
work fine.
However, I still think it might be worthwhile allowing the user to pass in
a min output length parameter too. I find for many hex strings having the
leading zeros to explicitly show the length can be useful. The value "0"
could cover the current behaviour of no-padding, otherwise the parameter
should indicate the number of bits to be displayed. (If we want to lock it
down we can use an enum parameter rather than int to limit it to 0, 8, 16,
32 or 64 bit displayed values).
All that said, I'm not massively concerned if we want to just keep the
current approach of always just printing without any leading zeros. It's a
nice-to-have only for me.
/Bruce
^ permalink raw reply [relevance 0%]
* RE: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 10:31 0% ` Bruce Richardson
@ 2022-12-12 11:02 0% ` Morten Brørup
2022-12-12 11:20 0% ` Bruce Richardson
0 siblings, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-12 11:02 UTC (permalink / raw)
To: Bruce Richardson, Huisong Li
Cc: dev, ciara.power, liudongdong3, huangdaode, fengchengwen
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 12 December 2022 11.32
>
> On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> > Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> > rte_tel_data_add_dict/array_int API. This may cause data conversion
> error
> > or data truncation.
> >
> > The 'u32' data can not be assigned to signed 32-bit integer. However,
> > assigning to u64 is very wasteful, after all, the buffer capacity of
> each
> > transfer is limited. So it is necessary for 'u32' data to add usigned
> > 32-bit integer type and a series of 'u32' operation APIs.
> >
> > This patchset uses the new 'u32' API to resolve the problem of data
> > conversion error, and use the 'u64' API to add 'u64' data.
> >
> > In addition, this patchset introduces two APIs to store u32 and u64
> > values as hexadecimal encoded strings in telemetry library.
> >
> > --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI
> break
> > warning. - introduce two APIs to store u32 and u64 values as
> hexadecimal
> > encoded strings.
> >
> I'm not convinced about adding the u32 value generically to the
> telemetry
> lib - except in the case of having explicit function calls for u32 vs
> u64
> hex strings. Having a u32 type doesn't gain us any space internally
> over a
> u64 value, since all values are in a union type. Also, for output as
> json,
> the numeric values are all output as decimal values, meaning that the
> value
> 1 appears as the same size in the output string whether it is a u32 or
> u64
> type. Now, it may save space in a future binary output format, but even
> then it still may not do so.
I agree that a u32 doesn't gain any space internally.
However, many SNMP counters are unsigned 32 bit, and expected to wrap around as such.
So I suppose the u32 type might be useful for SNMP, if obtained through the telemetry library.
Alternatively, we could somehow reuse the u64 type and require the application to pass (value & UINT32_MAX) to the u64 functions. To make this easy to use, we should add some wrappers to do it for the application. And eventually we would probably end up with something very similar to this patch.
>
> Therefore, I'd tend to keep the existing u64 type as-is, and instead
> only
> add the functions for outputting hex values. Those hex output functions
> could take an additional parameter indicating the desired hex output
> length, as there could well be cases where we want just 16-bit hex
> value
> too.
The way I read the patch series, the hex output length is not fixed, but an u64 value of 5 will be output as 0x5, not 0x0000000000000005.
So the only benefit of having both u32_hex and u64_hex functions is to avoid type promotion from uint32_t to uint64_t on input for 32 bit values.
Instead of passing a 3rd parameter or adding u16_hex functions, we could consider just having one set of hex functions using uint64_t for the value, and rely on type promotion for 32 and 16 bit values.
^ permalink raw reply [relevance 0%]
* Re: [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-12 6:42 3% ` [PATCH V3 " Huisong Li
@ 2022-12-12 10:31 0% ` Bruce Richardson
2022-12-12 11:02 0% ` Morten Brørup
0 siblings, 1 reply; 200+ results
From: Bruce Richardson @ 2022-12-12 10:31 UTC (permalink / raw)
To: Huisong Li; +Cc: dev, mb, ciara.power, liudongdong3, huangdaode, fengchengwen
On Mon, Dec 12, 2022 at 02:42:55PM +0800, Huisong Li wrote:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion error
> or data truncation.
>
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of each
> transfer is limited. So it is necessary for 'u32' data to add usigned
> 32-bit integer type and a series of 'u32' operation APIs.
>
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
>
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
>
> --- -v3: fix a misspelling mistake in commit log. -v2: - fix ABI break
> warning. - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings.
>
I'm not convinced about adding the u32 value generically to the telemetry
lib - except in the case of having explicit function calls for u32 vs u64
hex strings. Having a u32 type doesn't gain us any space internally over a
u64 value, since all values are in a union type. Also, for output as json,
the numeric values are all output as decimal values, meaning that the value
1 appears as the same size in the output string whether it is a u32 or u64
type. Now, it may save space in a future binary output format, but even
then it still may not do so.
Therefore, I'd tend to keep the existing u64 type as-is, and instead only
add the functions for outputting hex values. Those hex output functions
could take an additional parameter indicating the desired hex output
length, as there could well be cases where we want just 16-bit hex value
too.
/Bruce
^ permalink raw reply [relevance 0%]
* [PATCH V3 00/11] telemetry: add u32 value type and hex integer string API
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
@ 2022-12-12 6:42 3% ` Huisong Li
2022-12-12 10:31 0% ` Bruce Richardson
2022-12-13 10:15 3% ` [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API Huisong Li
` (4 subsequent siblings)
6 siblings, 1 reply; 200+ results
From: Huisong Li @ 2022-12-12 6:42 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, ciara.power, liudongdong3, huangdaode,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation.
The 'u32' data can not be assigned to signed 32-bit integer. However,
assigning to u64 is very wasteful, after all, the buffer capacity of
each transfer is limited. So it is necessary for 'u32' data to add
usigned 32-bit integer type and a series of 'u32' operation APIs.
This patchset uses the new 'u32' API to resolve the problem of data
conversion error, and use the 'u64' API to add 'u64' data.
In addition, this patchset introduces two APIs to store u32 and u64
values as hexadecimal encoded strings in telemetry library.
---
-v3: fix a misspelling mistake in commit log.
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (11):
telemetry: move to header to controllable range
telemetry: add u32 value type
test: add test cases for adding u32 value API
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: refactor mapping betwween value and array type
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer values API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 249 ++++++++++++++++++++++++++++-
app/test/test_telemetry_json.c | 23 ++-
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 14 +-
lib/ethdev/rte_ethdev.c | 13 +-
lib/mempool/rte_mempool.c | 24 +--
lib/telemetry/rte_telemetry.h | 112 ++++++++++++-
lib/telemetry/telemetry.c | 25 ++-
lib/telemetry/telemetry_data.c | 122 ++++++++++++--
lib/telemetry/telemetry_data.h | 2 +
lib/telemetry/telemetry_json.h | 29 ++++
lib/telemetry/version.map | 14 ++
12 files changed, 581 insertions(+), 48 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* Re: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
2022-12-09 18:24 0% ` Morten Brørup
@ 2022-12-12 6:23 0% ` lihuisong (C)
0 siblings, 0 replies; 200+ results
From: lihuisong (C) @ 2022-12-12 6:23 UTC (permalink / raw)
To: Morten Brørup, dev
Cc: bruce.richardson, ciara.power, liudongdong3, huangdaode, fengchengwen
在 2022/12/10 2:24, Morten Brørup 写道:
>> From: Huisong Li [mailto:lihuisong@huawei.com]
>> Sent: Friday, 9 December 2022 12.05
>>
>> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
>> rte_tel_data_add_dict/array_int API. This may cause data conversion
>> error or data truncation.
>>
>> The 'u32' data can not be assigned to signed 32-bit integer. However,
>> assigning to u64 is very wasteful, after all, the buffer capacity of
>> each transfer is limited. So it is necessary for 'u32' data to add
>> usigned 32-bit integer type and a series of 'u32' operation APIs.
>>
>> This patchset uses the new 'u32' API to resolve the problem of data
>> conversion error, and use the 'u64' API to add 'u64' data.
>>
>> In addition, this patchset introduces two APIs to store u32 and u64
>> values as hexadecimal encoded strings in telemetry library.
>>
>> ---
>> -v2:
>> - fix ABI break warning.
>> - introduce two APIs to store u32 and u64 values as hexadecimal
>> encoded strings.
> Looks good.
>
> Personally, I would prefer rte_tel_data_add_{dict|array}_u32_hex() over _hex_u32_str(), and similar for u64; but it is a matter of taste, so feel free to change or keep your own suggested names.
I think this name can represent the type of value stored in dict or
array.😁
>
> In the eal_common_memory.c patch, in rte_tel_data_add_dict_u32(d, "Head id", heap_id);, consider fixing the old typo too, it should be "Heap_id", not "Head id". On the other hand, it will change the JSON output, so perhaps it will be considered an API breakage?
Yes, you are right. I'll try fix it in another patch.
>
>
> Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
>
>
> .
^ permalink raw reply [relevance 0%]
* Re: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
2022-12-09 18:24 0% ` Morten Brørup
@ 2022-12-11 9:02 0% ` fengchengwen
1 sibling, 0 replies; 200+ results
From: fengchengwen @ 2022-12-11 9:02 UTC (permalink / raw)
To: Huisong Li, dev
Cc: bruce.richardson, mb, ciara.power, liudongdong3, huangdaode
LGTM
Series-acked-by: Chengwen Feng <fengchengwen@huawei.com>
On 2022/12/9 19:04, Huisong Li wrote:
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation.
>
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of
> each transfer is limited. So it is necessary for 'u32' data to add
> usigned 32-bit integer type and a series of 'u32' operation APIs.
>
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
>
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
>
> ---
> -v2:
> - fix ABI break warning.
> - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings.
>
> Huisong Li (11):
> telemetry: move to header to controllable range
> telemetry: add u32 value type
> test: add test cases for adding u32 value API
> ethdev: fix possible data truncation and conversion error
> mempool: fix possible data truncation and conversion error
> cryptodev: fix possible data conversion error
> mem: possible data truncation and conversion error
> telemetry: refactor mapping betwween value and array type
> telemetry: support adding integer value as hexadecimal
> test: add test cases for adding hex integer values API
> ethdev: display capability values in hexadecimal format
>
> app/test/test_telemetry_data.c | 249 ++++++++++++++++++++++++++++-
> app/test/test_telemetry_json.c | 23 ++-
> lib/cryptodev/rte_cryptodev.c | 2 +-
> lib/eal/common/eal_common_memory.c | 14 +-
> lib/ethdev/rte_ethdev.c | 13 +-
> lib/mempool/rte_mempool.c | 24 +--
> lib/telemetry/rte_telemetry.h | 112 ++++++++++++-
> lib/telemetry/telemetry.c | 25 ++-
> lib/telemetry/telemetry_data.c | 122 ++++++++++++--
> lib/telemetry/telemetry_data.h | 2 +
> lib/telemetry/telemetry_json.h | 29 ++++
> lib/telemetry/version.map | 14 ++
> 12 files changed, 581 insertions(+), 48 deletions(-)
>
^ permalink raw reply [relevance 0%]
* Re: help with pthread_t deprecation / api changes
2022-12-09 22:38 0% ` Stephen Hemminger
@ 2022-12-09 23:55 0% ` Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-09 23:55 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Monjalon, Morten Brørup, dev, david.marchand,
Bruce Richardson
On Fri, Dec 09, 2022 at 02:38:49PM -0800, Stephen Hemminger wrote:
> On Fri, 09 Dec 2022 22:14:33 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > 09/12/2022 17:48, Stephen Hemminger:
> > > On Fri, 09 Dec 2022 08:53:57 +0100
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> > > > >
> > > > > i think this raises a good question. is the purpose of setting a thread name
> > > > > meant to be something we can use from the application or is it something that
> > > > > is for debugging diagnostics and may be a best effort?
> > > >
> > > > I think yes it is only for debugging.
> > > > So best effort looks to be a good approach.
> > > > I'm not sure you need to replace the functions.
> > > > Can you just complete the implementations?
> > >
> > >
> > > Surprisingly, thread names are not preserved in core dumps.
> > > The core dump standard used by Linux does not put thread name in the image.
> > > Since this is a ELF ABI unlikely to be ever be added.
> >
> > What is missing exactly to have thread name in the core dump?
> >
> >
>
> Linux core dump file format is ELF.
> The thread info is storewd in the file notes as NT_PRPSINFO
> which contains info but not the thread name. In the kernel
> thread name is under comm.
>
>
> typedef struct prpsinfo { /* Information about process */
> unsigned char pr_state; /* Numeric process state */
> char pr_sname; /* Char for pr_state */
> unsigned char pr_zomb; /* Zombie */
> signed char pr_nice; /* Nice val */
> unsigned long pr_flag; /* Flags */
>
> uint32_t pr_uid; /* User ID */
> uint32_t pr_gid; /* Group ID */
>
> pid_t pr_pid; /* Process ID */
> pid_t pr_ppid; /* Parent's process ID */
> pid_t pr_pgrp; /* Group ID */
> pid_t pr_sid; /* Session ID */
> char pr_fname[16]; /* Filename of executable */
> char pr_psargs[80]; /* Initial part of arg list */
> } prpsinfo;
>
>
> Stack Overflow leads to this pages
> https://www.gabriel.urdhr.fr/2015/05/29/core-file/
> https://uhlo.blogspot.com/2012/05/brief-look-into-core-dumps.html
>
> Only know this because of investigating how to get thread names
> to show up in Azure with Watson.
from a dpdk specific perspective if we want to consistently have a
thread name in a dump / coredump then we have a better chance of
success just storing it in our applications namespace ourselves.
relying on platform-specific facilities to preserve it seems hit and
miss at best.
^ permalink raw reply [relevance 0%]
* Re: help with pthread_t deprecation / api changes
2022-12-09 21:14 0% ` Thomas Monjalon
@ 2022-12-09 22:38 0% ` Stephen Hemminger
2022-12-09 23:55 0% ` Tyler Retzlaff
0 siblings, 1 reply; 200+ results
From: Stephen Hemminger @ 2022-12-09 22:38 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Tyler Retzlaff, Morten Brørup, dev, david.marchand,
Bruce Richardson
On Fri, 09 Dec 2022 22:14:33 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:
> 09/12/2022 17:48, Stephen Hemminger:
> > On Fri, 09 Dec 2022 08:53:57 +0100
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> > > >
> > > > i think this raises a good question. is the purpose of setting a thread name
> > > > meant to be something we can use from the application or is it something that
> > > > is for debugging diagnostics and may be a best effort?
> > >
> > > I think yes it is only for debugging.
> > > So best effort looks to be a good approach.
> > > I'm not sure you need to replace the functions.
> > > Can you just complete the implementations?
> >
> >
> > Surprisingly, thread names are not preserved in core dumps.
> > The core dump standard used by Linux does not put thread name in the image.
> > Since this is a ELF ABI unlikely to be ever be added.
>
> What is missing exactly to have thread name in the core dump?
>
>
Linux core dump file format is ELF.
The thread info is storewd in the file notes as NT_PRPSINFO
which contains info but not the thread name. In the kernel
thread name is under comm.
typedef struct prpsinfo { /* Information about process */
unsigned char pr_state; /* Numeric process state */
char pr_sname; /* Char for pr_state */
unsigned char pr_zomb; /* Zombie */
signed char pr_nice; /* Nice val */
unsigned long pr_flag; /* Flags */
uint32_t pr_uid; /* User ID */
uint32_t pr_gid; /* Group ID */
pid_t pr_pid; /* Process ID */
pid_t pr_ppid; /* Parent's process ID */
pid_t pr_pgrp; /* Group ID */
pid_t pr_sid; /* Session ID */
char pr_fname[16]; /* Filename of executable */
char pr_psargs[80]; /* Initial part of arg list */
} prpsinfo;
Stack Overflow leads to this pages
https://www.gabriel.urdhr.fr/2015/05/29/core-file/
https://uhlo.blogspot.com/2012/05/brief-look-into-core-dumps.html
Only know this because of investigating how to get thread names
to show up in Azure with Watson.
^ permalink raw reply [relevance 0%]
* Re: help with pthread_t deprecation / api changes
2022-12-09 16:48 3% ` Stephen Hemminger
2022-12-09 20:06 0% ` Tyler Retzlaff
@ 2022-12-09 21:14 0% ` Thomas Monjalon
2022-12-09 22:38 0% ` Stephen Hemminger
1 sibling, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-09 21:14 UTC (permalink / raw)
To: Stephen Hemminger, Tyler Retzlaff
Cc: Morten Brørup, dev, david.marchand, Bruce Richardson
09/12/2022 17:48, Stephen Hemminger:
> On Fri, 09 Dec 2022 08:53:57 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> > >
> > > i think this raises a good question. is the purpose of setting a thread name
> > > meant to be something we can use from the application or is it something that
> > > is for debugging diagnostics and may be a best effort?
> >
> > I think yes it is only for debugging.
> > So best effort looks to be a good approach.
> > I'm not sure you need to replace the functions.
> > Can you just complete the implementations?
>
>
> Surprisingly, thread names are not preserved in core dumps.
> The core dump standard used by Linux does not put thread name in the image.
> Since this is a ELF ABI unlikely to be ever be added.
What is missing exactly to have thread name in the core dump?
^ permalink raw reply [relevance 0%]
* Re: help with pthread_t deprecation / api changes
2022-12-09 16:48 3% ` Stephen Hemminger
@ 2022-12-09 20:06 0% ` Tyler Retzlaff
2022-12-09 21:14 0% ` Thomas Monjalon
1 sibling, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-09 20:06 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Monjalon, Morten Brørup, dev, david.marchand,
Bruce Richardson
hey,
combining the reply to both Thomas and Stephen since i think this series
http://mails.dpdk.org/archives/dev/2022-December/257238.html addresses
both feedback comments.
On Fri, Dec 09, 2022 at 08:48:14AM -0800, Stephen Hemminger wrote:
> On Fri, 09 Dec 2022 08:53:57 +0100
> Thomas Monjalon <thomas@monjalon.net> wrote:
>
> > > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> > >
> > > i think this raises a good question. is the purpose of setting a thread name
> > > meant to be something we can use from the application or is it something that
> > > is for debugging diagnostics and may be a best effort?
> >
> Thomas Monjalon <thomas@monjalon.net> wrote:
> I think yes it is only for debugging.
> So best effort looks to be a good approach.
> I'm not sure you need to replace the functions.
> Can you just complete the implementations?
the patch series put forward allows a set / get name per-lcore, where
you get implicit (but not exposed via the eal api) call to underlying
platform thread setname.
the intent here is if you have it and it works you'll get it and if you
don't you won't but the eal doesn't force the application to deal with it
conditionally on a per-platform basis.
> Stephen wrote:
>
> Surprisingly, thread names are not preserved in core dumps.
> The core dump standard used by Linux does not put thread name in the image.
> Since this is a ELF ABI unlikely to be ever be added.
the patchset addresses this by actually keeping a copy of the name set,
so it will be available in the coredump.
the intent here is to make it available for use by the application i.e.
get that works on all platforms, but also you can actually pull the name
out under a debugger or a dump and does not require any conditional
dancing per-platform by the application.
as an aside there are 2 series up for review that finally clean the
remaining platform-specific thread references from the eal public
interface.
http://mails.dpdk.org/archives/dev/2022-December/257238.html
http://mails.dpdk.org/archives/dev/2022-December/257413.html
the set get name api patch series i'm preparing a v2 for due to some
minor things caught by the ci and an issue with mingw but otherwise if
we can get these in it will unblock a lot of the internal detail
cleanups we've been trying to accomplish.
really appreciate it guys.
thanks.
^ permalink raw reply [relevance 0%]
* RE: [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
@ 2022-12-09 18:24 0% ` Morten Brørup
2022-12-12 6:23 0% ` lihuisong (C)
2022-12-11 9:02 0% ` fengchengwen
1 sibling, 1 reply; 200+ results
From: Morten Brørup @ 2022-12-09 18:24 UTC (permalink / raw)
To: Huisong Li, dev
Cc: bruce.richardson, ciara.power, liudongdong3, huangdaode, fengchengwen
> From: Huisong Li [mailto:lihuisong@huawei.com]
> Sent: Friday, 9 December 2022 12.05
>
> Some lib telemetry interfaces add the 'u32' and 'u64' data by the
> rte_tel_data_add_dict/array_int API. This may cause data conversion
> error or data truncation.
>
> The 'u32' data can not be assigned to signed 32-bit integer. However,
> assigning to u64 is very wasteful, after all, the buffer capacity of
> each transfer is limited. So it is necessary for 'u32' data to add
> usigned 32-bit integer type and a series of 'u32' operation APIs.
>
> This patchset uses the new 'u32' API to resolve the problem of data
> conversion error, and use the 'u64' API to add 'u64' data.
>
> In addition, this patchset introduces two APIs to store u32 and u64
> values as hexadecimal encoded strings in telemetry library.
>
> ---
> -v2:
> - fix ABI break warning.
> - introduce two APIs to store u32 and u64 values as hexadecimal
> encoded strings.
Looks good.
Personally, I would prefer rte_tel_data_add_{dict|array}_u32_hex() over _hex_u32_str(), and similar for u64; but it is a matter of taste, so feel free to change or keep your own suggested names.
In the eal_common_memory.c patch, in rte_tel_data_add_dict_u32(d, "Head id", heap_id);, consider fixing the old typo too, it should be "Heap_id", not "Head id". On the other hand, it will change the JSON output, so perhaps it will be considered an API breakage?
Series-acked-by: Morten Brørup <mb@smartsharesystems.com>
^ permalink raw reply [relevance 0%]
* Re: help with pthread_t deprecation / api changes
@ 2022-12-09 16:48 3% ` Stephen Hemminger
2022-12-09 20:06 0% ` Tyler Retzlaff
2022-12-09 21:14 0% ` Thomas Monjalon
0 siblings, 2 replies; 200+ results
From: Stephen Hemminger @ 2022-12-09 16:48 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Morten Brørup, Tyler Retzlaff, dev, david.marchand,
Bruce Richardson
On Fri, 09 Dec 2022 08:53:57 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:
> > > If some execution environment doesn't support thread names, it could return a string that makes it possible for a human to identify the thread, e.g. the tread id. Again, this is assuming that it is only used for debugging, trace, and similar.
> >
> > i think this raises a good question. is the purpose of setting a thread name
> > meant to be something we can use from the application or is it something that
> > is for debugging diagnostics and may be a best effort?
>
> I think yes it is only for debugging.
> So best effort looks to be a good approach.
> I'm not sure you need to replace the functions.
> Can you just complete the implementations?
Surprisingly, thread names are not preserved in core dumps.
The core dump standard used by Linux does not put thread name in the image.
Since this is a ELF ABI unlikely to be ever be added.
^ permalink raw reply [relevance 3%]
* [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API
@ 2022-12-09 11:04 3% ` Huisong Li
2022-12-09 18:24 0% ` Morten Brørup
2022-12-11 9:02 0% ` fengchengwen
2022-12-12 6:42 3% ` [PATCH V3 " Huisong Li
` (5 subsequent siblings)
6 siblings, 2 replies; 200+ results
From: Huisong Li @ 2022-12-09 11:04 UTC (permalink / raw)
To: dev
Cc: bruce.richardson, mb, ciara.power, liudongdong3, huangdaode,
fengchengwen, lihuisong
Some lib telemetry interfaces add the 'u32' and 'u64' data by the
rte_tel_data_add_dict/array_int API. This may cause data conversion
error or data truncation.
The 'u32' data can not be assigned to signed 32-bit integer. However,
assigning to u64 is very wasteful, after all, the buffer capacity of
each transfer is limited. So it is necessary for 'u32' data to add
usigned 32-bit integer type and a series of 'u32' operation APIs.
This patchset uses the new 'u32' API to resolve the problem of data
conversion error, and use the 'u64' API to add 'u64' data.
In addition, this patchset introduces two APIs to store u32 and u64
values as hexadecimal encoded strings in telemetry library.
---
-v2:
- fix ABI break warning.
- introduce two APIs to store u32 and u64 values as hexadecimal
encoded strings.
Huisong Li (11):
telemetry: move to header to controllable range
telemetry: add u32 value type
test: add test cases for adding u32 value API
ethdev: fix possible data truncation and conversion error
mempool: fix possible data truncation and conversion error
cryptodev: fix possible data conversion error
mem: possible data truncation and conversion error
telemetry: refactor mapping betwween value and array type
telemetry: support adding integer value as hexadecimal
test: add test cases for adding hex integer values API
ethdev: display capability values in hexadecimal format
app/test/test_telemetry_data.c | 249 ++++++++++++++++++++++++++++-
app/test/test_telemetry_json.c | 23 ++-
lib/cryptodev/rte_cryptodev.c | 2 +-
lib/eal/common/eal_common_memory.c | 14 +-
lib/ethdev/rte_ethdev.c | 13 +-
lib/mempool/rte_mempool.c | 24 +--
lib/telemetry/rte_telemetry.h | 112 ++++++++++++-
lib/telemetry/telemetry.c | 25 ++-
lib/telemetry/telemetry_data.c | 122 ++++++++++++--
lib/telemetry/telemetry_data.h | 2 +
lib/telemetry/telemetry_json.h | 29 ++++
lib/telemetry/version.map | 14 ++
12 files changed, 581 insertions(+), 48 deletions(-)
--
2.33.0
^ permalink raw reply [relevance 3%]
* [PATCH v2 2/2] devtools: configure source repo to use as ABI reference
@ 2022-12-09 9:02 13% ` David Marchand
2022-12-21 15:02 4% ` David Marchand
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-12-09 9:02 UTC (permalink / raw)
To: dev; +Cc: thomas, bruce.richardson, gakhil, Ferruh Yigit
From: Ferruh Yigit <ferruh.yigit@amd.com>
By default 'test-meson-builds.sh' script clones the repository which the
script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
as a reference for ABI check.
This patch enables selecting different repository to clone for reference
using 'DPDK_ABI_REF_SRC' environment variable.
'DPDK_ABI_REF_SRC' may refer to a directory containing a cloned git
repository, or a remote git repository.
It is possible to put these variables to 'devel.config' config file, or
provide via command line, like:
`
DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable \
DPDK_ABI_REF_VERSION=v22.11.1 \
DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
./devtools/test-meson-builds.sh
`
When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
previously.
Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
other repo as a new 'remote' to the exiting git repository.
Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
Acked-by: Akhil Goyal <gakhil@marvell.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>
---
Changes since v1:
- expanded DPDK_ABI_REF_SRC usage to "non-local" sources,
---
devtools/test-meson-builds.sh | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 02541c19aa..48f4e52df3 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -19,6 +19,7 @@ srcdir=$(dirname $(readlink -f $0))/..
# - DPDK_MESON_OPTIONS
#
# - DPDK_ABI_REF_DIR
+# - DPDK_ABI_REF_SRC
# - DPDK_ABI_REF_VERSION
#
# - DPDK_BUILD_TEST_EXAMPLES
@@ -187,10 +188,15 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
if [ ! -d $abirefdir/$targetdir ]; then
# clone current sources
if [ ! -d $abirefdir/src ]; then
- git clone --local --no-hardlinks \
+ abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
+ abirefcloneopts=
+ if [ -d $abirefsrc ]; then
+ abirefcloneopts="--local --no-hardlinks"
+ fi
+ git clone $abirefcloneopts \
--single-branch \
-b $DPDK_ABI_REF_VERSION \
- $srcdir $abirefdir/src
+ $abirefsrc $abirefdir/src
fi
rm -rf $abirefdir/build
--
2.38.1
^ permalink raw reply [relevance 13%]
* Re: [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-09 8:22 8% ` David Marchand
@ 2022-12-09 8:44 4% ` Ferruh Yigit
0 siblings, 0 replies; 200+ results
From: Ferruh Yigit @ 2022-12-09 8:44 UTC (permalink / raw)
To: David Marchand; +Cc: Thomas Monjalon, Bruce Richardson, dev, Akhil Goyal
On 12/9/2022 8:22 AM, David Marchand wrote:
> On Tue, Dec 6, 2022 at 1:24 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>>
>> By default 'test-meson-builds.sh' script clones the repository which the
>> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
>> as a reference for ABI check.
>>
>> This patch enables selecting different repository to close for reference
>> using 'DPDK_ABI_REF_SRC' environment variable.
>>
>> It is possible to put these variables to 'devel.config' config file, or
>> provide via command line, like:
>> `
>> DPDK_ABI_REF_SRC=~/dpdk-stable/ \
>
> DPDK_ABI_REF_SRC could be passed as a remote repository.
> This should remove the need for any "git remote" configuration.
>
> $ DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable
> DPDK_ABI_REF_VERSION=v22.11.1 ./devtools/test-meson-builds.sh
>
+1 to 'DPDK_ABI_REF_SRC' accept either folder or remote git repo.
Can you send a v2 with your sign off added, or do you want me send a v2?
>
> diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
> index 406bf4e184..48f4e52df3 100755
> --- a/devtools/test-meson-builds.sh
> +++ b/devtools/test-meson-builds.sh
> @@ -18,8 +18,8 @@ srcdir=$(dirname $(readlink -f $0))/..
> #
> # - DPDK_MESON_OPTIONS
> #
> -# - DPDK_ABI_REF_SRC
> # - DPDK_ABI_REF_DIR
> +# - DPDK_ABI_REF_SRC
> # - DPDK_ABI_REF_VERSION
> #
> # - DPDK_BUILD_TEST_EXAMPLES
> @@ -186,10 +186,14 @@ build () # <directory> <target cc | cross file>
> <ABI check> [meson options]
> if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
> abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
> if [ ! -d $abirefdir/$targetdir ]; then
> - abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
> # clone current sources
> if [ ! -d $abirefdir/src ]; then
> - git clone --local --no-hardlinks \
> + abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
> + abirefcloneopts=
> + if [ -d $abirefsrc ]; then
> + abirefcloneopts="--local --no-hardlinks"
> + fi
> + git clone $abirefcloneopts \
> --single-branch \
> -b $DPDK_ABI_REF_VERSION \
> $abirefsrc $abirefdir/src
>
>
>> DPDK_ABI_REF_VERSION=v22.11.1 \
>> DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
>> ./devtools/test-meson-builds.sh
>> `
>>
>> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
>> previously.
>>
>> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
>> other repo as a new 'remote' to the exiting git repository.
>
>
>
^ permalink raw reply [relevance 4%]
* Re: [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-06 12:23 17% ` [PATCH 2/2] devtools: configure source repo to use as ABI reference Ferruh Yigit
2022-12-08 18:14 7% ` [EXT] " Akhil Goyal
@ 2022-12-09 8:22 8% ` David Marchand
2022-12-09 8:44 4% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: David Marchand @ 2022-12-09 8:22 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Thomas Monjalon, Bruce Richardson, dev, Akhil Goyal
On Tue, Dec 6, 2022 at 1:24 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> By default 'test-meson-builds.sh' script clones the repository which the
> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> as a reference for ABI check.
>
> This patch enables selecting different repository to close for reference
> using 'DPDK_ABI_REF_SRC' environment variable.
>
> It is possible to put these variables to 'devel.config' config file, or
> provide via command line, like:
> `
> DPDK_ABI_REF_SRC=~/dpdk-stable/ \
DPDK_ABI_REF_SRC could be passed as a remote repository.
This should remove the need for any "git remote" configuration.
$ DPDK_ABI_REF_SRC=https://dpdk.org/git/dpdk-stable
DPDK_ABI_REF_VERSION=v22.11.1 ./devtools/test-meson-builds.sh
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 406bf4e184..48f4e52df3 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -18,8 +18,8 @@ srcdir=$(dirname $(readlink -f $0))/..
#
# - DPDK_MESON_OPTIONS
#
-# - DPDK_ABI_REF_SRC
# - DPDK_ABI_REF_DIR
+# - DPDK_ABI_REF_SRC
# - DPDK_ABI_REF_VERSION
#
# - DPDK_BUILD_TEST_EXAMPLES
@@ -186,10 +186,14 @@ build () # <directory> <target cc | cross file>
<ABI check> [meson options]
if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
if [ ! -d $abirefdir/$targetdir ]; then
- abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
# clone current sources
if [ ! -d $abirefdir/src ]; then
- git clone --local --no-hardlinks \
+ abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
+ abirefcloneopts=
+ if [ -d $abirefsrc ]; then
+ abirefcloneopts="--local --no-hardlinks"
+ fi
+ git clone $abirefcloneopts \
--single-branch \
-b $DPDK_ABI_REF_VERSION \
$abirefsrc $abirefdir/src
> DPDK_ABI_REF_VERSION=v22.11.1 \
> DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> ./devtools/test-meson-builds.sh
> `
>
> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> previously.
>
> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> other repo as a new 'remote' to the exiting git repository.
--
David Marchand
^ permalink raw reply [relevance 8%]
* RE: [EXT] [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-08 19:43 4% ` Thomas Monjalon
@ 2022-12-09 4:16 4% ` Akhil Goyal
0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2022-12-09 4:16 UTC (permalink / raw)
To: Thomas Monjalon, Ferruh Yigit, Bruce Richardson; +Cc: David Marchand, dev
> 08/12/2022 19:14, Akhil Goyal:
> > > By default 'test-meson-builds.sh' script clones the repository which the
> > > script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> > > as a reference for ABI check.
> > >
> > > This patch enables selecting different repository to close for reference
> > > using 'DPDK_ABI_REF_SRC' environment variable.
> > >
> > > It is possible to put these variables to 'devel.config' config file, or
> > > provide via command line, like:
> > > `
> > > DPDK_ABI_REF_SRC=~/dpdk-stable/ \
> > > DPDK_ABI_REF_VERSION=v22.11.1 \
> > > DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> > > ./devtools/test-meson-builds.sh
> > > `
> > >
> > > When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> > > previously.
> > >
> > > Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> > > other repo as a new 'remote' to the exiting git repository.
> > >
> > > Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > > ---
> >
> > Acked-by: Akhil Goyal <gakhil@marvell.com>
> >
> > Worked for me, but I still needed to clone the dpdk-stable repo manually.
> > I was hoping, test-meson-build.sh would do that by itself.
> > Had it been a tag in same repo, it would have been straight forward as before.
> > I would still suggest to add a tag v22.11.1 in main branch and all can use that
> instead of v22.11.
>
> First, v22.11.1 exists already in dpdk-stable.
> Second, vXX.YY.z tags are supposed to be only in dpdk-stable.
May be some other tag name we can think. v22.11.hotfix or something better.
I was just asking to give a name to commit, and NOT updating the VERSION file.
>
> > The fix that we are talking about is a mandatory one for each one to use for
> ABI checks,
> > dpdk-stable patches are not mandatory for the users.
>
> You could have dpdk-stable as a remote in your main DPDK directory.
> If you don't want to do that, you could refer to the commit SHA1 of the fix I
> think.
>
Adding remote did not solve the issue as the commits are different(version commit).
I cloned stable repo separately and it worked for me.
Since you refer to use commit SHA, why not give it a name, remembering SHA is not easy.
-Akhil
^ permalink raw reply [relevance 4%]
* Re: [PATCH v2 1/3] eal: add rte control thread create API
2022-12-07 16:38 3% ` Tyler Retzlaff
@ 2022-12-08 21:59 0% ` Mattias Rönnblom
0 siblings, 0 replies; 200+ results
From: Mattias Rönnblom @ 2022-12-08 21:59 UTC (permalink / raw)
To: Tyler Retzlaff; +Cc: dev, thomas, david.marchand, stephen, olivier.matz, mb
On 2022-12-07 17:38, Tyler Retzlaff wrote:
> On Wed, Dec 07, 2022 at 10:13:39AM +0100, Mattias Rönnblom wrote:
>> On 2022-12-06 18:28, Tyler Retzlaff wrote:
>>> Add rte_control_thread_create API as a replacement for
>>> rte_ctrl_thread_create to allow deprecation of the use of platform
>>> specific types in DPDK public API.
>>>
>>> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>>> ---
>>> lib/eal/common/eal_common_thread.c | 93 ++++++++++++++++++++++++++++++++++----
>>> lib/eal/include/rte_thread.h | 29 ++++++++++++
>>> lib/eal/version.map | 3 ++
>>> 3 files changed, 117 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/lib/eal/common/eal_common_thread.c b/lib/eal/common/eal_common_thread.c
>>> index c5d8b43..7950b50 100644
>>> --- a/lib/eal/common/eal_common_thread.c
>>> +++ b/lib/eal/common/eal_common_thread.c
>>> @@ -234,7 +234,10 @@ enum __rte_ctrl_thread_status {
>>> };
>>> struct rte_thread_ctrl_params {
>>> - void *(*start_routine)(void *);
>>> + union {
>>> + void *(*start_routine)(void *);
>>> + rte_thread_func thread_func;
>>
>> To be consistent with function naming scheme, where "ctrl" is the
>> old API, and "control" the new, you could call the start functions
>> something with "ctrl" and "control" as well.
>
> i'll make this change in v3.
>
>>
>> Maybe it's worth mentioning that fact somewhere in the beginning of
>> the file, as a comment (i.e., that "ctrl" denotes the old API).
>
> i'll make this change in v3.
>
>>
>>> + } u;
>>> void *arg;
>>> int ret;
>>
>> Why is 'ret' needed? (This question is unrelated to your patch.)
>
> i'm not the original author so difficult to answer authoritatively. but
> if i have to speculate i'd say it might be to work around the windows
> pthread_join stub being implemented as a noop. specifically it didn't
> communicate the return value from the start_routine.
>
> the recently added rte_thread_join addresses this (which
> rte_control_thread_create uses) and could remove ret parameter and to
> avoid touching the new function implementation in the future it can not
> use ret now.
>
> i'll make this change in v3.
>
> for the original function i will leave the code as is to minimize the
> diff. when rte_ctrl_thread_create is removed i'll make a note to
> eliminate the ret parameter as well.
>
I would focus on minimizing the complexity of the end result, rather
than the size of the patch.
>>
>>> /* Control thread status.
>>> @@ -243,14 +246,12 @@ struct rte_thread_ctrl_params {
>>> enum __rte_ctrl_thread_status ctrl_thread_status;
>>> };
>>> -static void *ctrl_thread_init(void *arg)
>>> +static int ctrl_thread_init(void *arg)
>>> {
>>> struct internal_config *internal_conf =
>>> eal_get_internal_configuration();
>>> rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
>>> struct rte_thread_ctrl_params *params = arg;
>>> - void *(*start_routine)(void *) = params->start_routine;
>>> - void *routine_arg = params->arg;
>>> __rte_thread_init(rte_lcore_id(), cpuset);
>>> params->ret = pthread_setaffinity_np(pthread_self(), sizeof(*cpuset),
>>> @@ -258,13 +259,35 @@ static void *ctrl_thread_init(void *arg)
>>> if (params->ret != 0) {
>>> __atomic_store_n(¶ms->ctrl_thread_status,
>>> CTRL_THREAD_ERROR, __ATOMIC_RELEASE);
>>> - return NULL;
>>> + return params->ret;
>>> }
>>> __atomic_store_n(¶ms->ctrl_thread_status,
>>> CTRL_THREAD_RUNNING, __ATOMIC_RELEASE);
>>> - return start_routine(routine_arg);
>>> + return 0;
>>> +}
>>> +
>>> +static void *ctrl_thread_start(void *arg)
>>> +{
>>> + struct rte_thread_ctrl_params *params = arg;
>>> + void *(*start_routine)(void *) = params->u.start_routine;
>>> +
>>> + if (ctrl_thread_init(arg) != 0)
>>> + return NULL;
>>> +
>>> + return start_routine(params->arg);
>>> +}
>>> +
>>> +static uint32_t control_thread_start(void *arg)
>>> +{
>>> + struct rte_thread_ctrl_params *params = arg;
>>> + rte_thread_func start_routine = params->u.thread_func;
>>> +
>>> + if (ctrl_thread_init(arg) != 0)
>>> + return params->ret;
>>> +
>>> + return start_routine(params->arg);
>>> }
>>> int
>>> @@ -280,12 +303,12 @@ static void *ctrl_thread_init(void *arg)
>>> if (!params)
>>> return -ENOMEM;
>>> - params->start_routine = start_routine;
>>> + params->u.start_routine = start_routine;
>>> params->arg = arg;
>>> params->ret = 0;
>>> params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
>>> - ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
>>> + ret = pthread_create(thread, attr, ctrl_thread_start, (void *)params);
>>> if (ret != 0) {
>>> free(params);
>>> return -ret;
>>> @@ -322,6 +345,60 @@ static void *ctrl_thread_init(void *arg)
>>> }
>>> int
>>> +rte_control_thread_create(rte_thread_t *thread, const char *name,
>>> + const rte_thread_attr_t *attr,
>>> + rte_thread_func start_routine, void *arg)
>>> +{
>>> + struct rte_thread_ctrl_params *params;
>>> + enum __rte_ctrl_thread_status ctrl_thread_status;
>>> + int ret;
>>> +
>>> + params = malloc(sizeof(*params));
>>> + if (!params)
>>
>> params == NULL
>
> copied from original code, i'll fix the style in the new function to
> comply with the dpdk coding standard.
>
> i'll fix in v3.
>
>>
>>> + return -ENOMEM;
>>> +
>>> + params->u.thread_func = start_routine;
>>> + params->arg = arg;
>>> + params->ret = 0;
>>> + params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
>>> +
>>> + ret = rte_thread_create(thread, attr, control_thread_start, params);
>>> + if (ret != 0) {
>>> + free(params);
>>> + return -ret;
>>> + }
>>> +
>>> + if (name != NULL) {
>>> + ret = rte_thread_setname((pthread_t)thread->opaque_id, name);
>>> + if (ret < 0)
>>> + RTE_LOG(DEBUG, EAL,
>>> + "Cannot set name for ctrl thread\n");
>>> + }
>>> +
>>> + /* Wait for the control thread to initialize successfully */
>>> + while ((ctrl_thread_status =
>>> + __atomic_load_n(¶ms->ctrl_thread_status,
>>> + __ATOMIC_ACQUIRE)) == CTRL_THREAD_LAUNCHING) {
>>> + /* Yield the CPU. Using sched_yield call requires maintaining
>>> + * another implementation for Windows as sched_yield is not
>>> + * supported on Windows.
>>> + */
>>
>> sched_yield() also doesn't necessarily yield the CPU.
>
> copied from original code and understood, but are you requesting a
> change here or just a comment correction? can you offer wording you
> would find suitable?
>
I would just remove the comment.
"Yield the CPU. sched_yield() may seem like a natural choice here, but
does not guarantee that a context switch will actually occur, and also
does not exist on Windows."
>>
>>> + rte_delay_us_sleep(1);
>>> + }
>>> +
>>> + /* Check if the control thread encountered an error */
>>> + if (ctrl_thread_status == CTRL_THREAD_ERROR) {
>>> + /* ctrl thread is exiting */
>>> + rte_thread_join(*thread, NULL);
>>> + }
>>> +
>>> + ret = params->ret;
>>> + free(params);
>>> +
>>> + return ret;
>>> +}
>>> +
>>> +int
>>> rte_thread_register(void)
>>> {
>>> unsigned int lcore_id;
>>> diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
>>> index b9edf70..ae7afbe 100644
>>> --- a/lib/eal/include/rte_thread.h
>>> +++ b/lib/eal/include/rte_thread.h
>>> @@ -95,6 +95,35 @@ int rte_thread_create(rte_thread_t *thread_id,
>>> rte_thread_func thread_func, void *arg);
>>> /**
>>> + * Create a control thread.
>>> + *
>>> + * Creates a control thread with the given name and attributes. The
>>> + * affinity of the new thread is based on the CPU affinity retrieved
>>> + * at the time rte_eal_init() was called, the dataplane and service
>>> + * lcores are then excluded. If setting the name of the thread fails,
>>
>> "the EAL threads are then excluded"
>
> i'll modify in v3.
>
>>
>>> + * the error is ignored and a debug message is logged.
>>> + *
>>> + * @param thread
>>> + * Filled with the thread id of the new created thread.
>>> + * @param name
>>> + * The name of the control thread (max 16 characters including '\0').
>>
>> Is there a constant for this limit?
>
> i have a series introducing rte_lcore_{set,get}_name api that introduces
> a constant (probably i'll post it today). as of this series there is no
> constant.
>
>>
>>> + * @param thread_attr
>>> + * Attributes for the new thread.
>>> + * @param thread_func
>>> + * Function to be executed by the new thread.
>>> + * @param arg
>>> + * Argument passed to start_routine.
>>> + * @return
>>> + * On success, returns 0; on error, it returns a negative value
>>> + * corresponding to the error number.
>>
>> List the possible error codes.
>
> i would like to see the range of codes be part of the api & abi i've
> received resistance to the idea. for now i'll nack this comment which
> leaves it consistent with other apis documentation.
>>
>>> + */
>>> +__rte_experimental
>>> +int
>>> +rte_control_thread_create(rte_thread_t *thread, const char *name,
>>> + const rte_thread_attr_t *thread_attr,
>>> + rte_thread_func thread_func, void *arg);
>>> +
>>> +/**
>>> * @warning
>>> * @b EXPERIMENTAL: this API may change without prior notice.
>>> *
>>> diff --git a/lib/eal/version.map b/lib/eal/version.map
>>> index 7ad12a7..8f9eeb9 100644
>>> --- a/lib/eal/version.map
>>> +++ b/lib/eal/version.map
>>> @@ -440,6 +440,9 @@ EXPERIMENTAL {
>>> rte_thread_detach;
>>> rte_thread_equal;
>>> rte_thread_join;
>>> +
>>> + # added in 23.03
>>> + rte_control_thread_create;
>>> };
>>> INTERNAL {
^ permalink raw reply [relevance 0%]
* Re: [EXT] [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-08 18:14 7% ` [EXT] " Akhil Goyal
@ 2022-12-08 19:43 4% ` Thomas Monjalon
2022-12-09 4:16 4% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-08 19:43 UTC (permalink / raw)
To: Ferruh Yigit, Bruce Richardson, Akhil Goyal; +Cc: David Marchand, dev
08/12/2022 19:14, Akhil Goyal:
> > By default 'test-meson-builds.sh' script clones the repository which the
> > script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> > as a reference for ABI check.
> >
> > This patch enables selecting different repository to close for reference
> > using 'DPDK_ABI_REF_SRC' environment variable.
> >
> > It is possible to put these variables to 'devel.config' config file, or
> > provide via command line, like:
> > `
> > DPDK_ABI_REF_SRC=~/dpdk-stable/ \
> > DPDK_ABI_REF_VERSION=v22.11.1 \
> > DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> > ./devtools/test-meson-builds.sh
> > `
> >
> > When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> > previously.
> >
> > Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> > other repo as a new 'remote' to the exiting git repository.
> >
> > Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > ---
>
> Acked-by: Akhil Goyal <gakhil@marvell.com>
>
> Worked for me, but I still needed to clone the dpdk-stable repo manually.
> I was hoping, test-meson-build.sh would do that by itself.
> Had it been a tag in same repo, it would have been straight forward as before.
> I would still suggest to add a tag v22.11.1 in main branch and all can use that instead of v22.11.
First, v22.11.1 exists already in dpdk-stable.
Second, vXX.YY.z tags are supposed to be only in dpdk-stable.
> The fix that we are talking about is a mandatory one for each one to use for ABI checks,
> dpdk-stable patches are not mandatory for the users.
You could have dpdk-stable as a remote in your main DPDK directory.
If you don't want to do that, you could refer to the commit SHA1 of the fix I think.
^ permalink raw reply [relevance 4%]
* RE: [EXT] [PATCH 2/2] devtools: configure source repo to use as ABI reference
2022-12-06 12:23 17% ` [PATCH 2/2] devtools: configure source repo to use as ABI reference Ferruh Yigit
@ 2022-12-08 18:14 7% ` Akhil Goyal
2022-12-08 19:43 4% ` Thomas Monjalon
2022-12-09 8:22 8% ` David Marchand
1 sibling, 1 reply; 200+ results
From: Akhil Goyal @ 2022-12-08 18:14 UTC (permalink / raw)
To: Ferruh Yigit, Thomas Monjalon, Bruce Richardson; +Cc: David Marchand, dev
> By default 'test-meson-builds.sh' script clones the repository which the
> script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
> as a reference for ABI check.
>
> This patch enables selecting different repository to close for reference
> using 'DPDK_ABI_REF_SRC' environment variable.
>
> It is possible to put these variables to 'devel.config' config file, or
> provide via command line, like:
> `
> DPDK_ABI_REF_SRC=~/dpdk-stable/ \
> DPDK_ABI_REF_VERSION=v22.11.1 \
> DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
> ./devtools/test-meson-builds.sh
> `
>
> When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
> previously.
>
> Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
> other repo as a new 'remote' to the exiting git repository.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
> ---
Acked-by: Akhil Goyal <gakhil@marvell.com>
Worked for me, but I still needed to clone the dpdk-stable repo manually.
I was hoping, test-meson-build.sh would do that by itself.
Had it been a tag in same repo, it would have been straight forward as before.
I would still suggest to add a tag v22.11.1 in main branch and all can use that instead of v22.11.
The fix that we are talking about is a mandatory one for each one to use for ABI checks,
dpdk-stable patches are not mandatory for the users.
-Akhil
^ permalink raw reply [relevance 7%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-08 13:22 3% ` Thomas Monjalon
@ 2022-12-08 16:06 0% ` Patrick Robb
0 siblings, 0 replies; 200+ results
From: Patrick Robb @ 2022-12-08 16:06 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Ferruh Yigit, David Marchand, Akhil Goyal, ci, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
[-- Attachment #1: Type: text/plain, Size: 3201 bytes --]
Thomas - thanks for the response. We will proceed with making the necessary
changes for using v22.11.1.
On Thu, Dec 8, 2022 at 8:22 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> I'm sorry Patrick that it gives you more work.
> Your proposals below don't look possible because a tag is something fixed
> forever.
> We had an ABI issue in the initial tag so we cannot use the tag v22.11 as
> planned.
> I don't see how we can better plan except having more tests on release
> candidates.
>
>
> 07/12/2022 19:00, Patrick Robb:
> > Hello,
> >
> > Community Lab team members are wondering whether it is possible to bump
> > v22.11 to include at least this patch. We have an existing codebase which
> > relies on a vXX.XX scheme for producing ABI references. We parse that out
> > at different places in our code, so fixing this to handle vXX.XX.X will
> > require some changes on our end. We can do that, but it puts the timeline
> > on turning on ABI testing at the community lab back some. A v22.11 tagged
> > release with this patch would allow for us to turn on ABI testing
> > immediately. There was also a suggestion that having the "base" tag (like
> > the simple v22.11) point to the latest revision is a more standard
> version
> > naming approach and may be more intuitive than what is being used
> currently.
> >
> > If that is not possible, we will update our code to be able to refer to a
> > vXX.XX.X tag for producing the ABI reference. If we adopt this approach,
> we
> > would like to request that with future releases, a "vXX.XX.0" tag could
> > always be made available for us to produce ABI references from. That way,
> > we can prepare for turning on ABI testing knowing beforehand the tag name
> > we will be using.
> >
> > On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <ferruh.yigit@amd.com>
> wrote:
> >
> > > On 12/6/2022 10:18 AM, David Marchand wrote:
> > > > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <ferruh.yigit@amd.com>
> > > wrote:
> > > >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> > > >>> 05/12/2022 14:47, Akhil Goyal:
> > > >>>> But adding a tag on same repo is more convenient from developer
> point
> > > of view.
> > > >>>> However, it is my personal view, others may differ.
> > > >>>
> > > >>> From developer point of view, you should use
> > > devtools/test-meson-builds.sh
> > > >>> which does the "git clone" for you.
> > > >>>
> > > >>> This is what I have in ~/.config/dpdk/devel.config
> > > >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> > > >>> export DPDK_ABI_REF_VERSION=v22.11.1
> > > >>>
> > > >>
> > > >> Does it help to update 'test-meson-builds.sh' to use an environment
> > > >> variable to select which repo to clone?
> > > >> If so, I can send a patch for it.
> > > >
> > > > I was wondering too...
> > > > I would expect most maintainers have the stable repo in their config
> > > > but it would not hurt to handle the case when they don't for others.
> > > >
> > > > +1
> > >
> > > Sent following if it helps:
> > > https://patches.dpdk.org/project/dpdk/list/?series=26015
>
>
>
>
>
>
--
Patrick Robb
Technical Service Manager
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824
www.iol.unh.edu
[-- Attachment #2: Type: text/html, Size: 6221 bytes --]
^ permalink raw reply [relevance 0%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-07 18:00 5% ` Patrick Robb
@ 2022-12-08 13:22 3% ` Thomas Monjalon
2022-12-08 16:06 0% ` Patrick Robb
0 siblings, 1 reply; 200+ results
From: Thomas Monjalon @ 2022-12-08 13:22 UTC (permalink / raw)
To: Patrick Robb
Cc: Ferruh Yigit, David Marchand, Akhil Goyal, ci, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
I'm sorry Patrick that it gives you more work.
Your proposals below don't look possible because a tag is something fixed forever.
We had an ABI issue in the initial tag so we cannot use the tag v22.11 as planned.
I don't see how we can better plan except having more tests on release candidates.
07/12/2022 19:00, Patrick Robb:
> Hello,
>
> Community Lab team members are wondering whether it is possible to bump
> v22.11 to include at least this patch. We have an existing codebase which
> relies on a vXX.XX scheme for producing ABI references. We parse that out
> at different places in our code, so fixing this to handle vXX.XX.X will
> require some changes on our end. We can do that, but it puts the timeline
> on turning on ABI testing at the community lab back some. A v22.11 tagged
> release with this patch would allow for us to turn on ABI testing
> immediately. There was also a suggestion that having the "base" tag (like
> the simple v22.11) point to the latest revision is a more standard version
> naming approach and may be more intuitive than what is being used currently.
>
> If that is not possible, we will update our code to be able to refer to a
> vXX.XX.X tag for producing the ABI reference. If we adopt this approach, we
> would like to request that with future releases, a "vXX.XX.0" tag could
> always be made available for us to produce ABI references from. That way,
> we can prepare for turning on ABI testing knowing beforehand the tag name
> we will be using.
>
> On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> > On 12/6/2022 10:18 AM, David Marchand wrote:
> > > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <ferruh.yigit@amd.com>
> > wrote:
> > >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> > >>> 05/12/2022 14:47, Akhil Goyal:
> > >>>> But adding a tag on same repo is more convenient from developer point
> > of view.
> > >>>> However, it is my personal view, others may differ.
> > >>>
> > >>> From developer point of view, you should use
> > devtools/test-meson-builds.sh
> > >>> which does the "git clone" for you.
> > >>>
> > >>> This is what I have in ~/.config/dpdk/devel.config
> > >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> > >>> export DPDK_ABI_REF_VERSION=v22.11.1
> > >>>
> > >>
> > >> Does it help to update 'test-meson-builds.sh' to use an environment
> > >> variable to select which repo to clone?
> > >> If so, I can send a patch for it.
> > >
> > > I was wondering too...
> > > I would expect most maintainers have the stable repo in their config
> > > but it would not hurt to handle the case when they don't for others.
> > >
> > > +1
> >
> > Sent following if it helps:
> > https://patches.dpdk.org/project/dpdk/list/?series=26015
^ permalink raw reply [relevance 3%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
@ 2022-12-07 18:00 5% ` Patrick Robb
2022-12-08 13:22 3% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Patrick Robb @ 2022-12-07 18:00 UTC (permalink / raw)
To: Ferruh Yigit
Cc: David Marchand, Thomas Monjalon, Akhil Goyal, ci,
Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li, dev, stable, Bruce Richardson,
Michael Santana, Abdullah Ömer Yamaç,
Aaron Conole
[-- Attachment #1: Type: text/plain, Size: 2456 bytes --]
Hello,
Community Lab team members are wondering whether it is possible to bump
v22.11 to include at least this patch. We have an existing codebase which
relies on a vXX.XX scheme for producing ABI references. We parse that out
at different places in our code, so fixing this to handle vXX.XX.X will
require some changes on our end. We can do that, but it puts the timeline
on turning on ABI testing at the community lab back some. A v22.11 tagged
release with this patch would allow for us to turn on ABI testing
immediately. There was also a suggestion that having the "base" tag (like
the simple v22.11) point to the latest revision is a more standard version
naming approach and may be more intuitive than what is being used currently.
If that is not possible, we will update our code to be able to refer to a
vXX.XX.X tag for producing the ABI reference. If we adopt this approach, we
would like to request that with future releases, a "vXX.XX.0" tag could
always be made available for us to produce ABI references from. That way,
we can prepare for turning on ABI testing knowing beforehand the tag name
we will be using.
On Tue, Dec 6, 2022 at 7:25 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> On 12/6/2022 10:18 AM, David Marchand wrote:
> > On Tue, Dec 6, 2022 at 11:13 AM Ferruh Yigit <ferruh.yigit@amd.com>
> wrote:
> >> On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> >>> 05/12/2022 14:47, Akhil Goyal:
> >>>> But adding a tag on same repo is more convenient from developer point
> of view.
> >>>> However, it is my personal view, others may differ.
> >>>
> >>> From developer point of view, you should use
> devtools/test-meson-builds.sh
> >>> which does the "git clone" for you.
> >>>
> >>> This is what I have in ~/.config/dpdk/devel.config
> >>> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> >>> export DPDK_ABI_REF_VERSION=v22.11.1
> >>>
> >>
> >> Does it help to update 'test-meson-builds.sh' to use an environment
> >> variable to select which repo to clone?
> >> If so, I can send a patch for it.
> >
> > I was wondering too...
> > I would expect most maintainers have the stable repo in their config
> > but it would not hurt to handle the case when they don't for others.
> >
> > +1
> >
> >
>
> Sent following if it helps:
> https://patches.dpdk.org/project/dpdk/list/?series=26015
>
--
Patrick Robb
Technical Service Manager
UNH InterOperability Laboratory
21 Madbury Rd, Suite 100, Durham, NH 03824
www.iol.unh.edu
[-- Attachment #2: Type: text/html, Size: 5075 bytes --]
^ permalink raw reply [relevance 5%]
* Re: [PATCH v2 1/3] eal: add rte control thread create API
@ 2022-12-07 16:38 3% ` Tyler Retzlaff
2022-12-08 21:59 0% ` Mattias Rönnblom
0 siblings, 1 reply; 200+ results
From: Tyler Retzlaff @ 2022-12-07 16:38 UTC (permalink / raw)
To: Mattias Rönnblom
Cc: dev, thomas, david.marchand, stephen, olivier.matz, mb
On Wed, Dec 07, 2022 at 10:13:39AM +0100, Mattias Rönnblom wrote:
> On 2022-12-06 18:28, Tyler Retzlaff wrote:
> >Add rte_control_thread_create API as a replacement for
> >rte_ctrl_thread_create to allow deprecation of the use of platform
> >specific types in DPDK public API.
> >
> >Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> >---
> > lib/eal/common/eal_common_thread.c | 93 ++++++++++++++++++++++++++++++++++----
> > lib/eal/include/rte_thread.h | 29 ++++++++++++
> > lib/eal/version.map | 3 ++
> > 3 files changed, 117 insertions(+), 8 deletions(-)
> >
> >diff --git a/lib/eal/common/eal_common_thread.c b/lib/eal/common/eal_common_thread.c
> >index c5d8b43..7950b50 100644
> >--- a/lib/eal/common/eal_common_thread.c
> >+++ b/lib/eal/common/eal_common_thread.c
> >@@ -234,7 +234,10 @@ enum __rte_ctrl_thread_status {
> > };
> > struct rte_thread_ctrl_params {
> >- void *(*start_routine)(void *);
> >+ union {
> >+ void *(*start_routine)(void *);
> >+ rte_thread_func thread_func;
>
> To be consistent with function naming scheme, where "ctrl" is the
> old API, and "control" the new, you could call the start functions
> something with "ctrl" and "control" as well.
i'll make this change in v3.
>
> Maybe it's worth mentioning that fact somewhere in the beginning of
> the file, as a comment (i.e., that "ctrl" denotes the old API).
i'll make this change in v3.
>
> >+ } u;
> > void *arg;
> > int ret;
>
> Why is 'ret' needed? (This question is unrelated to your patch.)
i'm not the original author so difficult to answer authoritatively. but
if i have to speculate i'd say it might be to work around the windows
pthread_join stub being implemented as a noop. specifically it didn't
communicate the return value from the start_routine.
the recently added rte_thread_join addresses this (which
rte_control_thread_create uses) and could remove ret parameter and to
avoid touching the new function implementation in the future it can not
use ret now.
i'll make this change in v3.
for the original function i will leave the code as is to minimize the
diff. when rte_ctrl_thread_create is removed i'll make a note to
eliminate the ret parameter as well.
>
> > /* Control thread status.
> >@@ -243,14 +246,12 @@ struct rte_thread_ctrl_params {
> > enum __rte_ctrl_thread_status ctrl_thread_status;
> > };
> >-static void *ctrl_thread_init(void *arg)
> >+static int ctrl_thread_init(void *arg)
> > {
> > struct internal_config *internal_conf =
> > eal_get_internal_configuration();
> > rte_cpuset_t *cpuset = &internal_conf->ctrl_cpuset;
> > struct rte_thread_ctrl_params *params = arg;
> >- void *(*start_routine)(void *) = params->start_routine;
> >- void *routine_arg = params->arg;
> > __rte_thread_init(rte_lcore_id(), cpuset);
> > params->ret = pthread_setaffinity_np(pthread_self(), sizeof(*cpuset),
> >@@ -258,13 +259,35 @@ static void *ctrl_thread_init(void *arg)
> > if (params->ret != 0) {
> > __atomic_store_n(¶ms->ctrl_thread_status,
> > CTRL_THREAD_ERROR, __ATOMIC_RELEASE);
> >- return NULL;
> >+ return params->ret;
> > }
> > __atomic_store_n(¶ms->ctrl_thread_status,
> > CTRL_THREAD_RUNNING, __ATOMIC_RELEASE);
> >- return start_routine(routine_arg);
> >+ return 0;
> >+}
> >+
> >+static void *ctrl_thread_start(void *arg)
> >+{
> >+ struct rte_thread_ctrl_params *params = arg;
> >+ void *(*start_routine)(void *) = params->u.start_routine;
> >+
> >+ if (ctrl_thread_init(arg) != 0)
> >+ return NULL;
> >+
> >+ return start_routine(params->arg);
> >+}
> >+
> >+static uint32_t control_thread_start(void *arg)
> >+{
> >+ struct rte_thread_ctrl_params *params = arg;
> >+ rte_thread_func start_routine = params->u.thread_func;
> >+
> >+ if (ctrl_thread_init(arg) != 0)
> >+ return params->ret;
> >+
> >+ return start_routine(params->arg);
> > }
> > int
> >@@ -280,12 +303,12 @@ static void *ctrl_thread_init(void *arg)
> > if (!params)
> > return -ENOMEM;
> >- params->start_routine = start_routine;
> >+ params->u.start_routine = start_routine;
> > params->arg = arg;
> > params->ret = 0;
> > params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
> >- ret = pthread_create(thread, attr, ctrl_thread_init, (void *)params);
> >+ ret = pthread_create(thread, attr, ctrl_thread_start, (void *)params);
> > if (ret != 0) {
> > free(params);
> > return -ret;
> >@@ -322,6 +345,60 @@ static void *ctrl_thread_init(void *arg)
> > }
> > int
> >+rte_control_thread_create(rte_thread_t *thread, const char *name,
> >+ const rte_thread_attr_t *attr,
> >+ rte_thread_func start_routine, void *arg)
> >+{
> >+ struct rte_thread_ctrl_params *params;
> >+ enum __rte_ctrl_thread_status ctrl_thread_status;
> >+ int ret;
> >+
> >+ params = malloc(sizeof(*params));
> >+ if (!params)
>
> params == NULL
copied from original code, i'll fix the style in the new function to
comply with the dpdk coding standard.
i'll fix in v3.
>
> >+ return -ENOMEM;
> >+
> >+ params->u.thread_func = start_routine;
> >+ params->arg = arg;
> >+ params->ret = 0;
> >+ params->ctrl_thread_status = CTRL_THREAD_LAUNCHING;
> >+
> >+ ret = rte_thread_create(thread, attr, control_thread_start, params);
> >+ if (ret != 0) {
> >+ free(params);
> >+ return -ret;
> >+ }
> >+
> >+ if (name != NULL) {
> >+ ret = rte_thread_setname((pthread_t)thread->opaque_id, name);
> >+ if (ret < 0)
> >+ RTE_LOG(DEBUG, EAL,
> >+ "Cannot set name for ctrl thread\n");
> >+ }
> >+
> >+ /* Wait for the control thread to initialize successfully */
> >+ while ((ctrl_thread_status =
> >+ __atomic_load_n(¶ms->ctrl_thread_status,
> >+ __ATOMIC_ACQUIRE)) == CTRL_THREAD_LAUNCHING) {
> >+ /* Yield the CPU. Using sched_yield call requires maintaining
> >+ * another implementation for Windows as sched_yield is not
> >+ * supported on Windows.
> >+ */
>
> sched_yield() also doesn't necessarily yield the CPU.
copied from original code and understood, but are you requesting a
change here or just a comment correction? can you offer wording you
would find suitable?
>
> >+ rte_delay_us_sleep(1);
> >+ }
> >+
> >+ /* Check if the control thread encountered an error */
> >+ if (ctrl_thread_status == CTRL_THREAD_ERROR) {
> >+ /* ctrl thread is exiting */
> >+ rte_thread_join(*thread, NULL);
> >+ }
> >+
> >+ ret = params->ret;
> >+ free(params);
> >+
> >+ return ret;
> >+}
> >+
> >+int
> > rte_thread_register(void)
> > {
> > unsigned int lcore_id;
> >diff --git a/lib/eal/include/rte_thread.h b/lib/eal/include/rte_thread.h
> >index b9edf70..ae7afbe 100644
> >--- a/lib/eal/include/rte_thread.h
> >+++ b/lib/eal/include/rte_thread.h
> >@@ -95,6 +95,35 @@ int rte_thread_create(rte_thread_t *thread_id,
> > rte_thread_func thread_func, void *arg);
> > /**
> >+ * Create a control thread.
> >+ *
> >+ * Creates a control thread with the given name and attributes. The
> >+ * affinity of the new thread is based on the CPU affinity retrieved
> >+ * at the time rte_eal_init() was called, the dataplane and service
> >+ * lcores are then excluded. If setting the name of the thread fails,
>
> "the EAL threads are then excluded"
i'll modify in v3.
>
> >+ * the error is ignored and a debug message is logged.
> >+ *
> >+ * @param thread
> >+ * Filled with the thread id of the new created thread.
> >+ * @param name
> >+ * The name of the control thread (max 16 characters including '\0').
>
> Is there a constant for this limit?
i have a series introducing rte_lcore_{set,get}_name api that introduces
a constant (probably i'll post it today). as of this series there is no
constant.
>
> >+ * @param thread_attr
> >+ * Attributes for the new thread.
> >+ * @param thread_func
> >+ * Function to be executed by the new thread.
> >+ * @param arg
> >+ * Argument passed to start_routine.
> >+ * @return
> >+ * On success, returns 0; on error, it returns a negative value
> >+ * corresponding to the error number.
>
> List the possible error codes.
i would like to see the range of codes be part of the api & abi i've
received resistance to the idea. for now i'll nack this comment which
leaves it consistent with other apis documentation.
>
> >+ */
> >+__rte_experimental
> >+int
> >+rte_control_thread_create(rte_thread_t *thread, const char *name,
> >+ const rte_thread_attr_t *thread_attr,
> >+ rte_thread_func thread_func, void *arg);
> >+
> >+/**
> > * @warning
> > * @b EXPERIMENTAL: this API may change without prior notice.
> > *
> >diff --git a/lib/eal/version.map b/lib/eal/version.map
> >index 7ad12a7..8f9eeb9 100644
> >--- a/lib/eal/version.map
> >+++ b/lib/eal/version.map
> >@@ -440,6 +440,9 @@ EXPERIMENTAL {
> > rte_thread_detach;
> > rte_thread_equal;
> > rte_thread_join;
> >+
> >+ # added in 23.03
> >+ rte_control_thread_create;
> > };
> > INTERNAL {
^ permalink raw reply [relevance 3%]
* [PATCH 2/2] devtools: configure source repo to use as ABI reference
@ 2022-12-06 12:23 17% ` Ferruh Yigit
2022-12-08 18:14 7% ` [EXT] " Akhil Goyal
2022-12-09 8:22 8% ` David Marchand
1 sibling, 2 replies; 200+ results
From: Ferruh Yigit @ 2022-12-06 12:23 UTC (permalink / raw)
To: Thomas Monjalon, Bruce Richardson; +Cc: David Marchand, dev
By default 'test-meson-builds.sh' script clones the repository which the
script is in, and selects a configured branch ('DPDK_ABI_REF_VERSION')
as a reference for ABI check.
This patch enables selecting different repository to close for reference
using 'DPDK_ABI_REF_SRC' environment variable.
It is possible to put these variables to 'devel.config' config file, or
provide via command line, like:
`
DPDK_ABI_REF_SRC=~/dpdk-stable/ \
DPDK_ABI_REF_VERSION=v22.11.1 \
DPDK_ABI_REF_DIR=/tmp/dpdk-abiref \
./devtools/test-meson-builds.sh
`
When 'DPDK_ABI_REF_SRC' is not defined, script behaves as it did
previously.
Other alternative to using 'DPDK_ABI_REF_SRC' variable is adding that
other repo as a new 'remote' to the exiting git repository.
Signed-off-by: Ferruh Yigit <ferruh.yigit@amd.com>
---
devtools/test-meson-builds.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index bbe90e2bde2e..8a0ed92fcf0a 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -18,6 +18,7 @@ srcdir=$(dirname $(readlink -f $0))/..
#
# - DPDK_MESON_OPTIONS
#
+# - DPDK_ABI_REF_SRC
# - DPDK_ABI_REF_DIR
# - DPDK_ABI_REF_VERSION
#
@@ -185,12 +186,13 @@ build () # <directory> <target cc | cross file> <ABI check> [meson options]
if [ -n "$DPDK_ABI_REF_VERSION" -a "$abicheck" = ABI ] ; then
abirefdir=${DPDK_ABI_REF_DIR:-reference}/$DPDK_ABI_REF_VERSION
if [ ! -d $abirefdir/$targetdir ]; then
+ abirefsrc=${DPDK_ABI_REF_SRC:-$srcdir}
# clone current sources
if [ ! -d $abirefdir/src ]; then
git clone --local --no-hardlinks \
--single-branch \
-b $DPDK_ABI_REF_VERSION \
- $srcdir $abirefdir/src
+ $abirefsrc $abirefdir/src
fi
rm -rf $abirefdir/build
--
2.25.1
^ permalink raw reply [relevance 17%]
* 21.11.3 patches review and test
@ 2022-12-06 11:29 1% Kevin Traynor
2022-12-13 11:48 0% ` Christian Ehrhardt
2022-12-16 7:55 0% ` YangHang Liu
0 siblings, 2 replies; 200+ results
From: Kevin Traynor @ 2022-12-06 11:29 UTC (permalink / raw)
To: stable
Cc: dev, Abhishek Marathe, Ali Alnubani, benjamin.walker,
David Christensen, Hemant Agrawal, Ian Stokes, Jerin Jacob,
John McNamara, Ju-Hyoung Lee, Kevin Traynor, Luca Boccassi,
Pei Zhang, qian.q.xu, Raslan Darawsheh, Thomas Monjalon,
yanghliu, yuan.peng, zhaoyan.chen
Hi all,
Here is a list of patches targeted for stable release 21.11.3.
The planned date for the final release is 19th December.
Please help with testing and validation of your use cases and report
any issues/results with reply-all to this mail. For the final release
the fixes and reported validations will be added to the release notes.
A release candidate tarball can be found at:
https://dpdk.org/browse/dpdk-stable/tag/?id=v21.11.3-rc1
These patches are located at branch 21.11 of dpdk-stable repo:
https://dpdk.org/browse/dpdk-stable/
Thanks.
Kevin
---
Abdullah Sevincer (1):
event/dlb2: handle enqueuing more than maximum depth
Abhimanyu Saini (1):
common/sfc_efx/base: remove VQ index check during VQ start
Aleksandr Miloshenko (1):
net/iavf: fix Tx done descriptors cleanup
Alex Kiselev (1):
net/tap: fix overflow of network interface index
Alexander Chernavin (1):
net/virtio: fix crash when configured twice
Alexander Kozyrev (3):
net/mlx5: fix shared Rx queue config reuse
net/mlx5: fix first segment inline length
net/mlx5: fix indexed pool local cache crash
Ali Alnubani (1):
examples/l2fwd-crypto: fix typo in error message
Amit Prakash Shukla (6):
net/mvneta: fix build with GCC 12
test/ipsec: fix build with GCC 12
ipsec: fix build with GCC 12
crypto/qat: fix build with GCC 12
net/i40e: fix build with MinGW GCC 12
net/qede/base: fix 32-bit build with GCC 12
Andrew Boyer (5):
net/ionic: fix endianness for Rx and Tx
net/ionic: fix endianness for RSS
net/ionic: fix adapter name for logging
net/ionic: fix Rx filter save
net/ionic: fix reported error stats
Anoob Joseph (1):
test/crypto: fix PDCP vectors
Apeksha Gupta (2):
net/enetfec: fix restart
net/enetfec: fix buffer leak
Arek Kusztal (1):
common/qat: fix VF to PF answer
Ashwin Sekhar T K (1):
mempool/cnxk: fix destroying empty pool
Ben Magistro (1):
doc: fix dumpcap interface parameter option
Benjamin Le Berre (1):
net/bnxt: fix error code during MTU change
Bhagyada Modali (9):
net/axgbe: fix scattered Rx
net/axgbe: fix mbuf lengths in scattered Rx
net/axgbe: fix length of each segment in scattered Rx
net/axgbe: fix checksum and RSS in scattered Rx
net/axgbe: optimise scattered Rx
net/axgbe: remove freeing buffer in scattered Rx
net/axgbe: reset end of packet in scattered Rx
net/axgbe: clear buffer on scattered Rx chaining failure
net/axgbe: save segment data in scattered Rx
Bing Zhao (2):
net/mlx5: fix build with recent compilers
bus/auxiliary: prevent device from being probed again
Brian Dooley (1):
crypto/qat: fix null hash algorithm digest size
Changpeng Liu (1):
vhost: add non-blocking API for posting interrupt
Chaoyong He (1):
net/nfp: fix Rx descriptor DMA address
Chengwen Feng (8):
net/hns3: fix crash in SVE Tx
net/hns3: fix next-to-use overflow in SVE Tx
net/hns3: fix next-to-use overflow in simple Tx
net/hns3: fix crash when secondary process access FW
net/hns3: revert Tx performance optimization
net/hns3: revert fix mailbox communication with HW
net/hns3: fix VF mailbox message handling
app/testpmd: remove jumbo offload
Ciara Power (1):
test/crypto: fix wireless auth digest segment
Conor Walsh (1):
doc: fix reference to dma application example
Dariusz Sosnowski (1):
net/mlx5: fix hairpin split with set VLAN VID action
David Marchand (23):
vhost: fix virtqueue use after free on NUMA reallocation
app/testpmd: restore ixgbe bypass commands
net/failsafe: fix interrupt handle leak
net/bnxt: fix build with GCC 13
trace: fix mode for new trace point
trace: fix mode change
trace: fix leak with regexp
trace: fix dynamically enabling trace points
trace: fix race in debug dump
ci: bump versions of actions in GHA
ci: update to new API for step outputs in GHA
service: fix build with clang 15
vhost: fix build with clang 15
bus/dpaa: fix build with clang 15
net/atlantic: fix build with clang 15
net/dpaa2: fix build with clang 15
app/testpmd: fix build with clang 15
app/testpmd: fix build with clang 15 in flow code
test/efd: fix build with clang 15
test/member: fix build with clang 15
test/event: fix build with clang 15
ci: enable ABI check in GHA
trace: fix metadata dump
Dmitry Kozlyuk (4):
build: enable developer mode for all working trees
eal: fix side effect in some pointer arithmetic macros
mempool: make event callbacks process-private
common/mlx5: fix multi-process mempool registration
Dong Zhou (1):
net/mlx5: fix thread workspace memory leak
Dongdong Liu (2):
doc: fix application name in procinfo guide
doc: document device dump in procinfo guide
Erik Gabriel Carrillo (1):
service: fix early move to inactive status
Fidaullah Noonari (1):
malloc: fix storage size for some allocations
Frank Du (1):
net/ice: fix interrupt handler unregister
Gagandeep Singh (5):
net/dpaa: fix buffer freeing in slow path
net/dpaa: use internal mempool for SG table
net/dpaa: fix buffer freeing on SG Tx
net/dpaa2: use internal mempool for SG table
net/dpaa2: fix buffer freeing on SG Tx
Ganapati Kundapura (1):
eventdev/crypto: fix multi-process
Gregory Etelson (6):
net/mlx5: fix RSS expansion buffer size
app/testpmd: fix MAC header in checksum forward engine
common/mlx5: fix shared mempool subscription
net/mlx5: fix port initialization with small LRO
net/mlx5: fix maximum LRO message size
doc: add LRO size limitation in mlx5 guide
Haiyue Wang (1):
ring: fix description
Hamza Khan (1):
examples/vm_power_manager: use safe list iterator
Hanumanth Pothula (1):
net/cnxk: fix DF bit in vector mode
Hernan Vargas (14):
baseband/acc100: fix memory leak
baseband/acc100: check turbo dec/enc input
baseband/acc100: add null checks
baseband/acc100: fix input length for CRC24B
baseband/acc100: fix clearing PF IR outside handler
baseband/acc100: fix device minimum alignment
baseband/acc100: fix close cleanup
baseband/acc100: add LDPC encoder padding function
baseband/acc100: check AQ availability
baseband/acc100: fix ring availability calculation
baseband/acc100: enforce additional check on FCW
baseband/acc100: fix null HARQ input case
baseband/acc100: fix ring/queue allocation
baseband/acc100: fix double MSI intr in TB mode
Huisong Li (18):
net/hns3: fix Rx with PTP
net/hns3: delete unused markup
net/hns3: fix clearing hardware MAC statistics
net/hns3: fix RSS filter restore
net/hns3: fix RSS flow rule restore
net/hns3: move flow direction rule recovery
net/hns3: fix packet type for GENEVE
net/hns3: fix IPv4 and IPv6 RSS
net/hns3: fix typos in IPv6 SCTP fields
net/hns3: fix IPv4 RSS
net/hns3: add L3 and L4 RSS types
net/bonding: fix slave device Rx/Tx offload configuration
net/bonding: fix dropping valid MAC packets
net/bonding: fix mbuf fast free handling
net/hns3: extract functions to create RSS and FDIR flow rule
net/hns3: fix RSS rule restore
net/hns3: fix lock protection of RSS flow rule
net/hns3: fix restore filter function input
Huzaifa Rahman (1):
net/memif: fix crash with different number of Rx/Tx queues
Ilya Maximets (1):
doc: fix support table for Ethernet/VLAN flow items
Ivan Malov (3):
common/sfc_efx/base: fix maximum Tx data count
net/bonding: fix descriptor limit reporting
net/bonding: fix flow flush order on close
James Hershaw (1):
net/nfp: improve HW info header log readability
Jeremy Spewock (1):
test/ipsec: skip if no compatible device
Jerin Jacob (2):
eal: fix doxygen comments for UUID
power: fix some doxygen comments
Jiawei Wang (4):
net/mlx5: fix modify action with tunnel decapsulation
net/mlx5: fix tunnel header with IPIP offload
net/mlx5: fix source port checking in sample flow rule
net/mlx5: fix mirror flow validation with ASO action
Jiawen Wu (6):
net/txgbe: fix IPv6 flow rule
net/txgbe: remove semaphore between SW/FW
net/txgbe: rename some extended statistics
net/ngbe: rename some extended statistics
net/ngbe: remove semaphore between SW/FW
net/ngbe: fix maximum frame size
Jie Hai (1):
net/hns3: fix minimum Tx frame length
Jie Wang (1):
net/i40e: fix jumbo frame Rx with X722
Jun Qiu (3):
gro: trim tail padding bytes
net/bonding: fix Tx hash for TCP
hash: fix RCU configuration memory leak
Kai Ji (1):
test/crypto: fix bitwise operator in a SNOW3G case
Kalesh AP (2):
net/bnxt: remove unnecessary check
net/bnxt: fix representor info freeing
Ke Zhang (2):
net/i40e: fix VF representor release
net/iavf: fix L3 checksum Tx offload flag
Kevin Liu (2):
net/iavf: check illegal packet sizes
net/ice: check illegal packet sizes
Kevin Traynor (1):
Revert "cryptodev: fix missing SHA3 algorithm strings"
Kumara Parameshwaran (1):
gro: check payload length after trim
Long Li (2):
net/mlx4: fix Verbs FD leak in secondary process
net/mlx5: fix Verbs FD leak in secondary process
Long Wu (1):
net/nfp: fix memory leak in Rx
Luca Boccassi (1):
drivers: fix typos found by Lintian
Mao YingMing (1):
net/bnxt: fix null pointer dereference in LED config
Mattias Rönnblom (3):
net: accept unaligned data in checksum routines
event/dsw: fix flow migration
doc: fix event timer adapter guide
Maxime Coquelin (1):
vhost: fix build with GCC 12
Megha Ajmera (2):
sched: fix subport profile configuration
examples/qos_sched: fix number of subport profiles
Michael Baum (5):
net/mlx5: fix null check in devargs parsing
doc: fix underlines in testpmd guide
doc: fix colons in testpmd aged flow rules
net/mlx5: fix race condition in counter pool resizing
net/mlx5: fix port event cleaning order
Mingjin Ye (4):
net/ice: support VXLAN-GPE tunnel offload
net/i40e: fix pctype configuration for X722
net/ice: fix scalar Rx path segment
net/ice: fix scalar Tx path segment
Mário Kuka (1):
pcapng: fix write more packets than IOV_MAX limit
Naga Harish K S V (4):
eventdev/eth_tx: add spinlock for adapter start/stop
eventdev/eth_tx: fix adapter stop
timer: fix stopping all timers
eventdev/eth_tx: fix queue delete
Nithin Dabilpuram (3):
examples/ipsec-secgw: use Tx checksum offload conditionally
examples/l3fwd: fix MTU configuration with event mode
net/cnxk: fix later skip to include mbuf private data
Olivier Matz (7):
cryptodev: fix unduly newlines in logs
mem: fix API doc about allocation on secondary processes
event/sw: fix flow ID init in self test
event/sw: fix log in self test
net/ixgbe: fix broadcast Rx on VF after promisc removal
net/ixgbe: fix unexpected VLAN Rx in promisc mode on VF
net/ixgbevf: fix promiscuous and allmulti
Pablo de Lara (1):
examples/fips_validation: fix typo in error log
Pavan Nikhilesh (3):
event/cnxk: fix missing xstats operations
event/cnxk: fix mbuf offset calculation
event/cnxk: fix missing mempool cookie marking
Peng Zhang (3):
net/nfp: compose firmware file name with new hwinfo
buildtools: fix NUMA nodes count
net/nfp: fix internal buffer size and MTU check
Qi Zhang (12):
net/ice/base: fix division during E822 PTP init
net/ice/base: fix 100M speed capability
net/ice/base: fix DSCP PFC TLV creation
net/ice/base: fix media type of PHY 10G SFI C2C
net/ice/base: fix function descriptions for parser
net/ice/base: fix endian format
net/ice/base: fix array overflow in add switch recipe
net/ice/base: fix bit finding range over ptype bitmap
net/ice/base: fix add MAC rule
net/ice/base: fix double VLAN in promiscuous mode
net/ice/base: ignore promiscuous already exist
net/ice/base: fix input set of GTPoGRE
Qiming Yang (1):
app/testpmd: skip port reset in secondary process
Radu Nicolau (5):
net/iavf: update IPsec ESN values when updating session
net/iavf: fix IPsec flow create error check
net/iavf: fix SPI check
net/iavf: fix queue stop for large VF
examples/ipsec-secgw: fix Tx checksum offload flag
Raja Zidane (1):
net/mlx5: fix Tx check for hardware descriptor length
Rohit Raj (1):
net/dpaa: fix jumbo packet Rx in case of VSP
Satha Rao (1):
common/cnxk: fix schedule weight update
Satheesh Paul (3):
common/cnxk: fix log level during MCAM allocation
common/cnxk: fix missing flow counter reset
common/cnxk: fix printing disabled MKEX registers
Shiqi Liu (2):
node: check Rx element allocation
dma/idxd: check DSA device allocation
Shun Hao (4):
net/mlx5: fix meter profile delete after disable
net/mlx5: fix action flag data type
net/mlx5: fix drop action validation
net/mlx5: fix assert when creating meter policy
Stephen Coleman (1):
doc: fix typo depreciated instead of deprecated
Stephen Hemminger (8):
event/sw: fix device name in dump
eal: fix data race in multi-process support
pdump: do not allow enable/disable in primary process
app/dumpcap: fix crash on cleanup
app/dumpcap: fix pathname for output file
app/testpmd: make quit flag volatile
ring: remove leftover comment about watermark
doc: avoid meson deprecation in setup
Steve Yang (1):
net/iavf: fix pattern check for flow director parser
Steven Zou (1):
common/iavf: avoid copy in async mode
Sunyang Wu (1):
test/crypto: fix debug messages
Taekyung Kim (1):
vdpa/ifc: handle data path update failure
Tal Shnaiderman (1):
net/mlx5: fix thread termination check on Windows
Thomas Monjalon (2):
drivers: remove unused build variable
doc: add Rx buffer split capability for mlx5
Ting Xu (1):
net/ice/base: fix inner symmetric RSS hash in raw flow
Tomasz Jonak (1):
net/ice: fix null function pointer call
Vanshika Shukla (1):
net/dpaa2: fix DPDMUX error behaviour
Viacheslav Ovsiienko (3):
net/mlx5: fix check for orphan wait descriptor
net/mlx5: fix single not inline packet storing
net/mlx5: fix inline length exceeding descriptor limit
Vladimir Medvedkin (2):
test/hash: remove dead code in extendable bucket test
test/hash: fix bulk lookup check
Volodymyr Fialko (3):
cryptodev: fix missing SHA3 algorithm strings
eventdev: fix name of Rx conf type in documentation
app/eventdev: fix limits in error message
Wenwu Ma (1):
examples/vhost: fix use after free
Wenzhuo Lu (1):
net/iavf: fix VLAN offload
Yi Li (1):
doc: fix maximum packet size of virtio driver
Yiding Zhou (4):
net/iavf: fix VLAN insertion
net/iavf: revert VLAN insertion fix
net/ice/base: fix duplicate flow rules
net/iavf: add thread for event callbacks
Yunjian Wang (2):
net/bonding: fix array overflow in Rx burst
net/bonding: fix double slave link status query
Zhichao Zeng (3):
net/ice: fix RSS hash update
net/iavf: fix processing VLAN TCI in SSE path
net/iavf: fix outer checksum flags
Zhirun Yan (1):
graph: fix node objects allocation
^ permalink raw reply [relevance 1%]
* [PATCH] devtools: update Meson setup command
@ 2022-12-06 10:16 4% Thomas Monjalon
0 siblings, 0 replies; 200+ results
From: Thomas Monjalon @ 2022-12-06 10:16 UTC (permalink / raw)
To: dev; +Cc: Aaron Conole, Michael Santana, Bruce Richardson
The command "meson build" causes a deprecation warning with meson 0.64:
WARNING: Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated.
Signed-off-by: Thomas Monjalon <thomas@monjalon.net>
---
.ci/linux-build.sh | 2 +-
devtools/test-meson-builds.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index baec65a914..5225dc71c4 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -163,7 +163,7 @@ if [ "$ABI_CHECKS" = "true" ]; then
if [ ! -d reference ]; then
refsrcdir=$(readlink -f $(pwd)/../dpdk-$REF_GIT_TAG)
git clone --single-branch -b "$REF_GIT_TAG" $REF_GIT_REPO $refsrcdir
- meson $OPTS -Dexamples= $refsrcdir $refsrcdir/build
+ meson setup $OPTS -Dexamples= $refsrcdir $refsrcdir/build
ninja -C $refsrcdir/build
DESTDIR=$(pwd)/reference ninja -C $refsrcdir/build install
devtools/gen-abi.sh reference
diff --git a/devtools/test-meson-builds.sh b/devtools/test-meson-builds.sh
index 3a308bc9af..7efd5576fc 100755
--- a/devtools/test-meson-builds.sh
+++ b/devtools/test-meson-builds.sh
@@ -124,8 +124,8 @@ config () # <dir> <builddir> <meson options>
options="$options -D$option"
done
options="$options $*"
- echo "$MESON $options $dir $builddir" >&$verbose
- $MESON $options $dir $builddir
+ echo "$MESON setup $options $dir $builddir" >&$verbose
+ $MESON setup $options $dir $builddir
}
compile () # <builddir>
--
2.38.1
^ permalink raw reply [relevance 4%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 15:37 0% ` Thomas Monjalon
2022-12-05 16:26 0% ` Akhil Goyal
@ 2022-12-06 10:12 0% ` Ferruh Yigit
1 sibling, 1 reply; 200+ results
From: Ferruh Yigit @ 2022-12-06 10:12 UTC (permalink / raw)
To: Thomas Monjalon, David Marchand, Akhil Goyal
Cc: ci, Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li, dev, stable, Bruce Richardson,
Michael Santana, Abdullah Ömer Yamaç,
Aaron Conole
On 12/5/2022 3:37 PM, Thomas Monjalon wrote:
> 05/12/2022 14:47, Akhil Goyal:
>>> On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
>>>>> Please, maintainers and CI teams, when you enable ABI checks in the
>>>>> main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
>>>>> tag as a reference.
>>>>> Thanks.
>>>>
>>>> Should we also add a tag on main repo, as new development does not happen
>>>> on stable tree?
>>>
>>> You can fetch the v22.11.1 tag from the stable tree.
>> Yes, that is an obvious option.
>> But adding a tag on same repo is more convenient from developer point of view.
>> However, it is my personal view, others may differ.
>
> From developer point of view, you should use devtools/test-meson-builds.sh
> which does the "git clone" for you.
>
> This is what I have in ~/.config/dpdk/devel.config
> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> export DPDK_ABI_REF_VERSION=v22.11.1
>
Does it help to update 'test-meson-builds.sh' to use an environment
variable to select which repo to clone?
If so, I can send a patch for it.
^ permalink raw reply [relevance 0%]
* Re: [PATCH 3/3] eal: deprecate pthread control thread create API
@ 2022-12-06 0:24 3% ` Tyler Retzlaff
0 siblings, 0 replies; 200+ results
From: Tyler Retzlaff @ 2022-12-06 0:24 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: dev, thomas, david.marchand, olivier.matz
On Mon, Dec 05, 2022 at 01:18:05PM -0800, Stephen Hemminger wrote:
> On Mon, 5 Dec 2022 12:24:28 -0800
> Tyler Retzlaff <roretzla@linux.microsoft.com> wrote:
>
> > +
> > +* eal: The function ``rte_ctrl_thread_create`` will be removed and
> > + replaced by the new ``rte_control_thread_create``api, continuing the
> > + effort to decouple eal from platform-specific thread implementations.
>
> If you want to change this (which is a good idea)
> then mark the function with __rte_deprecated now, and cleanup all the examples
> and test programs please.
i would like to mark it deprecated now but it seems the policy governing
abi replacement prevent me from doing so.
```
3.3.3. New API replacing previous one
If a new API proposed functionally replaces an existing one, when the
new API becomes non-experimental then the old one is marked with
__rte_deprecated. Deprecated APIs are removed completely just after the
next LTS.
```
as i interpreted this i am not permitted to mark the old api
__rte_deprecated until the new api is no longer marked
__rte_experimental.
of course i'm happy to skip marking the new api __rte_experimental if
people find that a satisfactory solution?
let me know.
^ permalink raw reply [relevance 3%]
* RE: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 15:37 0% ` Thomas Monjalon
@ 2022-12-05 16:26 0% ` Akhil Goyal
2022-12-06 10:12 0% ` Ferruh Yigit
1 sibling, 0 replies; 200+ results
From: Akhil Goyal @ 2022-12-05 16:26 UTC (permalink / raw)
To: Thomas Monjalon, David Marchand
Cc: ci, Ferruh Yigit, Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li, dev, stable, Bruce Richardson,
Michael Santana, Abdullah Ömer Yamaç,
Aaron Conole
> 05/12/2022 14:47, Akhil Goyal:
> > > On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > > > Please, maintainers and CI teams, when you enable ABI checks in the
> > > > > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > > > > tag as a reference.
> > > > > Thanks.
> > > >
> > > > Should we also add a tag on main repo, as new development does not
> happen
> > > > on stable tree?
> > >
> > > You can fetch the v22.11.1 tag from the stable tree.
> > Yes, that is an obvious option.
> > But adding a tag on same repo is more convenient from developer point of
> view.
> > However, it is my personal view, others may differ.
>
> From developer point of view, you should use devtools/test-meson-builds.sh
> which does the "git clone" for you.
>
> This is what I have in ~/.config/dpdk/devel.config
> export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
> export DPDK_ABI_REF_VERSION=v22.11.1
Ok got it, thanks.
^ permalink raw reply [relevance 0%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 13:47 0% ` Akhil Goyal
@ 2022-12-05 15:37 0% ` Thomas Monjalon
2022-12-05 16:26 0% ` Akhil Goyal
2022-12-06 10:12 0% ` Ferruh Yigit
0 siblings, 2 replies; 200+ results
From: Thomas Monjalon @ 2022-12-05 15:37 UTC (permalink / raw)
To: David Marchand, Akhil Goyal
Cc: ci, Ferruh Yigit, Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li, dev, stable, Bruce Richardson,
Michael Santana, Abdullah Ömer Yamaç,
Aaron Conole
05/12/2022 14:47, Akhil Goyal:
> > On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > > Please, maintainers and CI teams, when you enable ABI checks in the
> > > > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > > > tag as a reference.
> > > > Thanks.
> > >
> > > Should we also add a tag on main repo, as new development does not happen
> > > on stable tree?
> >
> > You can fetch the v22.11.1 tag from the stable tree.
> Yes, that is an obvious option.
> But adding a tag on same repo is more convenient from developer point of view.
> However, it is my personal view, others may differ.
From developer point of view, you should use devtools/test-meson-builds.sh
which does the "git clone" for you.
This is what I have in ~/.config/dpdk/devel.config
export DPDK_ABI_REF_DIR=$root/dpdk-build/abiref
export DPDK_ABI_REF_VERSION=v22.11.1
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 12:36 0% ` David Marchand
@ 2022-12-05 13:47 0% ` Akhil Goyal
2022-12-05 15:37 0% ` Thomas Monjalon
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-12-05 13:47 UTC (permalink / raw)
To: David Marchand
Cc: ci, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
> On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > > Please, maintainers and CI teams, when you enable ABI checks in the
> > > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > > tag as a reference.
> > > Thanks.
> >
> > Should we also add a tag on main repo, as new development does not happen
> > on stable tree?
>
> You can fetch the v22.11.1 tag from the stable tree.
Yes, that is an obvious option.
But adding a tag on same repo is more convenient from developer point of view.
However, it is my personal view, others may differ.
-Akhil
^ permalink raw reply [relevance 0%]
* Re: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
2022-12-05 10:43 0% ` [EXT] " Akhil Goyal
@ 2022-12-05 12:36 0% ` David Marchand
2022-12-05 13:47 0% ` Akhil Goyal
0 siblings, 1 reply; 200+ results
From: David Marchand @ 2022-12-05 12:36 UTC (permalink / raw)
To: Akhil Goyal
Cc: ci, Thomas Monjalon, Ferruh Yigit, Andrew Rybchenko,
Ajit Khaparde, Qi Zhang, Jerin Jacob Kollanukkaran,
Raslan Darawsheh, Maxime Coquelin, Xia, Chenbo, Luca Boccassi,
Kevin Traynor, Christian Ehrhardt, Xueming(Steven) Li, dev,
stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
On Mon, Dec 5, 2022 at 11:44 AM Akhil Goyal <gakhil@marvell.com> wrote:
> > Please, maintainers and CI teams, when you enable ABI checks in the
> > main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> > tag as a reference.
> > Thanks.
>
> Should we also add a tag on main repo, as new development does not happen
> on stable tree?
You can fetch the v22.11.1 tag from the stable tree.
--
David Marchand
^ permalink raw reply [relevance 0%]
* RE: [EXT] Re: [PATCH v4 1/2] drivers: fix symbol exports when map is omitted
@ 2022-12-05 10:43 0% ` Akhil Goyal
2022-12-05 12:36 0% ` David Marchand
0 siblings, 1 reply; 200+ results
From: Akhil Goyal @ 2022-12-05 10:43 UTC (permalink / raw)
To: David Marchand, ci, Thomas Monjalon, Ferruh Yigit,
Andrew Rybchenko, Ajit Khaparde, Qi Zhang,
Jerin Jacob Kollanukkaran, Raslan Darawsheh, Maxime Coquelin,
Xia, Chenbo, Luca Boccassi, Kevin Traynor, Christian Ehrhardt,
Xueming(Steven) Li
Cc: dev, stable, Bruce Richardson, Michael Santana,
Abdullah Ömer Yamaç,
Aaron Conole
> On Fri, Dec 2, 2022 at 2:39 PM Aaron Conole <aconole@redhat.com> wrote:
> >
> > David Marchand <david.marchand@redhat.com> writes:
> >
> > > ld exports any global symbol by default if no version script is passed.
> > > As a consequence, the incriminated change let any public symbol leak
> > > out of the driver shared libraries.
> > >
> > > Hide again those symbols by providing a default map file which
> > > unexports any global symbol using a local: * catch-all statement.
> > >
> > > The checks are skipped for this default map file as it is intentionnally
> > > an empty map (see commit b67bdda86cd4 ("devtools: catch empty symbol
> > > maps")) and there is nothing else to check in this map.
> > >
> > > This change impacts the exported symbols, hence, bump the version in the
> > > ABI check to the v22.11.1 from the 22.11 LTS branch.
> > >
> > > Fixes: 7dde9c844a37 ("drivers: omit symbol map when unneeded")
> > > Cc: stable@dpdk.org
> > >
> > > Reported-by: Luca Boccassi <luca.boccassi@microsoft.com>
> > > Signed-off-by: David Marchand <david.marchand@redhat.com>
> > > Tested-by: Ferruh Yigit <ferruh.yigit@amd.com>
> > > Reviewed-by: Bruce Richardson <bruce.richardson@intel.com>
> > Acked-by: Aaron Conole <aconole@redhat.com>
>
> Series applied.
>
> Please, maintainers and CI teams, when you enable ABI checks in the
> main branch, or in the 22.11 LTS branch, use the dpdk-stable 22.11.1
> tag as a reference.
> Thanks.
Should we also add a tag on main repo, as new development does not happen
on stable tree?
Regards,
Akhil
^ permalink raw reply [relevance 0%]
Results 1801-2000 of ~18000 next (older) | prev (newer) | reverse | sort options + mbox downloads above
-- links below jump to the message on this page --
2021-09-13 8:45 [dpdk-dev] Questions about rte_eth_link_speed_to_str API Min Hu (Connor)
2021-09-16 2:56 ` [dpdk-dev] [RFC] ethdev: improve link speed to string Min Hu (Connor)
2021-09-16 6:22 ` Andrew Rybchenko
2021-09-16 8:16 ` Min Hu (Connor)
2021-09-16 8:21 ` Andrew Rybchenko
2021-09-17 0:43 ` Min Hu (Connor)
2023-01-19 11:41 3% ` Ferruh Yigit
2023-01-19 16:45 0% ` Stephen Hemminger
2022-04-20 8:16 [PATCH v1 0/5] Direct re-arming of buffers on receive side Feifei Wang
2023-01-04 7:30 ` [PATCH v3 0/3] " Feifei Wang
2023-01-04 7:30 ` [PATCH v3 1/3] ethdev: enable direct rearm with separate API Feifei Wang
2023-01-04 8:21 ` Morten Brørup
2023-01-04 8:51 ` 回复: " Feifei Wang
2023-01-04 10:11 4% ` Morten Brørup
2022-08-03 13:28 [dpdk-dev] [RFC PATCH 1/1] mldev: introduce machine learning device library jerinj
2023-02-03 8:42 ` [dpdk-dev] [PATCH v1 01/12] " Thomas Monjalon
2023-02-03 17:33 ` Stephen Hemminger
2023-02-03 20:18 2% ` Thomas Monjalon
2022-08-29 15:18 [RFC PATCH 0/3] Split logging out of EAL Bruce Richardson
2023-01-20 18:21 ` [PATCH v4 0/3] Split logging functionality " Bruce Richardson
2023-01-22 14:56 4% ` David Marchand
2023-01-23 14:24 3% ` Bruce Richardson
2023-01-23 14:31 3% ` David Marchand
2023-01-23 14:36 0% ` Bruce Richardson
2023-01-23 14:42 0% ` David Marchand
2022-09-29 10:29 [PATCH v2 0/4] add trace points in ethdev library Ankur Dwivedi
2022-12-14 12:10 ` [PATCH v3 1/4] ethdev: add trace points Ferruh Yigit
2022-12-15 6:49 ` Jerin Jacob
2023-01-12 9:10 ` Thomas Monjalon
2023-01-12 9:43 ` trace point symbols Morten Brørup
2023-01-13 11:22 3% ` Jerin Jacob
2022-10-14 17:23 [RFC 1/2] testpmd: make f_quit flag volatile Stephen Hemminger
2023-01-30 20:09 ` [PATCH v10 0/2] testpmd: handle signals safely Stephen Hemminger
2023-01-30 20:09 ` [PATCH v10 1/2] cmdline: handle EOF in cmdline_poll Stephen Hemminger
2023-01-30 22:12 3% ` Ferruh Yigit
2022-10-20 9:31 [PATCH V5] ethdev: fix one address occupies two indexes in MAC addrs Huisong Li
2023-02-01 13:15 3% ` [PATCH V7] ethdev: fix one address occupies two entries " Huisong Li
2023-02-02 12:36 3% ` [PATCH V8] " Huisong Li
2023-02-02 18:09 0% ` Ferruh Yigit
2022-11-23 10:26 [RFC PATCH 0/4] lcore telemetry improvements Robin Jarry
2022-12-07 16:21 ` [PATCH " Robin Jarry
2022-12-07 16:21 ` [PATCH 2/4] eal: allow applications to report their cpu usage Robin Jarry
2022-12-13 15:49 3% ` Robin Jarry
2022-12-13 16:39 0% ` Morten Brørup
2022-12-13 17:45 0% ` Tyler Retzlaff
2022-11-29 14:00 [PATCH] drivers: fix symbol exports when map is omitted David Marchand
2022-12-02 11:09 ` [PATCH v4 1/2] " David Marchand
2022-12-02 13:39 ` Aaron Conole
2022-12-05 10:23 ` David Marchand
2022-12-05 10:43 0% ` [EXT] " Akhil Goyal
2022-12-05 12:36 0% ` David Marchand
2022-12-05 13:47 0% ` Akhil Goyal
2022-12-05 15:37 0% ` Thomas Monjalon
2022-12-05 16:26 0% ` Akhil Goyal
2022-12-06 10:12 0% ` Ferruh Yigit
2022-12-06 10:18 ` David Marchand
2022-12-06 12:25 ` Ferruh Yigit
2022-12-07 18:00 5% ` Patrick Robb
2022-12-08 13:22 3% ` Thomas Monjalon
2022-12-08 16:06 0% ` Patrick Robb
2022-11-30 22:54 help with pthread_t deprecation / api changes Tyler Retzlaff
2022-12-02 8:03 ` Morten Brørup
2022-12-02 19:57 ` Tyler Retzlaff
2022-12-09 7:53 ` Thomas Monjalon
2022-12-09 16:48 3% ` Stephen Hemminger
2022-12-09 20:06 0% ` Tyler Retzlaff
2022-12-09 21:14 0% ` Thomas Monjalon
2022-12-09 22:38 0% ` Stephen Hemminger
2022-12-09 23:55 0% ` Tyler Retzlaff
2022-12-05 20:24 [PATCH 0/3] eal: rte_ctrl_thread_create API replacement Tyler Retzlaff
2022-12-05 20:24 ` [PATCH 3/3] eal: deprecate pthread control thread create API Tyler Retzlaff
2022-12-05 21:18 ` Stephen Hemminger
2022-12-06 0:24 3% ` Tyler Retzlaff
2022-12-06 17:28 ` [PATCH v2 0/3] eal: rte_ctrl_thread_create API replacement Tyler Retzlaff
2022-12-06 17:28 ` [PATCH v2 1/3] eal: add rte control thread create API Tyler Retzlaff
2022-12-07 9:13 ` Mattias Rönnblom
2022-12-07 16:38 3% ` Tyler Retzlaff
2022-12-08 21:59 0% ` Mattias Rönnblom
2022-12-06 5:54 [RFC 2/2] ethdev: add API to set process to primary or secondary Stephen Hemminger
2022-12-21 9:00 ` [RFC v3 0/2] add API to set process to active or standby Rongwei Liu
2022-12-21 9:00 ` [RFC v3 2/2] ethdev: " Rongwei Liu
2022-12-21 9:12 4% ` Jerin Jacob
2022-12-21 9:32 3% ` Rongwei Liu
2022-12-21 10:59 5% ` Jerin Jacob
2022-12-21 12:05 5% ` Rongwei Liu
2022-12-21 12:44 0% ` Jerin Jacob
2022-12-21 12:50 4% ` Rongwei Liu
2022-12-21 13:12 0% ` Jerin Jacob
2022-12-21 14:33 3% ` Rongwei Liu
2022-12-26 16:44 4% ` Ori Kam
2023-01-15 22:46 0% ` Thomas Monjalon
2022-12-06 10:16 4% [PATCH] devtools: update Meson setup command Thomas Monjalon
2022-12-06 11:29 1% 21.11.3 patches review and test Kevin Traynor
2022-12-13 11:48 0% ` Christian Ehrhardt
2022-12-16 7:55 0% ` YangHang Liu
2022-12-06 12:23 [PATCH 1/2] devtools: document test meson script config options Ferruh Yigit
2022-12-06 12:23 17% ` [PATCH 2/2] devtools: configure source repo to use as ABI reference Ferruh Yigit
2022-12-08 18:14 7% ` [EXT] " Akhil Goyal
2022-12-08 19:43 4% ` Thomas Monjalon
2022-12-09 4:16 4% ` Akhil Goyal
2022-12-09 8:22 8% ` David Marchand
2022-12-09 8:44 4% ` Ferruh Yigit
2022-12-09 9:02 ` [PATCH v2 1/2] devtools: document test meson script config options David Marchand
2022-12-09 9:02 13% ` [PATCH v2 2/2] devtools: configure source repo to use as ABI reference David Marchand
2022-12-21 15:02 4% ` David Marchand
2022-12-08 8:05 [PATCH 0/8] fix possible data truncation and conversion error Huisong Li
2022-12-09 11:04 3% ` [PATCH V2 00/11] telemetry: add u32 value type and hex integer string API Huisong Li
2022-12-09 18:24 0% ` Morten Brørup
2022-12-12 6:23 0% ` lihuisong (C)
2022-12-11 9:02 0% ` fengchengwen
2022-12-12 6:42 3% ` [PATCH V3 " Huisong Li
2022-12-12 10:31 0% ` Bruce Richardson
2022-12-12 11:02 0% ` Morten Brørup
2022-12-12 11:20 0% ` Bruce Richardson
2022-12-12 12:03 3% ` Morten Brørup
2022-12-12 12:16 3% ` Bruce Richardson
2022-12-13 11:00 0% ` Morten Brørup
2022-12-13 17:12 3% ` Bruce Richardson
2022-12-13 3:02 0% ` lihuisong (C)
2022-12-13 10:15 3% ` [PATCH V4 0/9] telemetry: fix data truncation and conversion error and add hex integer API Huisong Li
2022-12-14 12:32 3% ` [PATCH V5 0/8] " Huisong Li
2022-12-15 10:31 3% ` [PATCH V6 " Huisong Li
2022-12-16 1:54 3% ` [PATCH V7 " Huisong Li
2022-12-19 7:06 3% ` [PATCH V8 " Huisong Li
2023-01-16 12:06 0% ` lihuisong (C)
2023-01-30 10:39 0% ` lihuisong (C)
2022-12-12 15:10 3% [PATCH] cryptodev: add algo enums to string conversion APIs Akhil Goyal
2022-12-13 7:31 0% ` Ruifeng Wang
2022-12-13 7:37 0% ` Anoob Joseph
2022-12-13 8:22 0% ` Power, Ciara
2022-12-14 9:32 0% ` Zhang, Fan
2023-01-04 6:18 2% ` [PATCH v2] " Akhil Goyal
2023-01-05 10:56 0% ` Akhil Goyal
2022-12-13 15:07 3% [PATCH] ci: drop Travis configuration David Marchand
2022-12-13 18:27 4% [RFC PATCH 0/7] Standardize telemetry int types Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 6/7] telemetry: make internal int representation 64-bits Bruce Richardson
2022-12-13 18:27 3% ` [RFC PATCH 7/7] telemetry: change public API to use 64-bit signed values Bruce Richardson
2022-12-13 20:19 3% ` Morten Brørup
2022-12-14 17:53 0% ` Tyler Retzlaff
2022-12-15 2:39 0% ` lihuisong (C)
2022-12-14 17:38 ` [RFC PATCH 2/7] telemetry: add uint type as alias for u64 Tyler Retzlaff
2022-12-15 9:44 ` Bruce Richardson
2022-12-15 13:36 ` Thomas Monjalon
2022-12-15 13:58 4% ` Bruce Richardson
2022-12-19 10:37 0% ` Thomas Monjalon
2022-12-19 13:22 0% ` Bruce Richardson
2023-01-12 10:58 4% ` [PATCH v2 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 10:59 3% ` [PATCH v2 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-12 17:41 4% ` [PATCH v3 0/9] Standardize telemetry int types Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 8/9] telemetry: make internal int representation 64-bits Bruce Richardson
2023-01-12 17:41 3% ` [PATCH v3 9/9] telemetry: change public API to use 64-bit signed values Bruce Richardson
2023-01-13 16:39 0% ` [PATCH v3 0/9] Standardize telemetry int types Power, Ciara
2022-12-20 16:22 1% DPDK 21.11.3 released Kevin Traynor
2022-12-21 8:42 [RFC 1/9] ethdev: add IPv6 routing extension header definition Rongwei Liu
2023-01-19 3:11 ` [PATCH v2 0/8] add IPv6 routing extension support Rongwei Liu
2023-01-19 3:11 3% ` [PATCH v2 1/8] ethdev: add IPv6 routing extension header definition Rongwei Liu
2023-01-20 9:20 0% ` Andrew Rybchenko
2023-01-30 3:46 0% ` Rongwei Liu
2023-01-30 3:59 ` [PATCH v3 0/8] add IPv6 routing extension support Rongwei Liu
2023-01-30 3:59 3% ` [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition Rongwei Liu
2022-12-21 10:29 [RFC 0/5] add new port affinity item and affinity in Tx queue API Jiawei Wang
2022-12-21 10:29 2% ` [RFC 2/5] ethdev: introduce the affinity field " Jiawei Wang
2023-01-11 16:47 0% ` Ori Kam
2023-01-18 11:37 0% ` Thomas Monjalon
2023-01-18 14:44 0% ` Jiawei(Jonny) Wang
2023-01-18 16:31 0% ` Thomas Monjalon
2023-01-24 13:32 0% ` Jiawei(Jonny) Wang
2023-01-01 13:47 [PATCH] compressdev: fix end of comp PMD list macro conflict Michael Baum
2023-01-30 19:30 3% ` [EXT] " Akhil Goyal
2023-01-31 8:23 0% ` Akhil Goyal
2023-02-01 13:19 0% ` Akhil Goyal
2023-02-01 13:29 0% ` Michael Baum
2023-02-01 14:02 0% ` Akhil Goyal
2023-01-07 13:39 33% [PATCH] devtools: parallelize ABI check Thomas Monjalon
2023-01-09 9:34 23% ` [PATCH v2] " Thomas Monjalon
2023-01-10 11:08 4% ` Ferruh Yigit
2023-01-11 13:16 33% ` [PATCH v3] " Thomas Monjalon
2023-01-11 14:10 4% ` Bruce Richardson
2023-01-11 14:11 4% ` David Marchand
2023-01-11 17:04 4% ` Thomas Monjalon
2023-01-11 19:53 33% ` [PATCH v4] " Thomas Monjalon
2023-01-12 10:53 4% ` David Marchand
2023-01-12 14:14 4% ` Ferruh Yigit
2023-01-18 10:45 4% ` David Marchand
2023-01-18 11:43 4% ` Ferruh Yigit
2023-01-18 14:29 4% ` David Marchand
2023-01-07 16:18 [PATCH 1/3] eventdev/eth_rx: add params set/get APIs Naga Harish K S V
2023-01-18 10:22 4% ` Jerin Jacob
2023-01-20 8:58 0% ` Naga Harish K, S V
2023-01-20 9:32 0% ` Jerin Jacob
2023-01-20 10:33 0% ` Naga Harish K, S V
2023-01-23 9:31 0% ` Jerin Jacob
2023-01-23 18:07 0% ` Naga Harish K, S V
2023-01-23 18:04 ` [PATCH v2 " Naga Harish K S V
2023-01-24 4:29 ` Jerin Jacob
2023-01-24 13:07 ` Naga Harish K, S V
2023-01-25 4:12 ` Jerin Jacob
2023-01-25 9:52 ` Naga Harish K, S V
2023-01-25 10:38 3% ` Jerin Jacob
2023-01-25 16:32 0% ` Naga Harish K, S V
2023-01-28 10:53 0% ` Jerin Jacob
2023-01-28 17:21 3% ` Stephen Hemminger
2023-01-30 9:56 0% ` Naga Harish K, S V
2023-01-30 14:43 0% ` Jerin Jacob
2023-02-02 16:12 0% ` Naga Harish K, S V
2023-02-03 9:44 0% ` Jerin Jacob
2023-01-09 22:56 RFC abstracting atomics Tyler Retzlaff
2023-01-10 9:16 ` Bruce Richardson
2023-01-10 20:10 3% ` Tyler Retzlaff
2023-01-11 10:10 0% ` Bruce Richardson
2023-01-12 10:01 [PATCH v3 1/3] pcapng: comment option support for epb Amit Prakash Shukla
2023-01-24 11:21 4% ` [PATCH v4 " Amit Prakash Shukla
2023-01-24 11:21 2% ` [PATCH v4 2/3] graph: pcap capture for graph nodes Amit Prakash Shukla
2023-01-31 8:06 0% ` Jerin Jacob
2023-02-03 8:15 0% ` [EXT] " Amit Prakash Shukla
2023-02-03 8:19 4% ` [PATCH v5 1/3] pcapng: comment option support for epb Amit Prakash Shukla
2023-02-03 8:19 2% ` [PATCH v5 2/3] graph: pcap capture for graph nodes Amit Prakash Shukla
2023-01-12 11:21 [PATCH v5 0/6] add trace points in ethdev library Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 " Ankur Dwivedi
2023-01-20 8:40 ` [PATCH v6 1/6] eal: trace: add trace point emit for blob Ankur Dwivedi
2023-01-23 17:27 ` Ferruh Yigit
2023-01-25 15:02 ` [EXT] " Ankur Dwivedi
2023-01-25 16:09 2% ` Ferruh Yigit
2023-01-30 13:35 0% ` Ankur Dwivedi
2023-01-12 21:26 [PATCH] eal: abstract compiler atomics Tyler Retzlaff
2023-01-12 21:26 ` [PATCH] eal: introduce atomics abstraction Tyler Retzlaff
2023-01-31 22:42 ` Thomas Monjalon
2023-02-01 1:07 ` Honnappa Nagarahalli
2023-02-01 21:41 3% ` Tyler Retzlaff
2023-02-02 8:43 4% ` Morten Brørup
2023-02-02 19:00 4% ` Tyler Retzlaff
2023-02-02 20:44 0% ` Morten Brørup
2023-02-03 13:56 0% ` Bruce Richardson
2023-02-03 12:19 0% ` Bruce Richardson
2023-01-13 5:03 [RFC] Remove Kernel Network Interface (KNI) Stephen Hemminger
2023-01-13 8:12 ` Thomas Monjalon
2023-01-13 17:13 ` Stephen Hemminger
2023-01-13 18:34 ` Thomas Monjalon
2023-01-13 23:25 ` Stephen Hemminger
2023-01-14 22:21 3% ` Tyler Retzlaff
2023-01-16 15:37 [PATCH 0/5] dma/ioat: fix issues with stopping and restarting device Bruce Richardson
2023-01-16 15:37 3% ` [PATCH 5/5] test/dmadev: add tests for stopping and restarting dev Bruce Richardson
2023-01-16 17:37 ` [PATCH v2 0/6] dma/ioat: fix issues with stopping and restarting device Bruce Richardson
2023-01-16 17:37 3% ` [PATCH v2 6/6] test/dmadev: add tests for stopping and restarting dev Bruce Richardson
2023-01-17 10:16 3% [RFC] Fix cryptodev socket id for devices on unknown NUMA node Didier Pallard
2023-01-17 11:32 0% ` Morten Brørup
2023-01-23 9:02 4% Minutes of Technical Board Meeting, 2022-09-06 Thomas Monjalon
2023-01-23 9:03 4% Minutes of Technical Board Meeting, 2022-11-30 Thomas Monjalon
2023-01-24 10:33 3% DPDK Release Status Meeting 2023-01-19 Mcnamara, John
2023-01-25 22:36 3% deprecation notice process / clarification Tyler Retzlaff
2023-01-27 12:47 0% ` Thomas Monjalon
2023-01-28 13:08 [PATCH 0/2] add new mhpsdp hw port in the flow item and Tx queue API Jiawei Wang
2023-01-28 13:08 2% ` [PATCH 2/2] ethdev: introduce the mhpsdp hwport field in " Jiawei Wang
[not found] <http://patches.dpdk.org/project/dpdk/cover/20221221102934.13822-1-jiaweiw@nvidia.com/>
2023-01-30 17:00 ` [PATCH v2 0/2] add new PHY affinity in the flow item and " Jiawei Wang
2023-01-30 17:00 2% ` [PATCH v2 2/2] ethdev: introduce the PHY affinity field in " Jiawei Wang
2023-01-31 17:26 3% ` Thomas Monjalon
2023-02-01 9:45 0% ` Jiawei(Jonny) Wang
2023-02-01 9:05 0% ` Andrew Rybchenko
2023-02-01 15:50 0% ` Jiawei(Jonny) Wang
2023-02-02 9:28 0% ` Andrew Rybchenko
2023-02-02 14:43 0% ` Thomas Monjalon
2023-01-31 3:02 [PATCH v3 1/8] ethdev: add IPv6 routing extension header definition Stephen Hemminger
2023-01-31 9:36 ` [PATCH v4 0/3] add IPv6 routing extension support Rongwei Liu
2023-01-31 9:36 3% ` [PATCH v4 1/3] ethdev: add IPv6 routing extension header definition Rongwei Liu
2023-02-01 9:21 0% ` Andrew Rybchenko
2023-02-01 9:27 0% ` Rongwei Liu
2023-02-01 9:31 0% ` Andrew Rybchenko
2023-02-01 11:35 ` [PATCH v5 0/3] add IPv6 routing extension support Rongwei Liu
2023-02-01 11:35 3% ` [PATCH v5 1/3] ethdev: add IPv6 routing extension header definition Rongwei Liu
[not found] <20220825024425.10534-1-lihuisong@huawei.com>
2022-12-06 9:26 ` [PATCH V4 0/5] app/testpmd: support mulitple process attach and detach port Huisong Li
2023-01-10 16:51 3% ` Ferruh Yigit
2023-01-11 0:53 0% ` lihuisong (C)
2023-01-11 10:27 3% ` Ferruh Yigit
2023-01-11 10:46 0% ` Ferruh Yigit
2023-01-12 2:26 0% ` lihuisong (C)
2023-01-18 14:12 0% ` Thomas Monjalon
2023-01-19 10:31 0% ` lihuisong (C)
2023-01-19 14:35 0% ` Thomas Monjalon
2023-01-28 1:39 0% ` lihuisong (C)
2023-01-31 3:33 3% ` [PATCH V5 0/5] app/testpmd: support multiple " Huisong Li
2023-01-31 3:33 2% ` [PATCH V5 2/5] ethdev: fix skip valid port in probing callback Huisong Li
2023-02-01 13:44 [PATCH v5 1/3] ethdev: add IPv6 routing extension header definition Thomas Monjalon
2023-02-02 10:00 ` [PATCH v6 0/3] add IPv6 routing extension support Rongwei Liu
2023-02-02 10:00 3% ` [PATCH v6 1/3] ethdev: add IPv6 routing extension header definition Rongwei Liu
2023-02-02 19:23 Sign changes through function signatures Ben Magistro
2023-02-02 20:26 ` Tyler Retzlaff
2023-02-02 20:45 3% ` Thomas Monjalon
2023-02-02 21:26 3% ` Morten Brørup
2023-02-03 12:05 4% ` Bruce Richardson
[not found] <20221221102934.13822-1-jiaweiw@nvidia.com/>
2023-02-03 5:07 ` [PATCH v3 0/2] add new PHY affinity in the flow item and Tx queue API Jiawei Wang
2023-02-03 5:07 6% ` [PATCH v3 1/2] ethdev: introduce the PHY affinity field in " Jiawei Wang
2023-02-03 13:33 ` [PATCH v4 0/2] add new PHY affinity in the flow item and " Jiawei Wang
2023-02-03 13:33 6% ` [PATCH v4 1/2] ethdev: introduce the PHY affinity field in " Jiawei Wang
2023-02-03 8:08 6% [PATCH] doc: update NFP documentation with Corigine information Chaoyong He
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).