Re: Synopsys Ethernet QoS Driver

[Andy Shevchenko]

On Mon, Nov 21, 2016 at 2:52 PM, Giuseppe CAVALLARO
 wrote:

First of all, +1 to (re-)use stmmac.

> 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.

As Intel employee who did some clean ups to that, acknowledge above.

> Concerning the stmicro/stmmac naming, these come from a really old
> story and have no issue to adopt new folder/file names.

I don't think it would be best idea for platform driver (though we can
keep driver's name in the structure in async with file name).

-- 
With Best Regards,
Andy Shevchenko

Re: Synopsys Ethernet QoS Driver

[Pavel Machek]

Hi!

> > Thanks!
> 
> Regarding this subject, I am thinking of making the following adaption:
> 
> a) delete ethernet/synopsys
> b) rename ethernet/stmicro/stmmac to ethernet/synopsys
> 
> and send you a patch for you to evaluate. Both agree with the approach?
> To have a new work base would be important, because I will add to the "new"
> structure some missing QoS features like Multichannel support, CBS
> and later TSN.

Rename should be the easy part. Please do that last.

Thanks,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Synopsys Ethernet QoS Driver

[Giuseppe CAVALLARO]

On 11/23/2016 12:43 PM, Joao Pinto wrote:

> Rabin Vincent can review and test that the port works properly on our 
Artpec-chips that use dwc_eth_qos.c today.
>
> The main porting step is to implement the device tree binding in 
bindings/net/snps,dwc-qos-ethernet.txt. Also our chip has a strict requirement 
that the phy is enabled when the SWR reset bit is set (it needs a tx clock to 
complete the reset).
>
> - Lars

Ok, I will do the task.

@Peppe: Agree with the plan?


Agree

peppe

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

On 23-11-2016 11:41, Lars Persson wrote:
> 
>> 23 nov. 2016 kl. 12:11 skrev Joao Pinto :
>>
>> Hi Peppe and Lars,
>>
>>> On 23-11-2016 10:59, Giuseppe CAVALLARO wrote:
>>> Hello Joao, Lars.
>>>
 On 11/22/2016 3:16 PM, Joao Pinto wrote:
>> 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!
 Regarding this subject, I am thinking of making the following adaption:

 a) delete ethernet/synopsys
 b) rename ethernet/stmicro/stmmac to ethernet/synopsys

 and send you a patch for you to evaluate. Both agree with the approach?
 To have a new work base would be important, because I will add to the "new"
 structure some missing QoS features like Multichannel support, CBS and 
 later TSN.
>>>
>>> IMO, we have to agree on a common strategy making the change for
>>> net-next; I imaged the following steps:
>>
>> Yes it makes totally sense.
>>
>>>
>>> - to port missing feature or fixes from ethernet/synopsys
>>>  inside the stmmac taking care about the documentation too.
>>
>> @Lars: You are familiar with the synopsys qos driver. Could you please do 
>> this
>> porting. You can also make an analysis of what to port and I can do the 
>> porting
>> for you if you don't have the availability for it.
> 
> As my main duty is changing diapers until March next year, please go ahead 
> with this step if you can spend time on it before I am back in office.

Congratulations :)!

> 
> Rabin Vincent can review and test that the port works properly on our 
> Artpec-chips that use dwc_eth_qos.c today.
> 
> The main porting step is to implement the device tree binding in 
> bindings/net/snps,dwc-qos-ethernet.txt. Also our chip has a strict 
> requirement that the phy is enabled when the SWR reset bit is set (it needs a 
> tx clock to complete the reset).
> 
> - Lars

Ok, I will do the task.

@Peppe: Agree with the plan?

> 
>>
>>> - remove ethernet/synopsys
>>> - rename ethernet/stmicro/stmmac to ethernet/synopsys
>>
>> I volunteer to do this task.
>>
>>>
>>>  These latest two have some relevant impacts.
>>>
>>>  This change should be propagated to all the platforms that are using:
>>>  CONFIG_SYNOPSYS_DWC_ETH_QOS and CONFIG_STMMAC_ETH
>>>  plus device-tree compatibility.
>>
>> I volunteer to do this task also.
>>
>>>
>>> - enhance the stmmac with new features and new glue (part of these
>>>  can be anticipated for sure).
>>
>> I have to implement 3 new features for now, but I will take some time for 
>> it, so
>> I would suggest to make the previous task and incrementally add features.
>>
>>>
>>> what do you think? does it make sense? If yes, we can also
>>> understand how/who starts.
>>>
>>> Regards,
>>> Peppe
>>
>> Thanks and regards.
>>
>> Joao
>>
>>>
 Thanks.
