linux-kernel - Re: Synopsys Ethernet QoS Driver

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:   Mon, 21 Nov 2016 15:14:40 +0000
From:   Joao Pinto <Joao.Pinto@...opsys.com>
To:     Giuseppe CAVALLARO <peppe.cavallaro@...com>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Rayagond Kokatanur <rayagond@...avyalabs.com>,
        Rabin Vincent <rabin@....in>
CC:     mued dib <kreptor@...il.com>, David Miller <davem@...emloft.net>,
        "Jeff Kirsher" <jeffrey.t.kirsher@...el.com>, <jiri@...lanox.com>,
        <saeedm@...lanox.com>, <idosch@...lanox.com>,
        netdev <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <CARLOS.PALMINHA@...opsys.com>, <andreas.irestal@...s.com>,
        <alexandre.torgue@...com>, <lars.persson@...s.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Synopsys Ethernet QoS Driver

On 21-11-2016 15:03, Giuseppe CAVALLARO wrote:
> On 11/21/2016 4:00 PM, Joao Pinto wrote:
>> On 21-11-2016 14:36, Giuseppe CAVALLARO wrote:
>>> Hello Joao
>>>
>>> On 11/21/2016 2:48 PM, Joao Pinto wrote:
>>>> Synopsys QoS IP is a separated hardware component, so it should be reusable by
>>>> all implementations using it and so have its own "core driver" and platform +
>>>> pci glue drivers. This is necessary for example in hardware validation, where
>>>> you prototype an IP and instantiate its drivers and test it.
>>>>
>>>> Was there a strong reason to integrate QoS features directly in stmmac and not
>>>> in synopsys/dwc_eth_qos.*?
>>>
>>> We decided to enhance the stmmac on supporting the QoS for several
>>> reasons; for example the common APIs that the driver already exposed and
>>> actually suitable for other SYNP chips. Then, PTP, EEE,
>>> S/RGMII, MMC could be shared among different chips with a minimal
>>> effort.  This meant a lot of code already ready.
>>>
>>> For sure, the net-core, Ethtool, mdio parts were reused. Same for the
>>> glue logic files.
>>> For the latter, this helped to easily bring-up new platforms also
>>> because the stmmac uses the HW cap register to auto-configure many
>>> parts of the MAC core, DMA and modules. This helped many users, AFAIK.
>>>
>>> For validation purpose, this is my experience, the stmmac helped
>>> a lot because people used the same code to validate different HW
>>> and it was easy to switch to a platform to another one in order to
>>> verify / check if the support was ok or if a regression was introduced.
>>> This is important for complex supports like PTP or EEE.
>>>
>>> Hoping this can help.
>>>
>>> Do not hesitate to contact me for further details
>>
>> Thanks for the highly detailed info.
>> My target application is to prototype the Ethernet QoS IP in a FPGA, with a PHY
>> attached and make hardware validation.
>>
>> In your opinion a refactored stmmac with the missing QoS features would be
>> suitable for it?
> 
> I think so; somebody also added code for FPGA.
> 
> In any case, step-by-step we can explore and understand
> how to proceed. I wonder if you could start looking at the internal
> of the stmmac. Then welcome doubts and open question...

Yes I am going to do that thanks... taking my first steps in this IP :)

> 
>>
>> Thanks.
> 
> welcome
> 
> peppe
> 
>>
>>>
>>> peppe
>>
>>
>