Hello Nicolas, Maxime, On Tue, Aug 4, 2020 at 10:49 AM Maxime Coquelin <maxime.coque...@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