>>>
>>

Re: Synopsys Ethernet QoS Driver

[Lars Persson]

> 23 nov. 2016 kl. 12:11 skrev Joao Pinto :
> 
> Hi Peppe and Lars,
> 
>> On 23-11-2016 10:59, Giuseppe CAVALLARO wrote:
>> Hello Joao, Lars.
>> 
>>> On 11/22/2016 3:16 PM, Joao Pinto wrote:
> 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!
>>> Regarding this subject, I am thinking of making the following adaption:
>>> 
>>> a) delete ethernet/synopsys
>>> b) rename ethernet/stmicro/stmmac to ethernet/synopsys
>>> 
>>> and send you a patch for you to evaluate. Both agree with the approach?
>>> To have a new work base would be important, because I will add to the "new"
>>> structure some missing QoS features like Multichannel support, CBS and 
>>> later TSN.
>> 
>> IMO, we have to agree on a common strategy making the change for
>> net-next; I imaged the following steps:
> 
> Yes it makes totally sense.
> 
>> 
>> - to port missing feature or fixes from ethernet/synopsys
>>  inside the stmmac taking care about the documentation too.
> 
> @Lars: You are familiar with the synopsys qos driver. Could you please do this
> porting. You can also make an analysis of what to port and I can do the 
> porting
> for you if you don't have the availability for it.

As my main duty is changing diapers until March next year, please go ahead with 
this step if you can spend time on it before I am back in office.

Rabin Vincent can review and test that the port works properly on our 
Artpec-chips that use dwc_eth_qos.c today.

The main porting step is to implement the device tree binding in 
bindings/net/snps,dwc-qos-ethernet.txt. Also our chip has a strict requirement 
that the phy is enabled when the SWR reset bit is set (it needs a tx clock to 
complete the reset).

- Lars

> 
>> - remove ethernet/synopsys
>> - rename ethernet/stmicro/stmmac to ethernet/synopsys
> 
> I volunteer to do this task.
> 
>> 
>>  These latest two have some relevant impacts.
>> 
>>  This change should be propagated to all the platforms that are using:
>>  CONFIG_SYNOPSYS_DWC_ETH_QOS and CONFIG_STMMAC_ETH
>>  plus device-tree compatibility.
> 
> I volunteer to do this task also.
> 
>> 
>> - enhance the stmmac with new features and new glue (part of these
>>  can be anticipated for sure).
> 
> I have to implement 3 new features for now, but I will take some time for it, 
> so
> I would suggest to make the previous task and incrementally add features.
> 
>> 
>> what do you think? does it make sense? If yes, we can also
>> understand how/who starts.
>> 
>> Regards,
>> Peppe
> 
> Thanks and regards.
> 
> Joao
> 
>> 
>>> Thanks.
>> 
> 

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

Hi Peppe and Lars,

On 23-11-2016 10:59, Giuseppe CAVALLARO wrote:
> Hello Joao, Lars.
> 
> On 11/22/2016 3:16 PM, Joao Pinto wrote:
>>> 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!
>> Regarding this subject, I am thinking of making the following adaption:
>>
>> a) delete ethernet/synopsys
>> b) rename ethernet/stmicro/stmmac to ethernet/synopsys
>>
>> and send you a patch for you to evaluate. Both agree with the approach?
>> To have a new work base would be important, because I will add to the "new"
>> structure some missing QoS features like Multichannel support, CBS and later 
>> TSN.
> 
> IMO, we have to agree on a common strategy making the change for
> net-next; I imaged the following steps:

Yes it makes totally sense.

> 
> - to port missing feature or fixes from ethernet/synopsys
>   inside the stmmac taking care about the documentation too.

