From: "Chautru, Nicolas" <nicolas.chautru@intel.com>
To: Maxime Coquelin <maxime.coquelin@redhat.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "david.marchand@redhat.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
Date: Wed, 27 Sep 2023 23:50:29 +0000 [thread overview]
Message-ID: <BY5PR11MB445195E7AFFCEF797BBE0488F8C2A@BY5PR11MB4451.namprd11.prod.outlook.com> (raw)
In-Reply-To: <076b5c15-e8be-c78b-391a-b16d0958d530@redhat.com>
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 */
> >>>
> >
next prev parent reply other threads:[~2023-09-27 23:50 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 1:21 [PATCH v1 0/7] VRB2 BBDEV PMD introduction Nicolas Chautru
2023-09-19 1:21 ` [PATCH v1 1/7] bbdev: add FFT version member in driver info Nicolas Chautru
2023-09-19 9:55 ` Maxime Coquelin
2023-09-19 20:51 ` Chautru, Nicolas
2023-09-22 8:14 ` Maxime Coquelin
2023-09-22 16:41 ` Chautru, Nicolas
2023-09-26 10:00 ` Maxime Coquelin
2023-09-27 23:50 ` Chautru, Nicolas [this message]
2023-09-28 8:27 ` Maxime Coquelin
2023-09-28 16:33 ` Chautru, Nicolas
2023-10-03 11:46 ` Maxime Coquelin
2023-09-19 1:21 ` [PATCH v1 2/7] baseband/acc: add FFT version in the VRM PMD Nicolas Chautru
2023-09-19 1:21 ` [PATCH v1 3/7] baseband/acc: remove the 4G SO capability for VRB1 Nicolas Chautru
2023-09-19 15:20 ` David Marchand
2023-09-19 20:32 ` Chautru, Nicolas
2023-09-21 7:13 ` David Marchand
2023-09-21 17:18 ` Chautru, Nicolas
2023-09-27 7:08 ` Maxime Coquelin
2023-09-27 7:32 ` Maxime Coquelin
2023-09-19 1:21 ` [PATCH v1 4/7] baseband/acc: allocate FCW memory separately Nicolas Chautru
2023-09-19 1:21 ` [PATCH v1 5/7] baseband/acc: add support for MLD operation Nicolas Chautru
2023-09-19 1:21 ` [PATCH v1 6/7] baseband/acc: introduce the new VRB2 variant Nicolas Chautru
2023-09-19 1:21 ` [PATCH v1 7/7] baseband/acc: add configure helper for VRB2 Nicolas Chautru
2023-09-21 7:25 ` [PATCH v1 0/7] VRB2 BBDEV PMD introduction David Marchand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BY5PR11MB445195E7AFFCEF797BBE0488F8C2A@BY5PR11MB4451.namprd11.prod.outlook.com \
--to=nicolas.chautru@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=hemant.agrawal@nxp.com \
--cc=hernan.vargas@intel.com \
--cc=maxime.coquelin@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).