On 9/24/2018 12:51 PM, Marcin Wojtas wrote:
> Hi Ferruh,
> 
> pon., 24 wrz 2018 o 13:38 Ferruh Yigit <ferruh.yi...@intel.com> napisaƂ(a):
>>
>> On 9/23/2018 11:40 PM, Thomas Monjalon wrote:
>>> 19/09/2018 19:15, Ferruh Yigit:
>>>> On 9/4/2018 2:49 PM, Tomasz Duszynski wrote:
>>>>> From: Natalie Samsonov <nsams...@marvell.com>
>>>>> --- a/doc/guides/nics/mvpp2.rst
>>>>> +++ b/doc/guides/nics/mvpp2.rst
>>>>> -     git clone 
>>>>> https://github.com/MarvellEmbeddedProcessors/linux-marvell.git -b 
>>>>> linux-4.4.52-armada-17.10
>>>>> +     git clone 
>>>>> https://github.com/MarvellEmbeddedProcessors/linux-marvell.git -b 
>>>>> linux-4.4.120-armada-18.09
>>>>
>>>> There is a strict dependency to MUSDK 18.09, dpdk18.11 won't compile with 
>>>> older
>>>> versions. It is hard to trace this dependency, what do you think having a 
>>>> matrix
>>>> in DPDK documentation showing which DPDK version supports which MUSDK?
>>>
>>> It does not compile even with MUSDK 18.09.
>>>
>>> With MUSDK 18.09, the error is:
>>>       drivers/crypto/mvsam/rte_mrvl_pmd.c:867:26: error: 'SAM_HW_RING_NUM' 
>>> undeclared
>>
>> I confirm same error. I wasn't building with crypto PMD enabled so not 
>> caught it.
>>
>>>
>>> The explanation is in MUSDK:
>>> commit 9bf8b3ca4ddfa00619c0023dfb08ae1601054fce
>>> Author: Dmitri Epshtein <d...@marvell.com>
>>> Date:   Mon Nov 20 10:38:31 2017 +0200
>>>
>>>     sam: remove SAM_HW_RING_NUM from APIs
>>>
>>>     Use function:
>>>     u32 sam_get_num_cios(u32 inst);
>>>
>>> As a consequence, next-net cannot be pulled!
>>
>> Got it, should I drop the patchset from tree?
> 
> We're checking the error and will provide fix asap. Please let know if
> this should be another version of the entire patchset or fix on top.

There is another comment from Thomas (mvpp2_tm.png).

Both "fix on top" and "new version" is OK for me, pick whichever easy for you.
For "fix on top", I will squash fixes to original commits, so fixes should be
separate patches with a information which commit it targets.

But overall build should not be broken, it should be clear in which commit
dependency changed to 18.09. Let call the commit that switch happens X,
all commits before X should compile successfully with 17.10, commit X and all
following commits should be compile successfully with 18.09.

> Sorry for the problems.
> 
> Best regards,
> Marcin
> 

Reply via email to