Hi Maxime, > -----Original Message----- > From: Maxime Coquelin <maxime.coque...@redhat.com> > Sent: Friday, September 22, 2023 1:15 AM > To: Chautru, Nicolas <nicolas.chau...@intel.com>; > hemant.agra...@nxp.com; dev@dpdk.org > Cc: david.march...@redhat.com; Vargas, Hernan > <hernan.var...@intel.com> > Subject: Re: [PATCH v1 1/7] bbdev: add FFT version member in driver info > > 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.
Unsure this is that vendor specific. At least the interface allows to know a hash of the table being loaded (which is just pointwise data really, non-proprietary format). I did not state the content is a simple md5sum of the bin file being loaded from linux. > 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? This is configured for the device at platform level, ie. through operator. Common to all application/devices. This captures the windows shape assumptions. > > > 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) Yes looking forward to it. > > Regards, > Maxime > > > Thanks > > Nic > > > >> -----Original Message----- > >> From: Maxime Coquelin <maxime.coque...@redhat.com> > >> Sent: Tuesday, September 19, 2023 2:56 AM > >> To: Chautru, Nicolas <nicolas.chau...@intel.com>; dev@dpdk.org > >> Cc: hemant.agra...@nxp.com; david.march...@redhat.com; Vargas, > Hernan > >> <hernan.var...@intel.com> > >> 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 <nicolas.chau...@intel.com> > >>> --- > >>> 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 */ > >