-----Original Message----- From: Ferruh Yigit <ferruh.yi...@intel.com> Sent: Wednesday, 27 January 2021 16:35 To: Liron Himi <lir...@marvell.com>; Jerin Jacob Kollanukkaran <jer...@marvell.com> 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: > > > Liron Himi > Staff Software Engineer > > > > Park Azorim, Kyriat Arie, Petah Tikva, 49527, Israel > Mobile: +972.52.3329169 > > -----Original Message----- > From: Ferruh Yigit <ferruh.yi...@intel.com> > Sent: Wednesday, 27 January 2021 01:50 > To: Liron Himi <lir...@marvell.com>; Jerin Jacob Kollanukkaran > <jer...@marvell.com> > 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, lir...@marvell.com wrote: >> From: Liron Himi <lir...@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 <lir...@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
