Re: [dpdk-dev] [20.11, PATCH v2] baseband/fpga_5gnr_fec: add companion PF config App

[David Marchand <david.marchand@redhat.com>]

Hello Nicolas, Maxime,

On Tue, Aug 4, 2020 at 10:49 AM Maxime Coquelin
<maxime.coquelin@redhat.com> wrote:
> >>>> One question I have is whether this is the tool itself that has a
> >>>> dependency on the PMD, or just the config file?
> >>>
> >>> Each PMD directory would have its own version of the companion PF
> >> config application.
> >>> Ie. the patch above is only for baseband/fpga_5gnr_fec ie. Intel Vista Creek
> >> with 5G LDPC user image.
> >>
> >> OK. Does it mean the same application and configuration will work for
> >> baseband/fpga_5gnr_fec PMD versions v20.11, v21.02, v21.05, etc, ...?
> >>
> >> If not, is there a way for the PMD driver to detect whether a wrong
> >> configuration was applied? Something like checking the FW version of a NIC
> >> is supported by the PMD driver.
> >>
> >
> > As mentioned above there is no API between the 2 config-app companion and BBDEV/DPDK, as they belong logically to 2 different entities (possibly containers) without shared interface except indirectly through HW.
> > There is no strict API which could be broken between the 2, but purely 2 SW ingredients that ideally should be aligned to avoid discrepancy during deployment or validation.
> > To answer your question I don't foresee a specific case right now causing a strict loss of functional compatibility.
> >
> > Note that the configure function being used within config-app already exists right now within the DPDK PMD : ie. that function is the one being exposed by PMD and used when running bbdev-test in DPDK for PF. The limitation being that this is only used when running *within DPDK and from PF*, which is not the deployment use case ie. when DPDK is on the VF only, and PF only performs HW configuration without DPDK dependency (apologize for repeating).

I am naively thinking that the bitstream + this configuration are a
whole for a given usecase and should be loaded as a single step.
A bit like how vendors provide ready-to-use firmwares on their nics.

Leaving the users with the possibility to load whatever config they
write is scary.
When hitting an init issue, application crash etc... in a customer
env, how will we know the configuration is actually what it should be?


>
> OK, got it.
>
> > You can see 'fpga_write_config()' in the current patchset which does match line-for-line with 'fpga_5gnr_fec_configure()' already in the PMD on DPDK main branch. Virtually the same code really with same config input structure 'fpga_5gnr_fec_conf' and same registers being written to.
> > Difference being that the former implementation is formally integrated in DPDK while the other (config app companion in same directory) has no DPDK dependency. That's it.
> > There is concern in having these 2 different implementations of the same initialization sequence diverging (a fix to a register setting would need to be applied on both repositories with different versioning) and splitting the HW support into multiple repos, hence my personal preference to keep everything in one place.
>
> I understand it would be easier for you.
> Maybe an alternative would be to have a simple DPDK application that
> uses the PMD driver on the PF just for the initialization. Doing that,
> you would not even have to duplicate the config part between the PMD
> driver and the application, and you would have a single config app for
> every cards and bitstreams. It would also mean you get rid off the
> external dependency on inih library.
>
> > As stated from the beginning I personally see pros and cons on both sides, all in all DPDK arguably being cleaner to me for the reasons above.
> > Still the most important is that it needs to make sense and be valuable to DPDK.
> > Based on latest feedback from Maxime and Thomas, I believe this is now trending towards being preferred outside of DPDK. If you can confirm by email then that is fine and I will just abandon this ticket so that we can consider alternate options and split this into different repos.
>
> In its current form, this is a nack for me. I would prefer either having
> it outside of DPDK, or having a DPDK application calling the PMD
> driver init.

This is a nack from me too.

About having a DPDK application calling the PMD driver init.
This requires to have a DPDK application from version X touching the
hw in the host, while a guest could be running DPDK version Y.
This will result in ping/pong when the support on the host and guest
sides is done by two different teams.


Thanks.

-- 
David Marchand