[dpdk-dev] [EXT] Re: [PATCH v2 26/37] net/mvpp2: introduce fixup for fifo overrun

[Ferruh Yigit]

On 1/27/2021 2:46 PM, Liron Himi wrote:
> 
> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit at intel.com>
> Sent: Wednesday, 27 January 2021 16:35
> To: Liron Himi <lironh at marvell.com>; Jerin Jacob Kollanukkaran <jerinj at marvell.com>
> Cc: dev at dpdk.org
> Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v2 26/37] net/mvpp2: introduce fixup for fifo overrun
> 
> On 1/27/2021 2:08 PM, Liron Himi wrote:
>>
>>
>> Liron Himi
>> Staff Software Engineer
>>
>>    
>>
>> Park Azorim, Kyriat Arie, Petah Tikva, 49527, Israel
>> Mobile: +972.52.3329169
>>
>> -----Original Message-----
>> From: Ferruh Yigit <ferruh.yigit at intel.com>
>> Sent: Wednesday, 27 January 2021 01:50
>> To: Liron Himi <lironh at marvell.com>; Jerin Jacob Kollanukkaran
>> <jerinj at marvell.com>
>> Cc: dev at dpdk.org
>> Subject: [EXT] Re: [dpdk-dev] [PATCH v2 26/37] net/mvpp2: introduce
>> fixup for fifo overrun
>>
>> External Email
>>
>> ----------------------------------------------------------------------
>> On 1/22/2021 7:19 PM, lironh at marvell.com wrote:
>>> From: Liron Himi <lironh at marvell.com>
>>>
>>> Currently the HW is configured with only one pool which its buffer
>>> size may be larger than the rx-fifo-size.
>>> In that situation, frame size larger than the fifo-size is gets
>>> dropped due to fifo overrun.
>>> this is cause because the HW works in cut-through mode which waits to
>>> have in the fifo at least the amount of bytes as define in the
>>> smallest pool's buffer size.
>>>
>>> This patch add a dummy pool which its buffer size is very small
>>> (smaller than 64B frame). this tricks the HW and any frame size is
>>> gets passed from the FIFO to the PP2.
>>>
>>> Signed-off-by: Liron Himi <lironh at marvell.com>
>>
>> so this is fixing the FIFO overrun, can you please provide the fixes line?
>> [L.H.] it is kind of combination of HW fifo size (which defined by kernel driver), given buffer size and incoming pkt size. I don't think I can point to a line in DPDK driver code that this patch is fixing.
>> it is a kind of WA for a HW issue.
>>
> 
> Is HW FIFO size or HW behavior (to wait at least smallest pool's buffer size) changed with recent kernel driver or MUSDK to cause this problem? If so can you please mention/reference that change in the commit log?
> [L.H.] I don't think it was related to a change. But this combination was just tested by our QA team.
> I think it may have more affect when the buffer size is of 9K which in some cases may exceed the fifo size of a specific port.
> 

OK, thanks for clarification.

>> And should this patch backported?
>> [L.H.] it cannot be backported as it depends on MUSDK api change.
>>
> 
> Is the fix or problem depends on the MUSDK API change? If the fix has a dependency will this be a problem, since it means latest driver won't be usable with old MUSDK version?
> Can you please clarify the dependency in the commit log?
> [L.H.] I already updated the doc that latest driver (including meson stuff) required new MUSDK version.
> 
> Thanks,
> ferruh
>