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 <t...@redhat.com>
On 8/31/22 6:26 PM, Chautru, Nicolas wrote:
From: Tom Rix <t...@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
