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

[Ferruh Yigit]

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?

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

Thanks,
ferruh