Re: [dpdk-dev] [WARNING: UNSCANNABLE EXTRACTION FAILED][WARNING: UNSCANNABLE EXTRACTION FAILED] [PATCH v5] doc: mtr: add API walk through
On Fri, Aug 6, 2021 at 11:16 PM Dumitrescu, Cristian wrote: > > Hi Jerin, Hi Cristian, I will next version with your suggestions. > > > +API Walk-through > > + > > + > > +.. _figure_rte_mtr_chaining: > > + > > +.. figure:: img/rte_mtr_meter_chaining.* > > + > > + Meter components > > + > > +This section will introduce the reader to the critical APIs to use > > +the traffic meter and policing library. > > + > > +In general, the application performs the following steps to configure the > > +traffic meter and policing library. > > + > > +#. Application gets the meter driver capabilities using > > ``rte_mtr_capabilities_get()``. > > +#. The application creates the required meter profiles by using the > > + ``rte_mtr_meter_profile_add()`` API function. > > +#. The application creates the required meter policies by using the > > + ``rte_mtr_meter_policy_add()`` API function. > > +#. One of the previously created meter profile > > + (``struct rte_mtr_params::meter_profile_id``) and meter policy > > + (``struct rte_mtr_params::meter_policy_id``) are provided as arguments > > + at this step. > > You somehow dropped the first statement from this last bullet: > > The application creates a meter object using the rte_mtr_create() API > function. > > > +#. The application enables the meter object execution as part of the flow > > action > > + processing by calling the ``rte_flow_create()`` API function with one > > of the > > + flow action set to ``RTE_FLOW_ACTION_TYPE_METER`` and the associated > > + meter object ID set to this meter object. > > +#. The API allows chaining the meter objects to create complex metering > > topology > > + by the following methods. > > + > > + * Stacking multiple ``rte_flow_action`` as > > + ``RTE_FLOW_ACTION_TYPE_METER`` with ``struct > > rte_flow_action_meter::mtr_id`` > > + as meter ID. The last added RTE_FLOW_ACTION_TYPE_METER object > > represent as > > + leaf node (closest to ethdev receive queue) > > + > > Stacking might point people to reverse order execution of actions, which is > not the case, as the flow actions are executed sequentially from first to > last. Also the last meter action is not the last flow action (your reference > to leaf node?), as the last flow action must be the END action, right? > > How about: > * Adding multiple flow actions of the type > ``RTE_FLOW_ACTION_TYPE_METER`` to the same flow. Each of the meter action > typically refers to a different meter object. > > I was suggesting a similar diagram for this case, but it might be too much to > ask for :) > > > + * As show in :numref:`figure_rte_mtr_chaining` specify > > + ``struct rte_mtr_meter_policy_params::actions`` action as > > + ``RTE_FLOW_ACTION_TYPE_METER`` per color. > > I would add a high level statement before yours, something like: > * Adding one (or multiple) actions of the type > ``RTE_FLOW_ACTION_TYPE_METER`` to the list of meter actions specified per > color. > > Regards, > Cristian
[dpdk-dev] [PATCH v6] doc: mtr: add API walk through
From: Jerin Jacob Added a diagram to document meter library components and added text for steps performed by the application to configure the traffic meter and policing library. Signed-off-by: Jerin Jacob --- v2: Fix long lines in svg file to avoid patch apply issue v3: Fix all Thomas's comments at http://patches.dpdk.org/project/dpdk/patch/20210804113410.3604616-1-jer...@marvell.com/ v4: Fix all Cristian's commentss at http://patches.dpdk.org/project/dpdk/patch/20210805101046.4091894-1-jer...@marvell.com/ v5: Fix version number in the patch v6: Fix all Cristian's comments t http://patches.dpdk.org/project/dpdk/patch/20210806094518.807965-1-jer...@marvell.com/ .../prog_guide/img/rte_mtr_meter_chaining.svg | 1600 + .../traffic_metering_and_policing.rst | 41 + lib/ethdev/rte_mtr.h |4 +- 3 files changed, 1643 insertions(+), 2 deletions(-) create mode 100644 doc/guides/prog_guide/img/rte_mtr_meter_chaining.svg diff --git a/doc/guides/prog_guide/img/rte_mtr_meter_chaining.svg b/doc/guides/prog_guide/img/rte_mtr_meter_chaining.svg new file mode 100644 index 00..7214c5dc2b --- /dev/null +++ b/doc/guides/prog_guide/img/rte_mtr_meter_chaining.svg @@ -0,0 +1,1600 @@ + + + + +http://purl.org/dc/elements/1.1/"; xmlns:cc="http://creativecommons.org/ns#"; + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; + xmlns:svg="http://www.w3.org/2000/svg"; xmlns="http://www.w3.org/2000/svg"; + xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"; + xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"; width="233mm" height="198mm" + viewBox="0 0 233 198" version="1.1" id="svg8" inkscape:version="0.92.4 (5da689c313, + 2019-01-14)" sodipodi:docname="meter_new.svg"> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +image/svg+xml http://purl.org/dc/dcmitype/StillImage"; /> + + + + + + + + + + + + + + + + + RTE_FLOW_ITEM + + RTE_FLOW_ACTION_TYPE_METER + + + + + RED + + YELLOW + + GREEN + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + RED + + YELLOW + + GREEN + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + + CIR + + CBS + + EBS + + PIR + + PBS + + EIR + + + + CIR + + CBS + + EBS + + PIR + + PBS + + EIR + + + RED + + YELLOW + + GREEN + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + + + CIR + + CBS + + EBS + + PIR + + PBS + + EIR + + + RED + + YELLOW + + GREEN + + RTE_FLOW_ACTION_METER + + RTE_FLOW_ACTION + + RTE_FLOW_ACTION + + + + + + + + + + + + + + diff --git a/doc/guides/prog_guide/traffic_metering_and_policing.rst b/doc/guides/prog_guide/traffic_metering_and_policing.rst index c0537e653c..b29459c7cb 100644 --- a/doc/guides/prog_guide/traffic_metering_and_policing.rst +++ b/doc/guides/prog_guide/traffic_metering_and_policing.rst @@ -20,6 +20,7 @@ The main features are: and RFC 4115 Two Rate Three Color Marker (trTCM) * Policer actions (per meter output color): recolor, drop * Statistics (per policer output color) +* Chaining multiple meter objects Configuration steps --- @@ -64,3 +65,43 @@ The processing done for each input packet hitting an MTR object is: * Statistics: The set of counters maintained for each MTR object is configurable and subject to the implementation support. This set includes the number of packets and bytes dropped or passed for each output color. + +API Walk-through + + +.. _figure_rte_mtr_chaining: + +.. figure:: img/rte_mtr_meter_chaining.* + + Meter components + +This section will introduce the reader to the critical APIs to use +the traffic meter and policing library. + +In general, the application performs the following steps to configure the +traffic meter and policing library. + +#. Application gets the meter driver capabilities using ``rte_mtr_capabilities_get()``. +#. The application creates the required meter profiles by using the + ``rte_mtr_meter_profile_add()`` API function. +#. The application creates the required meter policies by using the + ``rte_mtr_meter_policy_add()`` API function
[dpdk-dev] [PATCH] vhost: fix coredump on port deletion
The rte_vhost_driver_unregister() and vhost_user_read_cb()
can be called at the same time by 2 threads.
Eg thread1 calls rte_vhost_driver_unregister() and frees memory of conn,
then thread2 calls vhost_user_read_cb() and access invalid memory of
conn.
The fix is to move the "fdset_try_del" in front of free memory of conn ,
then avoid the race condition.
Fixes: 52d874dc6705 ("vhost: fix crash on closing in client mode")
Signed-off-by: Gaoxiang Liu
---
lib/vhost/socket.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/lib/vhost/socket.c b/lib/vhost/socket.c
index 5d0d728d5..bc7278e8a 100644
--- a/lib/vhost/socket.c
+++ b/lib/vhost/socket.c
@@ -1024,6 +1024,19 @@ rte_vhost_driver_unregister(const char *path)
for (i = 0; i < vhost_user.vsocket_cnt; i++) {
struct vhost_user_socket *vsocket = vhost_user.vsockets[i];
+ if (vsocket->is_server) {
+ /*
+* If r/wcb is executing, release vhost_user's
+* mutex lock, and try again since the r/wcb
+* may use the mutex lock.
+*/
+ if (fdset_try_del(&vhost_user.fdset,
vsocket->socket_fd) == -1) {
+ pthread_mutex_unlock(&vhost_user.mutex);
+ goto again;
+ }
+} else if (vsocket->reconnect)
+ vhost_user_remove_reconnect(vsocket);
+
if (!strcmp(vsocket->path, path)) {
pthread_mutex_lock(&vsocket->conn_mutex);
for (conn = TAILQ_FIRST(&vsocket->conn_list);
@@ -1056,21 +1069,8 @@ rte_vhost_driver_unregister(const char *path)
pthread_mutex_unlock(&vsocket->conn_mutex);
if (vsocket->is_server) {
- /*
-* If r/wcb is executing, release vhost_user's
-* mutex lock, and try again since the r/wcb
-* may use the mutex lock.
-*/
- if (fdset_try_del(&vhost_user.fdset,
- vsocket->socket_fd) == -1) {
- pthread_mutex_unlock(&vhost_user.mutex);
- goto again;
- }
-
close(vsocket->socket_fd);
unlink(path);
- } else if (vsocket->reconnect) {
- vhost_user_remove_reconnect(vsocket);
}
pthread_mutex_destroy(&vsocket->conn_mutex);
--
2.32.0
[dpdk-dev] [Bug 781] why use rte_eth_dev_start/stop instead of rte_eth_set_link_up/down in kni_config_network_interface function in examples/kni/main.c
https://bugs.dpdk.org/show_bug.cgi?id=781 Bug ID: 781 Summary: why use rte_eth_dev_start/stop instead of rte_eth_set_link_up/down in kni_config_network_interface function in examples/kni/main.c Product: DPDK Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: jinag12...@gmail.com Target Milestone: --- why use rte_eth_dev_start/stop instead of rte_eth_set_link_up/down in kni_config_network_interface function in examples/kni/main.c -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] 回复: [PATCH] doc: announce the deprecation of lcore state FINISHED
On Thu, Aug 5, 2021 at 11:43 AM Feifei Wang wrote: > > > -邮件原件- > > 发件人: dev 代表 Honnappa Nagarahalli > > 发送时间: Saturday, July 31, 2021 3:59 AM > > 收件人: dev@dpdk.org; Honnappa Nagarahalli > > ; tho...@monjalon.net; > > konstantin.anan...@intel.com; Feifei Wang (Arm Technology China) > > > > 抄送: Ruifeng Wang ; nd > > 主题: [dpdk-dev] [PATCH] doc: announce the deprecation of lcore state > > FINISHED > > > > Lcore state FINISHED is used by the worker thread to indicate that it has > > completed the assigned task. The state is changed to WAIT by another > > thread after it observes the updated state. This additional step is > > redundant. > > After this deprecation, the worker thread will update the state to WAIT. > > > > Signed-off-by: Honnappa Nagarahalli > > Reviewed-by: Ruifeng Wang > > --- > Acked-by: Feifei Wang Acked-by: Jerin Jacob > > > More discussion at: > > http://patches.dpdk.org/project/dpdk/patch/20210224212018.17576-4- > > honnappa.nagaraha...@arm.com/ > > > > doc/guides/rel_notes/deprecation.rst | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index 9584d6bfd7..3adbde9e94 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -11,6 +11,10 @@ here. > > Deprecation Notices > > --- > > > > +* eal: The lcore state FINISHED will be removed from the enum > > + rte_lcore_state_t. The lcore state WAIT is enough to represent the > > +same > > + state. > > + > > * kvargs: The function ``rte_kvargs_process`` will get a new parameter > >for returning key match count. It will ease handling of no-match case. > > > > -- > > 2.17.1 >
Re: [dpdk-dev] [PATCH] doc: announce SA config option struct changes
On Thu, Aug 5, 2021 at 3:44 PM Hemant Agrawal wrote: > > Acked-by: Hemant Agrawal Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH 2/2] doc: announce eth new offload flag and group field
On Wed, Aug 4, 2021 at 5:59 PM Andrew Rybchenko wrote: > > On 8/4/21 11:08 AM, Slava Ovsiienko wrote: > >> -Original Message- > >> From: dev On Behalf Of Xueming Li > >> Sent: Monday, August 2, 2021 16:11 > >> Cc: dev@dpdk.org; Xueming(Steven) Li ; Ray Kinsella > >> > >> Subject: [dpdk-dev] [PATCH 2/2] doc: announce eth new offload flag and > >> group field > >> > >> To support shared Rx queue, this patch announces new offload flag > >> RTE_ETH_RX_OFFLOAD_SHARED_RXQ and new shared_group field to struct > >> rte_eth_rxconf in DPDK v21.11. > >> > >> [1] mail list discussion: > >> https://mails.dpdk.org/archives/dev/2021-July/215575.html > >> > >> Signed-off-by: Xueming Li > > > > We need this change to handle shared queues - the same queue > > object can be shared by multiple ports, and releasing routine should > > know exactly on which port_id/queue_id object is being released. > > > > Acked-by: Viacheslav Ovsiienko > > > > Acked-by: Andrew Rybchenko Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH] doc: announce IPsec xform struct changes
On Wed, Aug 4, 2021 at 11:05 PM Ananyev, Konstantin wrote: > > > > > > IPsec xform struct would be updated to include IPsec SA lifetime > > > configuration. The existing member 'esn_soft_limit' would only track > > > ESN. And as sequence number control is getting introduced, > > > 'esn_soft_limit' may not indicate the number of packets processed. > > > Replace that with a new structure to cover all lifetime cases with > > > support for specifying both soft and hard lifetimes. > > > > > > ESN control introduced by: > > > http://patches.dpdk.org/project/dpdk/patch/20210713133542.3550525-4- > > > radu.nico...@intel.com/ > > > > > > Signed-off-by: Anoob Joseph > > > --- > > Acked-by: Akhil Goyal > > > > Acked-by: Konstantin Ananyev Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH v2 1/2] ethdev: announce change to action modify data
On Wed, Aug 4, 2021 at 5:40 PM Andrew Rybchenko wrote: > > On 8/3/21 9:10 PM, Ajit Khaparde wrote: > > On Tue, Aug 3, 2021 at 1:58 AM Ori Kam wrote: > >> > >> In the current implementation, > >> the action rte_flow_action_modify_field is not well defined > >> for fields larger than 64 bits (for example IPv6 source) > >> In addition, the byte order is also not well defined. > >> > >> Both of those issue should be fixed. > >> > >> Signed-off-by: Ori Kam > >> Acked-by: Matan Azrad > > Acked-by: Ajit Khaparde > > Acked-by: Andrew Rybchenko Acked-by: Jerin Jacob >
Re: [dpdk-dev] [PATCH v2 2/2] ethdev: announce moving to general modify function
On Tue, Aug 3, 2021 at 11:35 PM Ajit Khaparde wrote: > > On Tue, Aug 3, 2021 at 1:58 AM Ori Kam wrote: > > > > Currently there is a dedicated modify function for each > > field that the application wants to change. > > For example: > > rte_flow_action_type_set_tp_port to modify destination port of UDP/TCP. > > rte_flow_action_type_set_ipv4_dst to modify destination of IPv4. > > > > A new function rte_flow_action_modify_field DPDK added the ability > > to use the same function to modify any field, in addition to be able to > > modify the value based on different field and not just immediate value. > > > > Signed-off-by: Ori Kam > > Acked-by: Matan Azrad > Acked-by: Ajit Khaparde Acked-by: Jerin Jacob > > > --- > > V2: > > Fix typo. > > --- > > doc/guides/rel_notes/deprecation.rst | 3 +++ > > 1 file chanAcked-by: Jerin Jacob ed, 3 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index b530616281..77491c322f 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -162,3 +162,6 @@ Deprecation Notices > > * ethdev: The struct ``rte_flow_action_modify_data`` will be modified > >to support modifying larger fields than 64 bits. > >In addition, documentation will be updated to clarify byte order. > > + > > +* ethdev: Announce moving from dedicated modify function for each field, > > + to using the general ``rte_flow_modify_field`` action. > > -- > > 2.25.1 > >
Re: [dpdk-dev] [PATCH] doc: announce restructuring of crypto session structs
On Thu, Aug 5, 2021 at 9:51 AM Anoob Joseph wrote: > > > Subject: [PATCH] doc: announce restructuring of crypto session structs > > > > The structures rte_cryptodev_sym_session and rte_cryptodev_asym_session are > > not used by the application directly. The application just need an opaque > > pointer > > which it can attach to rte_crypto_op while enqueue. > > Hence, these structures can be internal to library hidden from the user. > > > > Signed-off-by: Akhil Goyal > > --- > > doc/guides/rel_notes/deprecation.rst | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index f81bd87f10..7140e345b6 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -151,6 +151,11 @@ Deprecation Notices > > * cryptodev: The APIs for interfacing between library and PMD will be > > marked > >as internal APIs in DPDK 21.11. > > > > +* cryptodev: Hide structures ``rte_cryptodev_sym_session`` and > > + ``rte_cryptodev_asym_session`` to remove unnecessary indirection > > +between > > + session and the private data of session. An opaque pointer can be > > +exposed > > + directly to application which can be attached to the ``rte_crypto_op``. > > + > > * security: The functions ``rte_security_set_pkt_metadata`` and > >``rte_security_get_userdata`` will be made inline functions and > > additional > >flags will be added in structure ``rte_security_ctx`` in DPDK 21.11. > > -- > > Acked-by: Anoob Joseph Acked-by: Jerin Jacob > > >
Re: [dpdk-dev] [EXT] Re: [PATCH] doc: announce changes in security session struct
On Thu, Aug 5, 2021 at 9:45 AM Anoob Joseph wrote: > > > Subject: [EXT] Re: [PATCH] doc: announce changes in security session struct > > > > > > On Tue, Aug 3, 2021 at 5:36 AM Ananyev, Konstantin > > wrote: > > > > > > > > > > The structure rte_security_session is not directly used > > > > by the application. The application just need an opaque > > > > pointer to attached to the mbuf or rte_crypto_op while > > > > enqueue. Hence, it can be hidden inside the library > > > > and would prevent unnecessary indirection to the priv > > > > session data in fastpath. > > > > > > > > Signed-off-by: Akhil Goyal > > > > --- > > > > doc/guides/rel_notes/deprecation.rst | 4 > > > > 1 file changed, 4 insertions(+) > > > > > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > > > index c540c90f8e..8da1c2648c 100644 > > > > --- a/doc/guides/rel_notes/deprecation.rst > > > > +++ b/doc/guides/rel_notes/deprecation.rst > > > > @@ -159,3 +159,7 @@ Deprecation Notices > > > > * security: The functions ``rte_security_set_pkt_metadata`` and > > > >``rte_security_get_userdata`` will be made inline functions and > > > > additional > > > >flags will be added in structure ``rte_security_ctx`` in DPDK 21.11. > > > > + > > > > +* security: Hide stucture ``rte_security_session`` and expose an opaque > > > > + pointer for the private data to the application which can be attached > > > > + to the packet while enqueuing. > > > > -- > > > > > > Acked-by: Konstantin Ananyev > > Acked-by: Ajit Khaparde > > Acked-by: Anoob Joseph Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH 1/2] doc: announce ipsec rte_ipsec_sa_prm structure changes
On Thu, Aug 5, 2021 at 4:10 PM Ananyev, Konstantin wrote: > > > > > > > Signed-off-by: Radu Nicolau > > --- > > doc/guides/rel_notes/deprecation.rst | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > > b/doc/guides/rel_notes/deprecation.rst > > index f4a4d00db2..b87fa54e67 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -193,3 +193,6 @@ Deprecation Notices > >reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and > > other > >information from the crypto/security operation. This field will be used > > to > >communicate events such as soft expiry with IPsec in lookaside mode. > > + > > + * ipsec: The structure ``rte_ipsec_sa_prm`` will be extended with a new > > + field ``hdr_l3_len`` to configure tunnel l3 header lenght. > > -- > > Acked-by: Konstantin Ananyev Acked-by: Jerin Jacob > > > 2.25.1 >
Re: [dpdk-dev] [PATCH 2/2] fib: announce experimental tag removal of the fib API
On Thu, Aug 5, 2021 at 7:23 PM Walsh, Conor wrote: > > > This patch announces the experimental tag removal of all fib APIs, > > which have been experimental for 2 years. > > API will be promoted to stable in DPDK 21.11 > > > > Signed-off-by: Vladimir Medvedkin > > --- > > doc/guides/rel_notes/deprecation.rst | 2 ++ > > 1 file changed, 2 insertions(+) > > Acked-by: Conor Walsh Acked-by: Jerin Jacob
Re: [dpdk-dev] [PATCH 1/2] rib: announce experimental tag removal of the rib API
On Thu, Aug 5, 2021 at 4:56 PM Vladimir Medvedkin wrote: > > This patch announces the experimental tag removal of all rib APIs, > which have been experimental for 2 years. > API will be promoted to stable in DPDK 21.11 > > Signed-off-by: Vladimir Medvedkin Acked-by: Jerin Jacob > --- > doc/guides/rel_notes/deprecation.rst | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index f4a4d00..afb599a 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -193,3 +193,5 @@ Deprecation Notices >reserved bytes to 2 (from 3), and use 1 byte to indicate warnings and other >information from the crypto/security operation. This field will be used to >communicate events such as soft expiry with IPsec in lookaside mode. > + > +* rib: The ``rib`` library will be promoted from experimental to stable. > -- > 2.7.4 >
Re: [dpdk-dev] [PATCH] doc: abstract the behaviour of rte_ctrl_thread_create
30/07/2021 23:44, Honnappa Nagarahalli: > The current expected behaviour of the function rte_ctrl_thread_create > is rigid which makes the implementation of the function complex. > Make the expected behaviour abstract to allow for simplified > implementation. > > With this change, the calls to pthread_setaffinity_np can be moved > to the control thread. This will avoid the use of > pthread_barrier_wait and simplify the synchronization mechanism > between rte_ctrl_thread_create and the calling thread. > > Signed-off-by: Honnappa Nagarahalli > --- > +* eal: The expected behaviour of the function ``rte_ctrl_thread_create`` > + abstracted to allow for simplified implementation. The new behaviour is > + as follows: > + Creates a control thread with the given name. 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. I don't understand what is different of the current API: * Wrapper to pthread_create(), pthread_setname_np() and * pthread_setaffinity_np(). 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. Anyway, there is not enough meaningful acks.
Re: [dpdk-dev] 回复: [PATCH] doc: announce the deprecation of lcore state FINISHED
> > > Lcore state FINISHED is used by the worker thread to indicate that it has > > > completed the assigned task. The state is changed to WAIT by another > > > thread after it observes the updated state. This additional step is > > > redundant. > > > After this deprecation, the worker thread will update the state to WAIT. > > > > > > Signed-off-by: Honnappa Nagarahalli > > > Reviewed-by: Ruifeng Wang > > > --- > > Acked-by: Feifei Wang > > Acked-by: Jerin Jacob Acked-by: Thomas Monjalon Applied, thanks.
Re: [dpdk-dev] [PATCH] doc: announce change in crypto adapter metadata
> > >> In crypto adapter metadata, first 8 bytes of request info is a space > > >> holder for response info. For better clarity, reserved field should be > > >> removed from request info. New space for response info can be made by > > >> changing type of event crypto metadata to structure from union. > > >> > > >> Signed-off-by: Shijith Thotton > > > Acked-by: Akhil Goyal > > > > > Acked-by: Ray Kinsella > > + @Gujjar, Abhinandan S > > Acked-by: Jerin Jacob Applied, thanks.
Re: [dpdk-dev] [EXT] [PATCH v2] doc: announce change in crypto raw data vector
05/08/2021 16:04, Akhil Goyal: > > The current crypto raw data vectors need to be extended to support > > out of place processing. It is proposed to add additional desl_sgl > > to provide details for destination sgl. > > The same is also extended to support rte_security usecases, where > > we need total data length to know how much additional memory space > > is available in buffer other than data length so that driver/HW > > can write expanded size data after encryption. > > > > Signed-off-by: Gagandeep Singh > > Signed-off-by: Hemant Agrawal > > --- > > +* cryptodev: The structure ``rte_crypto_sym_vec`` would be updated to add > > + ``dest_sgl`` to support out of place processing. This field will be null > > for > > + inplace processing. This change is targeted for DPDK 21.11 > > + > > +* cryptodev: The structure ``rte_crypto_vec`` would be updated to add > > + ``tot_len`` to support total buffer length. This is required for security > > + cases like IPsec and PDCP encryption offload to know how much additional > > + memory space is available in buffer other than data length so that > > driver/HW > > + can write expanded size data after encryption. This change is targeted > > for > > + DPDK 21.11 > > + > Acked-by: Akhil Goyal Acked-by: Konstantin Ananyev Acked-by: Thomas Monjalon Applied, thanks.
Re: [dpdk-dev] [EXT] Re: [PATCH] doc: announce changes in security session struct
> > > > > The structure rte_security_session is not directly used > > > > > by the application. The application just need an opaque > > > > > pointer to attached to the mbuf or rte_crypto_op while > > > > > enqueue. Hence, it can be hidden inside the library > > > > > and would prevent unnecessary indirection to the priv > > > > > session data in fastpath. > > > > > > > > > > Signed-off-by: Akhil Goyal > > > > > --- > > > > > +* security: Hide stucture ``rte_security_session`` and expose an > > > > > opaque > > > > > + pointer for the private data to the application which can be > > > > > attached > > > > > + to the packet while enqueuing. > > > > > > > > Acked-by: Konstantin Ananyev > > > Acked-by: Ajit Khaparde > > Acked-by: Anoob Joseph > Acked-by: Jerin Jacob Applied, thanks.
Re: [dpdk-dev] [PATCH] doc: announce IPsec xform struct changes
> > > > IPsec xform struct would be updated to include IPsec SA lifetime > > > > configuration. The existing member 'esn_soft_limit' would only track > > > > ESN. And as sequence number control is getting introduced, > > > > 'esn_soft_limit' may not indicate the number of packets processed. > > > > Replace that with a new structure to cover all lifetime cases with > > > > support for specifying both soft and hard lifetimes. > > > > > > > > ESN control introduced by: > > > > http://patches.dpdk.org/project/dpdk/patch/20210713133542.3550525-4- > > > > radu.nico...@intel.com/ > > > > > > > > Signed-off-by: Anoob Joseph > > > Acked-by: Akhil Goyal > > Acked-by: Konstantin Ananyev > Acked-by: Jerin Jacob That's a lot of acks from Marvell but looks OK. Applied, thanks.
Re: [dpdk-dev] [PATCH] doc: announce SA config option struct changes
> > Propose new fields to support offloads like > > - IPsec inner checksum(L3/L4) > > - IPsec tunnel header verification > > - TSO > > - etc > > in the structure ``rte_security_ipsec_sa_options``. > > > > Signed-off-by: Archana Muniganti > > Signed-off-by: Tejasree Kondoj > > Acked-by: Akhil Goyal > > --- > > Proposal for changes are floated as per below links. > > https://mails.dpdk.org/archives/dev/2021-June/212977.html > > https://mails.dpdk.org/archives/dev/2021-July/213484.html > > https://mails.dpdk.org/archives/dev/2021-July/214521.html > > > Acked-by: Radu Nicolau Acked-by: Hemant Agrawal Acked-by: Jerin Jacob Applied, thanks.
Re: [dpdk-dev] [PATCH v2] vhost: announce experimental tag removal of vhost APIs
30/07/2021 10:24, Chenbo Xia: > This patch announces the experimental tag removal of 10 vhost APIs, > which have been experimental for more than 2 years. All APIs could > be made stable in DPDK 21.11. > > Signed-off-by: Chenbo Xia > Acked-by: Maxime Coquelin > --- > +* vhost: The experimental tags of ``rte_vhost_driver_get_protocol_features``, > + ``rte_vhost_driver_get_queue_num``, ``rte_vhost_crypto_create``, > + ``rte_vhost_crypto_free``, ``rte_vhost_crypto_fetch_requests``, > + ``rte_vhost_crypto_finalize_requests``, ``rte_vhost_crypto_set_zero_copy``, > + ``rte_vhost_va_from_guest_pa``, ``rte_vhost_extern_callback_register``, > + and ``rte_vhost_driver_set_protocol_features`` APIs will be removed and the > + APIs will be made stable in DPDK 21.11. Acked-by: Fan Zhang Acked-by: Marvin Liu "APIs" is replaced with "API functions" for correctness. Applied, thanks.
Re: [dpdk-dev] [PATCH v2 1/2] vhost: announce vDPA driver API marking as internal
30/07/2021 10:12, Maxime Coquelin: > This patch announces the marking of all the vDPA driver APIs > as internal. > > Acked-by: Chenbo Xia > Signed-off-by: Maxime Coquelin > --- > +* vhost: ``rte_vdpa_register_device``, ``rte_vdpa_unregister_device``, > + ``rte_vhost_host_notifier_ctrl`` and ``rte_vdpa_relay_vring_used`` vDPA > + driver API will be marked as internal in DPDK v21.11. "driver API" is replaced with "driver interface" for correctness. Acked-by: Andrew Rybchenko Acked-by: Marvin Liu Applied, thanks.
Re: [dpdk-dev] [PATCH v2 2/2] vhost: notice Vhost ops struct renaming
30/07/2021 10:12, Maxime Coquelin: > This patch announces the renaming of struct > vhost_device_ops to rte_vhost_device_ops in DPDK v21.11. > > Acked-by: Chenbo Xia > Signed-off-by: Maxime Coquelin > --- > +* vhost: rename ``struct vhost_device_ops`` to ``struct > rte_vhost_device_ops`` > + int DPDK v21.11. s/int/in/ Acked-by: Andrew Rybchenko Acked-by: Adrian Moreno Acked-by: Marvin Liu Applied, thanks.
Re: [dpdk-dev] [PATCH 2/2] doc: announce eth new offload flag and group field
> > >> To support shared Rx queue, this patch announces new offload flag > > >> RTE_ETH_RX_OFFLOAD_SHARED_RXQ and new shared_group field to struct > > >> rte_eth_rxconf in DPDK v21.11. > > >> > > >> [1] mail list discussion: > > >> https://mails.dpdk.org/archives/dev/2021-July/215575.html > > >> > > >> Signed-off-by: Xueming Li > > > > > > We need this change to handle shared queues - the same queue > > > object can be shared by multiple ports, and releasing routine should > > > know exactly on which port_id/queue_id object is being released. > > > > > > Acked-by: Viacheslav Ovsiienko > > Acked-by: Andrew Rybchenko > Acked-by: Jerin Jacob Applied, thanks.
Re: [dpdk-dev] [PATCH v2 1/2] ethdev: announce change to action modify data
> > >> In the current implementation, > > >> the action rte_flow_action_modify_field is not well defined > > >> for fields larger than 64 bits (for example IPv6 source) > > >> In addition, the byte order is also not well defined. > > >> > > >> Both of those issue should be fixed. > > >> > > >> Signed-off-by: Ori Kam > > >> Acked-by: Matan Azrad > > > Acked-by: Ajit Khaparde > > Acked-by: Andrew Rybchenko > Acked-by: Jerin Jacob Applied, thanks.
Re: [dpdk-dev] [PATCH v2 2/2] ethdev: announce moving to general modify function
> > > Currently there is a dedicated modify function for each > > > field that the application wants to change. > > > For example: > > > rte_flow_action_type_set_tp_port to modify destination port of UDP/TCP. > > > rte_flow_action_type_set_ipv4_dst to modify destination of IPv4. > > > > > > A new function rte_flow_action_modify_field DPDK added the ability > > > to use the same function to modify any field, in addition to be able to > > > modify the value based on different field and not just immediate value. > > > > > > Signed-off-by: Ori Kam > > > Acked-by: Matan Azrad > > Acked-by: Ajit Khaparde > Acked-by: Jerin Jacob > > > +* ethdev: Announce moving from dedicated modify function for each field, > > > + to using the general ``rte_flow_modify_field`` action. This is a very vague announce. OK we can replace a lot of actions with rte_flow_modify_field, but it doesn't say when and which functions will be removed. I think we should make a more precise announce for removal of some actions in DPDK 22.11. In the meantime, let's introduce this hint that something is changing as it is acked. Applied.
Re: [dpdk-dev] [PATCH v3 1/2] ethdev: announce flow API action PORT_ID changes
> > By its very name, action PORT_ID means that packets hit an ethdev with the > > given DPDK port ID. At least the current comments don't state the opposite. > > > > However some drivers implement it in a different way and direct traffic to > > the opposite end of the "wire" plugged to the given ethdev. For example in > > the case of a VF representor traffic is redirected to the corresponding VF > > itself rather than to the representor ethdev and OvS uses PORT_ID action > > this way. > > > > The documentation must be clarified and, likely, rte_flow_action_port_id > > structure should be extended to support both meanings. > > > > Signed-off-by: Andrew Rybchenko > > Acked-by: Ori Kam > > --- > > +* ethdev: Definition of the flow API action PORT_ID is ambiguous and needs > > + clarification. Structure rte_flow_action_port_id will be extended to > > + specify traffic direction to represented entity or ethdev port itself in > Nit! "to the represented entity"? > Otherwise > Acked-by: Ajit Khaparde I agree clarification is welcome. Acked-by: Thomas Monjalon Applied with above change, thanks.
Re: [dpdk-dev] [PATCH v3 2/2] ethdev: announce clarification of implicit filter by port
> > Transfer flow rules may be applied to traffic entering switch from > > many sources. There are flow API pattern items which allow to specify > > ingress port match criteria explicitly, but it is not documented > > if ethdev port used to create flow rule adds any implicit match > > criteria and how it coexists with explicit ones. > > > > These aspects should be documented and drivers and applications > > which use it in a a different way must be fixed. > nit! "in a different way..." > otherwise > > Acked-by: Ajit Khaparde > > > Signed-off-by: Andrew Rybchenko > > Acked-by: Ori Kam +1 for clarification Acked-by: Thomas Monjalon Applied, thanks.
[dpdk-dev] [PATCH v2] vhost: fix coredump on port deletion
The rte_vhost_driver_unregister() and vhost_user_read_cb()
can be called at the same time by 2 threads.
Eg thread1 calls rte_vhost_driver_unregister() and frees memory of conn,
then thread2 calls vhost_user_read_cb() and access invalid memory of
conn.
The fix is to move the "fdset_try_del" in front of free memory of conn ,
then avoid the race condition.
Fixes: 52d874dc6705 ("vhost: fix crash on closing in client mode")
v2:
fix coding style issues
Signed-off-by: Gaoxiang Liu
---
lib/vhost/socket.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/lib/vhost/socket.c b/lib/vhost/socket.c
index 5d0d728d5..2eb8fcadd 100644
--- a/lib/vhost/socket.c
+++ b/lib/vhost/socket.c
@@ -1024,6 +1024,20 @@ rte_vhost_driver_unregister(const char *path)
for (i = 0; i < vhost_user.vsocket_cnt; i++) {
struct vhost_user_socket *vsocket = vhost_user.vsockets[i];
+ if (vsocket->is_server) {
+ /*
+* If r/wcb is executing, release vhost_user's
+* mutex lock, and try again since the r/wcb
+* may use the mutex lock.
+*/
+ if (fdset_try_del(&vhost_user.fdset,
vsocket->socket_fd) == -1) {
+ pthread_mutex_unlock(&vhost_user.mutex);
+ goto again;
+ }
+ } else if (vsocket->reconnect) {
+ vhost_user_remove_reconnect(vsocket);
+ }
+
if (!strcmp(vsocket->path, path)) {
pthread_mutex_lock(&vsocket->conn_mutex);
for (conn = TAILQ_FIRST(&vsocket->conn_list);
@@ -1056,21 +1070,8 @@ rte_vhost_driver_unregister(const char *path)
pthread_mutex_unlock(&vsocket->conn_mutex);
if (vsocket->is_server) {
- /*
-* If r/wcb is executing, release vhost_user's
-* mutex lock, and try again since the r/wcb
-* may use the mutex lock.
-*/
- if (fdset_try_del(&vhost_user.fdset,
- vsocket->socket_fd) == -1) {
- pthread_mutex_unlock(&vhost_user.mutex);
- goto again;
- }
-
close(vsocket->socket_fd);
unlink(path);
- } else if (vsocket->reconnect) {
- vhost_user_remove_reconnect(vsocket);
}
pthread_mutex_destroy(&vsocket->conn_mutex);
--
2.32.0