@Lars: You are familiar with the synopsys qos driver. Could you please do this
porting. You can also make an analysis of what to port and I can do the porting
for you if you don't have the availability for it.

> - remove ethernet/synopsys
> - rename ethernet/stmicro/stmmac to ethernet/synopsys

I volunteer to do this task.

> 
>   These latest two have some relevant impacts.
> 
>   This change should be propagated to all the platforms that are using:
>   CONFIG_SYNOPSYS_DWC_ETH_QOS and CONFIG_STMMAC_ETH
>   plus device-tree compatibility.

I volunteer to do this task also.

> 
> - enhance the stmmac with new features and new glue (part of these
>   can be anticipated for sure).

I have to implement 3 new features for now, but I will take some time for it, so
I would suggest to make the previous task and incrementally add features.

> 
> what do you think? does it make sense? If yes, we can also
> understand how/who starts.
> 
> Regards,
> Peppe

Thanks and regards.

Joao

> 
>> Thanks.
> 

Re: Synopsys Ethernet QoS Driver

[Giuseppe CAVALLARO]

Hello Joao, Lars.

On 11/22/2016 3:16 PM, Joao Pinto wrote:

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!

Regarding this subject, I am thinking of making the following adaption:

a) delete ethernet/synopsys
b) rename ethernet/stmicro/stmmac to ethernet/synopsys

and send you a patch for you to evaluate. Both agree with the approach?
To have a new work base would be important, because I will add to the "new"
structure some missing QoS features like Multichannel support, CBS and later 
TSN.


IMO, we have to agree on a common strategy making the change for
net-next; I imaged the following steps:

- to port missing feature or fixes from ethernet/synopsys
  inside the stmmac taking care about the documentation too.
- remove ethernet/synopsys
- rename ethernet/stmicro/stmmac to ethernet/synopsys

  These latest two have some relevant impacts.

  This change should be propagated to all the platforms that are using:
  CONFIG_SYNOPSYS_DWC_ETH_QOS and CONFIG_STMMAC_ETH
  plus device-tree compatibility.

- enhance the stmmac with new features and new glue (part of these
  can be anticipated for sure).

what do you think? does it make sense? If yes, we can also
understand how/who starts.

Regards,
Peppe


Thanks.

Re: Synopsys Ethernet QoS Driver

[Giuseppe CAVALLARO]

Hello Ozgur

On 11/22/2016 9:38 AM, Ozgur Karatas wrote:

Hello all,

I think, ethtool and mdio don't work because the tool's not support to "QoS", 
right?

Maybe, need a new API. I'm looking for dwceqos code but "tc" tools is very idea.

I hope to be me always helpful.


tools work but indeed should be extended to support more for QoS.
This is another task we have to keep in mind, well spot.

Peppe



Regards,

Ozgur

21.11.2016, 16:38, "Giuseppe CAVALLARO" :

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

peppe

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

Hi Lars and Peppe,

On 21-11-2016 16:11, Joao Pinto wrote:
> 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 +, 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 (...)

>>
>> 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!

Regarding this subject, I am thinking of making the following adaption:

a) delete ethernet/synopsys
b) rename ethernet/stmicro/stmmac to ethernet/synopsys

and send you a patch for you to evaluate. Both agree with the approach?
To have a new work base would be important, because I will add to the "new"
structure some missing QoS features like Multichannel support, CBS and later 
TSN.

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.
>>>
>>>
>>>
>>>
>>
>

>>>
> 

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

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 +, 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.
>>
>>
>>
>>
>

>>>
>>

Re: Synopsys Ethernet QoS Driver

[Lars Persson]

> 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 +, 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
 platform
 related stuff.
 
 Our strategy would be:
 
 a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
 b) Implement a pci glue driver (dwc_eth_qos_pci.c)
 c) Implement a "core driver" (dwc_eth_qos.c) that would only have
 Ethernet QoS
 related stuff to be reused by the platform / pci drivers
 d) Add a set of features to the "core driver" that we have available
 internally
