> -----Original Message----- > From: David Miller <davem@xxxxxxxxxxxxx> > Sent: Wednesday, March 4, 2020 1:54 AM > To: Madalin Bucur (OSS) <madalin.bucur@xxxxxxxxxxx> > Subject: Re: [PATCH net 4/4] dpaa_eth: FMan erratum A050385 workaround > > From: Madalin Bucur <madalin.bucur@xxxxxxxxxxx> > Date: Tue, 3 Mar 2020 17:55:39 +0200 > > > +#define DPAA_FD_DATA_ALIGNMENT ((fman_has_errata_a050385()) ? \ > > You don't need parenthesis around that fman_has_errata_a050385() call. > > > +#define dpaa_bp_size(raw_size) ((SKB_WITH_OVERHEAD(raw_size)) & \ > > Similar again for SKB_WITH_OVERHEAD() I'll send a v2, thanks. > Also, how often does this errata code trigger on effected platforms and > what is the performance degradation from that? I don't see this analysis > performed anywhere. To reproduce this issue when the workaround is not applied, one needs to ensure the FMan DMA transaction queue is already full when a transaction split occurs so the system must be under high traffic load (i.e. multiple ports at line rate). After the errata occurs, the traffic stops. The only SoC impacted by this is the LS1043A, the other ARM DPAA 1 SoC or the PPC DPAA 1 SoCs do not have this erratum. Madalin
