[v1,1/7] bbdev: add FFT version member in driver info
Checks
Commit Message
This can be used to distinguish different version of the
flexible pointwise windowing applied to the FFT and expose
this to the application.
Signed-off-by: Nicolas Chautru <nicolas.chautru@intel.com>
---
lib/bbdev/rte_bbdev.h | 2 ++
1 file changed, 2 insertions(+)
Comments
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.chautru@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 */
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).
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,
Thanks
Nic
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Tuesday, September 19, 2023 2:56 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org
> Cc: hemant.agrawal@nxp.com; david.marchand@redhat.com; Vargas, Hernan
> <hernan.vargas@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.chautru@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 */
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 <maxime.coquelin@redhat.com>
>> Sent: Tuesday, September 19, 2023 2:56 AM
>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org
>> Cc: hemant.agrawal@nxp.com; david.marchand@redhat.com; Vargas, Hernan
>> <hernan.vargas@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.chautru@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 */
>
Hi Maxime,
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Friday, September 22, 2023 1:15 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
> hemant.agrawal@nxp.com; dev@dpdk.org
> Cc: david.marchand@redhat.com; Vargas, Hernan
> <hernan.vargas@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.coquelin@redhat.com>
> >> Sent: Tuesday, September 19, 2023 2:56 AM
> >> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org
> >> Cc: hemant.agrawal@nxp.com; david.marchand@redhat.com; Vargas,
> Hernan
> >> <hernan.vargas@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.chautru@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 */
> >
On 9/22/23 18:41, Chautru, Nicolas wrote:
> Hi Maxime,
>
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Friday, September 22, 2023 1:15 AM
>> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
>> hemant.agrawal@nxp.com; dev@dpdk.org
>> Cc: david.marchand@redhat.com; Vargas, Hernan
>> <hernan.vargas@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.
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 <maxime.coquelin@redhat.com>
>>>> Sent: Tuesday, September 19, 2023 2:56 AM
>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org
>>>> Cc: hemant.agrawal@nxp.com; david.marchand@redhat.com; Vargas,
>> Hernan
>>>> <hernan.vargas@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.chautru@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 */
>>>
>
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 <maxime.coquelin@redhat.com>
> Sent: Tuesday, September 26, 2023 3:00 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
> hemant.agrawal@nxp.com; dev@dpdk.org
> Cc: david.marchand@redhat.com; Vargas, Hernan
> <hernan.vargas@intel.com>
> 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 <maxime.coquelin@redhat.com>
> >> Sent: Friday, September 22, 2023 1:15 AM
> >> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
> >> hemant.agrawal@nxp.com; dev@dpdk.org
> >> Cc: david.marchand@redhat.com; Vargas, Hernan
> >> <hernan.vargas@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-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 <maxime.coquelin@redhat.com>
> >>>> Sent: Tuesday, September 19, 2023 2:56 AM
> >>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org
> >>>> Cc: hemant.agrawal@nxp.com; david.marchand@redhat.com; Vargas,
> >> Hernan
> >>>> <hernan.vargas@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.chautru@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 */
> >>>
> >
Hi Nicolas,
On 9/28/23 01:50, Chautru, Nicolas wrote:
> 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.
That sounds much better IMHO.
Regarding the array and values sizes:
1. Should it only covers 2048 points FFT? I see some references about
4096 FFT for 5G and satellites communications
2. Is uint16_t enough for all the usecases?
Since this array is quite big, could it be exposed to the application
via dedicated APIs instead of a field? An API to query the length of the
array so that the application can allocate required meory, and an API to
copy the data in the allocated mem?
Maybe overkill, but I feel different FFT size could be supported in the
future, so that would be both future proof and more memory efficient for
apps that don't need this.
> Let me know of opinion.
Thanks for suggesting this,
Maxime
> Thanks
> Nic
>
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Tuesday, September 26, 2023 3:00 AM
>> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
>> hemant.agrawal@nxp.com; dev@dpdk.org
>> Cc: david.marchand@redhat.com; Vargas, Hernan
>> <hernan.vargas@intel.com>
>> 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 <maxime.coquelin@redhat.com>
>>>> Sent: Friday, September 22, 2023 1:15 AM
>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
>>>> hemant.agrawal@nxp.com; dev@dpdk.org
>>>> Cc: david.marchand@redhat.com; Vargas, Hernan
>>>> <hernan.vargas@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-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 <maxime.coquelin@redhat.com>
>>>>>> Sent: Tuesday, September 19, 2023 2:56 AM
>>>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org
>>>>>> Cc: hemant.agrawal@nxp.com; david.marchand@redhat.com; Vargas,
>>>> Hernan
>>>>>> <hernan.vargas@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.chautru@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 */
>>>>>
>>>
>
HI Maxime,
> -----Original Message-----
> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> Sent: Thursday, September 28, 2023 1:27 AM
> To: Chautru, Nicolas <nicolas.chautru@intel.com>; hemant.agrawal@nxp.com;
> dev@dpdk.org
> Cc: david.marchand@redhat.com; Vargas, Hernan <hernan.vargas@intel.com>
> Subject: Re: [PATCH v1 1/7] bbdev: add FFT version member in driver info
>
> Hi Nicolas,
>
> On 9/28/23 01:50, Chautru, Nicolas wrote:
> > 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.
>
> That sounds much better IMHO.
>
> Regarding the array and values sizes:
> 1. Should it only covers 2048 points FFT? I see some references about
> 4096 FFT for 5G and satellites communications 2. Is uint16_t enough for all the
> usecases?
That is a misunderstanding, probably because I did not include the definition and value of RTE_BBDEV_MAX_FFT_WIN on the snippet above.
The dimension of the array is purely the number of windows to choose from, ie. 16.
That is NOT an array matching the size of the FFT. In effect that width value is for the reference for 2048 FFT, but the actual width would be scaled down when a lower FFT is being set or higher for bigger FFT, so this doesn’t make assumption on the max FFT size, just a given portion using a reference resolution for 2048 FFT.
Uint16_t is more than enough, that width cannot be more than 1024 based on reference above.
>
> Since this array is quite big, could it be exposed to the application via dedicated
> APIs instead of a field? An API to query the length of the array so that the
> application can allocate required meory, and an API to copy the data in the
> allocated mem?
>
> Maybe overkill, but I feel different FFT size could be supported in the future, so
> that would be both future proof and more memory efficient for apps that
> don't need this.
Note above, let me know if unclear.
>
> > Let me know of opinion.
>
> Thanks for suggesting this,
> Maxime
>
> > Thanks
> > Nic
> >
> >> -----Original Message-----
> >> From: Maxime Coquelin <maxime.coquelin@redhat.com>
> >> Sent: Tuesday, September 26, 2023 3:00 AM
> >> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
> >> hemant.agrawal@nxp.com; dev@dpdk.org
> >> Cc: david.marchand@redhat.com; Vargas, Hernan
> >> <hernan.vargas@intel.com>
> >> 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 <maxime.coquelin@redhat.com>
> >>>> Sent: Friday, September 22, 2023 1:15 AM
> >>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
> >>>> hemant.agrawal@nxp.com; dev@dpdk.org
> >>>> Cc: david.marchand@redhat.com; Vargas, Hernan
> >>>> <hernan.vargas@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-operat
> >>>> io
> >>>> 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 <maxime.coquelin@redhat.com>
> >>>>>> Sent: Tuesday, September 19, 2023 2:56 AM
> >>>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org
> >>>>>> Cc: hemant.agrawal@nxp.com; david.marchand@redhat.com; Vargas,
> >>>> Hernan
> >>>>>> <hernan.vargas@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.chautru@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 */
> >>>>>
> >>>
> >
On 9/28/23 18:33, Chautru, Nicolas wrote:
> HI Maxime,
>
>
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Thursday, September 28, 2023 1:27 AM
>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; hemant.agrawal@nxp.com;
>> dev@dpdk.org
>> Cc: david.marchand@redhat.com; Vargas, Hernan <hernan.vargas@intel.com>
>> Subject: Re: [PATCH v1 1/7] bbdev: add FFT version member in driver info
>>
>> Hi Nicolas,
>>
>> On 9/28/23 01:50, Chautru, Nicolas wrote:
>>> 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.
>>
>> That sounds much better IMHO.
>>
>> Regarding the array and values sizes:
>> 1. Should it only covers 2048 points FFT? I see some references about
>> 4096 FFT for 5G and satellites communications 2. Is uint16_t enough for all the
>> usecases?
>
> That is a misunderstanding, probably because I did not include the definition and value of RTE_BBDEV_MAX_FFT_WIN on the snippet above.
> The dimension of the array is purely the number of windows to choose from, ie. 16.
Ok, where is the number of windows made available?
> That is NOT an array matching the size of the FFT. In effect that width value is for the reference for 2048 FFT, but the actual width would be scaled down when a lower FFT is being set or higher for bigger FFT, so this doesn’t make assumption on the max FFT size, just a given portion using a reference resolution for 2048 FFT.
Ok, if you could document this with example that would be great.
Maybe you have some existing links explaining that?
> Uint16_t is more than enough, that width cannot be more than 1024 based on reference above.
>
>>
>> Since this array is quite big, could it be exposed to the application via dedicated
>> APIs instead of a field? An API to query the length of the array so that the
>> application can allocate required meory, and an API to copy the data in the
>> allocated mem?
>>
>> Maybe overkill, but I feel different FFT size could be supported in the future, so
>> that would be both future proof and more memory efficient for apps that
>> don't need this.
>
> Note above, let me know if unclear.
It is not clear to me how this representation is generic or specific to
your device.
Thanks,
Maxime
>
>>
>>> Let me know of opinion.
>>
>> Thanks for suggesting this,
>> Maxime
>>
>>> Thanks
>>> Nic
>>>
>>>> -----Original Message-----
>>>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>>>> Sent: Tuesday, September 26, 2023 3:00 AM
>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
>>>> hemant.agrawal@nxp.com; dev@dpdk.org
>>>> Cc: david.marchand@redhat.com; Vargas, Hernan
>>>> <hernan.vargas@intel.com>
>>>> 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 <maxime.coquelin@redhat.com>
>>>>>> Sent: Friday, September 22, 2023 1:15 AM
>>>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>;
>>>>>> hemant.agrawal@nxp.com; dev@dpdk.org
>>>>>> Cc: david.marchand@redhat.com; Vargas, Hernan
>>>>>> <hernan.vargas@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-operat
>>>>>> io
>>>>>> 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 <maxime.coquelin@redhat.com>
>>>>>>>> Sent: Tuesday, September 19, 2023 2:56 AM
>>>>>>>> To: Chautru, Nicolas <nicolas.chautru@intel.com>; dev@dpdk.org
>>>>>>>> Cc: hemant.agrawal@nxp.com; david.marchand@redhat.com; Vargas,
>>>>>> Hernan
>>>>>>>> <hernan.vargas@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.chautru@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 */
>>>>>>>
>>>>>
>>>
>
@@ -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 */