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>] [day] [month] [year] [list]
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