From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6BA76A0547; Fri, 29 Oct 2021 17:18:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 45D0641143; Fri, 29 Oct 2021 17:18:27 +0200 (CEST) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by mails.dpdk.org (Postfix) with ESMTP id A92474111F for ; Fri, 29 Oct 2021 17:18:25 +0200 (CEST) Received: by mail-io1-f43.google.com with SMTP id f9so12827310ioo.11 for ; Fri, 29 Oct 2021 08:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6hMTGJXEAIVXvtbxTJSXv33TT1xVhC32KAt/zGXq8Qo=; b=jQdemurhMKg1coh1LeSkVK1tk6VjV4+8UA6QwG6Um72SiOvjt6TWRemLY0UuAYIIWi 9iz2BHTLfUTNRPlc9ukVrrOdkO2UI+mVMQRzT7BO14DrZHEQHQNsUhFubKMmhkqd2tAz tK6oGuoeDF/0d/26JRxl0UbrU9TVNLIxitI2kCtKLzTGwcS4z/jykCcoSsZuM621Zq1C SL3qKWTcy4YO2xcUVOcZc7zlaZhntExypuNkRLBo05asMDfV2f35DtFk+1VeCYr60uAI pm5PUMBspTVXiCcciYf4czUbeD93qCS2ogyglTQJ+YXA6ks0uWi2qe6M5TjtaPJs+H4S IfLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6hMTGJXEAIVXvtbxTJSXv33TT1xVhC32KAt/zGXq8Qo=; b=OJQNeFXFUJFUb+kwL2ajyTmuVBZlAfqDPSG4biWti/4GilJQkqgljeNyNHvUMumtVt huVInpSyLWH5wklc2ZxP9TeNVZQhj/t9EVSFa3Vm02KAQ1v5QWYkulFQBDY2rVI6kArm 2UeCbDp2+MiyqmBwbwwupMMnO+Loixe2mjMQBlY217h6s0ZCsjGDrcy/JiN5klA+zD8G lrvO0ozJIklhHfGKp7B5Wa1DgpHTX6TRGrf1jo17GY0i4CdWyYYpajogedrBFCt4BSvU T4ln8Lq+QDoJJiQ0VTq2RXGRIQf/Bn93QfNfGHK41p6PpjFgY9Pz3x9KcxMq9CnQpYon Dvzw== X-Gm-Message-State: AOAM531AHN4jjaoutzjwhNJfqQT1wEEMKSWKf+AdqOeQBx2lY5GsKK2Y qKeZxJHSfkSHlipitWuJGcO7eNNEQXeM497KzPYfgGmFiYY= X-Google-Smtp-Source: ABdhPJwjWwjtgRqng7jIf7KNaIRwWNwpORJXYwXwMi4ndtXZSh26+ShPlMerfbqXuq8EhQt/SAc9yRfKF05F8agNK48= X-Received: by 2002:a05:6602:2d13:: with SMTP id c19mr8592873iow.199.1635520705061; Fri, 29 Oct 2021 08:18:25 -0700 (PDT) MIME-Version: 1.0 References: <3e8c8bab-783d-d132-a836-51bd4d5533bb@ericsson.com> <20211026173148.19399-1-mattias.ronnblom@ericsson.com> <7494151c-26b2-4ccc-f011-73ffceb92a85@ericsson.com> In-Reply-To: <7494151c-26b2-4ccc-f011-73ffceb92a85@ericsson.com> From: Jerin Jacob Date: Fri, 29 Oct 2021 20:47:59 +0530 Message-ID: To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "Van Haaren, Harry" , "McDaniel, Timothy" , Pavan Nikhilesh , Hemant Agrawal , Liang Ma Cc: "Richardson, Bruce" , Jerin Jacob , "Gujjar, Abhinandan S" , Erik Gabriel Carrillo , "Jayatheerthan, Jay" , dpdk-dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] [PATCH 1/3] eventdev: allow for event devices requiring maintenance X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Oct 29, 2021 at 8:33 PM Mattias R=C3=B6nnblom wrote: > > On 2021-10-29 16:38, Jerin Jacob wrote: > > On Tue, Oct 26, 2021 at 11:02 PM Mattias R=C3=B6nnblom > > wrote: > >> Extend Eventdev API to allow for event devices which require various > >> forms of internal processing to happen, even when events are not > >> enqueued to or dequeued from a port. > >> > >> PATCH v1: > >> - Adapt to the move of fastpath function pointers out of > >> rte_eventdev struct > >> - Attempt to clarify how often the application is expected to > >> call rte_event_maintain() > >> - Add trace point > >> RFC v2: > >> - Change rte_event_maintain() return type to be consistent > >> with the documentation. > >> - Remove unused typedef from eventdev_pmd.h. > >> > >> Signed-off-by: Mattias R=C3=B6nnblom > >> Tested-by: Richard Eklycke > >> Tested-by: Liron Himi > >> --- > >> > >> +/** > >> + * Maintain an event device. > >> + * > >> + * This function is only relevant for event devices which has the > >> + * RTE_EVENT_DEV_CAP_REQUIRES_MAINT flag set. Such devices require th= e > >> + * application to call rte_event_maintain() on a port during periods > >> + * which it is neither enqueuing nor dequeuing events from that > >> + * port. > > # We need to add "by the same core". Right? As other core such as > > service core can not call rte_event_maintain() > > > Do you mean by the same lcore thread that "owns" (dequeues and enqueues > to) the port? Yes. I thought that was implicit, since eventdev port are > not MT safe. I'll try to figure out some wording that makes that more cle= ar. OK. > > > > # Also, Incase of Adapters enqueue() happens, right? If so, either > > above text is not correct. > > # @Erik Gabriel Carrillo @Jayatheerthan, Jay @Gujjar, Abhinandan S > > Please review 3/3 patch on adapter change. > > Let me know you folks are OK with change or not or need more time to an= alyze. > > > > If it need only for the adapter subsystem then can we make it an > > internal API between DSW and adapters? > > > No, it's needed for any producer-only eventdev ports, including any such > ports used by the application. In that case, the code path in testeventdev, eventdev_pipeline, etc needs to be updated. I am worried about the performance impact for the drivers th= ey don't have such limitations. Why not have an additional config option in port_config which says it is a producer-only port by an application and takes care of the driver. In the current adapters code, you are calling maintain() when enqueue returns zero. In such a case, if the port is configured as producer and then internally it can call maintain. Thoughts from other eventdev maintainers? Cc+ @Van Haaren, Harry @Richardson, Bruce @Gujjar, Abhinandan S @Jayatheerthan, Jay @Erik Gabriel Carrillo @McDaniel, Timothy @Pavan Nikhilesh @Hemant Agrawal @Liang Ma > > > Should rte_event_maintain() be marked experimental? I don't know how > that works for inline functions. > > > > > > + rte_event_maintain() is a low-overhead function and should be > >> + * called at a high rate (e.g., in the applications poll loop). > >> + * > >> + * No port may be left unmaintained. > >> + * > >> + * rte_event_maintain() may be called on event devices which haven't > >> + * set RTE_EVENT_DEV_CAP_REQUIRES_MAINT flag, in which case it is a > >> + * no-operation. > >> + * > >> + * @param dev_id > >> + * The identifier of the device. > >> + * @param port_id > >> + * The identifier of the event port. > >> + * @return > >> + * - 0 on success. > >> + * - -EINVAL if *dev_id* or *port_id* is invalid > >> + * > >> + * @see RTE_EVENT_DEV_CAP_REQUIRES_MAINT > >> + */ > >> +static inline int > >> +rte_event_maintain(uint8_t dev_id, uint8_t port_id) > >> +{ > >> + const struct rte_event_fp_ops *fp_ops; > >> + void *port; > >> + > >> + fp_ops =3D &rte_event_fp_ops[dev_id]; > >> + port =3D fp_ops->data[port_id]; > >> +#ifdef RTE_LIBRTE_EVENTDEV_DEBUG > >> + if (dev_id >=3D RTE_EVENT_MAX_DEVS || > >> + port_id >=3D RTE_EVENT_MAX_PORTS_PER_DEV) { > >> + rte_errno =3D EINVAL; > >> + return 0; > >> + } > >> + > >> + if (port =3D=3D NULL) { > >> + rte_errno =3D EINVAL; > >> + return 0; > >> + } > >> +#endif > >> + rte_eventdev_trace_maintain(dev_id, port_id); > >> + > >> + if (fp_ops->maintain !=3D NULL) > >> + fp_ops->maintain(port); > >> + > >> + return 0; > >> +} > >> + > >> #ifdef __cplusplus > >> } > >> #endif > >> diff --git a/lib/eventdev/rte_eventdev_core.h b/lib/eventdev/rte_event= dev_core.h > >> index 61d5ebdc44..61fa65cab3 100644 > >> --- a/lib/eventdev/rte_eventdev_core.h > >> +++ b/lib/eventdev/rte_eventdev_core.h > >> @@ -29,6 +29,9 @@ typedef uint16_t (*event_dequeue_burst_t)(void *port= , struct rte_event ev[], > >> uint64_t timeout_ticks); > >> /**< @internal Dequeue burst of events from port of a device */ > >> > >> +typedef void (*event_maintain_t)(void *port); > >> +/**< @internal Maintains a port */ > >> + > >> typedef uint16_t (*event_tx_adapter_enqueue_t)(void *port, > >> struct rte_event ev[], > >> uint16_t nb_events); > >> @@ -54,6 +57,8 @@ struct rte_event_fp_ops { > >> /**< PMD dequeue function. */ > >> event_dequeue_burst_t dequeue_burst; > >> /**< PMD dequeue burst function. */ > >> + event_maintain_t maintain; > >> + /**< PMD port maintenance function. */ > >> event_tx_adapter_enqueue_t txa_enqueue; > >> /**< PMD Tx adapter enqueue function. */ > >> event_tx_adapter_enqueue_t txa_enqueue_same_dest; > >> diff --git a/lib/eventdev/rte_eventdev_trace_fp.h b/lib/eventdev/rte_e= ventdev_trace_fp.h > >> index 5639e0b83a..c5a79a14d8 100644 > >> --- a/lib/eventdev/rte_eventdev_trace_fp.h > >> +++ b/lib/eventdev/rte_eventdev_trace_fp.h > >> @@ -38,6 +38,13 @@ RTE_TRACE_POINT_FP( > >> rte_trace_point_emit_ptr(enq_mode_cb); > >> ) > >> > >> +RTE_TRACE_POINT_FP( > >> + rte_eventdev_trace_maintain, > >> + RTE_TRACE_POINT_ARGS(uint8_t dev_id, uint8_t port_id), > >> + rte_trace_point_emit_u8(dev_id); > >> + rte_trace_point_emit_u8(port_id); > >> +) > >> + > >> RTE_TRACE_POINT_FP( > >> rte_eventdev_trace_eth_tx_adapter_enqueue, > >> RTE_TRACE_POINT_ARGS(uint8_t dev_id, uint8_t port_id, void *e= v_table, > >> -- > >> 2.25.1 > >> >