On 1/27/2021 2:46 PM, Liron Himi wrote:

-----Original Message-----
From: Ferruh Yigit <redacted>
Sent: Wednesday, 27 January 2021 16:35
To: Liron Himi <redacted>; Jerin Jacob Kollanukkaran <redacted>
Cc: dev@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:

quoted

Liron Himi
Staff Software Engineer

   

Park Azorim, Kyriat Arie, Petah Tikva, 49527, Israel
Mobile: +972.52.3329169

-----Original Message-----
From: Ferruh Yigit <redacted>
Sent: Wednesday, 27 January 2021 01:50
To: Liron Himi <redacted>; Jerin Jacob Kollanukkaran
[off-list ref]
Cc: dev@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@marvell.com wrote:

quoted

From: Liron Himi <redacted>

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

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.

quoted

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