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 6C28642616; Fri, 22 Sep 2023 10:14:54 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3070440150; Fri, 22 Sep 2023 10:14:54 +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 EA9CD4013F for ; Fri, 22 Sep 2023 10:14:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695370492; 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=oa83HoAqxWUcusDaeqJ1ud3OyLTLPtJVctzT9AZCUfE=; b=YKRDmbtV16CVZF/NEzsC30E7vofTET02Mfnbota7ObTVx5+kt1whHWuLV89oELCZh00nY8 2gNPvNdGeg18p++rPr0gtqgyrdj//jFBg5Ffi8B7tXAAYsyqeJyb5ku14roRmO+41sK5ru QNW5Jw8k2ChGV5bjuewqNcCAk8E/hDk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-605-Sd8sswo7P86OEhP601DVBA-1; Fri, 22 Sep 2023 04:14:49 -0400 X-MC-Unique: Sd8sswo7P86OEhP601DVBA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D40A6811E7D; Fri, 22 Sep 2023 08:14:48 +0000 (UTC) Received: from [10.39.208.35] (unknown [10.39.208.35]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A3C761005B96; Fri, 22 Sep 2023 08:14:47 +0000 (UTC) Message-ID: <97488343-49b0-cdaf-2a6d-919a66093022@redhat.com> Date: Fri, 22 Sep 2023 10:14:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 To: "Chautru, Nicolas" , "hemant.agrawal@nxp.com" , "dev@dpdk.org" Cc: "david.marchand@redhat.com" , "Vargas, Hernan" References: <20230919012136.2818396-1-nicolas.chautru@intel.com> <20230919012136.2818396-2-nicolas.chautru@intel.com> <4295bcc3-145d-2bb2-8ce1-4689e7ef7d22@redhat.com> From: Maxime Coquelin Subject: Re: [PATCH v1 1/7] bbdev: add FFT version member in driver info In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Hi Nicolas, On 9/19/23 22:51, Chautru, Nicolas wrote: > Hi Maxime, > > This is neither part of 3GPP per se, nor specific to VRB device. Let me provide more context. > The SRS processing chain (https://doc.dpdk.org/guides/prog_guide/bbdev.html#bbdev-fft-operation) includes a pointwise multiplication by time window. > The generic API include some control of these windowing function but still the actual shape need to be programmed onto any device (ie. rectangular, taped, sinc, different width or offset, any abritraty shape defined as an array of scalars). These degrees of liberties cannot be exposed through a generic API (information is multi-kB, ie the data itself) and can be user specific (external to the HW IP itself or outside of Intel control). Thanks for the explanations. I also did my homework as my FFT knowledge was buried quite deep in my memory. :) So this is a vendor-specific way to express generic paramaters. Regarding VRB device, is this table per device or per VF? Could it be configured by the application directly, or has it to be done through the PF? > As an illustration for VRB device pf_bb_config provides to user an option to include such windowing data as an input ("FFT LUT bin file"), but more generally at platform level for any bb device this big Look-Up Table or big array can be configured on the host during platform initialization for a given deployment or vendor. > What is required here is for the user application to have knowledge of what version of such array is being used on the given platform, as this information would be relevant to processing done outside of bbdev (notably for noise estimate). Through that mechanism, the user can now map through that API which possible file was being used, and act accordingly. > The content itself is not specified, for VRB we just use the md5sum of that binary file (which is just a big array of int16 for point wise multiplication) so that this can be used to share knowledge between initialized platform configuration and at run-time user application assumption. > It is also important to under that the user/vendor may use any array or shape (based on their algorithm) regardless of Intel or IP, and still be able to share information mapping between what is configured on the platform (multiple versions possible) and what the application enumerates. > > I can add more details in the documentation indeed but above should arguably make sense. The name FFT_version naming may be quite vague, this is more related to the FFT pointwise windowing array variant assumed on the platform. I did not want to impose for it to be an md5sum necessarily, hence the vagueness, as it could be any hash shared between the device programming and the user application related to the semi-static FFT processing programming. > > Let me know if unclear or if any other thought, I think this is clear now to me. In my opinion, this is not good to have this part of the BBDEV API, as every vendor will have their own way to represent this. Other alternative is to have a vendor specific API. This is far from ideal and should be avoided as much as possible, but in this case the application has to know anyways which device it is driving. It would be at least clear the field has to be interpreted in a vendor-specific way. @Hemant, I would be interested in your opinion. (I don't know if NXP has or plans to have FFT accelerator IP) Regards, Maxime > Thanks > Nic > >> -----Original Message----- >> From: Maxime Coquelin >> Sent: Tuesday, September 19, 2023 2:56 AM >> To: Chautru, Nicolas ; dev@dpdk.org >> Cc: hemant.agrawal@nxp.com; david.marchand@redhat.com; Vargas, Hernan >> >> Subject: Re: [PATCH v1 1/7] bbdev: add FFT version member in driver info >> >> >> >> On 9/19/23 03:21, Nicolas Chautru wrote: >>> This can be used to distinguish different version of the flexible >>> pointwise windowing applied to the FFT and expose this to the >>> application. >> >> Does this version relates to a standard, or is this specific to the >> implementation of your VRB devices? >> >>> Signed-off-by: Nicolas Chautru >>> --- >>> lib/bbdev/rte_bbdev.h | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index >>> a5bcc09f10..d6e54ee9a4 100644 >>> --- a/lib/bbdev/rte_bbdev.h >>> +++ b/lib/bbdev/rte_bbdev.h >>> @@ -349,6 +349,8 @@ struct rte_bbdev_driver_info { >>> const struct rte_bbdev_op_cap *capabilities; >>> /** Device cpu_flag requirements */ >>> const enum rte_cpu_flag_t *cpu_flag_reqs; >>> + /** Versioning number for the FFT operation type. */ >>> + uint16_t fft_version; >>> }; >>> >>> /** Macro used at end of bbdev PMD list */ >