Hi Maxime, Hemant, I wanted initially to keep it fairly open hence a hash table for the windows profiles, but it is also possible to expose something more descriptive, that would work as well actually. Ie.
+ /** FFT windowing width for 2048 FFT. */ + uint16_t fft_window_width[RTE_BBDEV_MAX_FFT_WIN]; The provides the width of each windows shape which is enough to distinguish major variants and to estimate noise factor. Let me know of opinion. Thanks Nic > -----Original Message----- > From: Maxime Coquelin <[email protected]> > Sent: Tuesday, September 26, 2023 3:00 AM > To: Chautru, Nicolas <[email protected]>; > [email protected]; [email protected] > Cc: [email protected]; Vargas, Hernan > <[email protected]> > Subject: Re: [PATCH v1 1/7] bbdev: add FFT version member in driver info > > > > On 9/22/23 18:41, Chautru, Nicolas wrote: > > Hi Maxime, > > > >> -----Original Message----- > >> From: Maxime Coquelin <[email protected]> > >> Sent: Friday, September 22, 2023 1:15 AM > >> To: Chautru, Nicolas <[email protected]>; > >> [email protected]; [email protected] > >> Cc: [email protected]; Vargas, Hernan > >> <[email protected]> > >> 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-operatio > >> n) 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. > > Ok, I think it would be better to provide an API to get the table directly, > and > have the format being described in the documentation. > > With that, we can also provide the hash as you'd like, but the method to > calculate the hash should also be provided. Or the application can perform > the hash itself if it needs it. > > The fact that it is several KB is not an issue, as this information would > only be > queried once at init time if really needed. > > An non-DPDK alternative could be to pass such information to the pod via the > device plugin (as a mounted file for instance, or variable). > > >> 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. > > Thanks for the information! > > >> > >>> 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. > > Thanks, > Maxime > > > > >> > >> Regards, > >> Maxime > >> > >>> Thanks > >>> Nic > >>> > >>>> -----Original Message----- > >>>> From: Maxime Coquelin <[email protected]> > >>>> Sent: Tuesday, September 19, 2023 2:56 AM > >>>> To: Chautru, Nicolas <[email protected]>; [email protected] > >>>> Cc: [email protected]; [email protected]; Vargas, > >> Hernan > >>>> <[email protected]> > >>>> 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 <[email protected]> > >>>>> --- > >>>>> 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 */ > >>> > >
