Re: Synopsys Ethernet QoS Driver

Hello,

On 21-11-2016 05:29, Rayagond Kokatanur wrote:

On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent [off-list ref] wrote:

quoted

On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:

quoted

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?

quoted

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