>>> 
>>> Note that there are actually two drivers in mainline for this hardware:
>>> 
>>> drivers/net/ethernet/synopsis/
>>> drivers/net/ethernet/stmicro/stmmac/
>> 
>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>> please refer this driver once before you start.
>> 
>> You can start adding missing feature of 4.x in stmmac driver.
> 
> Thanks you all for all the info.
> Well, I think we are in a good position to organize the ethernet drivers
> concerning Synopsys IPs.
> 
> First of all, in my opinion, it does not make sense to have a 
> ethernet/synopsis
> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have 
> another
> vendor using the same IP it should be able to reuse the commonn 
> operations. But
> I would put that discussion for later :)
> 
> For now I suggest that for we create ethernet/qos and create there a 
> folder
> called dwc (designware controller) where all the synopsys qos IP specific 
> code
> in order to be reused for example by ethernet/stmicro/stmmac/. We just 
> have to
> figure out a clean interface for "client drivers" like stmmac to interact 
> with
> the new qos driver.
> 
> What do you think about this approach?
 
 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.

> 
>> 
>> 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 

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

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
>>
>>
> 

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

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?

Thanks.

> 
> peppe

Re: Synopsys Ethernet QoS Driver

[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 +, 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
>>> platform
>>> related stuff.
>>>
>>> Our strategy would be:
>>>
>>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have
>>> Ethernet QoS
>>> related stuff to be reused by the platform / pci drivers
>>> d) Add a set of features to the "core driver" that we have available
>>> internally
>>
>> Note that there are actually two drivers in mainline for this hardware:
>>
>> drivers/net/ethernet/synopsis/
>> drivers/net/ethernet/stmicro/stmmac/
>
> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
> please refer this driver once before you start.
>
> You can start adding missing feature of 4.x in stmmac driver.

 Thanks you all for all the info.
 Well, I think we are in a good position to organize the ethernet drivers
 concerning Synopsys IPs.

 First of all, in my opinion, it does not make sense to have a 
 ethernet/synopsis
 (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have 
 another
 vendor using the same IP it should be able to reuse the commonn 
 operations. But
 I would put that discussion for later :)

 For now I suggest that for we create ethernet/qos and create there a folder
 called dwc (designware controller) where all the synopsys qos IP specific 
 code
 in order to be reused for example by ethernet/stmicro/stmmac/. We just 
 have to
 figure out a clean interface for "client drivers" like stmmac to interact 
 with
 the new qos driver.

 What do you think about this approach?
>>>
>>> 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?


> 
> 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.




>>>
>>
> 

Re: Synopsys Ethernet QoS Driver

[Giuseppe CAVALLARO]

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...



Thanks.


welcome

peppe





peppe

Re: Synopsys Ethernet QoS Driver

[Giuseppe CAVALLARO]

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

peppe

Re: Synopsys Ethernet QoS Driver

[Giuseppe CAVALLARO]

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 +, 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 platform
related stuff.

Our strategy would be:

a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
b) Implement a pci glue driver (dwc_eth_qos_pci.c)
c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
related stuff to be reused by the platform / pci drivers
d) Add a set of features to the "core driver" that we have available internally


Note that there are actually two drivers in mainline for this hardware:

drivers/net/ethernet/synopsis/
drivers/net/ethernet/stmicro/stmmac/


Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
both 3.x and 4.x. It has glue layer for pci, platform, core etc,
please refer this driver once before you start.

You can start adding missing feature of 4.x in stmmac driver.


Thanks you all for all the info.
Well, I think we are in a good position to organize the ethernet drivers
concerning Synopsys IPs.

First of all, in my opinion, it does not make sense to have a ethernet/synopsis
(typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
vendor using the same IP it should be able to reuse the commonn operations. But
I would put that discussion for later :)

For now I suggest that for we create ethernet/qos and create there a folder
called dwc (designware controller) where all the synopsys qos IP specific code
in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
figure out a clean interface for "client drivers" like stmmac to interact with
the new qos driver.

What do you think about this approach?


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,

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.


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.

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

Hello Peppe,

On 21-11-2016 12:52, Giuseppe CAVALLARO wrote:
> 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 +, 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 
> platform
> related stuff.
>
> Our strategy would be:
>
> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
> c) Implement a "core driver" (dwc_eth_qos.c) that would only have 
> Ethernet QoS
> related stuff to be reused by the platform / pci drivers
> d) Add a set of features to the "core driver" that we have available
> internally

 Note that there are actually two drivers in mainline for this hardware:

  drivers/net/ethernet/synopsis/
  drivers/net/ethernet/stmicro/stmmac/
