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 72E6A42604; Thu, 21 Sep 2023 09:13:29 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5E0F640649; Thu, 21 Sep 2023 09:13:29 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id F36E24014F for ; Thu, 21 Sep 2023 09:13:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695280407; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QJkw5Yna3d+OrJjMtZjrgJv09O4dBbv44wR8dd8JZSs=; b=fFCfgmCD7S4Bl7PGz1Wco19X0ZFOD1h561Zg9jIJv4Qd+bMa5G3B7Y3OIpS+JXBXApW/Ww zkdJnnKh2M1f7omilxsWM4n2zIDXrUstwI42l3CIhAJzaEdJMJstSMGaP9ghnatN14lNC1 Ohmb+NJEWkMWkqrbyj0fm+yLldSXYoQ= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-661-iutVAGc-Mxeghu5O58W8EQ-1; Thu, 21 Sep 2023 03:13:24 -0400 X-MC-Unique: iutVAGc-Mxeghu5O58W8EQ-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2bfb9db0397so6899021fa.3 for ; Thu, 21 Sep 2023 00:13:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695280403; x=1695885203; 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=QJkw5Yna3d+OrJjMtZjrgJv09O4dBbv44wR8dd8JZSs=; b=bOoBjQjnaDg0i94UFhL9+j70IZRuP1SBNeMOYpkzFSiqcmXXtC/JoVe2Ul2WNvPsN6 IrTiOvu/l5LKmZI+DsOGcZo5iLYVIaQTbaDZ0/HNS5RV9zdLNS3grgU15ZIQ1RgD+1Nh AzYRK+Q/nIwnKk0WP+Q8tUGWiEoRBikWgf8Z5UgnXjSyQbvEt0Yn8cCTCcFuoMO8jUy2 9jwvX0JqNAH5EYLlstdeACDijVasyLGbm4mmlEWd3s4eYDkGd3JFtmS9BA8NK/iaA6aG Kvb1wtFtONKCkoex/o2wbMShhrVsbPIin/Wnpu4bEauVlNplMT8/6HlR5/bYzKkz/HQd B/pQ== X-Gm-Message-State: AOJu0YyA2XNy3ksslC6qn/qWMBpNo4FJ2s7E+GsnI4JlYdF0RuUUhWKU YFHyFMObinAEa9cOFJQFVLSxR5EoGQuK9QXa7SD1cwRvRvgHfuBu8rbwzDAxnkDZQKaP1euLLUs QWxrwoeB6japib3EANTA= X-Received: by 2002:a2e:8855:0:b0:2bf:7894:a490 with SMTP id z21-20020a2e8855000000b002bf7894a490mr4132316ljj.38.1695280402857; Thu, 21 Sep 2023 00:13:22 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEe8Jf7tHV/CcayFOUlPhrjOHB4dLi4zraug5ahUuaw/j3WjQ0BACX7dQN7d/5Wdk6aW2acM4etii9QFzbcgUA= X-Received: by 2002:a2e:8855:0:b0:2bf:7894:a490 with SMTP id z21-20020a2e8855000000b002bf7894a490mr4132296ljj.38.1695280402536; Thu, 21 Sep 2023 00:13:22 -0700 (PDT) MIME-Version: 1.0 References: <20230919012136.2818396-1-nicolas.chautru@intel.com> <20230919012136.2818396-4-nicolas.chautru@intel.com> In-Reply-To: From: David Marchand Date: Thu, 21 Sep 2023 09:13:11 +0200 Message-ID: Subject: Re: [PATCH v1 3/7] baseband/acc: remove the 4G SO capability for VRB1 To: "Chautru, Nicolas" Cc: "dev@dpdk.org" , "maxime.coquelin@redhat.com" , "hemant.agrawal@nxp.com" , "Vargas, Hernan" , Thomas Monjalon X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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 Tue, Sep 19, 2023 at 10:32=E2=80=AFPM Chautru, Nicolas wrote: > > Hi David, > > > -----Original Message----- > > From: David Marchand > > Sent: Tuesday, September 19, 2023 8:20 AM > > To: Chautru, Nicolas > > Cc: dev@dpdk.org; maxime.coquelin@redhat.com; > > hemant.agrawal@nxp.com; Vargas, Hernan > > Subject: Re: [PATCH v1 3/7] baseband/acc: remove the 4G SO capability f= or > > VRB1 > > > > On Tue, Sep 19, 2023 at 3:25=E2=80=AFAM Nicolas Chautru > > wrote: > > > > > > This removes the specific capability and support of LTE Decoder Soft > > > Output option on the VRB1 PMD. > > > > Please explain why such support is removed for this hw. > > The decision is made to defeature this optional capability as under certa= in race conditions enabling this may potentially cause reliability issues w= hich would not be acceptable. > Note that this is an optional additional output information (soft output= information) independent of the actual decoding operation. > More details below next to your other comments. This must be explained in the commitlog. > > > > > > > > > > > Signed-off-by: Nicolas Chautru > > > --- > > > drivers/baseband/acc/rte_vrb_pmd.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/drivers/baseband/acc/rte_vrb_pmd.c > > > b/drivers/baseband/acc/rte_vrb_pmd.c > > > index 3c8f3409ed..e0f50460bd 100644 > > > --- a/drivers/baseband/acc/rte_vrb_pmd.c > > > +++ b/drivers/baseband/acc/rte_vrb_pmd.c > > > @@ -1019,14 +1019,11 @@ vrb_dev_info_get(struct rte_bbdev *dev, struc= t > > rte_bbdev_driver_info *dev_info) > > > RTE_BBDEV_TURBO_CRC_TYPE_24B = | > > > RTE_BBDEV_TURBO_DEC_CRC_24B_D= ROP | > > > RTE_BBDEV_TURBO_EQUALIZER | > > > - RTE_BBDEV_TURBO_SOFT_OUT_SATU= RATE | > > > RTE_BBDEV_TURBO_HALF_ITERATIO= N_EVEN | > > > RTE_BBDEV_TURBO_CONTINUE_CRC_= MATCH | > > > - RTE_BBDEV_TURBO_SOFT_OUTPUT | > > > RTE_BBDEV_TURBO_EARLY_TERMINA= TION | > > > RTE_BBDEV_TURBO_DEC_INTERRUPT= S | > > > RTE_BBDEV_TURBO_NEG_LLR_1_BIT= _IN | > > > - RTE_BBDEV_TURBO_NEG_LLR_1_BIT= _SOFT_OUT | > > > RTE_BBDEV_TURBO_MAP_DEC | > > > RTE_BBDEV_TURBO_DEC_TB_CRC_24= B_KEEP | > > > > > > RTE_BBDEV_TURBO_DEC_SCATTER_GATHER, > > > @@ -1975,6 +1972,9 @@ enqueue_dec_one_op_cb(struct acc_queue *q, > > struct rte_bbdev_dec_op *op, > > > struct rte_mbuf *input, *h_output_head, *h_output, > > > *s_output_head, *s_output; > > > > > > + /* Disable explictly SO for VRB 1. */ > > > + op->turbo_dec.op_flags &=3D ~RTE_BBDEV_TURBO_SOFT_OUTPUT; > > > > Can you explain why it is needed to filter this out? > > > > I did not find a clear description in the bbdev API. > > It would help if there were explicits references in doxygen of which ca= pability > > is necessary for using flags/API. > > > > > > I was expecting that asking for RTE_BBDEV_TURBO_SOFT_OUTPUT to a driver > > is only allowed if rte_bbdev_op_cap contains it. > > With this assumption, it would be invalid for an application to request > > RTE_BBDEV_TURBO_SOFT_OUTPUT through rte_bbdev_enqueue_dec_ops. > > You may arguably expect this from a well behaved user application but sti= ll there is nothing that enforces it explicitly, ie. notably under negative= scenario conditions which we still need to manage gracefully. If your application is buggy (not reading / complying with the device capabilities), fix it. > Here we want to make sure that in case the optional operational flag is i= ncluded, we fall back to default mode when using the VRB1 variant. > Keep in mind that the unified driver can support multiple HW variant (see= rest of the serie) and may support this option for other variants using sa= me code. Whatever the HW variant, the API should be respected: exposing capabilities is done on a per device basis. > > In term of documentation, I believe that capability/flag (ie. note that t= he enum maps to a capability when retrieved from info_get, and to an operat= ion flag when provided to the bbdev api) is already captured explicitly for= many generations. Basically this an optional output of the LTE decoding pr= ocessing, to provide APP LLR which can be potentially be useful for the use= r application (separate optional mbuf). It may or may not be supported by a= bb device, and it may or may not be requested to be provided through the A= PI. Typically this is not enabled. Being optional does not mean that a driver can ignore it. Otherwise, there is no point in exposing a capability. Thanks. --=20 David Marchand