lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 9 Mar 2017 13:18:11 -0700
From:   Stephen Warren <swarren@...dotorg.org>
To:     Thierry Reding <thierry.reding@...il.com>,
        Mikko Perttunen <cyndis@...si.fi>
Cc:     "David S . Miller" <davem@...emloft.net>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Alexandre Courbot <gnurou@...il.com>,
        Jon Hunter <jonathanh@...dia.com>, netdev@...r.kernel.org,
        linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/7] net: stmmac: Program RX queue size and flow control

On 03/09/2017 12:42 PM, Thierry Reding wrote:
> On Mon, Feb 27, 2017 at 12:09:02PM +0200, Mikko Perttunen wrote:
>> On 23.02.2017 19:24, Thierry Reding wrote:
>>> From: Thierry Reding <treding@...dia.com>
>>>
>>> Program the receive queue size based on the RX FIFO size and enable
>>> hardware flow control for large FIFOs.

>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c

>>> @@ -252,6 +253,44 @@ static void dwmac4_dma_chan_op_mode(void __iomem *ioaddr, int txmode,
>>>  			mtl_rx_op |= MTL_OP_MODE_RTC_128;
>>>  	}
>>>
>>> +	mtl_rx_op &= ~MTL_OP_MODE_RQS_MASK;
>>> +	mtl_rx_op |= rqs << MTL_OP_MODE_RQS_SHIFT;
>>> +
>>> +	/* enable flow control only if each channel gets 4 KiB or more FIFO */
>>> +	if (rxfifosz >= 4096) {
>>> +		unsigned int rfd, rfa;
>>> +
>>> +		mtl_rx_op |= MTL_OP_MODE_EHFC;
>>> +
>>> +		switch (rxfifosz) {
>>> +		case 4096:
>>> +			rfd = 0x03;
>>> +			rfa = 0x01;
>>> +			break;
>>> +
>>> +		case 8192:
>>> +			rfd = 0x06;
>>> +			rfa = 0x0a;
>>> +			break;
>>> +
>>> +		case 16384:
>>> +			rfd = 0x06;
>>> +			rfa = 0x12;
>>> +			break;
>>> +
>>> +		default:
>>> +			rfd = 0x06;
>>> +			rfa = 0x1e;
>>> +			break;
>>> +		}
>>
>> Are these values correct? In the 4096 case, rfd > rfa, in all other cases
>> the other way around. In any case it would be useful to have a comment
>> clarifying the thresholds in bytes.
>
> I'll investigate. To be honest I simply took this from Stephen's U-Boot
> driver since that's already tested. I trust Stephen, so I didn't bother
> double-checking.

I don't recall for sure, but I think these values came directly from 
either the upstream kernel (the non-stmmac driver) or NV downstream 
kernel EQoS driver, and I re-used them without investigating. I'm not 
even sure if the outer if() expression is true; these numbers might not 
even end up being used?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