>>>
>>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>>> please refer this driver once before you start.
>>>
>>> You can start adding missing feature of 4.x in stmmac driver.
>>
>> Thanks you all for all the info.
>> Well, I think we are in a good position to organize the ethernet drivers
>> concerning Synopsys IPs.
>>
>> First of all, in my opinion, it does not make sense to have a 
>> ethernet/synopsis
>> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
>> vendor using the same IP it should be able to reuse the commonn operations. 
>> But
>> I would put that discussion for later :)
>>
>> For now I suggest that for we create ethernet/qos and create there a folder
>> called dwc (designware controller) where all the synopsys qos IP specific 
>> code
>> in order to be reused for example by ethernet/stmicro/stmmac/. We just have 
>> to
>> figure out a clean interface for "client drivers" like stmmac to interact 
>> with
>> the new qos driver.
>>
>> What do you think about this approach?
> 
> 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.

Great!

> 
> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
> are fully working.

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.*?

> 
> 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.

Thanks for the information, I am going to check it out.

> 
> 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.

Thank you for your availability!

> 
> 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
> 

Thanks
Joao

Re: Synopsys Ethernet QoS Driver

[Lars Persson]

> 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 +, 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 
> platform
> related stuff.
> 
> Our strategy would be:
> 
> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
> c) Implement a "core driver" (dwc_eth_qos.c) that would only have 
> Ethernet QoS
> related stuff to be reused by the platform / pci drivers
> d) Add a set of features to the "core driver" that we have available 
> internally
 
 Note that there are actually two drivers in mainline for this hardware:
 
 drivers/net/ethernet/synopsis/
 drivers/net/ethernet/stmicro/stmmac/
>>> 
>>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>>> please refer this driver once before you start.
>>> 
>>> You can start adding missing feature of 4.x in stmmac driver.
>> 
>> Thanks you all for all the info.
>> Well, I think we are in a good position to organize the ethernet drivers
>> concerning Synopsys IPs.
>> 
>> First of all, in my opinion, it does not make sense to have a 
>> ethernet/synopsis
>> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
>> vendor using the same IP it should be able to reuse the commonn operations. 
>> But
>> I would put that discussion for later :)
>> 
>> For now I suggest that for we create ethernet/qos and create there a folder
>> called dwc (designware controller) where all the synopsys qos IP specific 
>> code
>> in order to be reused for example by ethernet/stmicro/stmmac/. We just have 
>> to
>> figure out a clean interface for "client drivers" like stmmac to interact 
>> with
>> the new qos driver.
>> 
>> What do you think about this approach?
> 
> 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,

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.

- 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.
>> 
>> 
>> 
>> 
> 

Re: Synopsys Ethernet QoS Driver

[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 +, 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 platform
related stuff.

Our strategy would be:

a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
b) Implement a pci glue driver (dwc_eth_qos_pci.c)
c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
related stuff to be reused by the platform / pci drivers
d) Add a set of features to the "core driver" that we have available internally


Note that there are actually two drivers in mainline for this hardware:

 drivers/net/ethernet/synopsis/
 drivers/net/ethernet/stmicro/stmmac/


Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
both 3.x and 4.x. It has glue layer for pci, platform, core etc,
please refer this driver once before you start.

You can start adding missing feature of 4.x in stmmac driver.


Thanks you all for all the info.
Well, I think we are in a good position to organize the ethernet drivers
concerning Synopsys IPs.

First of all, in my opinion, it does not make sense to have a ethernet/synopsis
(typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
vendor using the same IP it should be able to reuse the commonn operations. But
I would put that discussion for later :)

For now I suggest that for we create ethernet/qos and create there a folder
called dwc (designware controller) where all the synopsys qos IP specific code
in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
figure out a clean interface for "client drivers" like stmmac to interact with
the new qos driver.

What do you think about this approach?


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








