On Mon, 7 Oct, 2019, 3:49 PM Jerin Jacob, <jerinjac...@gmail.com> wrote:
>
>
> On Sun, 6 Oct, 2019, 11:36 PM Thomas Monjalon, <tho...@monjalon.net>
> wrote:
>
>> 05/10/2019 17:28, Jerin Jacob:
>> > On Fri, Oct 4, 2019 at 4:27 AM Dharmik Thakkar <dharmik.thak...@arm.com>
>> wrote:
>> > >
>> > > Add new meson.build file for crypto/armv8
>> > >
>> > > Signed-off-by: Dharmik Thakkar <dharmik.thak...@arm.com>
>> > > ---
>> > > drivers/crypto/armv8/meson.build | 25 +++++++++++++++++++++++++
>> > > drivers/crypto/meson.build | 6 +++---
>> > > meson_options.txt | 2 ++
>> > > 3 files changed, 30 insertions(+), 3 deletions(-)
>> > > create mode 100644 drivers/crypto/armv8/meson.build
>> >
>> > >
>> > > option('allow_invalid_socket_id', type: 'boolean', value: false,
>> > > description: 'allow out-of-range NUMA socket id\'s for
>> platforms that don\'t report the value correctly')
>> > > +option('armv8_crypto_dir', type: 'string', value: '',
>> > > + description: 'path to the armv8_crypto library installation
>> directory')
>>
>> You should not need such option if you provide a pkg-config file
>> in your library.
>>
>>
>> > It is not specific to this patch but it is connected to this patch.
>> >
>> > Three years back when Cavium contributed to this driver the situation
>> > was different where only Cavium was contributing to DPDK and now we
>> > have multiple vendors from
>> > ARMv8 platform and ARM itself is contributing it.
>> >
>> > When it is submitted, I was not in favor of the external library. But
>> > various reasons it happened to be the external library where 90% meat
>> > in this library and shim PMD
>> > the driver moved to DPDK.
>> >
>> > Now, I look back, It does not make sense to the external library.
>> Reasons are
>> > - It won't allow another ARMv8 player to contribute to this library as
>> > Marvell owns this repo and there is no upstreaming path to this
>> > library.
>>
>> This is a real issue and you are able to fix it.
>>
>
> Note sure how I can fix it and why I need to fix it. I just dont want to
> start a parallel collaborating infrastructure for DPDK armv8.
>
>
>>
>> > - That made this library to not have 'any' change for the last three
>> > year and everyone have there owned copy of this driver. In fact the
>> > library was not compiling for last 2.5 years.
>> > - AES-NI case it makes sense to have an external library as it is a
>> > single vendor and it is not specific to DPDK. But in this, It is
>> > another way around
>>
>> I don't see how it is different, except it is badly maintained.
>>
>
> It is different because only one company contributing to it. In this case,
> multiple companies needs to contribute.
>
> The library badly maintained in upstream as there is no incentives to
> upstream to external library. I believe each vendor has it own copy of
> that. At least Some teams in Marvell internally has copy of it.
> What is their incentive to upstream? They ask me the same thing.
>
>
>>
>> > - If it an external library, we might as well add the PMD code as well
>> > there and that only 10% of the real stuff.
>> > We are not able able to improve anything in this library due to this
>> situation.
>> >
>> > Does anyone care about this PMD? If not, we might as well remove this
>> > DPDK and every vendor can manage the external library and external
>> > PMD(Situation won't change much)
>>
>> External PMD is bad.
>>
>
> It is SHIM layer. I would say external library also bad if it is specific
> to DPDK.
>
> I think this library should not be specific to DPDK,
>>
>
> Sadly it is VERY specific to DPDK for doing authentication and encryption
> in one shot to improve the performance. Openssl has already has armv8
> instructions support for doing it as two pass just that performance is not
> good. For use cae such as IPsec it make sense do authentication and
> encryption in one shot for performance improvement.
>
> so it would make sense as an external library
>
>
> If it an external library, it does NOT make much sense for Marvell to
> maintain it(No incentive and it is pain due lack of collaboration)
>
> Either someone need to step up and maintain it if we NOT choose to make it
> as external else we can remove the PMD from dpdk(Makes life easy for
> everyone). I don't want to maintain something not upsteamble nor
> collaboration friendly aka less quality.
>
> .
>>
>>
>>
>>
>> > Thoughts from ARM, other ARMv8 vendors or community?
>>
>
I have expressed my concerns. If there is no constructive feedback to fix
the concern. I will plan for submitting a patch to remove the shim crypto
Armv8 PMD from dpdk by next week.
>>
>>
>>
