From mboxrd@z Thu Jan 1 00:00:00 1970 From: santosh.shilimkar@ti.com (Santosh Shilimkar) Date: Mon, 8 Sep 2014 10:41:19 -0400 Subject: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support In-Reply-To: <53F79DC5.8030003@ti.com> References: <1408115562-22487-1-git-send-email-santosh.shilimkar@ti.com> <20140821.163612.282672926741753926.davem@davemloft.net> <53F79DC5.8030003@ti.com> Message-ID: <540DC00F.1080103@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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 >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Shilimkar Subject: Re: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support Date: Mon, 8 Sep 2014 10:41:19 -0400 Message-ID: <540DC00F.1080103@ti.com> References: <1408115562-22487-1-git-send-email-santosh.shilimkar@ti.com> <20140821.163612.282672926741753926.davem@davemloft.net> <53F79DC5.8030003@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53F79DC5.8030003-l0cyMroinI0@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Miller Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, sandeep_n-l0cyMroinI0@public.gmane.org List-Id: devicetree@vger.kernel.org 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 >> 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 devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753790AbaIHOlv (ORCPT ); Mon, 8 Sep 2014 10:41:51 -0400 Received: from bear.ext.ti.com ([192.94.94.41]:52808 "EHLO bear.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbaIHOlt (ORCPT ); Mon, 8 Sep 2014 10:41:49 -0400 Message-ID: <540DC00F.1080103@ti.com> Date: Mon, 8 Sep 2014 10:41:19 -0400 From: Santosh Shilimkar User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: David Miller CC: , , , , , , Subject: Re: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support References: <1408115562-22487-1-git-send-email-santosh.shilimkar@ti.com> <20140821.163612.282672926741753926.davem@davemloft.net> <53F79DC5.8030003@ti.com> In-Reply-To: <53F79DC5.8030003@ti.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Santosh Shilimkar Subject: Re: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support Date: Mon, 8 Sep 2014 10:41:19 -0400 Message-ID: <540DC00F.1080103@ti.com> References: <1408115562-22487-1-git-send-email-santosh.shilimkar@ti.com> <20140821.163612.282672926741753926.davem@davemloft.net> <53F79DC5.8030003@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Cc: , , , , , , To: David Miller Return-path: In-Reply-To: <53F79DC5.8030003-l0cyMroinI0@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org 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 >> 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 devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html