(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.

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

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 +, 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 
>>> platform
>>> related stuff.
>>>
>>> Our strategy would be:
>>>
>>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet 
>>> QoS
>>> related stuff to be reused by the platform / pci drivers
>>> d) Add a set of features to the "core driver" that we have available 
>>> internally
>>
>> Note that there are actually two drivers in mainline for this hardware:
>>
>>  drivers/net/ethernet/synopsis/
>>  drivers/net/ethernet/stmicro/stmmac/
> 
> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
> please refer this driver once before you start.
> 
> You can start adding missing feature of 4.x in stmmac driver.

Thanks you all for all the info.
Well, I think we are in a good position to organize the ethernet drivers
concerning Synopsys IPs.

First of all, in my opinion, it does not make sense to have a ethernet/synopsis
(typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
vendor using the same IP it should be able to reuse the commonn operations. But
I would put that discussion for later :)

For now I suggest that for we create ethernet/qos and create there a folder
called dwc (designware controller) where all the synopsys qos IP specific code
in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
figure out a clean interface for "client drivers" like stmmac to interact with
the new qos driver.

What do you think about this approach?


> 
>>
>> (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.

Re: Synopsys Ethernet QoS Driver

[Rayagond Kokatanur]

On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent  wrote:
> On Fri, Nov 18, 2016 at 02:20:27PM +, 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 
>> platform
>> related stuff.
>>
>> Our strategy would be:
>>
>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet 
>> QoS
>> related stuff to be reused by the platform / pci drivers
>> d) Add a set of features to the "core driver" that we have available 
>> internally
>
> Note that there are actually two drivers in mainline for this hardware:
>
>  drivers/net/ethernet/synopsis/
>  drivers/net/ethernet/stmicro/stmmac/

Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
both 3.x and 4.x. It has glue layer for pci, platform, core etc,
please refer this driver once before you start.

You can start adding missing feature of 4.x in stmmac driver.

>
> (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?



-- 
wwr
Rayagond

Re: Synopsys Ethernet QoS Driver

[Rabin Vincent]

On Fri, Nov 18, 2016 at 02:20:27PM +, 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 platform
> related stuff.
> 
> Our strategy would be:
> 
> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
> c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
> related stuff to be reused by the platform / pci drivers
> d) Add a set of features to the "core driver" that we have available 
> internally

Note that there are actually two drivers in mainline for this hardware:

 drivers/net/ethernet/synopsis/
 drivers/net/ethernet/stmicro/stmmac/

(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?

Re: Synopsys Ethernet QoS Driver

[Eric Dumazet]

On Fri, 2016-11-18 at 16:40 +, Joao Pinto wrote:

> help a lot, thank you!
> lets start working then :)

Please read this very useful document first, so that you can avoid
common mistakes ;)


https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt

Thanks

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

On 18-11-2016 16:35, Florian Fainelli wrote:
> 
> 
> On 11/18/2016 08:31 AM, Joao Pinto wrote:
>>  Hi Florian,
>>
>> On 18-11-2016 14:53, Florian Fainelli wrote:
>>> On November 18, 2016 4:28:30 AM PST, Joao Pinto  
>>> wrote:


snip (...)

 I would also gladly be available to be its maintainer if you agree with
 it.
>>>
>>> Since you have both the hardware and a clear todo list for this driver, 
>>> start submitting patches, get them included in David's tree and over time 
>>> chances are that you will become the maintainer, either explicitly by 
>>> adding an entry in the MAINTAINERS file or just by consistently 
>>> contributing to this area.
>>
>> Thanks for the feedback.
>>
>> So I found 2 suitable git trees:
>>  a) kernel/git/davem/net.git
>>  b) kernel/git/davem/net-next.git
>>
>> We should submit to net.git correct? The net-next.git is a tree with selected
>> patches for upstream only?
> 
> net-next.git is the git tree where new features/enhancements can be
> submitted, while net.git is for bug fixes. Unless you absolutely need
> to, it is common practice to avoid having changes in net-next.git depend
> on net.git and vice versa.
> 
> Hope this helps.
> 

help a lot, thank you!
lets start working then :)

Thanks,
Joao

Re: Synopsys Ethernet QoS Driver

[Florian Fainelli]

