Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754647AbcKUQML (ORCPT ); Mon, 21 Nov 2016 11:12:11 -0500 Received: from smtprelay.synopsys.com ([198.182.60.111]:56467 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752505AbcKUQMJ (ORCPT ); Mon, 21 Nov 2016 11:12:09 -0500 Subject: Re: Synopsys Ethernet QoS Driver To: Lars Persson , Joao Pinto References: <1dbb6047-2bbb-4d56-2a62-ab65a0254844@synopsys.com> <20161119135654.GA14079@lnxartpec.se.axis.com> <1248f4ce-4859-10e6-fef9-342ea543f8d4@synopsys.com> <87c8a24b-0812-7850-cb3f-7be691bab432@st.com> CC: Giuseppe CAVALLARO , Rayagond Kokatanur , Rabin Vincent , mued dib , David Miller , Jeff Kirsher , "jiri@mellanox.com" , "saeedm@mellanox.com" , "idosch@mellanox.com" , netdev , "linux-kernel@vger.kernel.org" , "CARLOS.PALMINHA@synopsys.com" , =?UTF-8?Q?Andreas_Irest=c3=a5l?= , "alexandre.torgue@st.com" , "linux-arm-kernel@lists.infradead.org" From: Joao Pinto Message-ID: <7c7798b5-8cd4-ba99-f526-22d3e06e05db@synopsys.com> Date: Mon, 21 Nov 2016 16:11:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.107.25.66] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3729 Lines: 118 On 21-11-2016 15:43, Lars Persson wrote: > > >> 21 nov. 2016 kl. 16:06 skrev Joao Pinto : >> >>> On 21-11-2016 14:25, Giuseppe CAVALLARO wrote: >>>> On 11/21/2016 2:28 PM, Lars Persson wrote: >>>> >>>> >>>>> 21 nov. 2016 kl. 13:53 skrev Giuseppe CAVALLARO : >>>>> >>>>> Hello Joao >>>>> >>>>>> On 11/21/2016 1:32 PM, Joao Pinto wrote: >>>>>> Hello, >>>>>> >>>>>>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote: >>>>>>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent wrote: >>>>>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote: >>>>>>>>> For now we are interesting in improving the synopsys QoS driver under >>>>>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a >>>>>>>>> single file >>>>>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and snip (...) >>>>> The stmmac drivers run since many years on several platforms >>>>> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of >>>>> configurations starting from 3.1x to 3.7x databooks. >>>>> >>>>> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a >>>>> are fully working. >>>>> >>>>> Also the stmmac has platform, device-tree and pcie supports and >>>>> a lot of maintained glue-logic files. >>>>> >>>>> It is fully documented inside the kernel tree. >>>>> >>>>> I am happy to have new enhancements from other developers. >>>>> So, on my side, if you want to spend your time on improving it on your >>>>> platforms please feel free to do it! >>>>> >>>>> Concerning the stmicro/stmmac naming, these come from a really old >>>>> story and have no issue to adopt new folder/file names. >>>>> >>>>> I am also open to merge fixes and changes from ethernet/synopsis. >>>>> I want to point you on some benchmarks made by Alex some months ago >>>>> (IIRC) that showed an stmmac winner (due to the several optimizations >>>>> analyzed and reviewed in this mailing list). >>>>> >>>>> Peppe >>>>> >>>> >>>> Hello Joao and others, >>>> >> >> Hi Lars, >> >>>> As the maintainer of dwc_eth_qos.c I prefer also that we put efforts on the >>>> most mature driver, the stmmac. >>>> >>>> I hope that the code can migrate into an ethernet/synopsys folder to keep the >>>> convention of naming the folder after the vendor. This makes it easy for >>>> others to find the driver. >>>> >>>> The dwc_eth_qos.c will eventually be removed and its DT binding interface can >>>> then be implemented in the stmmac driver. >> >> So your ideia is to pick the ethernet/stmmac and rename it to ethernet/synopsys >> and try to improve the structure and add the missing QoS features to it? > > Indeed this is what I prefer. Ok, it makes sense. Just for curiosity the target setup is the following: https://www.youtube.com/watch?v=8V-LB5y2Cos but instead of using internal drivers, we desire to use mainline drivers only. Thanks! > >> >>> >>> Thanks Lars, I will be happy to support all you on this transition >>> and I agree on renaming all. >>> >>> peppe >>> >>> >>>> - Lars >>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> (See http://lists.openwall.net/netdev/2016/02/29/127) >>>>>>>> >>>>>>>> The former only supports 4.x of the hardware. >>>>>>>> >>>>>>>> The later supports 4.x and 3.x and already has a platform glue driver >>>>>>>> with support for several platforms, a PCI glue driver, and a core driver >>>>>>>> with several features not present in the former (for example: TX/RX >>>>>>>> interrupt coalescing, EEE, PTP). >>>>>>>> >>>>>>>> Have you evaluated both drivers? Why have you decided to work on the >>>>>>>> former rather than the latter? >>>>>>> >>>>>>> >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>