[dpdk-dev] KNI automatic IP configuration
e1000 driver supports many different NIC devices. Do you know your NIC device type or device_id? > -Original Message- > From: Olivier Deme [mailto:odeme at druidsoftware.com] > Sent: Sunday, April 05, 2015 1:03 AM > To: Zhou, Danny > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] KNI automatic IP configuration > > Currently I?m using the e1000 PMD driver. > > Thanks, > Olivier. > > > On 4 Apr 2015, at 12:51, Zhou, Danny wrote: > > > > Which NIC device are you using now? > > > > KNI does not provide Ethtool support for all NICs supported by the > > Poll-Mode Drivers. > > > >> -Original Message- > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Deme > >> Sent: Friday, April 03, 2015 10:03 PM > >> To: dev at dpdk.org > >> Subject: [dpdk-dev] KNI automatic IP configuration > >> > >> Hi all, > >> > >> Is it possible on Linux to get the Linux network manager to automatically > >> configure a KNI virtual network interface as soon as it > >> comes up? > >> I haven?t been able to get Fedora to apply the configuration under > >> /etc/sysconfig/network-scripts/ifcfg-veth0 file upon > starting > >> my DPDK application. > >> > >> Executing ifup veth0 manually works but somehow the fedora network manager > >> seems to have an issue to apply the if cfg > config > >> automatically. > >> In the system logs I can see something along the lines ?kni doesn?t > >> support ethtool?. Is this related? > >> > >> I also tried ifplugd but without success. > >> > >> Many thanks for your help, > >> > >> Olivier. > >
[dpdk-dev] App acting strangely when Vector rx / FDIR is on
I have an app which processes packets, and for a while I had FDIR in
signature mode. Since I no longer needed filtering, I turned it off
(which also turned on vector rx) which caused some strange behaviour.
I changed the app so that it simply prints the length of the packet
for each incoming one, then sent 10,000 packets at a very slow speed
(10Mbps) with only one core.
Most noticable was that even though the NIC stats showed the same
packets received (rte_eth_stats.ipackets), only 9111 packet lengths
were printed when vector/fdir was off (and the entire 10,000 were
printed when it was on).
The data lengths themselves were also different, but I expected some
reordering. When looking at a set of all the lengths, there were many
lengths that only appeared when fdir was on, and only one that
appeared when it was on but not when it was off.
Can anyone think of any explanation for this phenomenon? Any checks I could do?
Using a 10G 2P X520 adapter. These are the startup logs (when fdir is
off. When it is on, the "Vector rx enabled" line is removed):
EAL: Detected lcore 0 as core 0 on socket 0
EAL: Detected lcore 1 as core 1 on socket 0
EAL: Detected lcore 2 as core 2 on socket 0
EAL: Detected lcore 3 as core 3 on socket 0
EAL: Detected lcore 4 as core 4 on socket 0
EAL: Detected lcore 5 as core 5 on socket 0
EAL: Detected lcore 6 as core 0 on socket 0
EAL: Detected lcore 7 as core 1 on socket 0
EAL: Detected lcore 8 as core 2 on socket 0
EAL: Detected lcore 9 as core 3 on socket 0
EAL: Detected lcore 10 as core 4 on socket 0
EAL: Detected lcore 11 as core 5 on socket 0
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 12 lcore(s)
EAL: Setting up memory...
EAL: Ask a virtual area of 0x4 bytes
EAL: Virtual area found at 0x7f57 (size = 0x4)
EAL: Requesting 16 pages of size 1024MB from socket 0
EAL: TSC frequency is ~2094901 KHz
EAL: Master core 0 is ready (tid=a40368c0)
EAL: Core 7 is ready (tid=10033700)
EAL: Core 6 is ready (tid=10834700)
EAL: Core 5 is ready (tid=11035700)
EAL: Core 4 is ready (tid=11836700)
EAL: Core 3 is ready (tid=12037700)
EAL: Core 2 is ready (tid=12838700)
EAL: Core 1 is ready (tid=13039700)
EAL: PCI device :04:00.0 on NUMA socket -1
EAL: probe driver: 8086:154d rte_ixgbe_pmd
EAL: :04:00.0 not managed by UIO driver, skipping
EAL: PCI device :04:00.1 on NUMA socket 0
EAL: probe driver: 8086:154d rte_ixgbe_pmd
EAL: PCI memory mapped at 0x7f5ba3e84000
EAL: PCI memory mapped at 0x7f5ba4045000
PMD: eth_ixgbe_dev_init(): MAC: 2, PHY: 11, SFP+: 4
PMD: eth_ixgbe_dev_init(): port 0 vendorID=0x8086 deviceID=0x154d
MAIN: Finished DPDK memory setup
PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f5700af0e40
hw_ring=0x7f59555fae00 dma_addr=0xe155fae00
PMD: ixgbe_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
satisfied. Rx Burst Bulk Alloc function will be used on port=0,
queue=0.
PMD: ixgbe_dev_rx_queue_setup(): Vector rx enabled, please make sure
RX burst size no less than 32.
PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5700af0900
hw_ring=0x7f595560ae80 dma_addr=0xe1560ae80
PMD: set_tx_function(): Using full-featured tx code path
PMD: set_tx_function(): - txq_flags = 0 [IXGBE_SIMPLE_FLAGS=f01]
PMD: set_tx_function(): - tx_rs_thresh = 32 [RTE_PMD_IXGBE_TX_MAX_BURST=32]
My (shortened) configuration:
static struct rte_eth_conf const ethconf = {
.link_speed = 0,
.link_duplex = 0,
.rxmode = {
.mq_mode = ETH_MQ_RX_RSS,
.max_rx_pkt_len = 2000,
.split_hdr_size = 0,
.header_split = 0,
.hw_ip_checksum = 0,
.hw_vlan_filter = 0,
.jumbo_frame = 1,
.hw_strip_crc = 0, /**< CRC stripped by hardware */
},
.rx_adv_conf = {
.rss_conf = {
.rss_key = NULL,
.rss_hf = ETH_RSS_IPV4 | ETH_RSS_IPV6,
}
},
.fdir_conf = {
.mode = RTE_FDIR_MODE_NONE, // Or RTE_FDIR_MODE_SIGNATURE,
},
};
static struct rte_eth_rxconf const rxconf = {
.rx_thresh = {
.pthresh = 8,
.hthresh = 8,
.wthresh = 0,
},
.rx_free_thresh = 300,
.rx_drop_en = 0,
};
Thanks.
[dpdk-dev] App acting strangely when Vector rx / FDIR is on
"Fixed" the problem.
I upgraded to DPDK 2.0, which did not allow vector rx to until I have
changed my RX hardware queue size to a power of two.
After I did that (and changed the rx_free_thresh accordingly), it simply worked.
On Sun, Apr 5, 2015 at 11:45 AM, Dor Green wrote:
> I have an app which processes packets, and for a while I had FDIR in
> signature mode. Since I no longer needed filtering, I turned it off
> (which also turned on vector rx) which caused some strange behaviour.
>
> I changed the app so that it simply prints the length of the packet
> for each incoming one, then sent 10,000 packets at a very slow speed
> (10Mbps) with only one core.
> Most noticable was that even though the NIC stats showed the same
> packets received (rte_eth_stats.ipackets), only 9111 packet lengths
> were printed when vector/fdir was off (and the entire 10,000 were
> printed when it was on).
> The data lengths themselves were also different, but I expected some
> reordering. When looking at a set of all the lengths, there were many
> lengths that only appeared when fdir was on, and only one that
> appeared when it was on but not when it was off.
>
> Can anyone think of any explanation for this phenomenon? Any checks I could
> do?
>
> Using a 10G 2P X520 adapter. These are the startup logs (when fdir is
> off. When it is on, the "Vector rx enabled" line is removed):
>
> EAL: Detected lcore 0 as core 0 on socket 0
> EAL: Detected lcore 1 as core 1 on socket 0
> EAL: Detected lcore 2 as core 2 on socket 0
> EAL: Detected lcore 3 as core 3 on socket 0
> EAL: Detected lcore 4 as core 4 on socket 0
> EAL: Detected lcore 5 as core 5 on socket 0
> EAL: Detected lcore 6 as core 0 on socket 0
> EAL: Detected lcore 7 as core 1 on socket 0
> EAL: Detected lcore 8 as core 2 on socket 0
> EAL: Detected lcore 9 as core 3 on socket 0
> EAL: Detected lcore 10 as core 4 on socket 0
> EAL: Detected lcore 11 as core 5 on socket 0
> EAL: Support maximum 128 logical core(s) by configuration.
> EAL: Detected 12 lcore(s)
> EAL: Setting up memory...
> EAL: Ask a virtual area of 0x4 bytes
> EAL: Virtual area found at 0x7f57 (size = 0x4)
> EAL: Requesting 16 pages of size 1024MB from socket 0
> EAL: TSC frequency is ~2094901 KHz
> EAL: Master core 0 is ready (tid=a40368c0)
> EAL: Core 7 is ready (tid=10033700)
> EAL: Core 6 is ready (tid=10834700)
> EAL: Core 5 is ready (tid=11035700)
> EAL: Core 4 is ready (tid=11836700)
> EAL: Core 3 is ready (tid=12037700)
> EAL: Core 2 is ready (tid=12838700)
> EAL: Core 1 is ready (tid=13039700)
> EAL: PCI device :04:00.0 on NUMA socket -1
> EAL: probe driver: 8086:154d rte_ixgbe_pmd
> EAL: :04:00.0 not managed by UIO driver, skipping
> EAL: PCI device :04:00.1 on NUMA socket 0
> EAL: probe driver: 8086:154d rte_ixgbe_pmd
> EAL: PCI memory mapped at 0x7f5ba3e84000
> EAL: PCI memory mapped at 0x7f5ba4045000
> PMD: eth_ixgbe_dev_init(): MAC: 2, PHY: 11, SFP+: 4
> PMD: eth_ixgbe_dev_init(): port 0 vendorID=0x8086 deviceID=0x154d
> MAIN: Finished DPDK memory setup
> PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f5700af0e40
> hw_ring=0x7f59555fae00 dma_addr=0xe155fae00
> PMD: ixgbe_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
> satisfied. Rx Burst Bulk Alloc function will be used on port=0,
> queue=0.
> PMD: ixgbe_dev_rx_queue_setup(): Vector rx enabled, please make sure
> RX burst size no less than 32.
> PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f5700af0900
> hw_ring=0x7f595560ae80 dma_addr=0xe1560ae80
> PMD: set_tx_function(): Using full-featured tx code path
> PMD: set_tx_function(): - txq_flags = 0 [IXGBE_SIMPLE_FLAGS=f01]
> PMD: set_tx_function(): - tx_rs_thresh = 32 [RTE_PMD_IXGBE_TX_MAX_BURST=32]
>
>
> My (shortened) configuration:
>
> static struct rte_eth_conf const ethconf = {
> .link_speed = 0,
> .link_duplex = 0,
> .rxmode = {
> .mq_mode = ETH_MQ_RX_RSS,
> .max_rx_pkt_len = 2000,
> .split_hdr_size = 0,
> .header_split = 0,
> .hw_ip_checksum = 0,
> .hw_vlan_filter = 0,
> .jumbo_frame = 1,
> .hw_strip_crc = 0, /**< CRC stripped by hardware */
> },
>
> .rx_adv_conf = {
> .rss_conf = {
> .rss_key = NULL,
> .rss_hf = ETH_RSS_IPV4 | ETH_RSS_IPV6,
> }
> },
>
> .fdir_conf = {
> .mode = RTE_FDIR_MODE_NONE, // Or RTE_FDIR_MODE_SIGNATURE,
> },
> };
>
> static struct rte_eth_rxconf const rxconf = {
> .rx_thresh = {
> .pthresh = 8,
> .hthresh = 8,
> .wthresh = 0,
> },
>
> .rx_free_thresh = 300,
> .rx_drop_en = 0,
> };
>
> Thanks.
[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() |---. > >> >> >> | `-' | > >> >> >> | | > >> >> >> | | > >> >> >> ,---. > >> >>,--