On 11/18/2016 08:31 AM, Joao Pinto wrote:
>  Hi Florian,
> 
> On 18-11-2016 14:53, Florian Fainelli wrote:
>> On November 18, 2016 4:28:30 AM PST, Joao Pinto  
>> wrote:
>>>
>>> Dear all,
>>>
>>> My name is Joao Pinto and I work at Synopsys.
>>> I am a kernel developer with special focus in mainline collaboration,
>>> both Linux
>>> and Buildroot. I was recently named one of the maintainers of the PCIe
>>> Designware core driver and I was the author of the Designware UFS
>>> driver stack.
>>>
>>> I am sending you this e-mail because you were the suggested contacts
>> >from the
>>> get_maintainers script concerning Ethernet drivers :).
>>>
>>> Currently I have the task to work on the mainline Ethernet QoS driver
>>> in which
>>> you are the author. The work would consist of the following:
>>>
>>> a) Separate the current driver in a Core driver (common ops) + platform
>>> glue
>>> driver + pci glue driver
>>> b) Add features that are currently only available internally
>>> c) Add specific phy support using the PHY framework
>>>
>>> I would also gladly be available to be its maintainer if you agree with
>>> it.
>>
>> Since you have both the hardware and a clear todo list for this driver, 
>> start submitting patches, get them included in David's tree and over time 
>> chances are that you will become the maintainer, either explicitly by adding 
>> an entry in the MAINTAINERS file or just by consistently contributing to 
>> this area.
> 
> Thanks for the feedback.
> 
> So I found 2 suitable git trees:
>  a) kernel/git/davem/net.git
>  b) kernel/git/davem/net-next.git
> 
> We should submit to net.git correct? The net-next.git is a tree with selected
> patches for upstream only?

net-next.git is the git tree where new features/enhancements can be
submitted, while net.git is for bug fixes. Unless you absolutely need
to, it is common practice to avoid having changes in net-next.git depend
on net.git and vice versa.

Hope this helps.
-- 
Florian

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

 Hi Florian,

On 18-11-2016 14:53, Florian Fainelli wrote:
> On November 18, 2016 4:28:30 AM PST, Joao Pinto  
> wrote:
>>
>> Dear all,
>>
>> My name is Joao Pinto and I work at Synopsys.
>> I am a kernel developer with special focus in mainline collaboration,
>> both Linux
>> and Buildroot. I was recently named one of the maintainers of the PCIe
>> Designware core driver and I was the author of the Designware UFS
>> driver stack.
>>
>> I am sending you this e-mail because you were the suggested contacts
>>from the
>> get_maintainers script concerning Ethernet drivers :).
>>
>> Currently I have the task to work on the mainline Ethernet QoS driver
>> in which
>> you are the author. The work would consist of the following:
>>
>> a) Separate the current driver in a Core driver (common ops) + platform
>> glue
>> driver + pci glue driver
>> b) Add features that are currently only available internally
>> c) Add specific phy support using the PHY framework
>>
>> I would also gladly be available to be its maintainer if you agree with
>> it.
> 
> Since you have both the hardware and a clear todo list for this driver, start 
> submitting patches, get them included in David's tree and over time chances 
> are that you will become the maintainer, either explicitly by adding an entry 
> in the MAINTAINERS file or just by consistently contributing to this area.

Thanks for the feedback.

So I found 2 suitable git trees:
 a) kernel/git/davem/net.git
 b) kernel/git/davem/net-next.git

We should submit to net.git correct? The net-next.git is a tree with selected
patches for upstream only?

> 

Re: Synopsys Ethernet QoS Driver

[Florian Fainelli]

On November 18, 2016 4:28:30 AM PST, Joao Pinto  wrote:
>
>Dear all,
>
>My name is Joao Pinto and I work at Synopsys.
>I am a kernel developer with special focus in mainline collaboration,
>both Linux
>and Buildroot. I was recently named one of the maintainers of the PCIe
>Designware core driver and I was the author of the Designware UFS
>driver stack.
>
>I am sending you this e-mail because you were the suggested contacts
>from the
>get_maintainers script concerning Ethernet drivers :).
>
>Currently I have the task to work on the mainline Ethernet QoS driver
>in which
>you are the author. The work would consist of the following:
>
>a) Separate the current driver in a Core driver (common ops) + platform
>glue
>driver + pci glue driver
>b) Add features that are currently only available internally
>c) Add specific phy support using the PHY framework
>
>I would also gladly be available to be its maintainer if you agree with
>it.

