| 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
| ||
|
Message-ID: <31dafcf4-5136-02b0-ab21-c56725c6a68a@synopsys.com>
Date: Wed, 28 Dec 2016 12:26:13 +0000
From: Joao Pinto <Joao.Pinto@...opsys.com>
To: Kishan Sandeep <sandeepkishan108@...il.com>,
Joao Pinto <Joao.Pinto@...opsys.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH v3] stmmac: enable rx queues
Às 12:23 PM de 12/28/2016, Kishan Sandeep escreveu:
> On Dec 28, 2016 5:50 PM, "Joao Pinto" <Joao.Pinto@...opsys.com> wrote:
>>
>> Às 12:19 PM de 12/28/2016, Joao Pinto escreveu:
>>> Às 12:15 PM de 12/28/2016, Kishan Sandeep escreveu:
>>>> On Dec 28, 2016 5:36 PM, "Joao Pinto" <Joao.Pinto@...opsys.com> wrote:
>>>>>
>>>>> Às 12:02 PM de 12/28/2016, Kishan Sandeep escreveu:
>>>>>> On Wed, Dec 28, 2016 at 5:23 PM, Joao Pinto <Joao.Pinto@...opsys.com>
>>>> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Às 11:50 AM de 12/28/2016, Kishan Sandeep escreveu:
>>>>>>>> On Wed, Dec 28, 2016 at 4:45 PM, Joao Pinto <
> Joao.Pinto@...opsys.com>
>>>> wrote:
>>>>>>>>
>>>>>>>>> When the hardware is synthesized with multiple queues, all queues
> are
>>>>>>>>> disabled for default. This patch adds the rx queues configuration.
>>>>>>>>> This patch was successfully tested in a Synopsys QoS Reference
>>>> design.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Joao Pinto <jpinto@...opsys.com>
>>>>>>>>> ---
>>>>>>>>> changes v2 -> v3 (Seraphin Bonnaffe):
>>>>>>>>> - GMAC_RX_QUEUE_CLEAR macro simplified
>>>>>>>>> changes v1 -> v2 (Niklas Cassel and Seraphin Bonnaffe):
>>>>>>>>> - Instead of using number of DMA channels, lets use number of
> queues
>>>>>>>>> - Create 2 flavors of RX queue enable Macros: AV and DCB (AV by
>>>> default)
>>>>>>>>> - Make sure that the RX queue related bits are cleared before
> setting
>>>>>>>>> - Check if rx_queue_enable is available before executing
>>>>>>>>>
>>>>>>>>> drivers/net/ethernet/stmicro/stmmac/common.h | 5 +++++
>>>>>>>>> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 8 ++++++++
>>>>>>>>> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 12
> ++++++++++++
>>>>>>>>> drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 5 +++++
>>>>>>>>> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 22
>>>>>>>>> ++++++++++++++++++++++
>>>>>>>>> 5 files changed, 52 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>>> b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>>> index b13a144..6c96291 100644
>>>>>>>>> --- a/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>>> +++ b/drivers/net/ethernet/stmicro/stmmac/common.h
>>>>>>>>> @@ -323,6 +323,9 @@ struct dma_features {
>>>>>>>>> /* TX and RX number of channels */
>>>>>>>>> unsigned int number_rx_channel;
>>>>>>>>> unsigned int number_tx_channel;
>>>>>>>>> + /* TX and RX number of queues */
>>>>>>>>> + unsigned int number_rx_queues;
>>>>>>>>> + unsigned int number_tx_queues;
>>>>>>>>>
>>>>>>>>
>>>>>>>> Looks like this variable is unused. Current driver is only
> supporting
>>>>>>>> single Tx channel/queue. ?? Is current driver not supporting
>>>>>>>> multichannel/multiqueue ?
>>>>>>>
>>>>>>> stmmac has a good base for multichannel / multiple queue support,
> but
>>>> is only
>>>>>>> using 1 for now. My next task is to add complete multiple queues /
>>>> channel to
>>>>>>> stmmac amd that is why number of tx queues is being available.
>>>>>>>
>>>>>>> Thanks!
>>>>>>
>>>>>> I believe *number_tx_queues* variable can be added at the time
> support
>>>>>> we are providing.
>>>>>>
>>>>>> One query is that what is the algorithm that we are following
>>>>>> currently in the driver if we enable multi Rx queues/DMA channels ?
>>>>>
>>>>> In a synthesized core with single channel, multi dma/queues is not an
>>>> issue
>>>>> since it has a single queue and that's it. For a synthesized core with
>>>> multiple
>>>>> there are some algorithms that can be configured in the driver. I will
>>>> include
>>>>> them later. I can change this patch and enale rx queue 0 only, no
> problem.
>>>>
>>>> Generally there will be one to one mapping from the DMA channel to
>>>> corresponding MTL queue. If we enable multiple MTL RX queues, is there
> any
>>>> requirement to use those many number of DMA channels in RX path or
> single
>>>> DMA RX channel is sufficient ???
>>>
>>> I am using an ethernet QoS reference design synthesized with 4
> channels / 4
>>> queues. Since stmmac only uses one 1 queue / 1 dma channel. Of course
> the
>>> performance is not the same as using the 4 available ones. I would say
> the
>>> correct approach would be tp get the available rx/tx dma channel number
> and
>>> rx/tx queue number configured in the hardware and get the driver adapt
> and use
>>> as many as there are.
>>
>> Of course there should be always dma channels = queues.
>>
>>>
>>>>
>>>
> In that case here we need to enable multi DMA channels along with multiple
> RX channels also we may need to program the algorithm that needs to run on
> queues
I understand your concern. In order to do this step by step, I am going to
change the patch and enable RX queue 0 only, and then when I finish multiple
support I will add multi rx and tx. I will send a v4 in the afternoon. This way
it will be cleaner and less confusing.
Thanks.
Powered by blists - more mailing lists