[PATCH 0/8] optimize the firmware loading process

[Chaoyong He]

> On 1/25/2024 2:06 AM, Chaoyong He wrote:
> >>>>>> On 1/15/2024 2:54 AM, Chaoyong He wrote:
> >>>>>>> This patch series aims to speedup the DPDK application start by
> >>>>>>> optimize the firmware loading process in sereval places.
> >>>>>>> We also simplify the port name in multiple PF firmware case to
> >>>>>>> make the customer happy.
> >>>>>>>
> >>>>>>
> >>>>>> <...>
> >>>>>>
> >>>>>>>   net/nfp: add the elf module
> >>>>>>>   net/nfp: reload the firmware only when firmware changed
> >>>>>>
> >>>>>> Above commit adds elf parser capability and second one loads
> >>>>>> firmware when build time is different.
> >>>>>>
> >>>>>> I can see this is an optimization effort, to understand FW status
> >>>>>> before loading FW, but relying on build time seems fragile. Does
> >>>>>> it help to add a new section to store version information and
> >>>>>> evaluate based
> >>>> on this information?
> >>>>>>
> >>>>>
> >>>>> We have a branch of firmware (several app type combined with
> >>>>> NFD3/NFDk) with the same version information(monthly publish), so
> >>>>> the
> >>>> version information can't help us, because we can't distinguish
> >>>> among
> >> them.
> >>>>>
> >>>>> But the build time is different for every firmware, and that's the
> >>>>> reason we
> >>>> choose it.
> >>>>>
> >>>>
> >>>> If version is same although FW itself is different, isn't this
> >>>> problem on its
> >> own?
> >>>> Perhaps an additional field is required in version syntax.
> >>>
> >>> Actually, it's just the role the build time which embed in the
> >>> firmware plays,
> >> which is unique for every firmware, and which can't be modified once
> >> the firmware was published.
> >>>
> >>
> >> I see it is already in the elf binary but relying on build time of a
> >> FW to decide to load it or not looks a weak method to me, and fragile as
> stated before.
> >>
> >>> What you said also has its mean, but in practice we can't accept(at
> >>> least can't
> >> do it immediately), which needs to discuss with firmware team.
> >>>
> >>
> >> As it is an optimization I assume it is not urgent, so would you mind
> >> discussing the issue with the FW team, perhaps it can lead to a
> >> better solution, we can proceed after that.
> >
> > After discussing with the FW team, seems we still can't just use version
> because our firmware are published monthly.
> >
> > Between two public version, we also have internal versions like 'rc0, rc1'
> scheme just as DPDK.
> > But the problem is, we may compile and share many firmware in daily
> development.
> > They are maybe only valid for one time and will never publish, so we won't
> assign a version for them.
> >
> 
> So is my understanding correct that this effort is not for customers and not for
> published FWs, but mostly for developers with development FWs.
> 
> If so perhaps it can be simplified even more, there can be a devarg that force
> loads the FW, for development scenario.
> By default, driver checks the FW version and loads according, but if flag is set it
> loads the FW even with same version. When a new development FW is out,
> developer can run DPDK app with this parameter and it loads the FW to test,
> does this make sense.

Yeah, it's a perfect method, thanks.

> 
> I am not trying to be difficult, just the proposed approach didn't satisfy me I
> am trying to understand it and help if I can. And if you please continue
> discussion in the mailing list it enables others to comment and perhaps
> provide a better option.
> 
> 
> > So the build time is the only information we can distinguish them, if just
> using version, PMD will not reload the firmware which needs to test and
> debug.
> >
> > How about we first using version to check, and then using build time to
> check for the same version?
> >
> 
> Nope, I though elf parsing and relying on build time can be removed, if you
> have them anyway, no need to add the version check, can use just the build
> time to check.
> 
> 
> And another related question, if developers are using daily FWs with exact
> same version, when a developer had an unexpected behavior, how she will
> know exactly which version of the FW (in the device), this maybe required to
> track down the problem. Shouldn't each FW have a unique identifier, except
> the "build time" info  which is stored in the elf binary not FW itself?

We will use the devarg and version as your advice, and remove the build time logics.

> 
> >>
> >> Meanwhile I will continue with remaining patches, excluding these two
> >> patches.
> >>
> >>> If you insist that we should change the design, maybe we can just
> >>> kick off
> >> two commits, and upstream the other commits?
> >>> - net/nfp: add the elf module
> >>> - net/nfp: reload the firmware only when firmware changed
> >