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 */
> >
