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: Fri, 22 Sep 2023 16:41:50 +0000 [thread overview]
Message-ID: <BY5PR11MB4451B9717680E5296626250EF8FFA@BY5PR11MB4451.namprd11.prod.outlook.com> (raw)
In-Reply-To: <97488343-49b0-cdaf-2a6d-919a66093022@redhat.com>
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 */
> >
next prev parent reply other threads:[~2023-09-22 16:42 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 [this message]
2023-09-26 10:00 ` Maxime Coquelin
2023-09-27 23:50 ` Chautru, Nicolas
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=BY5PR11MB4451B9717680E5296626250EF8FFA@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).