[PATCH v1 00/10] baseband/acc200

[Maxime Coquelin]

On 9/14/22 15:19, Bruce Richardson wrote:
> On Wed, Sep 14, 2022 at 01:50:05PM +0200, Maxime Coquelin wrote:
>>
>>
>> On 9/14/22 12:35, Thomas Monjalon wrote:
>>> 06/09/2022 14:51, Tom Rix:
>>>> On 9/1/22 1:34 PM, Chautru, Nicolas wrote:
>>>>> From: Tom Rix <trix at redhat.com>
>>>>>> On 8/31/22 6:26 PM, Chautru, Nicolas wrote:
>>>>>>> From: Tom Rix <trix at redhat.com>
>>>>>>>> On 8/31/22 3:37 PM, Chautru, Nicolas wrote:
>>>>>>>>>>>>> Comparing ACC200 & ACC100 header files, I
>>>>>>>>>>>>> understand ACC200 is an evolution of the ACC10x
>>>>>>>>>>>>> family. The FEC bits are really close, ACC200 main
>>>>>>>>>>>>> addition seems to be FFT acceleration which could
>>>>>>>>>>>>> be handled in ACC10x driver based on device ID.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think both drivers have to be merged in order to
>>>>>>>>>>>>> avoid code duplication. That's how other families
>>>>>>>>>>>>> of devices (e.g. i40e) are handled.
>>>>>>>>>>>> I haven't seen your reply on this point.  Do you
>>>>>>>>>>>> confirm you are working on a single driver for ACC
>>>>>>>>>>>> family in order to avoid code duplication?
>>>>>>>>>>>>
>>>>>>>>>>> The implementation is based on distinct ACC100 and
>>>>>>>>>>> ACC200 drivers.  The 2
>>>>>>>>>> devices are fundamentally different generation, processes
>>>>>>>>>> and IP.
>>>>>>>>>>> MountBryce is an eASIC device over PCIe while ACC200 is
>>>>>>>>>>> an integrated
>>>>>>>>>> accelerator on Xeon CPU.
>>>>>>>>>>> The actual implementation are not the same, underlying
>>>>>>>>>>> IP are all distinct
>>>>>>>>>> even if many of the descriptor format have similarities.
>>>>>>>>>>> The actual capabilities of the acceleration are
>>>>>>>>>>> different and/or new.  The workaround and silicon
>>>>>>>>>>> errata are also different causing different
>>>>>>>>>> limitation and implementation in the driver (see the
>>>>>>>>>> serie with ongoing changes for ACC100 in parallel).
>>>>>>>>>>> This is fundamentally distinct from ACC101 which was a
>>>>>>>>>>> derivative product
>>>>>>>>>> from ACC100 and where it made sense to share
>>>>>>>>>> implementation
>>>>>> between
>>>>>>>>>> ACC100 and ACC101.
>>>>>>>>>>> So in a nutshell these 2 devices and drivers are 2
>>>>>>>>>>> different beasts and the
>>>>>>>>>> intention is to keep them intentionally separate as in
>>>>>>>>>> the serie.
>>>>>>>>>>> Let me know if unclear, thanks!
>>>>>>>>>> Nic,
>>>>>>>>>>
>>>>>>>>>> I used a similarity checker to compare acc100 and acc200
>>>>>>>>>>
>>>>>>>>>> https://dickgrune.com/Programs/similarity_tester/
>>>>>>>>>>
>>>>>>>>>> l=simum.log if [ -f $l ]; then rm $l fi
>>>>>>>>>>
>>>>>>>>>> sim_c -s -R -o$l -R -p -P -a .
>>>>>>>>>>
>>>>>>>>>> There results are
>>>>>>>>>>
>>>>>>>>>> ./acc200/acc200_pf_enum.h consists for 100 % of
>>>>>>>>>> ./acc100/acc100_pf_enum.h material
>>>>>>>>>> ./acc100/acc100_pf_enum.h consists for 98 % of
>>>>>>>>>> ./acc200/acc200_pf_enum.h material
>>>>>>>>>> ./acc100/rte_acc100_pmd.h consists for 98 % of
>>>>>>>>>> ./acc200/acc200_pmd.h material ./acc200/acc200_vf_enum.h
>>>>>>>>>> consists for 95 % of ./acc100/acc100_pf_enum.h material
>>>>>>>>>> ./acc200/acc200_pmd.h consists for 92 % of
>>>>>>>>>> ./acc100/rte_acc100_pmd.h material
>>>>>>>>>> ./acc200/rte_acc200_cfg.h consists for 92 % of
>>>>>>>>>> ./acc100/rte_acc100_cfg.h material
>>>>>>>>>> ./acc100/rte_acc100_pmd.c consists for 87 % of
>>>>>>>>>> ./acc200/rte_acc200_pmd.c material
>>>>>>>>>> ./acc100/acc100_vf_enum.h consists for 80 % of
>>>>>>>>>> ./acc200/acc200_pf_enum.h material
>>>>>>>>>> ./acc200/rte_acc200_pmd.c consists for 78 % of
>>>>>>>>>> ./acc100/rte_acc100_pmd.c material
>>>>>>>>>> ./acc100/rte_acc100_cfg.h consists for 75 % of
>>>>>>>>>> ./acc200/rte_acc200_cfg.h material
>>>>>>>>>>
>>>>>>>>>> Spot checking the first *pf_enum.h at 100%, these are the
>>>>>>>>>> devices' registers, they are the same.
>>>>>>>>>>
>>>>>>>>>> I raised this similarity issue with 100 vs 101.
>>>>>>>>>>
>>>>>>>>>> Having multiple copies is difficult to support and should
>>>>>>>>>> be avoided.
>>>>>>>>>>
>>>>>>>>>> For the end user, they should have to use only one
>>>>>>>>>> driver.
>>>>>>>>>>
>>>>>>>>> There are really different IP and do not have the same
>>>>>>>>> interface (PCIe/DDR vs
>>>>>>>> integrated) and there is big serie of changes which are
>>>>>>>> specific to ACC100 coming in parallel. Any workaround,
>>>>>>>> optimization would be
>>>>>> different.
>>>>>>>>> I agree that for the coming serie of integrated accelerator
>>>>>>>>> we will use a
>>>>>>>> unified driver approach but for that very case that would be
>>>>>>>> quite messy to artificially put them within the same PMD.
>>>>>>>>
>>>>>>>> How is the IP different when 100% of the registers are the
>>>>>>>> same ?
>>>>>>>>
>>>>>>> These are 2 different HW aspects. The base toplevel
>>>>>>> configuration registers
>>>>>> are kept similar on purpose but the underlying IP are totally
>>>>>> different design and implementation.
>>>>>>> Even the registers have differences but not visible here, the
>>>>>>> actual RDL file
>>>>>> would define more specifically these registers bitfields and
>>>>>> implementation including which ones are not implemented (but that
>>>>>> is proprietary information), and at bbdev level the interface is
>>>>>> not some much register based than processing based on data from
>>>>>> DMA.
>>>>>>> Basically even if there was a common driver, all these would be
>>>>>>> duplicated
>>>>>> and they are indeed different IP (including different vendors)..
>>>>>>> But I agree with the general intent and to have a common driver
>>>>>>> for the
>>>>>> integrated driver serie (ACC200, ACC300...) now that we are
>>>>>> moving away from PCIe/DDR lookaside acceleration and eASIC/FPGA
>>>>>> implementation (ACC100/AC101).
>>>>>>
>>>>>> Looking a little deeper, at how the driver is lays out some of
>>>>>> its bitfields and private data by reviewing the
>>>>>>
>>>>>> ./acc200/acc200_pmd.h consists for 92 % of
>>>>>> ./acc100/rte_acc100_pmd.h
>>>>>>
>>>>>> There are some minor changes to existing reserved bitfields.  A
>>>>>> new structure for fft.  The acc200_device, the private data for
>>>>>> the driver, is an exact copy of acc100_device.
>>>>>>
>>>>>> acc200_pmd.h is the superset and could be used with little
>>>>>> changes as a common acc_pmd.h.  acc200 is doing everything the
>>>>>> acc100 did in a very similar if not exact way, adding the fft
>>>>>> feature.
>>>>>>
>>>>>> Can you point to some portion of this patchset that is so unique
>>>>>> that it could not be abstracted to an if-check or function and so
>>>>>> requiring this separate, nearly identical driver ?
>>>>>>
>>>>> You used a similarity checker really, there are actually way more
>>>>> relevent differences than what you imply here.  With regards to the
>>>>> 2 pf_enum.h file, there are many registers that have same or
>>>>> similar names but have now different values being mapped hence you
>>>>> just cannot use one for the other.  Saying that
>>>>> "./acc200/acc200_pmd.h consists for 92 % of
>>>>> ./acc100/rte_acc100_pmd.h" is just not correct and really
>>>>> irrelevant.  Just do a diff side by side please and check, that
>>>>> should be extremely obvious, that metrics tells more about the
>>>>> similarity checker limitation than anything else.  Even when using
>>>>> a common driver for ACC200/300 they will have distinct register
>>>>> enum files being auto-generated and coming from distinct RDL.
>>>>> Again just do a diff of these 2 files. I believe you will agree
>>>>> that is not relevant for these files to try to artificially merged
>>>>> these together.
>>>>>
>>>>> With regards to the pmd.h, some structure/defines are indeed common
>>>>> and could be moved to a common file (for instance turboencoder and
>>>>> LDPC encoder which are more vanilla and unlikely to change for
>>>>> future product unlike the decoders which have different feature set
>>>>> and behaviour; or some 3GPP constant that can be defined once).  We
>>>>> can definitely change these to put together shared
>>>>> structures/defines, but not intending to try to artificially put
>>>>> things together with spaghetti code.  We would like to keep 3
>>>>> parallel versions of these PMD for 3 different product lines which
>>>>> are indeed fundamentally different designs (including different
>>>>> workaround required as can be seen on the parallel ACC100 serie
>>>>> under review).  - one version for FPGA implementation (support for
>>>>> N3000, N6000, ...) - one version for eASIC lookaside card
>>>>> implementation (ACC100, ACC101, ...) - one version for the
>>>>> integrated Xeon accelerators (ACC200, ACC300, ...)
>>>>
>>>> Some suggestions on refactoring,
>>>>
>>>> For the registers, have a common file.
>>>>
>>>> For the shared functionality, ex/ ldpc encoder, break these out to
>>>> its own shared file.
>>>>
>>>> The public interface, see my earlier comments on the documentation,
>>>> should be have the same interfaces and the few differences
>>>> highlighted.
>>>
>>> +1 to have common files, and all in a single directory
>>> drivers/baseband/acc100/
>>
>> Jus to be sure we are aligned, do you mean to have both drivers in the
>> same directory, which will share some common files? That's the way I
>> would go.
>>
> 
> I think the expectation is that the two drivers will diverge in future, so
> having separate directories should be ok, even with common files placed in
> one directory are shared with another. With meson include paths its pretty
> trivial to manage if it's just header files, and even if there are common C
> files, there is always the option of using drivers/common if we want to
> split them out. As I understand it, right now it's only headers inluding
> functions which can be static inline, so simple sharing via include paths
> should work fine.

Ok, then I prefer having the common parts in drivers/common/acc, in
order to make it clear changes to these common files have impact on
other drivers than ACC100.

Is that good for you?

Thanks,
Maxime

> /Bruce
>