[dpdk-dev] [PATCH 5/5] config: enable dpaaX drivers compilation for ARMv8

Hemant Agrawal hemant.agrawal at nxp.com
Tue Jan 30 10:33:19 CET 2018


On 1/30/2018 2:12 PM, Hemant Agrawal wrote:
> Hi Jerin,
> 
> On 1/25/2018 4:51 PM, Jerin Jacob wrote:
>> -----Original Message-----
>>> Date: Thu, 25 Jan 2018 15:23:31 +0530
>>> From: Hemant Agrawal <hemant.agrawal at nxp.com>
>>> To: dev at dpdk.org
>>> CC: jerin.jacob at caviumnetworks.com
>>> Subject: [PATCH 5/5] config: enable dpaaX drivers compilation for ARMv8
>>> X-Mailer: git-send-email 2.7.4
>>>
>>> This patch enables the NXP DPAA & DPAA2 drivers for
>>> ARMV8 targets. They can be used with standard armv8 config
>>> with command line mempool argument or newly introduced
>>> platform mempool internal registration mechanism.
>>>
>>> Note that the dpaa(x) specific config files are still preserved
>>> to continue customer support. They also contain some of the ARM
>>> performance tuning flags. e.g the default ARM cache size of 128
>>> is not optimal for NXP platforms.
>>>
>>> However, these configs will eventually be removed once a dynamic
>>> mechanisms are developed to detect the performance settings.
>>>
>>> Signed-off-by: Hemant Agrawal <hemant.agrawal at nxp.com>
>>> ---
>>>   config/common_armv8a_linuxapp | 58 
>>> +++++++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 58 insertions(+)
>>>
>>> diff --git a/config/common_armv8a_linuxapp 
>>> b/config/common_armv8a_linuxapp
>>> index 790e716..572db11 100644
>>> --- a/config/common_armv8a_linuxapp
>>> +++ b/config/common_armv8a_linuxapp
>>> @@ -34,3 +34,61 @@ CONFIG_RTE_LIBRTE_SFC_EFX_PMD=n
>>>   CONFIG_RTE_LIBRTE_AVP_PMD=n
>>>   CONFIG_RTE_SCHED_VECTOR=n
>>> +
>>> +#
>>> +# ARMv8 Specific driver compilation flags
>>> +#
>>
>> Will it be better if it is enabled in generic config?
>>
>> If you have any assembly code then you just stub it for non arm64.
>> Since these are integrate controllers, I guess, there is no issue in
>> stubbing the non arm64 specific things.
>>
>> I believe in that way, it will be maintainable. i.e there will not
>> any case where arm64 config failing but not non arm64 configs.
>>
>> On the upside, The common code(ethdev, cryptodev) changes will be build
>> against your driver by all the developers.
> 
> It is a good suggestion and we did attempted it and realized that the 
> amount of changes required are more than expected.
> We will attempt it for next release.
> 
> However, if you are ok, please ack it in ARM for now.
> 
> 
I take it back. I figured out easy changes to make it compile for x86 as 
well.

We will submit the v2.


More information about the dev mailing list