Since you have both the hardware and a clear todo list for this driver, start 
submitting patches, get them included in David's tree and over time chances are 
that you will become the maintainer, either explicitly by adding an entry in 
the MAINTAINERS file or just by consistently contributing to this area.

-- 
Florian

Re: Synopsys Ethernet QoS Driver

[Joao Pinto]

Hello Ozgur,

Thanks for your feedback.

On 18-11-2016 13:09, mued dib wrote:
> Dear Joao;
> 
> thanks for support and this project is good. I have some questions, Linux
> already support to QoS with "tc". right?
> 
> Can you send us a list of driver files you are interested?

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 platform
related stuff.

Our strategy would be:

a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
b) Implement a pci glue driver (dwc_eth_qos_pci.c)
c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
related stuff to be reused by the platform / pci drivers
d) Add a set of features to the "core driver" that we have available internally

Thanks,
Joao


> 
> Regards,
> 
> Ozgur Karatas
> 
> 2016-11-18 15:28 GMT+03:00 Joao Pinto :
> 
>>
>> Dear all,
>>
>> My name is Joao Pinto and I work at Synopsys.
>> I am a kernel developer with special focus in mainline collaboration, both
>> Linux
>> and Buildroot. I was recently named one of the maintainers of the PCIe
>> Designware core driver and I was the author of the Designware UFS driver
>> stack.
>>
>> I am sending you this e-mail because you were the suggested contacts from
>> the
>> get_maintainers script concerning Ethernet drivers :).
>>
>> Currently I have the task to work on the mainline Ethernet QoS driver in
>> which
>> you are the author. The work would consist of the following:
>>
>> a) Separate the current driver in a Core driver (common ops) + platform
>> glue
>> driver + pci glue driver
>> b) Add features that are currently only available internally
>> c) Add specific phy support using the PHY framework
>>
>> I would also gladly be available to be its maintainer if you agree with it.
>>
>> It would be great to have your collaboration in the project if you are
>> available
>> to review the work in progress.
>>
>> Thank you and I am looking forward for your feedback!
>>
>> Joao Pinto
>>
> 

Synopsys Ethernet QoS Driver

[Joao Pinto]

[The previous e-mail had an error, please consider this one. Thank you.]

Dear all,

My name is Joao Pinto and I work at Synopsys.
I am a kernel developer with special focus in mainline collaboration, both Linux
and Buildroot. I was recently named one of the maintainers of the PCIe
Designware core driver and I was the author of the Designware UFS driver stack.

I am sending you this e-mail because you were the suggested contacts from the
get_maintainers script concerning Ethernet drivers :).

Currently I have the task to work on the mainline Ethernet QoS driver. The work
would consist of the following:

a) Separate the current driver in a Core driver (common ops) + platform glue
driver + pci glue driver
b) Add features that are currently only available internally
c) Add specific phy support using the PHY framework

I would also gladly be available to be its maintainer if you agree with it.

It would be great to have your collaboration in the project if you are available
to review the work in progress.

Thank you and I am looking forward for your feedback!

Joao Pinto

Synopsys Ethernet QoS Driver

[Joao Pinto]

Dear all,

My name is Joao Pinto and I work at Synopsys.
I am a kernel developer with special focus in mainline collaboration, both Linux
and Buildroot. I was recently named one of the maintainers of the PCIe
Designware core driver and I was the author of the Designware UFS driver stack.

I am sending you this e-mail because you were the suggested contacts from the
get_maintainers script concerning Ethernet drivers :).

Currently I have the task to work on the mainline Ethernet QoS driver in which
you are the author. The work would consist of the following:

a) Separate the current driver in a Core driver (common ops) + platform glue
driver + pci glue driver
b) Add features that are currently only available internally
c) Add specific phy support using the PHY framework

I would also gladly be available to be its maintainer if you agree with it.

It would be great to have your collaboration in the project if you are available
to review the work in progress.

Thank you and I am looking forward for your feedback!

Joao Pinto