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

[Liron Himi]

-----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.

> 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