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 656FD42988; Wed, 19 Apr 2023 13:07:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C80340A79; Wed, 19 Apr 2023 13:07:27 +0200 (CEST) Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by mails.dpdk.org (Postfix) with ESMTP id CD5BE4021F for ; Wed, 19 Apr 2023 13:07:25 +0200 (CEST) Received: by mail-vs1-f48.google.com with SMTP id e19so13595828vsa.12 for ; Wed, 19 Apr 2023 04:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681902445; x=1684494445; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=msRhSmQ0F/0mnGxY7wGc7toCoIVKLhzhNZmYwLOhyNQ=; b=YIUYTqU06iAoTKFtRnPmTB17MNqFLmr28lCntGEM+v45RAiO6GALfsV9Rp/Anc2aWc B4pCGqK4MXbVfxdhBLcfNnvgFcFLJtxkw8D37dUFNYHWJ6xry/xi82Uhkh0lrXbiuIim S0TAJTbPsCPgHelTqTPSJlVFO7HLhF6tk7vE8tSu4jlRKOo1ox+RfrHP1FNGte29Z5Y3 fLFpWoGhQ2JbTRZbs/5sB9I3PiMaDffaALZ2bIiuM2WqxMIR01YnWlkJUOBqLITkYjJb llig0KOmJyfWPyeWMF1FK1ItHeICvd6l7gJ+FL1CIp9W5QdzavWJit7Q0l38F/PTZ80E jCwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681902445; x=1684494445; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=msRhSmQ0F/0mnGxY7wGc7toCoIVKLhzhNZmYwLOhyNQ=; b=KR0IvlWC6YQedgLUf1IY51I4uYekdjuLU7Pop5NRLHMU09/QEXI1Rbjugd72oGXSBD PgUVkAWaUMma+A0bLIZzdfDbFL4FnKbOkIV0iBGIqX7nxd22kvwbg+8UJ7vEkS712hdB C2txMpgJdlCOX2FlR1kUB3I418MDMxTXxe25p/GOvjAyvbLwPrjV/sBGZlXFVw2vf8QH 5Yl3Dkzi47MVuZinRWWN6TNMiNCPklD/lFudsw8E1DF5uuCDofNhAAQ5QhxYlMWDapuZ HbAQUS7mOh5pdO1vpO+CUCbwhJhP3TWjjDTnCujTcLr0vTUpNeXDTZtas8D8CEENcAj9 ukDw== X-Gm-Message-State: AAQBX9cdT5w599aBcw18tK6WvjCPfxwMUgTIZNB2tjsBfJjOtZLNsfI1 iiweBYH00DYWE1EL6JEq8odzgkHc0H4+V+Ai9os= X-Google-Smtp-Source: AKy350Ztp0VIAEXwUjhLpoLMdo3nCzgw5Gq+tgZh3iFbIshhWtlVvOiZcd6PrSsr+4Qc5IsMHLcDhrLRPGH+VRUtxw4= X-Received: by 2002:a67:e9c5:0:b0:42c:9864:3adf with SMTP id q5-20020a67e9c5000000b0042c98643adfmr6613374vso.31.1681902445104; Wed, 19 Apr 2023 04:07:25 -0700 (PDT) MIME-Version: 1.0 References: <8f8db2f7-0d82-48fa-01b1-f5cadb0b57b3@ericsson.com> In-Reply-To: <8f8db2f7-0d82-48fa-01b1-f5cadb0b57b3@ericsson.com> From: Jerin Jacob Date: Wed, 19 Apr 2023 16:36:59 +0530 Message-ID: Subject: Re: Event device early back-pressure indication To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: Jerin Jacob Kollanukkaran , "timothy.mcdaniel@intel.com" , Hemant Agrawal , Harry van Haaren , "dev@dpdk.org" , =?UTF-8?B?U3ZhbnRlIErDpHJ2c3Ryw6V0?= , Heng Wang , Stefan Sundkvist , Peter Nilsson , Maria Lingemark , Pavan Nikhilesh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Mon, Apr 17, 2023 at 9:06=E2=80=AFPM Mattias R=C3=B6nnblom wrote: > > On 2023-04-17 14:52, Jerin Jacob wrote: > > On Thu, Apr 13, 2023 at 12:24=E2=80=AFPM Mattias R=C3=B6nnblom > > wrote: > >> > >> > >> void > >> rte_event_return_new_credits(...); > >> > >> Thoughts? > > > > I see the following cons on this approach. > > > > Does the use case in my original e-mail seem like a reasonable one to > you? If yes, is there some way one could solve this problem with a > clever use of the current Eventdev API? That would obviously be preferabl= e. I think, the use case is reasonable. For me, most easy path to achieve the functionality is setting rte_event_dev_config::nb_events_limit as for a given application always targeted to work X number of packets per second. Giving that upfront kind of make life easy for application writers and drivers at the cost of allocating required memory. > > > # Adding multiple APIs in fast path to driver layer may not > > performance effective solution. > > For event devices with a software-managed credit system, pre-allocation > would be very cheap. And, if an application prefer to handle back > pressure after-the-fact, that option is still available. I am worried about exposing PMD calls and application starts calling per pa= cket, e.s.p with burst size =3D 1 for latency critical applications. > > > # At least for cnxk HW, credits are for device, not per port. So cnxk > > HW implementation can not use this scheme. > > > > DSW's credit pool is also per device, but are cached on a per-port > basis. Does cnxk driver rely on the hardware to signal "new event" back > pressure? (From the driver code it looks like that is the case.) Yes. But we can not really cache it per port without introducing complex atomic logic. > > > Alternative solution could be, adding new flag for > > rte_enqueue_new_burst(), where drivers waits until credit is available > > to reduce the application overhead > and support in different HW implem= entations if this use case critical. > > > > #define RTE_EVENT_FLAG_WAIT_TILL_CREDIT_AVILABLE (UINT32_C(1) << 0) > > > > > > This solution only works if the event device is the only source of work > for the EAL thread. That is a really nice model, but I wouldn't trust on > that to always be the case. For non EAL thread, I am assuming it is HW event adapter kind of case, In such case, they don't need to wait. I think, for SW EAL threads case onl= y we need to wait as application is expecting to make sure wait till the credit is available to avoid error handling in application. > > Also, there may be work that should only be performed, if the system is > not under very high load. Credits being available, especially combined > with a flexible new even threshold would be an indicator. > > Another way would be to just provide an API call that gave an indication > of a particular threshold has been reached (or simply return an > approximation of the number of in-flight events). Such a mechanism > wouldn't be able to leave any guarantees, but could make a future > enqueue operation very likely to succeed. Giving rte_event_dev_credits_avaiable(device_id) should be OK provided it is not expecting fine-grained accuracy. But my worry is applications st= arts calling that per packet. Marking correct documentation may help. Not sure. > > >> > >> Best regards, > >> Mattias >