Message-ID: <540DC00F.1080103@ti.com>
Date:	Mon, 8 Sep 2014 10:41:19 -0400
From:	Santosh Shilimkar <santosh.shilimkar@...com>
To:	David Miller <davem@...emloft.net>
CC:	<netdev@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <robh+dt@...nel.org>,
	<grant.likely@...aro.org>, <devicetree@...r.kernel.org>,
	<sandeep_n@...com>
Subject: Re: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support

Hi Dave,

On 8/22/14 3:45 PM, Santosh Shilimkar wrote:
> Hi David,
>
> On Thursday 21 August 2014 07:36 PM, David Miller wrote:
>> From: Santosh Shilimkar <santosh.shilimkar@...com>
>> Date: Fri, 15 Aug 2014 11:12:39 -0400
>>
>>> Update version after incorporating David Miller's comment from earlier
>>> posting [1]. I would like to get these merged for upcoming 3.18 merge
>>> window if there are no concerns on this version.
>>>
>>> The network coprocessor (NetCP) is a hardware accelerator that processes
>>> Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
>>> switch sub-module to send and receive packets. NetCP also includes a packet
>>> accelerator (PA) module to perform packet classification operations such as
>>> header matching, and packet modification operations such as checksum
>>> generation. NetCP can also optionally include a Security Accelerator(SA)
>>> capable of performing IPSec operations on ingress/egress packets.
>>>
>>> Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
>>> includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
>>> 1Gb/s rates per Ethernet port.
>>>
>>> NetCP driver has a plug-in module architecture where each of the NetCP
>>> sub-modules exist as a loadable kernel module which plug in to the netcp
>>> core. These sub-modules are represented as "netcp-devices" in the dts
>>> bindings. It is mandatory to have the ethernet switch sub-module for
>>> the ethernet interface to be operational. Any other sub-module like the
>>> PA is optional.
>>>
>>> Both GBE and XGBE network processors supported using common driver. It
>>> is also designed to handle future variants of NetCP.
>>
>> I don't want to see an offload driver that doesn't plug into the existing
>> generic frameworks for configuration et al.
>>
>> If no existing facility exists to support what you need, you must work
>> with the upstream maintainers to design and create one.
>>
>> It is absolutely no reasonable for every "switch on a chip" driver to
>> export it's own configuration knob, we need a standard interface all
>> such drivers will plug into and provide.
>>
> The NetCP plugin module infrastructure use all the standard kernel
> infrastructure and its very tiny. To best represent the Network processor
> and its sub module hardware which have inter dependency and ordering
> needs, we needed such infrastructure. This lets us handle all the
> hardware needs without any code duplication per module.
>
> To elaborate more, there are 4 variants of network switch modules and
> then few accelerator modules like Packet accelerator, QOS and Security
> accelerator. There can be multiple instances of switches on same SOC.
> Example 1 Gbe and 10 Gbe switches. Then additional accelerator modules
> are inter connected with switch, streaming fabric and packet DMA.
> Packet routing changes based on the various offload modules presence and hence
> needs hooks for tx/rx to be called in particular order with special
> handling. This scheme is very hardware specific and doesn't have ways
> to isolate the modules from each other.
>
> On the other hand, we definitely wanted to have minimal code
> instead of duplicating ndo operations and core packet processing logic
> in multiple drivers or layers. The module approach helps
> to isolate the code based on the customer choice who can choose
> say not to build 10 Gbe hardware or say don't need QOS or Security
> accelerators. That way we keep the packet processing hot path as
> what we need without any overhead.
>
> As you can see, the tiny module handling was added more to represent
> the hardware, keep the modularity and avoid code duplication. The
> infrastructure is very minimal and NETCP specific. With this small
> infrastructure we are able to re-use code for NetCP1.0, NetCP1.5,
> 10 GBe and upcoming NetCP variants from just *one* driver.
>
> Hope this gives you a better idea and rationale behind the design.
>
Did you happen to see the reply ?
I am hoping to get this driver in for upcoming merge window.

Regards,
Santosh

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists