[dpdk-dev] [RFC] Adding multiple device types to DPDK.
Hi all, (hoping format of the text is maintained) Bruce and myself are submitting this RFC in hopes of providing discussion points for the idea. Please do not get carried away with the code included, it was to help everyone understand the proposal/RFC. The RFC is to describe a proposed change we are looking to make to DPDK to add more device types. We would like to add in to DPDK the idea of a generic packet-device or ?pktdev?, which can be thought of as a thin layer for all device classes. For other device types such as potentially a ?cryptodev? or ?dpidev?. One of the main goals is to not effect performance and not require any current application to be modified. The pktdev layer is providing a light framework for developers to add a device to DPDK. Reason for Change - The reason why we are looking to introduce these concepts to DPDK are: * Expand the scope of DPDK so that it can provide APIs for more than just packet acquisition and transmission, but also provide APIs that can be used to work with other hardware and software offloads, such as cryptographic accelerators, or accelerated libraries for cryptographic functions. [The reason why both software and hardware are mentioned is so that the same APIs can be used whether or not a hardware accelerator is actually available]. * Provide a minimal common basis for device abstraction in DPDK, that can be used to unify the different types of packet I/O devices already existing in DPDK. To this end, the ethdev APIs are a good starting point, but the ethdev library contains too many functions which are NIC-specific to be a general-purpose set of APIs across all devices. Note: The idea was previously touched on here: http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 Description of Proposed Change -- The basic idea behind "pktdev" is to abstract out a few common routines and structures/members of structures by starting with ethdev structures as a starting point, cut it down to little more than a few members in each structure then possible add just rx_burst and tx_burst. Then use the structures as a starting point for writing a device type. Currently we have the rx_burst/tx_burst routines moved to the pktdev and it see like move a couple more common functions maybe resaonable. It could be the Rx/Tx routines in pktdev should be left as is, but in the code below is a possible reason to abstract a few routines into a common set of files. >From there, we have the ethdev type which adds in the existing functions specific to Ethernet devices, and also, for example, a cryptodev which may add in functions specific for cryptographic offload. As now, with the ethdev, the specific drivers provide concrete implementations of the functionality exposed by the interface. This hierarchy is shown in the diagram below, using the existing ethdev and ixgbe drivers as a reference, alongside a hypothetical cryptodev class and driver implementation (catchingly called) "X": ,-. | struct rte_pktdev | +-+ | rte_pkt_rx_burst() | .---| rte_pkt_tx_burst() |---. | `-' | | | | | ,---.,--. |struct rte_ethdev || struct rte_cryptodev| +---++--+ | rte_eth_dev_configure() || rte_crypto_init_sym_session()| | rte_eth_allmulticast_enable() || rte_crypto_del_sym_session() | | rte_eth_filter_ctrl() || | `---'`---.--' | | | | ,-'-.,---'--. |struct rte_pmd_ixgbe || struct rte_pmd_X| +---++--+ | .configure -> ixgbe_configure || .init_session -> X_init_ses()| | .tx_burst -> ixgbe_xmit_pkts || .tx_burst -> X_handle_pkts() | `---'`--' We are not attempting to create a real class model here only looking at creating a very basic common set of APIs and structures for other device types. In terms of code changes for this, we obviously need to add in new interface libraries for pktdev and cryptodev. The pktdev library can define a skeleton structure for the first few elements of the nested structures to ensure consistency. Each of the defines below illustrate the common members in device structures, which gives some basic structure the device framework. Ea
[dpdk-dev] [RFC] Adding multiple device types to DPDK.
Hi All, just to make a comment on my own email :-) On 4/1/15, 7:44 AM, "Wiles, Keith" wrote: >Hi all, (hoping format of the text is maintained) > >Bruce and myself are submitting this RFC in hopes of providing discussion >points for the idea. Please do not get carried away with the code >included, it was to help everyone understand the proposal/RFC. > >The RFC is to describe a proposed change we are looking to make to DPDK to >add more device types. We would like to add in to DPDK the idea of a >generic packet-device or ?pktdev?, which can be thought of as a thin layer >for all device classes. For other device types such as potentially a >?cryptodev? or ?dpidev?. One of the main goals is to not effect >performance and not require any current application to be modified. The >pktdev layer is providing a light framework for developers to add a device >to DPDK. > >Reason for Change >- > >The reason why we are looking to introduce these concepts to DPDK are: > >* Expand the scope of DPDK so that it can provide APIs for more than just >packet acquisition and transmission, but also provide APIs that can be >used to work with other hardware and software offloads, such as >cryptographic accelerators, or accelerated libraries for cryptographic >functions. [The reason why both software and hardware are mentioned is so >that the same APIs can be used whether or not a hardware accelerator is >actually available]. >* Provide a minimal common basis for device abstraction in DPDK, that can >be used to unify the different types of packet I/O devices already >existing in DPDK. To this end, the ethdev APIs are a good starting point, >but the ethdev library contains too many functions which are NIC-specific >to be a general-purpose set of APIs across all devices. > Note: The idea was previously touched on here: >http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 > >Description of Proposed Change >-- > >The basic idea behind "pktdev" is to abstract out a few common routines >and structures/members of structures by starting with ethdev structures as >a starting point, cut it down to little more than a few members in each >structure then possible add just rx_burst and tx_burst. Then use the >structures as a starting point for writing a device type. Currently we >have the rx_burst/tx_burst routines moved to the pktdev and it see like >move a couple more common functions maybe resaonable. It could be the >Rx/Tx routines in pktdev should be left as is, but in the code below is a >possible reason to abstract a few routines into a common set of files. > >From there, we have the ethdev type which adds in the existing functions >specific to Ethernet devices, and also, for example, a cryptodev which may >add in functions specific for cryptographic offload. As now, with the >ethdev, the specific drivers provide concrete implementations of the >functionality exposed by the interface. This hierarchy is shown in the >diagram below, using the existing ethdev and ixgbe drivers as a reference, >alongside a hypothetical cryptodev class and driver implementation >(catchingly called) "X": > >,-. >| struct rte_pktdev | >+-+ >| rte_pkt_rx_burst() | >.---| rte_pkt_tx_burst() |---. >| `-' | >| | >| | > ,---.,--. > |struct rte_ethdev || struct rte_cryptodev| > +---++--+ > | rte_eth_dev_configure() || rte_crypto_init_sym_session()| > | rte_eth_allmulticast_enable() || rte_crypto_del_sym_session() | > | rte_eth_filter_ctrl() || | > `---'`---.--' >| | >| | > ,-'-.,---'--. > |struct rte_pmd_ixgbe || struct rte_pmd_X| > +---++--+ > | .configure -> ixgbe_configure || .init_session -> X_init_ses()| > | .tx_burst -> ixgbe_xmit_pkts || .tx_burst -> X_handle_pkts() | > `---'`--' > >We are not attempting to create a real class model here only looking at >creating a very basic common set of APIs and structures for other device >types. > >In terms of code changes for this, we obviously need to add in new >interface libraries for pktdev and cryptodev. The pktdev library can >define a skeleton structure for the first few elements
[dpdk-dev] [RFC] Adding multiple device types to DPDK.
On Wed, Apr 01, 2015 at 12:44:54PM +, Wiles, Keith wrote: > Hi all, (hoping format of the text is maintained) > > Bruce and myself are submitting this RFC in hopes of providing discussion > points for the idea. Please do not get carried away with the code > included, it was to help everyone understand the proposal/RFC. > > The RFC is to describe a proposed change we are looking to make to DPDK to > add more device types. We would like to add in to DPDK the idea of a > generic packet-device or ?pktdev?, which can be thought of as a thin layer > for all device classes. For other device types such as potentially a > ?cryptodev? or ?dpidev?. One of the main goals is to not effect > performance and not require any current application to be modified. The > pktdev layer is providing a light framework for developers to add a device > to DPDK. > > Reason for Change > - > > The reason why we are looking to introduce these concepts to DPDK are: > > * Expand the scope of DPDK so that it can provide APIs for more than just > packet acquisition and transmission, but also provide APIs that can be > used to work with other hardware and software offloads, such as > cryptographic accelerators, or accelerated libraries for cryptographic > functions. [The reason why both software and hardware are mentioned is so > that the same APIs can be used whether or not a hardware accelerator is > actually available]. > * Provide a minimal common basis for device abstraction in DPDK, that can > be used to unify the different types of packet I/O devices already > existing in DPDK. To this end, the ethdev APIs are a good starting point, > but the ethdev library contains too many functions which are NIC-specific > to be a general-purpose set of APIs across all devices. > Note: The idea was previously touched on here: > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 > > Description of Proposed Change > -- > > The basic idea behind "pktdev" is to abstract out a few common routines > and structures/members of structures by starting with ethdev structures as > a starting point, cut it down to little more than a few members in each > structure then possible add just rx_burst and tx_burst. Then use the > structures as a starting point for writing a device type. Currently we > have the rx_burst/tx_burst routines moved to the pktdev and it see like > move a couple more common functions maybe resaonable. It could be the > Rx/Tx routines in pktdev should be left as is, but in the code below is a > possible reason to abstract a few routines into a common set of files. > > >From there, we have the ethdev type which adds in the existing functions > specific to Ethernet devices, and also, for example, a cryptodev which may > add in functions specific for cryptographic offload. As now, with the > ethdev, the specific drivers provide concrete implementations of the > functionality exposed by the interface. This hierarchy is shown in the > diagram below, using the existing ethdev and ixgbe drivers as a reference, > alongside a hypothetical cryptodev class and driver implementation > (catchingly called) "X": > > ,-. > | struct rte_pktdev | > +-+ > | rte_pkt_rx_burst() | > .---| rte_pkt_tx_burst() |---. > | `-' | > | | > | | > ,---.,--. > |struct rte_ethdev || struct rte_cryptodev| > +---++--+ > | rte_eth_dev_configure() || rte_crypto_init_sym_session()| > | rte_eth_allmulticast_enable() || rte_crypto_del_sym_session() | > | rte_eth_filter_ctrl() || | > `---'`---.--' > | | > | | > ,-'-.,---'--. > |struct rte_pmd_ixgbe || struct rte_pmd_X| > +---++--+ > | .configure -> ixgbe_configure || .init_session -> X_init_ses()| > | .tx_burst -> ixgbe_xmit_pkts || .tx_burst -> X_handle_pkts() | > `---'`--' > > We are not attempting to create a real class model here only looking at > creating a very basic common set of APIs and structures for other device > types. > > In terms of code changes for this, we obviously need to add in new > interface libraries for pktdev and cryptodev. The pktdev library can >
[dpdk-dev] [RFC] Adding multiple device types to DPDK.
Hi Neil, On 4/3/15, 12:00 PM, "Neil Horman" wrote: >On Wed, Apr 01, 2015 at 12:44:54PM +, Wiles, Keith wrote: >> Hi all, (hoping format of the text is maintained) >> >> Bruce and myself are submitting this RFC in hopes of providing >>discussion >> points for the idea. Please do not get carried away with the code >> included, it was to help everyone understand the proposal/RFC. >> >> The RFC is to describe a proposed change we are looking to make to DPDK >>to >> add more device types. We would like to add in to DPDK the idea of a >> generic packet-device or ?pktdev?, which can be thought of as a thin >>layer >> for all device classes. For other device types such as potentially a >> ?cryptodev? or ?dpidev?. One of the main goals is to not effect >> performance and not require any current application to be modified. The >> pktdev layer is providing a light framework for developers to add a >>device >> to DPDK. >> >> Reason for Change >> - >> >> The reason why we are looking to introduce these concepts to DPDK are: >> >> * Expand the scope of DPDK so that it can provide APIs for more than >>just >> packet acquisition and transmission, but also provide APIs that can be >> used to work with other hardware and software offloads, such as >> cryptographic accelerators, or accelerated libraries for cryptographic >> functions. [The reason why both software and hardware are mentioned is >>so >> that the same APIs can be used whether or not a hardware accelerator is >> actually available]. >> * Provide a minimal common basis for device abstraction in DPDK, that >>can >> be used to unify the different types of packet I/O devices already >> existing in DPDK. To this end, the ethdev APIs are a good starting >>point, >> but the ethdev library contains too many functions which are >>NIC-specific >> to be a general-purpose set of APIs across all devices. >> Note: The idea was previously touched on here: >> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 >> >> Description of Proposed Change >> -- >> >> The basic idea behind "pktdev" is to abstract out a few common routines >> and structures/members of structures by starting with ethdev structures >>as >> a starting point, cut it down to little more than a few members in each >> structure then possible add just rx_burst and tx_burst. Then use the >> structures as a starting point for writing a device type. Currently we >> have the rx_burst/tx_burst routines moved to the pktdev and it see like >> move a couple more common functions maybe resaonable. It could be the >> Rx/Tx routines in pktdev should be left as is, but in the code below is >>a >> possible reason to abstract a few routines into a common set of files. >> >> >From there, we have the ethdev type which adds in the existing >>functions >> specific to Ethernet devices, and also, for example, a cryptodev which >>may >> add in functions specific for cryptographic offload. As now, with the >> ethdev, the specific drivers provide concrete implementations of the >> functionality exposed by the interface. This hierarchy is shown in the >> diagram below, using the existing ethdev and ixgbe drivers as a >>reference, >> alongside a hypothetical cryptodev class and driver implementation >> (catchingly called) "X": >> >> ,-. >> | struct rte_pktdev | >> +-+ >> | rte_pkt_rx_burst() | >> .---| rte_pkt_tx_burst() |---. >> | `-' | >> | | >> | | >> ,---.,--. >> |struct rte_ethdev || struct rte_cryptodev| >> +---++--+ >> | rte_eth_dev_configure() || rte_crypto_init_sym_session()| >> | rte_eth_allmulticast_enable() || rte_crypto_del_sym_session() | >> | rte_eth_filter_ctrl() || | >> `---'`---.--' >> | | >> | | >> ,-'-.,---'--. >> |struct rte_pmd_ixgbe || struct rte_pmd_X| >> +---++--+ >> | .configure -> ixgbe_configure || .init_session -> X_init_ses()| >> | .tx_burst -> ixgbe_xmit_pkts || .tx_burst -> X_handle_pkts() | >> `---'`--' >> >> We are not attempting to create a real class model here only looking at >> creating a very basic common set of APIs and structures for o
[dpdk-dev] [RFC] Adding multiple device types to DPDK.
On Fri, Apr 03, 2015 at 10:32:01PM +, Wiles, Keith wrote: > Hi Neil, > > On 4/3/15, 12:00 PM, "Neil Horman" wrote: > > >On Wed, Apr 01, 2015 at 12:44:54PM +, Wiles, Keith wrote: > >> Hi all, (hoping format of the text is maintained) > >> > >> Bruce and myself are submitting this RFC in hopes of providing > >>discussion > >> points for the idea. Please do not get carried away with the code > >> included, it was to help everyone understand the proposal/RFC. > >> > >> The RFC is to describe a proposed change we are looking to make to DPDK > >>to > >> add more device types. We would like to add in to DPDK the idea of a > >> generic packet-device or ?pktdev?, which can be thought of as a thin > >>layer > >> for all device classes. For other device types such as potentially a > >> ?cryptodev? or ?dpidev?. One of the main goals is to not effect > >> performance and not require any current application to be modified. The > >> pktdev layer is providing a light framework for developers to add a > >>device > >> to DPDK. > >> > >> Reason for Change > >> - > >> > >> The reason why we are looking to introduce these concepts to DPDK are: > >> > >> * Expand the scope of DPDK so that it can provide APIs for more than > >>just > >> packet acquisition and transmission, but also provide APIs that can be > >> used to work with other hardware and software offloads, such as > >> cryptographic accelerators, or accelerated libraries for cryptographic > >> functions. [The reason why both software and hardware are mentioned is > >>so > >> that the same APIs can be used whether or not a hardware accelerator is > >> actually available]. > >> * Provide a minimal common basis for device abstraction in DPDK, that > >>can > >> be used to unify the different types of packet I/O devices already > >> existing in DPDK. To this end, the ethdev APIs are a good starting > >>point, > >> but the ethdev library contains too many functions which are > >>NIC-specific > >> to be a general-purpose set of APIs across all devices. > >> Note: The idea was previously touched on here: > >> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 > >> > >> Description of Proposed Change > >> -- > >> > >> The basic idea behind "pktdev" is to abstract out a few common routines > >> and structures/members of structures by starting with ethdev structures > >>as > >> a starting point, cut it down to little more than a few members in each > >> structure then possible add just rx_burst and tx_burst. Then use the > >> structures as a starting point for writing a device type. Currently we > >> have the rx_burst/tx_burst routines moved to the pktdev and it see like > >> move a couple more common functions maybe resaonable. It could be the > >> Rx/Tx routines in pktdev should be left as is, but in the code below is > >>a > >> possible reason to abstract a few routines into a common set of files. > >> > >> >From there, we have the ethdev type which adds in the existing > >>functions > >> specific to Ethernet devices, and also, for example, a cryptodev which > >>may > >> add in functions specific for cryptographic offload. As now, with the > >> ethdev, the specific drivers provide concrete implementations of the > >> functionality exposed by the interface. This hierarchy is shown in the > >> diagram below, using the existing ethdev and ixgbe drivers as a > >>reference, > >> alongside a hypothetical cryptodev class and driver implementation > >> (catchingly called) "X": > >> > >> ,-. > >> | struct rte_pktdev | > >> +-+ > >> | rte_pkt_rx_burst() | > >> .---| rte_pkt_tx_burst() |---. > >> | `-' | > >> | | > >> | | > >> ,---.,--. > >> |struct rte_ethdev || struct rte_cryptodev| > >> +---++--+ > >> | rte_eth_dev_configure() || rte_crypto_init_sym_session()| > >> | rte_eth_allmulticast_enable() || rte_crypto_del_sym_session() | > >> | rte_eth_filter_ctrl() || | > >> `---'`---.--' > >> | | > >> | | > >> ,-'-.,---'--. > >> |struct rte_pmd_ixgbe || struct rte_pmd_X| > >> +---++--+ > >> | .configure -> ixgbe_configure || .init_session -> X_init_ses()| > >> | .tx_burst -> ixgbe_xmit_pkt
[dpdk-dev] [RFC] Adding multiple device types to DPDK.
On 4/4/15, 8:11 AM, "Neil Horman" wrote: >On Fri, Apr 03, 2015 at 10:32:01PM +, Wiles, Keith wrote: >> Hi Neil, >> >> On 4/3/15, 12:00 PM, "Neil Horman" wrote: >> >> >On Wed, Apr 01, 2015 at 12:44:54PM +, Wiles, Keith wrote: >> >> Hi all, (hoping format of the text is maintained) >> >> >> >> Bruce and myself are submitting this RFC in hopes of providing >> >>discussion >> >> points for the idea. Please do not get carried away with the code >> >> included, it was to help everyone understand the proposal/RFC. >> >> >> >> The RFC is to describe a proposed change we are looking to make to >>DPDK >> >>to >> >> add more device types. We would like to add in to DPDK the idea of a >> >> generic packet-device or ?pktdev?, which can be thought of as a thin >> >>layer >> >> for all device classes. For other device types such as potentially a >> >> ?cryptodev? or ?dpidev?. One of the main goals is to not effect >> >> performance and not require any current application to be modified. >>The >> >> pktdev layer is providing a light framework for developers to add a >> >>device >> >> to DPDK. >> >> >> >> Reason for Change >> >> - >> >> >> >> The reason why we are looking to introduce these concepts to DPDK >>are: >> >> >> >> * Expand the scope of DPDK so that it can provide APIs for more than >> >>just >> >> packet acquisition and transmission, but also provide APIs that can >>be >> >> used to work with other hardware and software offloads, such as >> >> cryptographic accelerators, or accelerated libraries for >>cryptographic >> >> functions. [The reason why both software and hardware are mentioned >>is >> >>so >> >> that the same APIs can be used whether or not a hardware accelerator >>is >> >> actually available]. >> >> * Provide a minimal common basis for device abstraction in DPDK, that >> >>can >> >> be used to unify the different types of packet I/O devices already >> >> existing in DPDK. To this end, the ethdev APIs are a good starting >> >>point, >> >> but the ethdev library contains too many functions which are >> >>NIC-specific >> >> to be a general-purpose set of APIs across all devices. >> >> Note: The idea was previously touched on here: >> >> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 >> >> >> >> Description of Proposed Change >> >> -- >> >> >> >> The basic idea behind "pktdev" is to abstract out a few common >>routines >> >> and structures/members of structures by starting with ethdev >>structures >> >>as >> >> a starting point, cut it down to little more than a few members in >>each >> >> structure then possible add just rx_burst and tx_burst. Then use the >> >> structures as a starting point for writing a device type. Currently >>we >> >> have the rx_burst/tx_burst routines moved to the pktdev and it see >>like >> >> move a couple more common functions maybe resaonable. It could be the >> >> Rx/Tx routines in pktdev should be left as is, but in the code below >>is >> >>a >> >> possible reason to abstract a few routines into a common set of >>files. >> >> >> >> >From there, we have the ethdev type which adds in the existing >> >>functions >> >> specific to Ethernet devices, and also, for example, a cryptodev >>which >> >>may >> >> add in functions specific for cryptographic offload. As now, with the >> >> ethdev, the specific drivers provide concrete implementations of the >> >> functionality exposed by the interface. This hierarchy is shown in >>the >> >> diagram below, using the existing ethdev and ixgbe drivers as a >> >>reference, >> >> alongside a hypothetical cryptodev class and driver implementation >> >> (catchingly called) "X": >> >> >> >> ,-. >> >> | struct rte_pktdev | >> >> +-+ >> >> | rte_pkt_rx_burst() | >> >> .---| rte_pkt_tx_burst() |---. >> >> | `-' | >> >> | | >> >> | | >> >> ,---. >>,--. >> >> |struct rte_ethdev || struct rte_cryptodev >> | >> >> +---+ >>+--+ >> >> | rte_eth_dev_configure() || >>rte_crypto_init_sym_session()| >> >> | rte_eth_allmulticast_enable() || >>rte_crypto_del_sym_session() | >> >> | rte_eth_filter_ctrl() || >> | >> >> `---' >>`---.--' >> >> | | >> >> | | >> >> ,-'-. >>,---'--. >> >> |struct rte_pmd_ixgbe || struct rte_pmd_X >> | >> >> +---+ >>+---
[dpdk-dev] [RFC] Adding multiple device types to DPDK.
On Sat, Apr 04, 2015 at 03:16:08PM +, Wiles, Keith wrote: > > > On 4/4/15, 8:11 AM, "Neil Horman" wrote: > > >On Fri, Apr 03, 2015 at 10:32:01PM +, Wiles, Keith wrote: > >> Hi Neil, > >> > >> On 4/3/15, 12:00 PM, "Neil Horman" wrote: > >> > >> >On Wed, Apr 01, 2015 at 12:44:54PM +, Wiles, Keith wrote: > >> >> Hi all, (hoping format of the text is maintained) > >> >> > >> >> Bruce and myself are submitting this RFC in hopes of providing > >> >>discussion > >> >> points for the idea. Please do not get carried away with the code > >> >> included, it was to help everyone understand the proposal/RFC. > >> >> > >> >> The RFC is to describe a proposed change we are looking to make to > >>DPDK > >> >>to > >> >> add more device types. We would like to add in to DPDK the idea of a > >> >> generic packet-device or ?pktdev?, which can be thought of as a thin > >> >>layer > >> >> for all device classes. For other device types such as potentially a > >> >> ?cryptodev? or ?dpidev?. One of the main goals is to not effect > >> >> performance and not require any current application to be modified. > >>The > >> >> pktdev layer is providing a light framework for developers to add a > >> >>device > >> >> to DPDK. > >> >> > >> >> Reason for Change > >> >> - > >> >> > >> >> The reason why we are looking to introduce these concepts to DPDK > >>are: > >> >> > >> >> * Expand the scope of DPDK so that it can provide APIs for more than > >> >>just > >> >> packet acquisition and transmission, but also provide APIs that can > >>be > >> >> used to work with other hardware and software offloads, such as > >> >> cryptographic accelerators, or accelerated libraries for > >>cryptographic > >> >> functions. [The reason why both software and hardware are mentioned > >>is > >> >>so > >> >> that the same APIs can be used whether or not a hardware accelerator > >>is > >> >> actually available]. > >> >> * Provide a minimal common basis for device abstraction in DPDK, that > >> >>can > >> >> be used to unify the different types of packet I/O devices already > >> >> existing in DPDK. To this end, the ethdev APIs are a good starting > >> >>point, > >> >> but the ethdev library contains too many functions which are > >> >>NIC-specific > >> >> to be a general-purpose set of APIs across all devices. > >> >> Note: The idea was previously touched on here: > >> >> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 > >> >> > >> >> Description of Proposed Change > >> >> -- > >> >> > >> >> The basic idea behind "pktdev" is to abstract out a few common > >>routines > >> >> and structures/members of structures by starting with ethdev > >>structures > >> >>as > >> >> a starting point, cut it down to little more than a few members in > >>each > >> >> structure then possible add just rx_burst and tx_burst. Then use the > >> >> structures as a starting point for writing a device type. Currently > >>we > >> >> have the rx_burst/tx_burst routines moved to the pktdev and it see > >>like > >> >> move a couple more common functions maybe resaonable. It could be the > >> >> Rx/Tx routines in pktdev should be left as is, but in the code below > >>is > >> >>a > >> >> possible reason to abstract a few routines into a common set of > >>files. > >> >> > >> >> >From there, we have the ethdev type which adds in the existing > >> >>functions > >> >> specific to Ethernet devices, and also, for example, a cryptodev > >>which > >> >>may > >> >> add in functions specific for cryptographic offload. As now, with the > >> >> ethdev, the specific drivers provide concrete implementations of the > >> >> functionality exposed by the interface. This hierarchy is shown in > >>the > >> >> diagram below, using the existing ethdev and ixgbe drivers as a > >> >>reference, > >> >> alongside a hypothetical cryptodev class and driver implementation > >> >> (catchingly called) "X": > >> >> > >> >> ,-. > >> >> | struct rte_pktdev | > >> >> +-+ > >> >> | rte_pkt_rx_burst() | > >> >> .---| rte_pkt_tx_burst() |---. > >> >> | `-' | > >> >> | | > >> >> | | > >> >> ,---. > >>,--. > >> >> |struct rte_ethdev || struct rte_cryptodev > >> | > >> >> +---+ > >>+--+ > >> >> | rte_eth_dev_configure() || > >>rte_crypto_init_sym_session()| > >> >> | rte_eth_allmulticast_enable() || > >>rte_crypto_del_sym_session() | > >> >> | rte_eth_filter_ctrl() || > >> | > >> >> `---' > >>`---.--' > >> >> |
[dpdk-dev] [RFC] Adding multiple device types to DPDK.
On 4/5/15, 2:37 PM, "Neil Horman" wrote: >On Sat, Apr 04, 2015 at 03:16:08PM +, Wiles, Keith wrote: >> >> >> On 4/4/15, 8:11 AM, "Neil Horman" wrote: >> >> >On Fri, Apr 03, 2015 at 10:32:01PM +, Wiles, Keith wrote: >> >> Hi Neil, >> >> >> >> On 4/3/15, 12:00 PM, "Neil Horman" wrote: >> >> >> >> >On Wed, Apr 01, 2015 at 12:44:54PM +, Wiles, Keith wrote: >> >> >> Hi all, (hoping format of the text is maintained) >> >> >> >> >> >> Bruce and myself are submitting this RFC in hopes of providing >> >> >>discussion >> >> >> points for the idea. Please do not get carried away with the code >> >> >> included, it was to help everyone understand the proposal/RFC. >> >> >> >> >> >> The RFC is to describe a proposed change we are looking to make to >> >>DPDK >> >> >>to >> >> >> add more device types. We would like to add in to DPDK the idea >>of a >> >> >> generic packet-device or ?pktdev?, which can be thought of as a >>thin >> >> >>layer >> >> >> for all device classes. For other device types such as >>potentially a >> >> >> ?cryptodev? or ?dpidev?. One of the main goals is to not effect >> >> >> performance and not require any current application to be >>modified. >> >>The >> >> >> pktdev layer is providing a light framework for developers to add >>a >> >> >>device >> >> >> to DPDK. >> >> >> >> >> >> Reason for Change >> >> >> - >> >> >> >> >> >> The reason why we are looking to introduce these concepts to DPDK >> >>are: >> >> >> >> >> >> * Expand the scope of DPDK so that it can provide APIs for more >>than >> >> >>just >> >> >> packet acquisition and transmission, but also provide APIs that >>can >> >>be >> >> >> used to work with other hardware and software offloads, such as >> >> >> cryptographic accelerators, or accelerated libraries for >> >>cryptographic >> >> >> functions. [The reason why both software and hardware are >>mentioned >> >>is >> >> >>so >> >> >> that the same APIs can be used whether or not a hardware >>accelerator >> >>is >> >> >> actually available]. >> >> >> * Provide a minimal common basis for device abstraction in DPDK, >>that >> >> >>can >> >> >> be used to unify the different types of packet I/O devices already >> >> >> existing in DPDK. To this end, the ethdev APIs are a good starting >> >> >>point, >> >> >> but the ethdev library contains too many functions which are >> >> >>NIC-specific >> >> >> to be a general-purpose set of APIs across all devices. >> >> >> Note: The idea was previously touched on here: >> >> >> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 >> >> >> >> >> >> Description of Proposed Change >> >> >> -- >> >> >> >> >> >> The basic idea behind "pktdev" is to abstract out a few common >> >>routines >> >> >> and structures/members of structures by starting with ethdev >> >>structures >> >> >>as >> >> >> a starting point, cut it down to little more than a few members in >> >>each >> >> >> structure then possible add just rx_burst and tx_burst. Then use >>the >> >> >> structures as a starting point for writing a device type. >>Currently >> >>we >> >> >> have the rx_burst/tx_burst routines moved to the pktdev and it see >> >>like >> >> >> move a couple more common functions maybe resaonable. It could be >>the >> >> >> Rx/Tx routines in pktdev should be left as is, but in the code >>below >> >>is >> >> >>a >> >> >> possible reason to abstract a few routines into a common set of >> >>files. >> >> >> >> >> >> >From there, we have the ethdev type which adds in the existing >> >> >>functions >> >> >> specific to Ethernet devices, and also, for example, a cryptodev >> >>which >> >> >>may >> >> >> add in functions specific for cryptographic offload. As now, with >>the >> >> >> ethdev, the specific drivers provide concrete implementations of >>the >> >> >> functionality exposed by the interface. This hierarchy is shown in >> >>the >> >> >> diagram below, using the existing ethdev and ixgbe drivers as a >> >> >>reference, >> >> >> alongside a hypothetical cryptodev class and driver implementation >> >> >> (catchingly called) "X": >> >> >> >> >> >> ,-. >> >> >> | struct rte_pktdev | >> >> >> +-+ >> >> >> | rte_pkt_rx_burst() | >> >> >> .---| rte_pkt_tx_burst() |---. >> >> >> | `-' | >> >> >> | | >> >> >> | | >> >> >> ,---. >> >>,--. >> >> >> |struct rte_ethdev || struct rte_cryptodev >> >> | >> >> >> +---+ >> >>+--+ >> >> >> | rte_eth_dev_configure() || >> >>rte_crypto_init_sym_session()| >> >> >> | rte_eth_allmulticast_enable() || >> >>
[dpdk-dev] [RFC] Adding multiple device types to DPDK.
On Sun, Apr 05, 2015 at 10:20:10PM +, Wiles, Keith wrote: > > > On 4/5/15, 2:37 PM, "Neil Horman" wrote: > > >On Sat, Apr 04, 2015 at 03:16:08PM +, Wiles, Keith wrote: > >> > >> > >> On 4/4/15, 8:11 AM, "Neil Horman" wrote: > >> > >> >On Fri, Apr 03, 2015 at 10:32:01PM +, Wiles, Keith wrote: > >> >> Hi Neil, > >> >> > >> >> On 4/3/15, 12:00 PM, "Neil Horman" wrote: > >> >> > >> >> >On Wed, Apr 01, 2015 at 12:44:54PM +, Wiles, Keith wrote: > >> >> >> Hi all, (hoping format of the text is maintained) > >> >> >> > >> >> >> Bruce and myself are submitting this RFC in hopes of providing > >> >> >>discussion > >> >> >> points for the idea. Please do not get carried away with the code > >> >> >> included, it was to help everyone understand the proposal/RFC. > >> >> >> > >> >> >> The RFC is to describe a proposed change we are looking to make to > >> >>DPDK > >> >> >>to > >> >> >> add more device types. We would like to add in to DPDK the idea > >>of a > >> >> >> generic packet-device or ?pktdev?, which can be thought of as a > >>thin > >> >> >>layer > >> >> >> for all device classes. For other device types such as > >>potentially a > >> >> >> ?cryptodev? or ?dpidev?. One of the main goals is to not effect > >> >> >> performance and not require any current application to be > >>modified. > >> >>The > >> >> >> pktdev layer is providing a light framework for developers to add > >>a > >> >> >>device > >> >> >> to DPDK. > >> >> >> > >> >> >> Reason for Change > >> >> >> - > >> >> >> > >> >> >> The reason why we are looking to introduce these concepts to DPDK > >> >>are: > >> >> >> > >> >> >> * Expand the scope of DPDK so that it can provide APIs for more > >>than > >> >> >>just > >> >> >> packet acquisition and transmission, but also provide APIs that > >>can > >> >>be > >> >> >> used to work with other hardware and software offloads, such as > >> >> >> cryptographic accelerators, or accelerated libraries for > >> >>cryptographic > >> >> >> functions. [The reason why both software and hardware are > >>mentioned > >> >>is > >> >> >>so > >> >> >> that the same APIs can be used whether or not a hardware > >>accelerator > >> >>is > >> >> >> actually available]. > >> >> >> * Provide a minimal common basis for device abstraction in DPDK, > >>that > >> >> >>can > >> >> >> be used to unify the different types of packet I/O devices already > >> >> >> existing in DPDK. To this end, the ethdev APIs are a good starting > >> >> >>point, > >> >> >> but the ethdev library contains too many functions which are > >> >> >>NIC-specific > >> >> >> to be a general-purpose set of APIs across all devices. > >> >> >> Note: The idea was previously touched on here: > >> >> >> http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/13545 > >> >> >> > >> >> >> Description of Proposed Change > >> >> >> -- > >> >> >> > >> >> >> The basic idea behind "pktdev" is to abstract out a few common > >> >>routines > >> >> >> and structures/members of structures by starting with ethdev > >> >>structures > >> >> >>as > >> >> >> a starting point, cut it down to little more than a few members in > >> >>each > >> >> >> structure then possible add just rx_burst and tx_burst. Then use > >>the > >> >> >> structures as a starting point for writing a device type. > >>Currently > >> >>we > >> >> >> have the rx_burst/tx_burst routines moved to the pktdev and it see > >> >>like > >> >> >> move a couple more common functions maybe resaonable. It could be > >>the > >> >> >> Rx/Tx routines in pktdev should be left as is, but in the code > >>below > >> >>is > >> >> >>a > >> >> >> possible reason to abstract a few routines into a common set of > >> >>files. > >> >> >> > >> >> >> >From there, we have the ethdev type which adds in the existing > >> >> >>functions > >> >> >> specific to Ethernet devices, and also, for example, a cryptodev > >> >>which > >> >> >>may > >> >> >> add in functions specific for cryptographic offload. As now, with > >>the > >> >> >> ethdev, the specific drivers provide concrete implementations of > >>the > >> >> >> functionality exposed by the interface. This hierarchy is shown in > >> >>the > >> >> >> diagram below, using the existing ethdev and ixgbe drivers as a > >> >> >>reference, > >> >> >> alongside a hypothetical cryptodev class and driver implementation > >> >> >> (catchingly called) "X": > >> >> >> > >> >> >> ,-. > >> >> >> | struct rte_pktdev | > >> >> >> +-+ > >> >> >> | rte_pkt_rx_burst() | > >> >> >> .---| rte_pkt_tx_burst() |---. > >> >> >> | `-' | > >> >> >> | | > >> >> >> | | > >> >> >> ,---. > >> >>,--
