[dpdk-dev] [PATCH] igb_uio: cap max VFs at 7 to reserve one for PF
Hi Bruce, >> > However, even with that, I would suggest that any limit should be possible >> > to >> override. It's entirely possible that someone max actually want to reserve >> the >> full number of VFs, either because they don't want to use the NIC on the >> host at >> all, or because they are happy to use a VF on the host instead. Module >> parameter to allow override might work - and information on it could be added >> to the error message when we limit the VFs inside the driver. >> >> It's been a while since I've looked at this, but my recollection is >> the PF must be there (basic mailbox handling, for example). >> >> Would you rather a simple warning message as a hint? >I'm not sure about the PF still needing to be there or not - I'm not an expert >in that area, so you may indeed be right. >However, as for this patch, I'd probably be ok for now with a version that >queried the max_vfs and limited based on that. If in >future we do need to add >an override it should be trivial to add later-on. I don't think it is a right way to put all this logic into the kernel module: igb_uio doesn't know how many queues user-space PF plans to use for itself. In your example: 16 queues in total, 7 VFsx2queues = 14 queues, 2 queues left to PF. But then user-space PF decides it needs 4 queues and we we would hit the same problem again. I think, that to fix that issue properly we need to do that in userspace PMD. After rte_eth_dev_init(), we should know how many queues that device has in total, and how many of them are reserved for VFs. So at rte_eth_dev_configure() we can add a check that number of requested queues doesn't exceed max_queues - vf_reserved_queues and make rte_eth_dev_configure() to fail, if it does. Konstantin
[dpdk-dev] [PATCH v4 0/4] NIC filters support for generic filter
Tested-by: Waterman Cao This patch includes 4 files, and has been tested by Intel. Please see test environment information as the following: Fedora 20 x86_64, Linux Kernel 3.11.10-301, GCC 4.8.2 Intel Xeon CPU E5-2680 v2 @ 2.80GHz NIC: Intel Niantic 82599, Intel i350, Intel 82580 and Intel 82576 We verified ethertype filter, 2-tuple filter, 5-tuple filter, flex filter and SYN filter with above NICs. Total casesPassed Failed 27 25 2 Failures were caused by HW issues, no impact on functionality. Please see example: how to distribute specific packet to assigned queue. Firstly, launch testpmd firstly, then run the following command: ---add syn filter --- testpmd> add_syn_filter (port_id) priority (high|low) queue (queue_id) ---get syn filter info --- testpmd> get_syn_filter (port_id) ---remove syn filter --- testpmd> remove_syn_filter (port_id)
[dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes)
> -Original Message- <...snip...> > > this doesn't seem like an idea solution either. I'm not 100% clear why > > rte_eal_pci_probe is currently called by the application code and not > > initiated > > from within rte_eal_dev_init, if this was the case we would be able to > > figure > out > > a dependency tree for initialization of devices, based on the parsed input > > arguments without having extra user input to or multiple calls of > rte_eal_dev_init. > > > I agree, I think you should move it into its proper place within rte_eal_init, > though I think multiple calls to rte_eal_dev_init is perfectly acceptible in > this scenario. You certainly could parse the command line to build a > dependency > tree if you wish, though I don't think thats crruently overly complex. The > current > dependency tree is static at (physical devices, virtual devices, probe, > stacked > devices). If you need something more complex later, you can re-write it > freely > as it will be an internal library mechanism with no external visibility. > How useful is this going to be? The more complicated the ethdev stacking being done, the better suited it is to being done via the C APIs, via code which can do analysis of the hardware and cores at runtime and make logical decisions? After all, even if we do have applications being run to use bonded devices at runtime in place of physical ones, the bonded devices don't actually replace the physical ones, so some other application logic is needed to ensure that the application knows to only use the bonded devices. In most cases simply having a port-mask suffices, but not all apps will have a port-mask parameter, and for those that do, it introduces complexity for the user counting out interfaces and trying to work out what ports will have what numbers to set the appropriate bits in the portmask.
[dpdk-dev] [PATCH 00/13] IP fragmentation and reassembly
> Anatoly Burakov (13): > ip_frag: Moving fragmentation/reassembly headers into a separate > library > Refactored IPv4 fragmentation into a proper library > Fixing issues reported by checkpatch > ip_frag: new internal common header > ip_frag: removed unneeded check and macro > ip_frag: renaming structures in fragmentation table to be more generic > ip_frag: refactored reassembly code and made it a proper library > ip_frag: renamed ipv4 frag function > ip_frag: added IPv6 fragmentation support > examples: renamed ipv4_frag example app to ip_fragmentation > example: overhaul of ip_fragmentation example app > ip_frag: add support for IPv6 reassembly > examples: overhaul of ip_reassembly app Acked-by: Thomas Monjalon I've fixed few code style issues and added the library in doxygen. Applied for version 1.7.0. Thanks -- Thomas
[dpdk-dev] [PATCH v2 0/7] add mtu and flow control handlers
Hi David,
> This patchset introduces 3 new ethdev operations: flow control parameters
> retrieval and mtu get/set operations.
> Changes since v1:
> - compute min rx buffer size at ethdev level (to simplify pmd mtu checks)
> - introduce enable_scatter rx mode so that we can advise pmd to configure
> scatter mode
> - rework mtu get/set operations (based on Konstantin comments)
> - pass checkpatch.pl checks
1) [PATCH v2 3/7] ethdev: store min rx buffer size
@@ -879,6 +879,8 @@ rte_eth_rx_queue_setup(uint8_t port_id, uint16_t
rx_queue_id,
const struct rte_eth_rxconf *rx_conf,
struct rte_mempool *mp)
{
...
+ if (!ret) {
+ if (dev->data->min_rx_buf_size > mbp_buf_size)
+ dev->data->min_rx_buf_size = mbp_buf_size;
+ }
+
+ return ret;
Where do you set the initial value of min_rx_buf_size?
Can't find it by some reason.
2) [PATCH v2 5/7] ethdev: add mtu accessors
+static int
+ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
...
+ if (!dev->data->scattered_rx &&
+ frame_size > dev->data->min_rx_buf_size - RTE_PKTMBUF_HEADROOM)
+ return -EINVAL;
Reading 82599 spec, 8.2.3.22.13 Max Frame Size - MAXFRS (0x04268; RW):
" The MFS does not include the 4 bytes of the VLAN header. Packets with VLAN
header
can be as large as MFS + 4. When double VLAN is enabled, the device adds 8 to
the
MFS for any packets."
So, I suppose it should be:
if (!dev->data->scattered_rx &&
frame_size + 2 * IXGBE_VLAN_TAG_SIZE > dev->data->min_rx_buf_size -
RTE_PKTMBUF_HEADROOM)
Like in ixgbe_dev_rx_init().
3) if ((mtu < 68) || (frame_size > dev_info.max_rx_pktlen))
Can we add a new define for min allowable MTU (68) as it used in few places.
Thanks
Konstantin
[dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes)
On Mon, Jun 16, 2014 at 04:17:03PM +, Richardson, Bruce wrote: > > > > -Original Message- > <...snip...> > > > this doesn't seem like an idea solution either. I'm not 100% clear why > > > rte_eal_pci_probe is currently called by the application code and not > > > initiated > > > from within rte_eal_dev_init, if this was the case we would be able to > > > figure > > out > > > a dependency tree for initialization of devices, based on the parsed input > > > arguments without having extra user input to or multiple calls of > > rte_eal_dev_init. > > > > > I agree, I think you should move it into its proper place within > > rte_eal_init, > > though I think multiple calls to rte_eal_dev_init is perfectly acceptible in > > this scenario. You certainly could parse the command line to build a > > dependency > > tree if you wish, though I don't think thats crruently overly complex. The > > current > > dependency tree is static at (physical devices, virtual devices, probe, > > stacked > > devices). If you need something more complex later, you can re-write it > > freely > > as it will be an internal library mechanism with no external visibility. > > > > How useful is this going to be? The more complicated the ethdev stacking > being done, the better suited it is to being done via the C APIs, via code > which can do analysis of the hardware and cores at runtime and make logical > decisions? After all, even if we do have applications being run to use bonded > devices at runtime in place of physical ones, the bonded devices don't > actually replace the physical ones, so some other application logic is needed > to ensure that the application knows to only use the bonded devices. In most > cases simply having a port-mask suffices, but not all apps will have a > port-mask parameter, and for those that do, it introduces complexity for the > user counting out interfaces and trying to work out what ports will have what > numbers to set the appropriate bits in the portmask. Honestly? I don't know. As Stephen indicates the command line options might not be overly used, as its not always the best interface to select when building an application. But by the same token, not everyone is building an application that needs dynamic configuration with DPDK. My main concern here is one of consistency, which is really what people look for in a package within a distribution (i.e. Fedora, what I'm doing with the dpdk right now). You're probably correct in that lots of people will use the C api to build bonded interfaces since its a new api and they won't have been using bonds yet. But I'm concerned that, with a distributed package, lots of people might also be porting legacy applications to use the DPDK, in which case they may very well want to create static configurations within the dpdk to lower their porting efforts. Those people may well be very turned off by the fact that some, but not all interfaces can use the command line to be configured. In the end, its all about consistency in my mind. I get that the --vdev command line parameter perhaps isn't the most useful interface available, but its whats there. And if you start creating PMD's that use separate configuration interfaces and abandon the ones before it, you'll wind up with a hodgepodge of apis, all of which an application will have to be aware of to provide a full robust feature set. If --vdev stays, we should make it work for all the PMD's. Most might not use it, but some will, and those that do will appreciate the consistency you provide. If it just doesn't make sense to keep it around anymore, lets drop it and replace it with something better. Perhaps a configuration file interface would be good, so that the initialization of the pmds and the creation of interfaces is separated from the acutal application (thats actually a good idea I think, as it implies that all an application needs to know about is interfaces, not how they are constructed or stacked). But lets not just quietly start abandoning stuff because its inconvienient. Neil
[dpdk-dev] [PATCH v4 0/4] NIC filters support for generic filter
2014-06-16 15:31, Jingjing Wu: > A generic filter mechanism for handling special packet is required. > It will allow filters to be set in HW when available so that specific > packet may be filtered by NICs to specific descriptor queues for > processing. Currently only Flow Director for Intel's 10GbE 82599 > devices is available. Other types of filter are not support. > NIC filters list below are implemented in this patchset: > ethertype filter, syn filter, 2tuple filter and flex filter for 82580 and > i350 > ethertype filter, syn filter, 5tuple filter for 82576 > ethertype filter, syn filter and 5tuple filter for 82599 Reviewed-by: Vladimir Medvedkin Acked-by: Thomas Monjalon I've fixed some doxygen comments and logs. Applied for version 1.7.0. Hope to see more patches about filtering in coming weeks. Thanks -- Thomas
[dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes)
> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Monday, June 16, 2014 10:48 AM > To: Richardson, Bruce > Cc: Doherty, Declan; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library > (librte_eal/librte_ether link bonding support changes) > > On Mon, Jun 16, 2014 at 04:17:03PM +, Richardson, Bruce wrote: > > > > > > > -Original Message- > > <...snip...> > > > > this doesn't seem like an idea solution either. I'm not 100% clear why > > > > rte_eal_pci_probe is currently called by the application code and not > initiated > > > > from within rte_eal_dev_init, if this was the case we would be able to > figure > > > out > > > > a dependency tree for initialization of devices, based on the parsed > > > > input > > > > arguments without having extra user input to or multiple calls of > > > rte_eal_dev_init. > > > > > > > I agree, I think you should move it into its proper place within > > > rte_eal_init, > > > though I think multiple calls to rte_eal_dev_init is perfectly acceptible > > > in > > > this scenario. You certainly could parse the command line to build a > dependency > > > tree if you wish, though I don't think thats crruently overly complex. The > current > > > dependency tree is static at (physical devices, virtual devices, probe, > > > stacked > > > devices). If you need something more complex later, you can re-write it > freely > > > as it will be an internal library mechanism with no external visibility. > > > > > > > How useful is this going to be? The more complicated the ethdev stacking > being done, the better suited it is to being done via the C APIs, via code > which > can do analysis of the hardware and cores at runtime and make logical > decisions? After all, even if we do have applications being run to use bonded > devices at runtime in place of physical ones, the bonded devices don't > actually > replace the physical ones, so some other application logic is needed to ensure > that the application knows to only use the bonded devices. In most cases > simply > having a port-mask suffices, but not all apps will have a port-mask parameter, > and for those that do, it introduces complexity for the user counting out > interfaces and trying to work out what ports will have what numbers to set the > appropriate bits in the portmask. > > Honestly? I don't know. As Stephen indicates the command line options might > not be overly used, as its not always the best interface to select when > building > an application. But by the same token, not everyone is building an > application > that needs dynamic configuration with DPDK. My main concern here is one of > consistency, which is really what people look for in a package within a > distribution (i.e. Fedora, what I'm doing with the dpdk right now). You're > probably correct in that lots of people will use the C api to build bonded > interfaces since its a new api and they won't have been using bonds yet. But > I'm concerned that, with a distributed package, lots of people might also be > porting legacy applications to use the DPDK, in which case they may very well > want to create static configurations within the dpdk to lower their porting > efforts. Those people may well be very turned off by the fact that some, but > not all interfaces can use the command line to be configured. > > In the end, its all about consistency in my mind. I get that the --vdev > command > line parameter perhaps isn't the most useful interface available, but its > whats > there. And if you start creating PMD's that use separate configuration > interfaces and abandon the ones before it, you'll wind up with a hodgepodge of > apis, all of which an application will have to be aware of to provide a full > robust feature set. > > If --vdev stays, we should make it work for all the PMD's. Most might not use > it, but some will, and those that do will appreciate the consistency you > provide. If it just doesn't make sense to keep it around anymore, lets drop > it > and replace it with something better. Perhaps a configuration file interface > would be good, so that the initialization of the pmds and the creation of > interfaces is separated from the acutal application (thats actually a good > idea > I think, as it implies that all an application needs to know about is > interfaces, not how they are constructed or stacked). But lets not just > quietly > start abandoning stuff because its inconvienient. > The config file idea is one that's probably worth considering for the future. The thing about the vpmd option the assumption that all PMDs are equal. It works well for creating pseudo-physical ethdevs, such as pcap, raw-socket or ring or other similar ethdevs, but I'm not sure it's a good abstraction for higher level functionality that we want to expose via an ethdev interface. However, what to do for all these is not a decision we need to make for 1.7 :-)
[dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes)
2014-06-16 13:47, Neil Horman: > But lets not just quietly start abandoning stuff because its inconvienient. Fully agree. The minimum is to have "TODO" comments. And please, don't consider existing API as a reference. We must build a convenient and robust API, and probably break the existing one in many areas. The command line could be also reworked. Thanks for your efforts -- Thomas
[dpdk-dev] Writing a new driver
Joubert, By all means, look at the existing PMDs. It also helps if you have an existing kernel driver to use/modify (preferably BSD based). That way you can have a baseline to compare against. At least, that is method I used. Patrick > On Jun 13, 2014, at 9:08 AM, Joubert Berger wrote: > > I am looking at writing a new driver for DPDK for a NIC that is currently > not supported. What is the best way to start this? Is the a porting > guide? Or should I look at existing drivers as examples? > > --joubert
[dpdk-dev] vfio detection
Hi all, Now that vfio support has merged into the dpdk.org mainline, I'm seeing a number of issues with running applications, and I'm hoping someone can explain the observed behaviour. I have a number of NIC ports which were working correctly yesterday and are bound correctly to the igb_uio driver - and I want to keep using them through the igb_uio driver for now, not vfio. However, whenever I run a dpdk application today, I find that the vfio kernel module is getting loaded each time - even after I manually remove it, and verify that it has been removed by checking lsmod. Is this expected? If so, why are we loading the vfio driver when I just want to continue using igb_uio which works fine? Secondly, then, when testpmd or any other app loads, it automatically tries to map the NIC using vfio and then aborts on the very first NIC port when it fails to do so. This a) prevents the port from being mapped using igb_uio, and b) for ports which are meant to stay under linux control, forces me to start enumerating ports using blacklist or whitelisting, rather than having things "just work" on a properly configured system as before, i.e. if a port is bound to igb_uio or vfio it is used, if not bound, it is ignored. Again, is this by design and expected, because it seems a major regression in usability? Regards, /Bruce
[dpdk-dev] [PATCH] vfio: make container open error non-fatal
When setting up an app to run using the uio driver, errors caused by
VFIO failures should not abruptly cause the app to fail.
Example: on a board with 8 ports bound to igb_uio module, and no VFIO
configuration, a testpmd run currently fails with:
EAL: cannot open VFIO container!
EAL: :04:00.0 cannot open VFIO container!
EAL: Error - exiting with code: 1
Cause: Requested device :04:00.0 cannot be used
With this patch applied, the problem with VFIO is ignored and testpmd
successfully starts up - with ignored errors with vfio - as below:
EAL: PCI device :04:00.0 on NUMA socket 0
EAL: probe driver: 8086:1521 rte_igb_pmd
EAL: unknown IOMMU driver!
EAL: :04:00.0 cannot open VFIO container!
EAL: :04:00.0 not managed by UIO driver, skipping
<...scan results for other ports skipped...>
EAL: PCI device :8e:00.0 on NUMA socket 1
EAL: probe driver: 8086:154a rte_ixgbe_pmd
EAL: unknown IOMMU driver!
EAL: :8e:00.0 cannot open VFIO container!
EAL: PCI memory mapped at 0x7ff4ff5fa000
EAL: PCI memory mapped at 0x7ff4ff5f6000
EAL: PCI device :8e:00.1 on NUMA socket 1
EAL: probe driver: 8086:154a rte_ixgbe_pmd
EAL: unknown IOMMU driver!
EAL: :8e:00.1 cannot open VFIO container!
EAL: PCI memory mapped at 0x7ff4ff4f6000
EAL: PCI memory mapped at 0x7ff4ff4f2000
Interactive-mode selected
Configuring Port 0 (socket 0)
<...other 7 ports ...>
Checking link statuses...
Port 0 Link Up - speed 1 Mbps - full-duplex
Port 1 Link Down
Port 2 Link Up - speed 1 Mbps - full-duplex
Port 3 Link Down
Port 4 Link Up - speed 1 Mbps - full-duplex
Port 5 Link Down
Port 6 Link Up - speed 1 Mbps - full-duplex
Port 7 Link Down
Done
testpmd>
This issue is introduced by the VFIO patch set addition, specifically
commit ff0b67d1.
Signed-off-by: Bruce Richardson
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
index 4de6061..4af38f6 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
@@ -528,7 +528,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
int vfio_container_fd = pci_vfio_get_container_fd();
if (vfio_container_fd < 0) {
RTE_LOG(ERR, EAL, " %s cannot open VFIO container!\n",
pci_addr);
- return -1;
+ return 1;
}
vfio_cfg.vfio_container_fd = vfio_container_fd;
--
1.9.3
[dpdk-dev] [PATCH] vfio: make container open error non-fatal
The below patch is the quickest fix I found to make my applications work again,
but I'm not sure it's the best solution. Can anyone else offer other
suggestions to improve this?
> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, June 16, 2014 3:29 PM
> To: dev at dpdk.org
> Cc: Richardson, Bruce
> Subject: [PATCH] vfio: make container open error non-fatal
>
> When setting up an app to run using the uio driver, errors caused by
> VFIO failures should not abruptly cause the app to fail.
>
> Example: on a board with 8 ports bound to igb_uio module, and no VFIO
> configuration, a testpmd run currently fails with:
>
> EAL: cannot open VFIO container!
> EAL: :04:00.0 cannot open VFIO container!
> EAL: Error - exiting with code: 1
> Cause: Requested device :04:00.0 cannot be used
>
> With this patch applied, the problem with VFIO is ignored and testpmd
> successfully starts up - with ignored errors with vfio - as below:
>
> EAL: PCI device :04:00.0 on NUMA socket 0
> EAL: probe driver: 8086:1521 rte_igb_pmd
> EAL: unknown IOMMU driver!
> EAL: :04:00.0 cannot open VFIO container!
> EAL: :04:00.0 not managed by UIO driver, skipping
> <...scan results for other ports skipped...>
> EAL: PCI device :8e:00.0 on NUMA socket 1
> EAL: probe driver: 8086:154a rte_ixgbe_pmd
> EAL: unknown IOMMU driver!
> EAL: :8e:00.0 cannot open VFIO container!
> EAL: PCI memory mapped at 0x7ff4ff5fa000
> EAL: PCI memory mapped at 0x7ff4ff5f6000
> EAL: PCI device :8e:00.1 on NUMA socket 1
> EAL: probe driver: 8086:154a rte_ixgbe_pmd
> EAL: unknown IOMMU driver!
> EAL: :8e:00.1 cannot open VFIO container!
> EAL: PCI memory mapped at 0x7ff4ff4f6000
> EAL: PCI memory mapped at 0x7ff4ff4f2000
> Interactive-mode selected
> Configuring Port 0 (socket 0)
> <...other 7 ports ...>
> Checking link statuses...
> Port 0 Link Up - speed 1 Mbps - full-duplex
> Port 1 Link Down
> Port 2 Link Up - speed 1 Mbps - full-duplex
> Port 3 Link Down
> Port 4 Link Up - speed 1 Mbps - full-duplex
> Port 5 Link Down
> Port 6 Link Up - speed 1 Mbps - full-duplex
> Port 7 Link Down
> Done
> testpmd>
>
> This issue is introduced by the VFIO patch set addition, specifically
> commit ff0b67d1.
>
> Signed-off-by: Bruce Richardson
> ---
> lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> index 4de6061..4af38f6 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_vfio.c
> @@ -528,7 +528,7 @@ pci_vfio_map_resource(struct rte_pci_device *dev)
> int vfio_container_fd = pci_vfio_get_container_fd();
> if (vfio_container_fd < 0) {
> RTE_LOG(ERR, EAL, " %s cannot open VFIO
> container!\n", pci_addr);
> - return -1;
> + return 1;
> }
>
> vfio_cfg.vfio_container_fd = vfio_container_fd;
> --
> 1.9.3
[dpdk-dev] [dpdk-stv] [PATCH 0/1] Fix the pointer 'ctx1' uninitialized error with gcc4.5.1
Description: This patch is aimed to fix the the pointer 'ctx1' uninitialized error with gcc4.5.1 as described below. Download dpdk source code from http://dpdk.org, and compile the source code(commit cc333208d5658fea642098b665cd429e6cda54a9). It has the following compilation error on fedora14 with gcc4.5.1 while it is fine on Fedorak20 with gcc4.8.2: "dpdk/lib/librte_kvargs/rte_kvargs.c:51:14: error: 'ctx1' may be used uninitialized in this function" According to the latest DPDK OS Building Test Report(commit:cc333208d5658fea642098b665cd429e6cda54a9, the master branch from http://dpdk.org), this error also occurs on SUSE11SP2_64 with gcc4.5.1, SUSE11SP3_32 with gcc4.5.1 and SUSE11SP3_64 with gcc4.3.4. Initializing the pointer can solve this problem. Signed-off-by: Zhan Zhaochen Acked-by: Liu, Jijiang Tested-by: Waterman Cao Zhan Zhaochen (1): Fix the pointer 'ctx1' uninitialized error with gcc 4.5.1 lib/librte_kvargs/rte_kvargs.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) -- 1.7.3.1
[dpdk-dev] [dpdk-stv] [PATCH 1/1] Fix the pointer 'ctx1' uninitialized error with gcc 4.5.1
Discription: This patch is aimed to fix the the pointer 'ctx1' uninitialized
error with gcc4.5.1 as described below:
"dpdk/lib/librte_kvargs/rte_kvargs.c:51:14: error: 'ctx1' may be used
uninitialized in this function"
Signed-off-by: Zhan Zhaochen
Acked-by: Liu, Jijiang
Tested-by: Waterman Cao
---
lib/librte_kvargs/rte_kvargs.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/lib/librte_kvargs/rte_kvargs.c b/lib/librte_kvargs/rte_kvargs.c
index a7586a3..8bc1e46 100644
--- a/lib/librte_kvargs/rte_kvargs.c
+++ b/lib/librte_kvargs/rte_kvargs.c
@@ -48,7 +48,9 @@ static int
rte_kvargs_tokenize(struct rte_kvargs *kvlist, const char *params)
{
unsigned i;
- char *str, *ctx1, *ctx2;
+ char *str;
+ char *ctx1 = NULL;
+ char *ctx2 = NULL;
/* Copy the const char *params to a modifiable string
* to pass to rte_strsplit
--
1.7.3.1
[dpdk-dev] [dpdk-stv] [PATCH 0/1] Fix the pointer 'ctx1' uninitialized error with gcc4.5.1
Description: This patch is aimed to fix the the pointer 'ctx1' uninitialized error with gcc4.5.1 as described below. Download dpdk source code from http://dpdk.org, and compile the source code(commit cc333208d5658fea642098b665cd429e6cda54a9). It has the following compilation error on fedora14 with gcc4.5.1 while it is fine on Fedorak20 with gcc4.8.2: "dpdk/lib/librte_kvargs/rte_kvargs.c:51:14: error: 'ctx1' may be used uninitialized in this function" According to the latest DPDK OS Building Test Report(commit:cc333208d5658fea642098b665cd429e6cda54a9, the master branch from http://dpdk.org), this error also occurs on SUSE11SP2_64 with gcc4.5.1, SUSE11SP3_32 with gcc4.5.1 and SUSE11SP3_64 with gcc4.3.4. Initializing the pointer can solve this problem. Signed-off-by: Cao Min Acked-by: Liu, Jijiang Tested-by: Waterman Cao Zhan Zhaochen (1): Fix the pointer 'ctx1' uninitialized error with gcc 4.5.1 lib/librte_kvargs/rte_kvargs.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) -- 1.7.3.1
[dpdk-dev] [dpdk-stv] [PATCH 1/1] Fix the pointer 'ctx1' uninitialized error with gcc 4.5.1
Discription: This patch is aimed to fix the the pointer 'ctx1' uninitialized
error with gcc4.5.1 as described below:
"dpdk/lib/librte_kvargs/rte_kvargs.c:51:14: error: 'ctx1' may be used
uninitialized in this function"
Signed-off-by: Cao Min
Acked-by: Liu, Jijiang
Tested-by: Waterman Cao
---
lib/librte_kvargs/rte_kvargs.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/lib/librte_kvargs/rte_kvargs.c b/lib/librte_kvargs/rte_kvargs.c
index a7586a3..8bc1e46 100644
--- a/lib/librte_kvargs/rte_kvargs.c
+++ b/lib/librte_kvargs/rte_kvargs.c
@@ -48,7 +48,9 @@ static int
rte_kvargs_tokenize(struct rte_kvargs *kvlist, const char *params)
{
unsigned i;
- char *str, *ctx1, *ctx2;
+ char *str;
+ char *ctx1 = NULL;
+ char *ctx2 = NULL;
/* Copy the const char *params to a modifiable string
* to pass to rte_strsplit
--
1.7.3.1
[dpdk-dev] l2fwd application - packets not getting forwarded
I can get this working after some changes. 1. I have pci_assign=buses and intel_iommu=on present in grub.conf , Removed them 2. Before running l2fwd application, removed ixgbe driver. I was actually getting some kernel errors without these steps, while running l2fwd application. Now, I can see the packets getting forwarded using l2fwd application and able to observe the packets using tcpdump. Yes, as you said, ping is not getting reply back. but it is getting forwarded to the other end ( observed using tcpdump). Thanks! On Fri, Jun 13, 2014 at 10:39 PM, Richardson, Bruce wrote: >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Raj Ravi >> Sent: Thursday, June 12, 2014 6:35 PM >> To: dev at dpdk.org >> Subject: Re: [dpdk-dev] l2fwd application - packets not getting forwarded >> >> Is there any requirement to modify l2fwd appliucation with updated mac >> address to make it work ? >> >> In one example, it is mentioned something similar. >> www.slideshare.net/hisaki/intel-dpdk-step-by-step-instructions >> >> >> Also, in order to make ping work it is necessary to add static entry >> for those IP addresses ? >> >> Please let me know. Thanks, >> > Hi, > > In terms of using ping: the Intel DPDK works below the IP level, and the > basic l2fwd sample app has no concept of an IP address or what an ICMP ping > message is, so you won't get a proper ping reply out of the application as > there is no IP stack to reply. What it will do, its take the ping message and > forward it out a different port. > > As for the more basic question of receiving packets on the NIC, normally, > yes, you would need to set the destination mac address of your packets to > match that of the NIC port, but in this case I believe the l2fwd app switches > the port to promiscuous mode so it should receive all packets sent to it. > [Other sample apps often need a "-P" flag passed to them to do this.] > > Regards, > /Bruce
[dpdk-dev] [PATCH v4 0/4] NIC filters support for generic filter
--- the v4 patchset changes: --- change the type of rx_queue to uint16_t --- change the parameter of rte_eth_dev_add_syn_filter API --- the v3 patchset changes: --- comments alignment --- the v2 patchset changes: --- add NIC filter support for 82576 --- rework for the whitespace and tab warning if using git apply to apply patch A generic filter mechanism for handling special packet is required. It will allow filters to be set in HW when available so that specific packet may be filtered by NICs to specific descriptor queues for processing. Currently only Flow Director for Intel's 10GbE 82599 devices is available. Other types of filter are not support. NIC filters list below are implemented in this patchset: ethertype filter, syn filter, 2tuple filter and flex filter for 82580 and i350 ethertype filter, syn filter, 5tuple filter for 82576 ethertype filter, syn filter and 5tuple filter for 82599 jingjing.wu (4): ethdev: add ethdev APIs for NIC filters of generic filter e1000: add igb NIC filters of generic filter feature ixgbe: add ixgbe NIC filters of generic filter feature app/test-pmd: add commands in testpmd for NIC filters app/test-pmd/cmdline.c | 909 +++- app/test-pmd/config.c | 147 ++ app/test-pmd/testpmd.h | 5 + lib/librte_ether/rte_ethdev.c | 275 +++ lib/librte_ether/rte_ethdev.h | 428 + lib/librte_pmd_e1000/e1000_ethdev.h | 53 +++ lib/librte_pmd_e1000/igb_ethdev.c | 768 ++ lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 440 + lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 34 ++ 9 files changed, 3058 insertions(+), 1 deletion(-) -- 1.8.1.4
[dpdk-dev] [PATCH v4 4/4] app/test-pmd: add commands in testpmd for NIC filters
add commands in testpmd for NIC filters:
add_ethertype_filter
remove_ethertype_filter
get_ethertype_filter
add_2tuple_filter
remove_2tuple_filter
get_2tuple_filter
add_5tuple_filter
remove_5tuple_filter
get_5tuple_filter
add_syn_filter
remove_syn_filter
get_syn_filter
add_flex_filter
remove_flex_filter
get_flex_filter
Signed-off-by: jingjing.wu
---
app/test-pmd/cmdline.c | 909 -
app/test-pmd/config.c | 147
app/test-pmd/testpmd.h | 5 +
3 files changed, 1060 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 4678977..8065836 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -113,6 +113,7 @@ static void cmd_help_brief_parsed(__attribute__((unused))
void *parsed_result,
"help ports : Configuring ports.\n"
"help flowdir: Flow Director filter help.\n"
"help registers : Reading and setting port registers.\n"
+ "help filters: Filters configuration help.\n"
"help all: All of the above sections.\n\n"
);
@@ -554,6 +555,67 @@ static void cmd_help_long_parsed(void *parsed_result,
"Set single bit value of a port register.\n\n"
);
}
+ if (show_all || !strcmp(res->section, "filters")) {
+
+ cmdline_printf(
+ cl,
+ "\n"
+ "filters:\n"
+ "--\n\n"
+
+ "add_ethertype_filter (port_id) ethertype (eth_value)"
+ " priority (enable|disable)(pri_value) queue (queue_id)
index (idx)\n"
+ "add an ethertype filter.\n\n"
+
+ "remove_ethertype_filter (port_id) index (idx)\n"
+ "remove an ethertype filter.\n\n"
+
+ "get_ethertype_filter (port_id) index (idx)\n"
+ "get info of a ethertype filter.\n\n"
+
+ "add_2tuple_filter (port_id) protocol (pro_value)
(pro_mask)"
+ " dst_port (port_value) (port_mask) flags (flg_value)
priority (prio_value)"
+ " queue (queue_id) index (idx)\n"
+ "add a 2tuple filter.\n\n"
+
+ "remove_2tuple_filter (port_id) index (idx)\n"
+ "remove a 2tuple filter.\n\n"
+
+ "get_2tuple_filter (port_id) index (idx)\n"
+ "get info of a 2tuple filter.\n\n"
+
+ "add_5tuple_filter (port_id) dst_ip (dst_address)
src_ip (src_address)"
+ " dst_port (dst_port_value) src_port (src_port_value)
protocol (protocol_value)"
+ " mask (mask_value) flags (flags_value) priority
(prio_value)"
+ " queue (queue_id) index (idx)\n"
+ "add a 5tuple filter.\n\n"
+
+ "remove_5tuple_filter (port_id) index (idx)\n"
+ "remove a 5tuple filter.\n\n"
+
+ "get_5tuple_filter (port_id) index (idx)\n"
+ "get info of a 5tuple filter.\n\n"
+
+ "add_syn_filter (port_id) priority (high|low) queue
(queue_id)"
+ "add syn filter.\n\n"
+
+ "remove_syn_filter (port_id)"
+ "remove syn filter.\n\n"
+
+ "get_syn_filter (port_id) "
+ "get syn filter info.\n\n"
+
+ "add_flex_filter (port_id) len (len_value) bytes
(bytes_string) mask (mask_value)"
+ " priority (prio_value) queue (queue_id) index (idx)\n"
+ "add a flex filter.\n\n"
+
+ "remove_flex_filter (port_id) index (idx)\n"
+ "remove a flex filter.\n\n"
+
+ "get_flex_filter (port_id) index (idx)\n"
+ "get info of a flex filter.\n\n"
+ );
+ }
}
cmdline_parse_token_string_t cmd_help_long_help =
@@ -562,7 +624,7 @@ cmdline_parse_token_string_t cmd_help_long_help =
cmdline_parse_token_string_t cmd_help_long_section =
TOKEN_STRING_INITIALIZER(struct cmd_help_long_result, section,
"all#control#display#config#flowdir#"
- "ports#registers");
+ "ports#registers#filters");
cmdline_parse_inst_t cmd_help_long = {
.f = cmd_help_long_parsed,
@@ -5534,6 +5596,836 @@ cmdline_parse_inst_t cmd_dump_one = {
},
};
+/* *** ADD/REMOVE an ethertype FILTER *** */
+struct cmd_ethertype_filter_result {
+ cmdline_fixed_string_t filter;
+ uint8_t port_id;
+ cmdline_fixed_string_t ethertype;
+ uint16_t ethertype_value;
[dpdk-dev] [PATCH v4 1/4] ethdev: add ethdev APIs for NIC filters of generic filter
This patch adds APIs for NIC filters list below:
ethertype filter, syn filter, 2tuple filter, flex filter, 5tuple filter
Signed-off-by: jingjing.wu
---
lib/librte_ether/rte_ethdev.c | 275 +++
lib/librte_ether/rte_ethdev.h | 428 ++
2 files changed, 703 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 8011b8b..42333ee 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2606,3 +2607,277 @@ rte_eth_dev_bypass_wd_reset(uint8_t port_id)
return 0;
}
#endif
+
+int
+rte_eth_dev_add_syn_filter(uint8_t port_id,
+ struct rte_syn_filter *filter, uint16_t rx_queue)
+{
+ struct rte_eth_dev *dev;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -ENODEV;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->add_syn_filter, -ENOTSUP);
+ return (*dev->dev_ops->add_syn_filter)(dev, filter, rx_queue);
+}
+
+int
+rte_eth_dev_remove_syn_filter(uint8_t port_id)
+{
+ struct rte_eth_dev *dev;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -ENODEV;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->remove_syn_filter, -ENOTSUP);
+ return (*dev->dev_ops->remove_syn_filter)(dev);
+}
+
+int
+rte_eth_dev_get_syn_filter(uint8_t port_id,
+ struct rte_syn_filter *filter, uint16_t *rx_queue)
+{
+ struct rte_eth_dev *dev;
+
+ if (filter == NULL || rx_queue == NULL)
+ return -EINVAL;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -ENODEV;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_syn_filter, -ENOTSUP);
+ return (*dev->dev_ops->get_syn_filter)(dev, filter, rx_queue);
+}
+
+int
+rte_eth_dev_add_ethertype_filter(uint8_t port_id, uint16_t index,
+ struct rte_ethertype_filter *filter, uint16_t rx_queue)
+{
+ struct rte_eth_dev *dev;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -ENODEV;
+ }
+ if (filter->ethertype == ETHER_TYPE_IPv4 ||
+ filter->ethertype == ETHER_TYPE_IPv6){
+ PMD_DEBUG_TRACE("IP and IPv6 are not supported"
+ " in ethertype filter\n");
+ return -EINVAL;
+ }
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->add_ethertype_filter, -ENOTSUP);
+ return (*dev->dev_ops->add_ethertype_filter)(dev, index,
+ filter, rx_queue);
+}
+
+int
+rte_eth_dev_remove_ethertype_filter(uint8_t port_id, uint16_t index)
+{
+ struct rte_eth_dev *dev;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -ENODEV;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->remove_ethertype_filter, -ENOTSUP);
+ return (*dev->dev_ops->remove_ethertype_filter)(dev, index);
+}
+
+int
+rte_eth_dev_get_ethertype_filter(uint8_t port_id, uint16_t index,
+ struct rte_ethertype_filter *filter, uint16_t *rx_queue)
+{
+ struct rte_eth_dev *dev;
+
+ if (filter == NULL || rx_queue == NULL)
+ return -EINVAL;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -ENODEV;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_ethertype_filter, -ENOTSUP);
+ return (*dev->dev_ops->get_ethertype_filter)(dev, index,
+ filter, rx_queue);
+}
+
+int
+rte_eth_dev_add_2tuple_filter(uint8_t port_id, uint16_t index,
+ struct rte_2tuple_filter *filter, uint16_t rx_queue)
+{
+ struct rte_eth_dev *dev;
+
+ if (port_id >= nb_ports) {
+ PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id);
+ return -ENODEV;
+ }
+ if (filter->protocol != IPPROTO_TCP &&
+ filter->tcp_flags != 0){
+ PMD_DEBUG_TRACE("tcp flags is 0x%x, but the protocol value"
+ " is not TCP\n",
+ filter->tcp_flags);
+ return -EINVAL;
+ }
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->add_2tuple_filter, -ENOTSUP);
+ return (*dev->dev_ops->add_2tuple_filter)(dev, index, filter, rx_queue);
+}
+
+int
+rte_eth_dev_remove_2tuple
[dpdk-dev] [PATCH v4 2/4] e1000: add igb NIC filters of generic filter feature
This patch adds following igb NIC filters implement:
syn filter, ethertype filter, 2tuple filter, flex filter for intel NIC 82580
and i350
syn filter, ethertype filter, 5tuple filter for intel NIC 82576
Signed-off-by: jingjing.wu
---
lib/librte_pmd_e1000/e1000_ethdev.h | 53 +++
lib/librte_pmd_e1000/igb_ethdev.c | 768
2 files changed, 821 insertions(+)
diff --git a/lib/librte_pmd_e1000/e1000_ethdev.h
b/lib/librte_pmd_e1000/e1000_ethdev.h
index a287f40..71eb5fb 100644
--- a/lib/librte_pmd_e1000/e1000_ethdev.h
+++ b/lib/librte_pmd_e1000/e1000_ethdev.h
@@ -52,6 +52,59 @@
#define E1000_CTRL_EXT_EXTEND_VLAN (1<<26)/* EXTENDED VLAN */
#define IGB_VFTA_SIZE 128
+#define IGB_MAX_RX_QUEUE_NUM 8
+#define IGB_MAX_RX_QUEUE_NUM_82576 16
+
+#define E1000_SYN_FILTER_ENABLE0x0001 /* syn filter enable field */
+#define E1000_SYN_FILTER_QUEUE 0x000E /* syn filter queue field */
+#define E1000_SYN_FILTER_QUEUE_SHIFT 1 /* syn filter queue field */
+#define E1000_RFCTL_SYNQFP 0x0008 /* SYNQFP in RFCTL register
*/
+
+#define E1000_ETQF_ETHERTYPE 0x
+#define E1000_ETQF_QUEUE 0x0007
+#define E1000_ETQF_QUEUE_SHIFT 16
+#define E1000_MAX_ETQF_FILTERS 8
+
+#define E1000_IMIR_DSTPORT 0x
+#define E1000_IMIR_PRIORITY0xE000
+#define E1000_IMIR_EXT_SIZE_BP 0x1000
+#define E1000_IMIR_EXT_CTRL_UGR0x2000
+#define E1000_IMIR_EXT_CTRL_ACK0x4000
+#define E1000_IMIR_EXT_CTRL_PSH0x8000
+#define E1000_IMIR_EXT_CTRL_RST0x0001
+#define E1000_IMIR_EXT_CTRL_SYN0x0002
+#define E1000_IMIR_EXT_CTRL_FIN0x0004
+#define E1000_IMIR_EXT_CTRL_BP 0x0008
+#define E1000_MAX_TTQF_FILTERS 8
+#define E1000_2TUPLE_MAX_PRI 7
+
+#define E1000_MAX_FLEXIBLE_FILTERS 8
+#define E1000_MAX_FHFT 4
+#define E1000_MAX_FHFT_EXT 4
+#define E1000_MAX_FLEX_FILTER_PRI7
+#define E1000_MAX_FLEX_FILTER_LEN128
+#define E1000_FHFT_QUEUEING_LEN 0x007F
+#define E1000_FHFT_QUEUEING_QUEUE0x0700
+#define E1000_FHFT_QUEUEING_PRIO 0x0007
+#define E1000_FHFT_QUEUEING_OFFSET 0xFC
+#define E1000_FHFT_QUEUEING_QUEUE_SHIFT 8
+#define E1000_FHFT_QUEUEING_PRIO_SHIFT 16
+#define E1000_WUFC_FLEX_HQ 0x4000
+
+#define E1000_SPQF_SRCPORT 0x
+
+#define E1000_MAX_FTQF_FILTERS 8
+#define E1000_FTQF_PROTOCOL_MASK 0x00FF
+#define E1000_FTQF_5TUPLE_MASK_SHIFT 28
+#define E1000_FTQF_PROTOCOL_COMP_MASK0x1000
+#define E1000_FTQF_SOURCE_ADDR_MASK 0x2000
+#define E1000_FTQF_DEST_ADDR_MASK0x4000
+#define E1000_FTQF_SOURCE_PORT_MASK 0x8000
+#define E1000_FTQF_VF_MASK_EN0x8000
+#define E1000_FTQF_QUEUE_MASK0x03ff
+#define E1000_FTQF_QUEUE_SHIFT 16
+#define E1000_FTQF_QUEUE_ENABLE 0x0100
+
/* structure for interrupt relative data */
struct e1000_interrupt {
uint32_t flags;
diff --git a/lib/librte_pmd_e1000/igb_ethdev.c
b/lib/librte_pmd_e1000/igb_ethdev.c
index 6e835c3..343a78c 100644
--- a/lib/librte_pmd_e1000/igb_ethdev.c
+++ b/lib/librte_pmd_e1000/igb_ethdev.c
@@ -124,6 +124,44 @@ static int eth_igb_rss_reta_update(struct rte_eth_dev *dev,
static int eth_igb_rss_reta_query(struct rte_eth_dev *dev,
struct rte_eth_rss_reta *reta_conf);
+static int eth_igb_add_syn_filter(struct rte_eth_dev *dev,
+ struct rte_syn_filter *filter, uint16_t rx_queue);
+static int eth_igb_remove_syn_filter(struct rte_eth_dev *dev);
+static int eth_igb_get_syn_filter(struct rte_eth_dev *dev,
+ struct rte_syn_filter *filter, uint16_t *rx_queue);
+static int eth_igb_add_ethertype_filter(struct rte_eth_dev *dev,
+ uint16_t index,
+ struct rte_ethertype_filter *filter, uint16_t rx_queue);
+static int eth_igb_remove_ethertype_filter(struct rte_eth_dev *dev,
+ uint16_t index);
+static int eth_igb_get_ethertype_filter(struct rte_eth_dev *dev,
+ uint16_t index,
+ struct rte_ethertype_filter *filter, uint16_t
*rx_queue);
+static int eth_igb_add_2tuple_filter(struct rte_eth_dev *dev,
+ uint16_t index,
+ struct rte_2tuple_filter *filter, uint16_t rx_queue);
+static int eth_igb_remove_2tuple_filter(struct rte_eth_dev *dev,
+ uint16_t index);
+static int eth_igb_get_2tuple_filter(struct rte_eth_dev *dev,
+ uint16_t index,
+ struct rte_2tuple_filter *filter, uint16_t *rx_queue);
+static int eth_igb_add_flex_filter(struct rte_eth_dev *dev,
+ uint16_t index,
+
[dpdk-dev] [PATCH v4 3/4] ixgbe: add ixgbe NIC filters of generic filter feature
This patch adds following ixgbe NIC filters implement:
syn filter, ethertype filter, 5tuple filter for intel NIC 82599
Signed-off-by: jingjing.wu
---
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 440
lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 34 +++
2 files changed, 474 insertions(+)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
index 10e5633..ed34386 100644
--- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
+++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -196,6 +197,23 @@ static void ixgbevf_add_mac_addr(struct rte_eth_dev *dev,
struct ether_addr *mac_addr,
uint32_t index, uint32_t pool);
static void ixgbevf_remove_mac_addr(struct rte_eth_dev *dev, uint32_t index);
+static int ixgbe_add_syn_filter(struct rte_eth_dev *dev,
+ struct rte_syn_filter *filter, uint16_t rx_queue);
+static int ixgbe_remove_syn_filter(struct rte_eth_dev *dev);
+static int ixgbe_get_syn_filter(struct rte_eth_dev *dev,
+ struct rte_syn_filter *filter, uint16_t *rx_queue);
+static int ixgbe_add_ethertype_filter(struct rte_eth_dev *dev, uint16_t index,
+ struct rte_ethertype_filter *filter, uint16_t rx_queue);
+static int ixgbe_remove_ethertype_filter(struct rte_eth_dev *dev,
+ uint16_t index);
+static int ixgbe_get_ethertype_filter(struct rte_eth_dev *dev, uint16_t index,
+ struct rte_ethertype_filter *filter, uint16_t
*rx_queue);
+static int ixgbe_add_5tuple_filter(struct rte_eth_dev *dev, uint16_t index,
+ struct rte_5tuple_filter *filter, uint16_t rx_queue);
+static int ixgbe_remove_5tuple_filter(struct rte_eth_dev *dev,
+ uint16_t index);
+static int ixgbe_get_5tuple_filter(struct rte_eth_dev *dev, uint16_t index,
+ struct rte_5tuple_filter *filter, uint16_t *rx_queue);
/*
* Define VF Stats MACRO for Non "cleared on read" register
@@ -326,6 +344,15 @@ static struct eth_dev_ops ixgbe_eth_dev_ops = {
#endif /* RTE_NIC_BYPASS */
.rss_hash_update = ixgbe_dev_rss_hash_update,
.rss_hash_conf_get= ixgbe_dev_rss_hash_conf_get,
+ .add_syn_filter = ixgbe_add_syn_filter,
+ .remove_syn_filter = ixgbe_remove_syn_filter,
+ .get_syn_filter = ixgbe_get_syn_filter,
+ .add_ethertype_filter= ixgbe_add_ethertype_filter,
+ .remove_ethertype_filter = ixgbe_remove_ethertype_filter,
+ .get_ethertype_filter= ixgbe_get_ethertype_filter,
+ .add_5tuple_filter = ixgbe_add_5tuple_filter,
+ .remove_5tuple_filter= ixgbe_remove_5tuple_filter,
+ .get_5tuple_filter = ixgbe_get_5tuple_filter,
};
/*
@@ -3388,6 +3415,419 @@ ixgbevf_remove_mac_addr(struct rte_eth_dev *dev,
uint32_t index)
}
}
+/*
+ * add syn filter
+ *
+ * @param
+ * dev: Pointer to struct rte_eth_dev.
+ * filter: ponter to the filter that will be added.
+ * rx_queue: the queue id the filter assigned to.
+ *
+ * @return
+ *- On success, zero.
+ *- On failure, a negative value.
+ */
+static int
+ixgbe_add_syn_filter(struct rte_eth_dev *dev,
+ struct rte_syn_filter *filter, uint16_t rx_queue)
+{
+ struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ uint32_t synqf;
+
+ if (hw->mac.type != ixgbe_mac_82599EB)
+ return -ENOSYS;
+
+ if (rx_queue >= IXGBE_MAX_RX_QUEUE_NUM)
+ return -EINVAL;
+
+ synqf = IXGBE_READ_REG(hw, IXGBE_SYNQF);
+
+ if (synqf & IXGBE_SYN_FILTER_ENABLE)
+ return -EINVAL;
+
+ synqf = (uint32_t)(((rx_queue << IXGBE_SYN_FILTER_QUEUE_SHIFT) &
+ IXGBE_SYN_FILTER_QUEUE) | IXGBE_SYN_FILTER_ENABLE);
+
+ if (filter->hig_pri)
+ synqf |= IXGBE_SYN_FILTER_SYNQFP;
+ else
+ synqf &= ~IXGBE_SYN_FILTER_SYNQFP;
+
+ IXGBE_WRITE_REG(hw, IXGBE_SYNQF, synqf);
+ return 0;
+}
+
+/*
+ * remove syn filter
+ *
+ * @param
+ * dev: Pointer to struct rte_eth_dev.
+ *
+ * @return
+ *- On success, zero.
+ *- On failure, a negative value.
+ */
+static int
+ixgbe_remove_syn_filter(struct rte_eth_dev *dev)
+{
+ struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
+ uint32_t synqf;
+
+ if (hw->mac.type != ixgbe_mac_82599EB)
+ return -ENOSYS;
+
+ synqf = IXGBE_READ_REG(hw, IXGBE_SYNQF);
+
+ synqf &= ~(IXGBE_SYN_FILTER_QUEUE | IXGBE_SYN_FILTER_ENABLE);
+
+ IXGBE_WRITE_REG(hw, IXGBE_SYNQF, synqf);
+ return 0;
+}
+
+
+/*
+ * get the syn filter's info
+ *
+ * @param
+ * dev: Pointer to struct rte_eth_dev.
+ * filter: ponter to the filter that returns.
+ * *rx_queue: pointer to the queue id the filter assigned to
[dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes)
> -Original Message- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > Sent: Friday, June 13, 2014 10:59 PM > To: Doherty, Declan > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library > (librte_eal/librte_ether link bonding support changes) > > On Fri, 13 Jun 2014 15:41:59 +0100 > Declan Doherty wrote: > > > Updating functionality in EAL to support adding link bonding > > devices via ???vdev option. Link bonding devices will be > > initialized after all physical devices have been probed and > > initialized. > > > > Signed-off-by: Declan Doherty > > The DPDK is used by both static (demo style) applications and dynamic > applications that need to be able to modify parameters while running. > The tendency of the code has been to have values that can only be set > at initialization, and this kind of inflexibility is hard to fix. > > The whole dev args style of configuration is a poor design for those > reasons. How do you support creating additional bond devices at runtime? > > Remember what works for a demo doesn't make a good API for real world. > > Hi Stephen, I totally agree but all of the dev argument parsing / static initialization here is based on the rte_eth_bond.h public API. Actually testpmd has full support for dynamic initialization and management of bonding devices in run-time through the interactive command line options which pretty much have options corresponding to all of the public link bonding APIs. It is my intent that this would main interface that this API would be used by user applications and that the static configuration options using --vdev interface would only be used if a user wanted to use a bonded device in a existing application without having to make any changes to their code or add any explicit reference to the link bonding library.
[dpdk-dev] mmap() hint address
Hi Bruce, Stephen, > > Hello, > > > > I have seen a case where a secondary DPDK process tries to map uio > > resource in which mmap() normally sends the corresponding virtual > > address as a hint address. However on some instances mmap() returns a > > virtual address that is not the hint address, and it result in > > rte_panic() and the secondary process goes defunct. > > > > This happens from time to time on an embedded device when > nr_hugepages is > > set to 128, but never when nr_hugepage is set to 256 on the same device. > My > > question is, if mmap() can find the correct memory regions when > > hugepages is set to 256, would it not require less resources (and > > therefore be more likely to > > pass) at a lower value such as 128? > > > > Any ideas what would cause this mmap() behavior at a lower nr_hugepage > > value? > > > > - Stephen > > Hi Stephen, > > That's a strange one! > I don't know for definite why this is happening, but here is one possible > theory. :-) > > It could be due to the size of the memory blocks that are getting mmapped. > When you use 256 pages, the blocks of memory getting mapped may well be > larger (depending on how fragmented in memory the 2MB pages are), and > so may be getting mapped at a higher set of address ranges where there is > more free memory. This set of address ranges is then free in the secondary > process and it is similarly able to map the memory. > With the 128 hugepages, you may be looking for smaller amounts of memory > and so the addresses get mapped in at a different spot in the virtual address > space, one that may be more heavily used. Then when the secondary > process tries to duplicate the mappings, it already has memory in that region > in use and the mapping fails. > In short - one theory is that having bigger blocks to map causes the memory > to be mapped to a different location in memory which is free from conflicts in > the secondary process. > > So, how to confirm or refute this, and generally debug this issue? > Well, in general we would need to look at the messages printed out at > startup in the primary process to see how big of blocks it is trying to map in > each case, and where they end up in the virtual address-space. As I remember, OVDK project has had vaguely similar issues (only they were trying to map hugepages into the space that QEMU has already occupied). This resulted in us adding a --base-virtaddr EAL command-line flag that would specify the start virtual address where primary process would start mapping pages. I guess you can try that as well (just remember that it needs to be done in the primary process, because the secondary one just copies the mappings and succeeds or fails to do so). Best regards, Anatoly Burakov DPDK SW Engineer
[dpdk-dev] [PATCH v2 09/10] igbuio: show irq mode in sysfs
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Wednesday, June 11, 2014 9:08 PM
> To: Carew, Alan
> Cc: Neil Horman; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 09/10] igbuio: show irq mode in sysfs
>
> This is what I am testing, along with 10 other virtio patches.
>
> Subject: virtio: check for using msix interrupt
>
> Fix how the device driver detects MSI-X vs INTX mode.
> Look in sysfs to find if MSI-X is enabled.
>
> Suggested-by: Neil Horman
> Signed-off-by: Stephen Hemminger
>
>
> --- a/lib/librte_pmd_virtio/virtio_ethdev.c
> +++ b/lib/librte_pmd_virtio/virtio_ethdev.c
> @@ -709,6 +709,28 @@
> return 0;
> }
>
> +/*
> + * Detect if using INTX or MSI-X by looking for:
> + * /sys/bus/pci/devices//msi_irqs/
> + * if directory exists, must be using msi-x
> + */
> +static int
> +has_msix(const struct rte_pci_addr *loc)
> +{
> + DIR *d;
> + char dirname[PATH_MAX];
> +
> + rte_snprintf(dirname, sizeof(dirname),
> + SYSFS_PCI_DEVICES "/" PCI_PRI_FMT "/msi_irqs",
> + loc->domain, loc->bus, loc->devid, loc->function);
> +
> + d = opendir(dirname);
> + if (d)
> + closedir(d);
> +
> + return (d != NULL);
> +}
> +
> static int get_uio_dev(struct rte_pci_addr *loc, char *buf, unsigned int
> buflen)
> {
> unsigned int uio_num;
> @@ -872,6 +894,8 @@
> PMD_INIT_LOG(DEBUG,
>"PCI Port IO found start=0x%lx with size=0x%lx\n",
>start, size);
> +
> + hw->use_msix = has_msix(&pci_dev->addr);
> }
> #endif
> hw->io_base = (uint32_t)(uintptr_t)pci_dev->mem_resource[0].addr;
> --- a/lib/librte_pmd_virtio/virtio_pci.h
> +++ b/lib/librte_pmd_virtio/virtio_pci.h
> @@ -177,6 +177,7 @@
> uint16_tsubsystem_device_id;
> uint16_tsubsystem_vendor_id;
> uint8_t revision_id;
> + uint8_t use_msix;
> uint8_t mac_addr[ETHER_ADDR_LEN];
> int adapter_stopped;
> };
> @@ -194,13 +195,11 @@
> uint16_t max_virtqueue_pairs;
> } __attribute__((packed));
>
> -/* Value indicated in device config */
> -#define VIRTIO_PCI_FLAG_MSIX 0x0020
> /*
> * The remaining space is defined by each driver as the per-driver
> * configuration space.
> */
> -#define VIRTIO_PCI_CONFIG(hw) (((hw)->guest_features &
> VIRTIO_PCI_FLAG_MSIX) ? 24 : 20)
> +#define VIRTIO_PCI_CONFIG(hw) (((hw)->use_msix) ? 24 : 20)
>
> /*
> * How many bits to shift physical queue address written to QUEUE_PFN.
Hi Stephen,
The mechanism is fine, however I would be against OS specific code in
abstracted drivers. If "has_msix" was a helper function in eal (and suitably
renamed) we could then add a FreeBSD equivalent implementation. A less
favourable solution would be conditional
compilation(RTE_EXEC_ENV_LINUXAPP/BSDPAPP) around the above function.
Thanks,
Alan
[dpdk-dev] [PATCH v3] 10G PMD: New vectorized functions for RX/TX
2014-06-13 23:52, Bruce Richardson: > New file containing optimized receive and transmit functions which > use 128bit vector instructions to improve performance. When conditions > permit, these functions will be enabled at runtime by the device > initialization routines already in the PMD. > > The compilation of the vectorized RX and TX code paths is controlled by > a new setting in the build time configuration for the IXGBE driver. Also > added is a setting which allows an optional further performance increase > by disabling the use of the olflags field on packet RX. Acked-by: Thomas Monjalon I've adjusted code for 2 "ASSIGN_IN_IF" checkpatch errors and applied for version 1.7.0. Thanks -- Thomas
[dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes)
> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Friday, June 13, 2014 8:38 PM
> To: Doherty, Declan
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library
> (librte_eal/librte_ether link bonding support changes)
>
> On Fri, Jun 13, 2014 at 06:34:04PM +, Doherty, Declan wrote:
> > > -Original Message-
> > > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > Sent: Friday, June 13, 2014 5:08 PM
> > > To: Doherty, Declan
> > > Cc: dev at dpdk.org
> > > Subject: Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library
> > > (librte_eal/librte_ether link bonding support changes)
> > >
> > > On Fri, Jun 13, 2014 at 03:41:59PM +0100, Declan Doherty wrote:
> > > > Updating functionality in EAL to support adding link bonding
> > > > devices via ?vdev option. Link bonding devices will be
> > > > initialized after all physical devices have been probed and
> > > > initialized.
> > > >
> > > > Signed-off-by: Declan Doherty
> > > > ---
> > > > lib/librte_eal/common/eal_common_dev.c | 66
> > > +++--
> > > > lib/librte_eal/common/eal_common_pci.c | 6 +++
> > > > lib/librte_eal/common/include/eal_private.h | 7 +++
> > > > lib/librte_eal/common/include/rte_dev.h | 1 +
> > > > lib/librte_ether/rte_ethdev.c | 34 +--
> > > > lib/librte_ether/rte_ethdev.h | 7 ++-
> > > > lib/librte_pmd_pcap/rte_eth_pcap.c | 22 +-
> > > > lib/librte_pmd_ring/rte_eth_ring.c | 32 +++---
> > > > lib/librte_pmd_ring/rte_eth_ring.h | 3 +-
> > > > lib/librte_pmd_xenvirt/rte_eth_xenvirt.c| 2 +-
> > > > 10 files changed, 144 insertions(+), 36 deletions(-)
> > > >
> > > > diff --git a/lib/librte_eal/common/eal_common_dev.c
> > > b/lib/librte_eal/common/eal_common_dev.c
> > > > index eae5656..b50c908 100644
> > > > --- a/lib/librte_eal/common/eal_common_dev.c
> > > > +++ b/lib/librte_eal/common/eal_common_dev.c
> > > > @@ -75,14 +75,28 @@ rte_eal_dev_init(void)
> > > >
> > > > /* call the init function for each virtual device */
> > > > TAILQ_FOREACH(devargs, &devargs_list, next) {
> > > > + uint8_t bdev = 0;
> > > >
> > > > if (devargs->type != RTE_DEVTYPE_VIRTUAL)
> > > > continue;
> > > >
> > > > TAILQ_FOREACH(driver, &dev_driver_list, next) {
> > > > - if (driver->type != PMD_VDEV)
> > > > + /* RTE_DEVTYPE_VIRTUAL can only be a virtual or
> > > > bonded
> > > device*/
> > > > + if (driver->type != PMD_VDEV && driver->type !=
> > > PMD_BDEV)
> > > > continue;
> > > >
> > > > + /*
> > > > +* Bonded devices are not initialize here, we
> > > > do it later in
> > > > +* rte_eal_bonded_dev_init() after all physical
> > > > devices
> > > have been
> > > > +* probed and initialized
> > > > +*/
> > > > + if (driver->type == PMD_BDEV &&
> > > > + !strncmp(driver->name, devargs-
> > > >virtual.drv_name,
> > > > +
> > > > strlen(driver->name))) {
> > > > + bdev = 1;
> > > > + break;
> > > > + }
> > > > +
> > > I really don't think you need to add a new device type for bonded devs.
> > > Its got
> > > no specific hardware that it drives, and you configure it with a --vdev
> command,
> > > so treat it as one here. I understand that you need to pass additional
> > > information about slaves to a bonded device, which is fine, but you can
> > > do that
> > > with kvargs pretty easily, at which point its just another vdev. The only
> > > other
> > > requirement is that you initilize the bonded vdev after the slave vdevs
> > > have
> > > been created, which you can do by any of several methods (a priority
> > > field to
> > > indicate that bonded drivers should be initilized last/later, a deferral
> > > return
> > > code from the init routine, or by dead reckoning via the careful
> > > construction
> of
> > > the application command line (placed the bonded --vdev option last on the
> > > command line argument list at run time).
> > >
> > It was my initial intent to do as you have describe above, but the physical
> > devices
> > cause a real issue here, physical devices don't call through to
> rte_eth_dev_allocate until
> > during rte_eal_pci_probe call, so it's not possible to initialize the
> > bonded device
> from
> > within rte_eal_dev_init as the physical devices have not been fully
> > initialized at
> this
> > point, as a port_id has not been allocated and can't be added as bonding
> > slaves. I
> don't
> > see away around this
[dpdk-dev] [PATCH v6 00/20] Add VFIO support to DPDK
Hi Anatoly, The signed-off-by line disappeared from v6 patches. I assume to be Signed-off-by: Anatoly Burakov Please confirm. -- Thomas
[dpdk-dev] [PATCH v6 00/20] Add VFIO support to DPDK
Hi Thomas, > The signed-off-by line disappeared from v6 patches. > I assume to be > Signed-off-by: Anatoly Burakov Please > confirm. Yes, sorry about that, was having a rather long day :-( Both VFIO and tailq patches assume signoff. Best regards, Anatoly Burakov DPDK SW Engineer
[dpdk-dev] [PATCH 0/4] librte_pmd_virtio :Fix: virtio_pci.h non-existent virtio feature bit-flag tested
> -Original Message- > From: Carew, Alan > Sent: Thursday, June 05, 2014 3:39 PM > To: dev at dpdk.org > Cc: Carew, Alan > Subject: [PATCH 0/4] librte_pmd_virtio :Fix: virtio_pci.h non-existent virtio > feature bit-flag tested > > This series addresses an issue with librte_pmd_virtio where the offset to the > virtio device specific header may be incorrect depending on whether MSI-X has > been enabled or not. > > If MSI-X is configured the device specific header is placed at byte offset 24 > relative to the IO base address. > If MSI-X is not configured the device specific header is placed at > byte offset 20. > > The following macro defined in virtio_pci.h is used to test the > presence of the MSI-X header and determine the correct offset: > #define VIRTIO_PCI_CONFIG(hw) (((hw)->guest_features & > VIRTIO_PCI_FLAG_MSIX) ? 24 : 20) > > However, VIRTIO_PCI_FLAG_MSIX is not a guest_feature nor is it part of the > Virtio Specification and resolves to the VIRTIO_NET_F_MAC feature as both > are #defined as 0x20. > > VIRTIO_PCI_FLAG_MSIX or similar flag should instead be set by the kernel > driver allocating resources and passed to user space for testing. > i.e. > #define VIRTIO_PCI_CONFIG(hw) (((hw)->intr_mode & > IGBUIO_MSIX_INTR_MODE) ? 24 : 20) > > To enable this testing of interrupt mode, this series allows for the kernel > driver(igb_uio) to place the configured interrupt mode into a sysfs entry. > sysfs is then parsed by eal_pci to determine the configured mode, which > allows all user space devices to correctly determine the interrupt mode, > including virtio_ethdev. > > This series should be applied prior to Anatoly Burakov's > [VFIO] Add VFIO support to DPDK series > > Alan Carew (4): > igb_uio: Add interrupt_mode sysfs entry for igb_uio devices > eal_pci: Add interrupt mode to rte_pci_device and parsing to eal_pci > FreeBSD: Adds the equivalent interrupt mode setting and parsing > virtio: Fixes the VIRTIO_PCI_CONFIG macro to use the correct offset > to the Virtio header > > lib/librte_eal/bsdapp/eal/eal_pci.c| 44 ++ > lib/librte_eal/bsdapp/nic_uio/nic_uio.c| 14 +++ > lib/librte_eal/common/Makefile |1 + > lib/librte_eal/common/include/rte_pci.h|2 + > .../common/include/rte_pci_dev_feature_defs.h | 85 > > .../common/include/rte_pci_dev_features.h | 70 > lib/librte_eal/linuxapp/eal/eal_pci.c | 78 ++ > lib/librte_eal/linuxapp/igb_uio/igb_uio.c | 48 +--- > lib/librte_pmd_virtio/virtio_ethdev.c |1 + > lib/librte_pmd_virtio/virtio_pci.h |4 +- > 10 files changed, 336 insertions(+), 11 deletions(-) > create mode 100755 > lib/librte_eal/common/include/rte_pci_dev_feature_defs.h > create mode 100755 lib/librte_eal/common/include/rte_pci_dev_features.h Self NAK, alternative approach and patch set to follow.
[dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library (librte_eal/librte_ether link bonding support changes)
On Mon, Jun 16, 2014 at 08:59:25AM +, Doherty, Declan wrote:
> > -Original Message-
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Friday, June 13, 2014 8:38 PM
> > To: Doherty, Declan
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library
> > (librte_eal/librte_ether link bonding support changes)
> >
> > On Fri, Jun 13, 2014 at 06:34:04PM +, Doherty, Declan wrote:
> > > > -Original Message-
> > > > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > > Sent: Friday, June 13, 2014 5:08 PM
> > > > To: Doherty, Declan
> > > > Cc: dev at dpdk.org
> > > > Subject: Re: [dpdk-dev] [PATCH v3 2/5] Link Bonding PMD Library
> > > > (librte_eal/librte_ether link bonding support changes)
> > > >
> > > > On Fri, Jun 13, 2014 at 03:41:59PM +0100, Declan Doherty wrote:
> > > > > Updating functionality in EAL to support adding link bonding
> > > > > devices via ?vdev option. Link bonding devices will be
> > > > > initialized after all physical devices have been probed and
> > > > > initialized.
> > > > >
> > > > > Signed-off-by: Declan Doherty
> > > > > ---
> > > > > lib/librte_eal/common/eal_common_dev.c | 66
> > > > +++--
> > > > > lib/librte_eal/common/eal_common_pci.c | 6 +++
> > > > > lib/librte_eal/common/include/eal_private.h | 7 +++
> > > > > lib/librte_eal/common/include/rte_dev.h | 1 +
> > > > > lib/librte_ether/rte_ethdev.c | 34 +--
> > > > > lib/librte_ether/rte_ethdev.h | 7 ++-
> > > > > lib/librte_pmd_pcap/rte_eth_pcap.c | 22 +-
> > > > > lib/librte_pmd_ring/rte_eth_ring.c | 32 +++---
> > > > > lib/librte_pmd_ring/rte_eth_ring.h | 3 +-
> > > > > lib/librte_pmd_xenvirt/rte_eth_xenvirt.c| 2 +-
> > > > > 10 files changed, 144 insertions(+), 36 deletions(-)
> > > > >
> > > > > diff --git a/lib/librte_eal/common/eal_common_dev.c
> > > > b/lib/librte_eal/common/eal_common_dev.c
> > > > > index eae5656..b50c908 100644
> > > > > --- a/lib/librte_eal/common/eal_common_dev.c
> > > > > +++ b/lib/librte_eal/common/eal_common_dev.c
> > > > > @@ -75,14 +75,28 @@ rte_eal_dev_init(void)
> > > > >
> > > > > /* call the init function for each virtual device */
> > > > > TAILQ_FOREACH(devargs, &devargs_list, next) {
> > > > > + uint8_t bdev = 0;
> > > > >
> > > > > if (devargs->type != RTE_DEVTYPE_VIRTUAL)
> > > > > continue;
> > > > >
> > > > > TAILQ_FOREACH(driver, &dev_driver_list, next) {
> > > > > - if (driver->type != PMD_VDEV)
> > > > > + /* RTE_DEVTYPE_VIRTUAL can only be a virtual or
> > > > > bonded
> > > > device*/
> > > > > + if (driver->type != PMD_VDEV && driver->type !=
> > > > PMD_BDEV)
> > > > > continue;
> > > > >
> > > > > + /*
> > > > > + * Bonded devices are not initialize here, we
> > > > > do it later in
> > > > > + * rte_eal_bonded_dev_init() after all physical
> > > > > devices
> > > > have been
> > > > > + * probed and initialized
> > > > > + */
> > > > > + if (driver->type == PMD_BDEV &&
> > > > > + !strncmp(driver->name, devargs-
> > > > >virtual.drv_name,
> > > > > +
> > > > > strlen(driver->name))) {
> > > > > + bdev = 1;
> > > > > + break;
> > > > > + }
> > > > > +
> > > > I really don't think you need to add a new device type for bonded devs.
> > > > Its got
> > > > no specific hardware that it drives, and you configure it with a --vdev
> > command,
> > > > so treat it as one here. I understand that you need to pass additional
> > > > information about slaves to a bonded device, which is fine, but you can
> > > > do that
> > > > with kvargs pretty easily, at which point its just another vdev. The
> > > > only other
> > > > requirement is that you initilize the bonded vdev after the slave vdevs
> > > > have
> > > > been created, which you can do by any of several methods (a priority
> > > > field to
> > > > indicate that bonded drivers should be initilized last/later, a
> > > > deferral return
> > > > code from the init routine, or by dead reckoning via the careful
> > > > construction
> > of
> > > > the application command line (placed the bonded --vdev option last on
> > > > the
> > > > command line argument list at run time).
> > > >
> > > It was my initial intent to do as you have describe above, but the
> > > physical devices
> > > cause a real issue here, physical devices don't call through to
> > rte_eth_dev_allocate until
> > > during rte_eal_pci_probe call, so it's not possible to initialize the
> > > bo
[dpdk-dev] [PATCH 0/1] librte_pmd_virtio: Fix incorrect device specific header offset when MSI-X is disabled
Following discussion with Stephen Hemminger and Neil Horman: http://dpdk.org/ml/archives/dev/2014-June/003139.html http://dpdk.org/ml/archives/dev/2014-June/00.html http://dpdk.org/ml/archives/dev/2014-June/003295.html There is no need for sysfs entries, instead localise the logic to virtio_ethdev, I am basing this on Stephens effort to include FreeBSD support. Suggested-by: Neil Horman Suggested-by: Stephen Hemminger Alan Carew (1): librte_pmd_virtio: Fix incorrect device specific header offset when MSI-X is disabled config/common_bsdapp | 2 +- lib/librte_pmd_virtio/virtio_ethdev.c | 28 +++- lib/librte_pmd_virtio/virtio_pci.h| 5 ++--- 3 files changed, 30 insertions(+), 5 deletions(-) -- 1.9.3
[dpdk-dev] [PATCH 1/1] librte_pmd_virtio: Fix incorrect device specific header offset when MSI-X is disabled
Signed-off-by: Alan Carew
---
config/common_bsdapp | 2 +-
lib/librte_pmd_virtio/virtio_ethdev.c | 28 +++-
lib/librte_pmd_virtio/virtio_pci.h| 5 ++---
3 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/config/common_bsdapp b/config/common_bsdapp
index ef8eeab..f7397ee 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -169,7 +169,7 @@ CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE=n
#
# Compile burst-oriented VIRTIO PMD driver
#
-CONFIG_RTE_LIBRTE_VIRTIO_PMD=n
+CONFIG_RTE_LIBRTE_VIRTIO_PMD=y
CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_INIT=n
CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_RX=n
CONFIG_RTE_LIBRTE_VIRTIO_DEBUG_TX=n
diff --git a/lib/librte_pmd_virtio/virtio_ethdev.c
b/lib/librte_pmd_virtio/virtio_ethdev.c
index d0b419d..ecdf6f8 100644
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -583,7 +583,8 @@ parse_sysfs_value(const char *filename, unsigned long *val)
return 0;
}
-static int get_uio_dev(struct rte_pci_addr *loc, char *buf, unsigned int
buflen)
+static
+int get_uio_dev(struct rte_pci_addr *loc, char *buf, unsigned int buflen)
{
unsigned int uio_num;
struct dirent *e;
@@ -647,6 +648,30 @@ static int get_uio_dev(struct rte_pci_addr *loc, char
*buf, unsigned int buflen)
return 0;
}
+
+static int
+virtio_has_msix(const struct rte_pci_addr *loc)
+{
+ DIR *d;
+ char dirname[PATH_MAX];
+
+ rte_snprintf(dirname, sizeof(dirname),
+SYSFS_PCI_DEVICES "/" PCI_PRI_FMT "/msi_irqs",
+loc->domain, loc->bus, loc->devid, loc->function);
+
+ d = opendir(dirname);
+ if (d)
+ closedir(d);
+
+ return (d != NULL);
+}
+#else
+static int
+virtio_has_msix(const struct rte_pci_addr *loc __rte_unused)
+{
+ /* nic_uio does not enable interrupts, return 0 (false). */
+ return 0;
+}
#endif
/*
@@ -720,6 +745,7 @@ eth_virtio_dev_init(__rte_unused struct eth_driver *eth_drv,
start, size);
}
#endif
+ hw->use_msix = virtio_has_msix(&pci_dev->addr);
hw->io_base = (uint32_t)(uintptr_t)pci_dev->mem_resource[0].addr;
/* Reset the device although not necessary at startup */
diff --git a/lib/librte_pmd_virtio/virtio_pci.h
b/lib/librte_pmd_virtio/virtio_pci.h
index 864b084..d27b734 100644
--- a/lib/librte_pmd_virtio/virtio_pci.h
+++ b/lib/librte_pmd_virtio/virtio_pci.h
@@ -177,6 +177,7 @@ struct virtio_hw {
uint16_tsubsystem_device_id;
uint16_tsubsystem_vendor_id;
uint8_t revision_id;
+ uint8_t use_msix;
uint8_t mac_addr[ETHER_ADDR_LEN];
int adapter_stopped;
struct rte_eth_stats eth_stats;
@@ -195,13 +196,11 @@ struct virtio_net_config {
uint16_t max_virtqueue_pairs;
} __attribute__((packed));
-/* Value indicated in device config */
-#define VIRTIO_PCI_FLAG_MSIX 0x0020
/*
* The remaining space is defined by each driver as the per-driver
* configuration space.
*/
-#define VIRTIO_PCI_CONFIG(hw) (((hw)->guest_features & VIRTIO_PCI_FLAG_MSIX) ?
24 : 20)
+#define VIRTIO_PCI_CONFIG(hw) (((hw)->use_msix) ? 24 : 20)
/*
* How many bits to shift physical queue address written to QUEUE_PFN.
--
1.9.3
[dpdk-dev] [PATCH v4 0/6] Link Bonding Library
AThis patch contains the initial release of the Link Bonding PMD Library Supporting bonding modes: 0 - Round Robin 1 - Active Backup 2 - Balance (Supporting 3 transmission polices) layer 2, layer 2+3, layer 3+4 3 - Broadcast Version 4 of patch set: - Fixes some checkpatch formatting issues - Splits unique pmd naming and link bonding intialization changes in EAL into separate patches Patch Set Description: 0001 - librte_pmd_bond + makefile changes 0002 - librte_ether changes to support unique naming of pmds 0003 - librte_eal changes to support bonding device intialization 0005 - link bonding unti test suite 0005 - testpmd link bonding support changes 0006 - doxygen additions Declan Doherty (6): Link Bonding Library (lib/librte_pmd_bond) initial release with support for Mode 0 - Round Robin Mode 1 - Active Backup Mode 2 - Balance -> Supports 3 transmit polices (layer 2, layer 2+3, la Mode 3 - Broadcast Support for unique interface naming of pmds EAL support for link bonding device initialization Link bonding Unit Tests testpmd link bonding additions Link Bonding Library doxygen additions app/test-pmd/cmdline.c | 571 app/test-pmd/config.c |4 +- app/test-pmd/parameters.c |3 + app/test-pmd/testpmd.c | 37 +- app/test-pmd/testpmd.h |2 + app/test/Makefile |4 +- app/test/commands.c |7 + app/test/packet_burst_generator.c | 288 ++ app/test/packet_burst_generator.h | 78 + app/test/test.h |1 + app/test/test_link_bonding.c| 3958 +++ app/test/virtual_pmd.c | 574 app/test/virtual_pmd.h | 74 + config/common_bsdapp|5 + config/common_linuxapp |5 + doc/doxy-api-index.md |1 + doc/doxy-api.conf |1 + lib/Makefile|1 + lib/librte_eal/common/eal_common_dev.c | 66 +- lib/librte_eal/common/eal_common_pci.c |6 + lib/librte_eal/common/include/eal_private.h |7 + lib/librte_eal/common/include/rte_dev.h |1 + lib/librte_ether/rte_ethdev.c | 33 +- lib/librte_ether/rte_ethdev.h |7 +- lib/librte_pmd_bond/Makefile| 32 + lib/librte_pmd_bond/rte_eth_bond.c | 2149 +++ lib/librte_pmd_bond/rte_eth_bond.h | 255 ++ lib/librte_pmd_pcap/rte_eth_pcap.c | 22 +- lib/librte_pmd_ring/rte_eth_ring.c | 32 +- lib/librte_pmd_ring/rte_eth_ring.h |3 +- lib/librte_pmd_xenvirt/rte_eth_xenvirt.c|2 +- mk/rte.app.mk |5 + 32 files changed, 8191 insertions(+), 43 deletions(-) create mode 100644 app/test/packet_burst_generator.c create mode 100644 app/test/packet_burst_generator.h create mode 100644 app/test/test_link_bonding.c create mode 100644 app/test/virtual_pmd.c create mode 100644 app/test/virtual_pmd.h create mode 100644 lib/librte_pmd_bond/Makefile create mode 100644 lib/librte_pmd_bond/rte_eth_bond.c create mode 100644 lib/librte_pmd_bond/rte_eth_bond.h
[dpdk-dev] [PATCH v4 3/6] EAL support for link bonding device initialization
Updating functionality in EAL to support adding link bonding
devices via ?vdev option. Link bonding devices will be
initialized after all physical devices have been probed and
initialized.
Signed-off-by: Declan Doherty
---
lib/librte_eal/common/eal_common_dev.c | 66 +--
lib/librte_eal/common/eal_common_pci.c |6 +++
lib/librte_eal/common/include/eal_private.h |7 +++
lib/librte_eal/common/include/rte_dev.h |1 +
4 files changed, 76 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common/eal_common_dev.c
index eae5656..b50c908 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -75,14 +75,28 @@ rte_eal_dev_init(void)
/* call the init function for each virtual device */
TAILQ_FOREACH(devargs, &devargs_list, next) {
+ uint8_t bdev = 0;
if (devargs->type != RTE_DEVTYPE_VIRTUAL)
continue;
TAILQ_FOREACH(driver, &dev_driver_list, next) {
- if (driver->type != PMD_VDEV)
+ /* RTE_DEVTYPE_VIRTUAL can only be a virtual or bonded
device*/
+ if (driver->type != PMD_VDEV && driver->type !=
PMD_BDEV)
continue;
+ /*
+* Bonded devices are not initialize here, we do it
later in
+* rte_eal_bonded_dev_init() after all physical devices
have been
+* probed and initialized
+*/
+ if (driver->type == PMD_BDEV &&
+ !strncmp(driver->name,
devargs->virtual.drv_name,
+ strlen(driver->name))) {
+ bdev = 1;
+ break;
+ }
+
/* search a driver prefix in virtual device name */
if (!strncmp(driver->name, devargs->virtual.drv_name,
strlen(driver->name))) {
@@ -92,9 +106,9 @@ rte_eal_dev_init(void)
}
}
- if (driver == NULL) {
- rte_panic("no driver found for %s\n",
- devargs->virtual.drv_name);
+ if (driver == NULL && !bdev) {
+ rte_panic("no driver found for %s and is not a bonded
vdev %d\n",
+ devargs->virtual.drv_name, bdev);
}
}
@@ -107,3 +121,47 @@ rte_eal_dev_init(void)
}
return 0;
}
+
+#ifdef RTE_LIBRTE_PMD_BOND
+int
+rte_eal_bonded_dev_init(void)
+{
+ struct rte_devargs *devargs;
+ struct rte_driver *driver;
+
+ TAILQ_FOREACH(devargs, &devargs_list, next) {
+ int vdev = 0;
+
+ if (devargs->type != RTE_DEVTYPE_VIRTUAL)
+ continue;
+
+ TAILQ_FOREACH(driver, &dev_driver_list, next) {
+ if (driver->type != PMD_VDEV && driver->type !=
PMD_BDEV)
+ continue;
+
+ /* Virtual devices have already been initialized so we
skip them
+* here*/
+ if (driver->type == PMD_VDEV &&
+ !strncmp(driver->name,
devargs->virtual.drv_name,
+ strlen(driver->name))) {
+ vdev = 1;
+ break;
+ }
+
+ /* search a driver prefix in bonded device name */
+ if (!strncmp(driver->name, devargs->virtual.drv_name,
+ strlen(driver->name))) {
+ driver->init(devargs->virtual.drv_name,
devargs->args);
+ break;
+ }
+ }
+
+ if (driver == NULL && !vdev) {
+ rte_panic("no driver found for %s\n",
+ devargs->virtual.drv_name);
+ }
+ }
+ return 0;
+}
+#endif
+
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 4d877ea..9b584f5 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -166,7 +166,13 @@ rte_eal_pci_probe(void)
dev->addr.devid, dev->addr.function);
}
+#ifdef RTE_LIBRTE_PMD_BOND
+ /* After all physical PCI devices have been probed and initialized then
we
+* initialize the bonded devices */
+ return rte_eal_bonded_dev_init();
+#else
return 0;
+#endif
}
/* dump one device */
diff --git a/lib/librte_eal/common/include/
[dpdk-dev] [PATCH v4 2/6] Support for unique interface naming of pmds
Adding support to rte_eth_dev_data structure to support unique
name identifier for ethdevs to support adding slave ethdevs
(specifically virtual devices which have no public unique
identifier) to a link bonding device. This changes the API
rte_eth_dev_allocate() to require a const char *name when
allocating a ethdev, which also verifies that the name is
unique and hasn?t been already used by an existed allocated
rte_eth_dev. Also contains updates to virtual pmd?s to now call
the API with a name parameter.
Signed-off-by: Declan Doherty
---
lib/librte_ether/rte_ethdev.c| 33 +++--
lib/librte_ether/rte_ethdev.h|7 +-
lib/librte_pmd_pcap/rte_eth_pcap.c | 22 ++--
lib/librte_pmd_ring/rte_eth_ring.c | 32 +++-
lib/librte_pmd_ring/rte_eth_ring.h |3 +-
lib/librte_pmd_xenvirt/rte_eth_xenvirt.c |2 +-
6 files changed, 67 insertions(+), 32 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 8011b8b..e5373fe 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include "rte_ether.h"
#include "rte_ethdev.h"
@@ -152,8 +153,21 @@ rte_eth_dev_data_alloc(void)
RTE_MAX_ETHPORTS * sizeof(*rte_eth_dev_data));
}
+static int
+rte_eth_dev_name_unique(const char *name)
+{
+ unsigned i;
+
+ for (i = 0; i < nb_ports; i++) {
+ if (strcmp(rte_eth_devices[i].data->name, name) == 0)
+ return -1;
+ }
+
+ return 0;
+}
+
struct rte_eth_dev *
-rte_eth_dev_allocate(void)
+rte_eth_dev_allocate(const char *name)
{
struct rte_eth_dev *eth_dev;
@@ -165,23 +179,36 @@ rte_eth_dev_allocate(void)
if (rte_eth_dev_data == NULL)
rte_eth_dev_data_alloc();
+ if (rte_eth_dev_name_unique(name)) {
+ PMD_DEBUG_TRACE("Ethernet Device with name %s already
allocated!\n");
+ return NULL;
+ }
+
eth_dev = &rte_eth_devices[nb_ports];
eth_dev->data = &rte_eth_dev_data[nb_ports];
+ rte_snprintf(eth_dev->data->name, sizeof(eth_dev->data->name),
+ "%s", name);
eth_dev->data->port_id = nb_ports++;
return eth_dev;
}
static int
rte_eth_dev_init(struct rte_pci_driver *pci_drv,
-struct rte_pci_device *pci_dev)
+ struct rte_pci_device *pci_dev)
{
struct eth_driver*eth_drv;
struct rte_eth_dev *eth_dev;
+ char ethdev_name[RTE_ETH_NAME_MAX_LEN];
+
int diag;
eth_drv = (struct eth_driver *)pci_drv;
- eth_dev = rte_eth_dev_allocate();
+ /* Create unique ethdev name from pci address */
+ rte_snprintf(ethdev_name, RTE_ETH_NAME_MAX_LEN, "%d:%d.%d",
+ pci_dev->addr.bus, pci_dev->addr.devid,
pci_dev->addr.function);
+
+ eth_dev = rte_eth_dev_allocate(ethdev_name);
if (eth_dev == NULL)
return -ENOMEM;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 67eda50..27ed0ab 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1233,6 +1233,8 @@ struct rte_eth_dev_sriov {
};
#define RTE_ETH_DEV_SRIOV(dev) ((dev)->data->sriov)
+#define RTE_ETH_NAME_MAX_LEN (32)
+
/**
* @internal
* The data part, with no function pointers, associated with each ethernet
device.
@@ -1241,6 +1243,8 @@ struct rte_eth_dev_sriov {
* processes in a multi-process configuration.
*/
struct rte_eth_dev_data {
+ char name[RTE_ETH_NAME_MAX_LEN]; /**< Unique identifier name */
+
void **rx_queues; /**< Array of pointers to RX queues. */
void **tx_queues; /**< Array of pointers to TX queues. */
uint16_t nb_rx_queues; /**< Number of RX queues. */
@@ -1293,10 +1297,11 @@ extern uint8_t rte_eth_dev_count(void);
* Allocates a new ethdev slot for an ethernet device and returns the pointer
* to that slot for the driver to use.
*
+ * @param nameUnique identifier name for each Ethernet device
* @return
* - Slot in the rte_dev_devices array for a new device;
*/
-struct rte_eth_dev *rte_eth_dev_allocate(void);
+struct rte_eth_dev *rte_eth_dev_allocate(const char *name);
struct eth_driver;
/**
diff --git a/lib/librte_pmd_pcap/rte_eth_pcap.c
b/lib/librte_pmd_pcap/rte_eth_pcap.c
index b3dbbda..12b7e0c 100644
--- a/lib/librte_pmd_pcap/rte_eth_pcap.c
+++ b/lib/librte_pmd_pcap/rte_eth_pcap.c
@@ -534,7 +534,7 @@ open_tx_iface(const char *key __rte_unused, const char
*value, void *extra_args)
static int
-rte_pmd_init_internals(const unsigned nb_rx_queues,
+rte_pmd_init_internals(const char *name, const unsigned nb_rx_queues,
const unsigned nb_tx_queues,
const unsigned numa_node,
struct pmd_internals **internals,
@@ -558,20
[dpdk-dev] [PATCH v4 1/6] Link Bonding Library (lib/librte_pmd_bond) initial release with support for Mode 0 - Round Robin Mode 1 - Active Backup Mode 2 - Balance -> Supports 3 transmit polices (layer
Signed-off-by: Declan Doherty --- config/common_bsdapp |5 + config/common_linuxapp |5 + lib/Makefile |1 + lib/librte_pmd_bond/Makefile | 32 + lib/librte_pmd_bond/rte_eth_bond.c | 2149 lib/librte_pmd_bond/rte_eth_bond.h | 255 + mk/rte.app.mk |5 + 7 files changed, 2452 insertions(+), 0 deletions(-) create mode 100644 lib/librte_pmd_bond/Makefile create mode 100644 lib/librte_pmd_bond/rte_eth_bond.c create mode 100644 lib/librte_pmd_bond/rte_eth_bond.h diff --git a/config/common_bsdapp b/config/common_bsdapp index ef8eeab..6846cba 100644 --- a/config/common_bsdapp +++ b/config/common_bsdapp @@ -189,6 +189,11 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16 CONFIG_RTE_LIBRTE_PMD_PCAP=y # +# Compile link bonding pmd library +# +CONFIG_RTE_LIBRTE_PMD_BOND=y + +# # Do prefetch of packet data within PMD driver receive function # CONFIG_RTE_PMD_PACKET_PREFETCH=y diff --git a/config/common_linuxapp b/config/common_linuxapp index 9f93569..3039591 100644 --- a/config/common_linuxapp +++ b/config/common_linuxapp @@ -218,6 +218,11 @@ CONFIG_RTE_PMD_RING_MAX_TX_RINGS=16 CONFIG_RTE_LIBRTE_PMD_PCAP=n # +# Compile link bonding pmd library +# +CONFIG_RTE_LIBRTE_PMD_BOND=y + +# # Compile Xen PMD # CONFIG_RTE_LIBRTE_PMD_XENVIRT=n diff --git a/lib/Makefile b/lib/Makefile index a9f94b4..5b025c7 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -47,6 +47,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += librte_pmd_pcap DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += librte_pmd_virtio DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += librte_pmd_vmxnet3 DIRS-$(CONFIG_RTE_LIBRTE_PMD_XENVIRT) += librte_pmd_xenvirt +DIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += librte_pmd_bond DIRS-$(CONFIG_RTE_LIBRTE_HASH) += librte_hash DIRS-$(CONFIG_RTE_LIBRTE_LPM) += librte_lpm DIRS-$(CONFIG_RTE_LIBRTE_ACL) += librte_acl diff --git a/lib/librte_pmd_bond/Makefile b/lib/librte_pmd_bond/Makefile new file mode 100644 index 000..51f6159 --- /dev/null +++ b/lib/librte_pmd_bond/Makefile @@ -0,0 +1,32 @@ +# + +include $(RTE_SDK)/mk/rte.vars.mk + +# +# library name +# +LIB = librte_pmd_bond.a + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +# +# all source are stored in SRCS-y +# +SRCS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += rte_eth_bond.c + + +# +# Export include files +# +SYMLINK-y-include += rte_eth_bond.h + + +# this lib depends upon: +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_mbuf +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_ether +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_malloc +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_eal +DEPDIRS-$(CONFIG_RTE_LIBRTE_PMD_BOND) += lib/librte_kvargs + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_pmd_bond/rte_eth_bond.c b/lib/librte_pmd_bond/rte_eth_bond.c new file mode 100644 index 000..01d917d --- /dev/null +++ b/lib/librte_pmd_bond/rte_eth_bond.c @@ -0,0 +1,2149 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of Intel Corporation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include "rte_eth_bond.h" + +/* Link Bonding KVARG option defintions for --vdev */ +#define PMD_BOND_KVARG
[dpdk-dev] [PATCH v4 6/6] Link Bonding Library doxygen additions
Signed-off-by: Declan Doherty
---
doc/doxy-api-index.md |1 +
doc/doxy-api.conf |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/doc/doxy-api-index.md b/doc/doxy-api-index.md
index 83303a1..8338a9b 100644
--- a/doc/doxy-api-index.md
+++ b/doc/doxy-api-index.md
@@ -36,6 +36,7 @@ API {#index}
There are many libraries, so their headers may be grouped by topics:
- **device**:
+ [bond] (@ref rte_eth_bond.h),
[ethdev] (@ref rte_ethdev.h),
[devargs](@ref rte_devargs.h),
[KNI](@ref rte_kni.h),
diff --git a/doc/doxy-api.conf b/doc/doxy-api.conf
index e5a8520..3af8dad 100644
--- a/doc/doxy-api.conf
+++ b/doc/doxy-api.conf
@@ -30,6 +30,7 @@
PROJECT_NAME= DPDK
INPUT = doc/doxy-api-index.md \
+ lib/librte_pmd_bond \
lib/librte_eal/common/include \
lib/librte_acl \
lib/librte_distributor \
--
1.7.0.7
[dpdk-dev] [PATCH v4 5/6] testpmd link bonding additions
- Includes the ability to create new bonded devices.
- Add /remove bonding slave devices.
- Interogate bonded device stats/configuration
- Change bonding modes and select balance transmit polices
Signed-off-by: Declan Doherty
---
app/test-pmd/cmdline.c| 571 +
app/test-pmd/config.c |4 +-
app/test-pmd/parameters.c |3 +
app/test-pmd/testpmd.c| 37 +++-
app/test-pmd/testpmd.h|2 +
5 files changed, 611 insertions(+), 6 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 4678977..fd220e7 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -84,6 +84,9 @@
#include
#include
#include
+#ifdef RTE_LIBRTE_PMD_BOND
+#include
+#endif
#include "testpmd.h"
@@ -400,6 +403,31 @@ static void cmd_help_long_parsed(void *parsed_result,
" Show the bypass configuration for a bypass enabled
NIC"
" using the lowest port on the NIC.\n\n"
#endif
+#ifdef RTE_LIBRTE_PMD_BOND
+ "create bonded device (mode) (socket)\n"
+ " Create a new bonded device with specific
bonding mode and socket.\n\n"
+
+ "add bonding slave (slave_id) (port_id)\n"
+ " Add a slave device to a bonded device.\n\n"
+
+ "remove bonding slave (slave_id) (port_id)\n"
+ " Remove a slave device from a bonded device.\n\n"
+
+ "set bonding mode (value) (port_id)\n"
+ " Set the bonding mode on a bonded device.\n\n"
+
+ "set bonding primary (slave_id) (port_id)\n"
+ " Set the primary slave for a bonded device.\n\n"
+
+ "show bonding config (port_id)\n"
+ " Show the bonding config for port_id.\n\n"
+
+ "set bonding mac_addr (port_id) (address)\n"
+ " Set the MAC address of a bonded device.\n\n"
+
+ "set bonding xmit_balance_policy (port_id)
(l2|l23|l34)\n"
+ " Set the transmit balance policy for bonded
device running in balance mode.\n\n"
+#endif
, list_pkt_forwarding_modes()
);
@@ -2856,6 +2884,539 @@ cmdline_parse_inst_t cmd_show_bypass_config = {
};
#endif
+#ifdef RTE_LIBRTE_PMD_BOND
+/* *** SET BONDING MODE *** */
+struct cmd_set_bonding_mode_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t bonding;
+ cmdline_fixed_string_t mode;
+ uint8_t value;
+ uint8_t port_id;
+};
+
+static void cmd_set_bonding_mode_parsed(void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_set_bonding_mode_result *res = parsed_result;
+ portid_t port_id = res->port_id;
+
+ /* Set the bonding mode for the relevant port. */
+ if (0 != rte_eth_bond_mode_set(port_id, res->value))
+ printf("\t Failed to set bonding mode for port = %d.\n",
port_id);
+}
+
+cmdline_parse_token_string_t cmd_setbonding_mode_set =
+TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_mode_result,
+ set, "set");
+cmdline_parse_token_string_t cmd_setbonding_mode_bonding =
+TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_mode_result,
+ bonding, "bonding");
+cmdline_parse_token_string_t cmd_setbonding_mode_mode =
+TOKEN_STRING_INITIALIZER(struct cmd_set_bonding_mode_result,
+ mode, "mode");
+cmdline_parse_token_num_t cmd_setbonding_mode_value =
+TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
+ value, UINT8);
+cmdline_parse_token_num_t cmd_setbonding_mode_port =
+TOKEN_NUM_INITIALIZER(struct cmd_set_bonding_mode_result,
+ port_id, UINT8);
+
+cmdline_parse_inst_t cmd_set_bonding_mode = {
+ .f = cmd_set_bonding_mode_parsed,
+ .help_str = "set bonding mode (mode_value) (port_id): Set the
bonding mode for port_id",
+ .data = NULL,
+ .tokens = {
+ (void *) &cmd_setbonding_mode_set,
+ (void *) &cmd_setbonding_mode_bonding,
+ (void *) &cmd_setbonding_mode_mode,
+ (void *) &cmd_setbonding_mode_value,
+ (void *) &cmd_setbonding_mode_port,
+ NULL
+ }
+};
+
+/* *** SET BALANCE XMIT POLICY *** */
+struct cmd_set_bonding_balance_xmit_policy_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t bonding;
+ cmdline_fixed_string_t balance_xmit_policy;
+ uint8_t port_id;
+ cmdline_fixed_string_t policy;
+};
+
+static void cmd_set_bonding_balance_xmit_policy_parsed(void *parsed_result,
+
[dpdk-dev] [PATCH v4 4/6] Link bonding Unit Tests
Including: - code to generate packet bursts for testing rx and tx functionality of bonded device - virtual/stubbed out ethdev for use as slave ethdev in testing Signed-off-by: Declan Doherty --- app/test/Makefile |4 +- app/test/commands.c |7 + app/test/packet_burst_generator.c | 288 +++ app/test/packet_burst_generator.h | 78 + app/test/test.h |1 + app/test/test_link_bonding.c | 3958 + app/test/virtual_pmd.c| 574 ++ app/test/virtual_pmd.h| 74 + 8 files changed, 4983 insertions(+), 1 deletions(-) create mode 100644 app/test/packet_burst_generator.c create mode 100644 app/test/packet_burst_generator.h create mode 100644 app/test/test_link_bonding.c create mode 100644 app/test/virtual_pmd.c create mode 100644 app/test/virtual_pmd.h diff --git a/app/test/Makefile b/app/test/Makefile index 3b050c3..02eff0f 100644 --- a/app/test/Makefile +++ b/app/test/Makefile @@ -96,7 +96,9 @@ SRCS-$(CONFIG_RTE_APP_TEST) += test_ivshmem.c SRCS-$(CONFIG_RTE_APP_TEST) += test_distributor.c SRCS-$(CONFIG_RTE_APP_TEST) += test_distributor_perf.c SRCS-$(CONFIG_RTE_APP_TEST) += test_devargs.c - +SRCS-$(CONFIG_RTE_APP_TEST) += virtual_pmd.c +SRCS-$(CONFIG_RTE_APP_TEST) += packet_burst_generator.c +SRCS-$(CONFIG_RTE_APP_TEST) += test_link_bonding.c ifeq ($(CONFIG_RTE_APP_TEST),y) SRCS-$(CONFIG_RTE_LIBRTE_ACL) += test_acl.c SRCS-$(CONFIG_RTE_LIBRTE_PMD_RING) += test_pmd_ring.c diff --git a/app/test/commands.c b/app/test/commands.c index 016410d..c31389d 100644 --- a/app/test/commands.c +++ b/app/test/commands.c @@ -157,6 +157,10 @@ static void cmd_autotest_parsed(void *parsed_result, ret = test_timer(); if (!strcmp(res->autotest, "timer_perf_autotest")) ret = test_timer_perf(); +#ifdef RTE_LIBRTE_PMD_BOND + if (!strcmp(res->autotest, "link_bonding_autotest")) + ret = test_link_bonding(); +#endif if (!strcmp(res->autotest, "mempool_autotest")) ret = test_mempool(); if (!strcmp(res->autotest, "mempool_perf_autotest")) @@ -225,6 +229,9 @@ cmdline_parse_token_string_t cmd_autotest_autotest = "alarm_autotest#interrupt_autotest#" "version_autotest#eal_fs_autotest#" "cmdline_autotest#func_reentrancy_autotest#" +#ifdef RTE_LIBRTE_PMD_BOND + "link_bonding_autotest#" +#endif "mempool_perf_autotest#hash_perf_autotest#" "memcpy_perf_autotest#ring_perf_autotest#" "red_autotest#meter_autotest#sched_autotest#" diff --git a/app/test/packet_burst_generator.c b/app/test/packet_burst_generator.c new file mode 100644 index 000..38db383 --- /dev/null +++ b/app/test/packet_burst_generator.c @@ -0,0 +1,288 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of Intel Corporation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +#include + +#include "packet_burst_generator.h" + +#define UDP_SRC_PORT 1024 +#define UDP_DST_PORT 1024 + + +#define IP_DEFTTL 64 /* from RFC 1340. */ +#define IP_VERSION 0x40 +#define IP_HDRLEN 0x05 /* default IP header length == five 32-bits words. */ +#define IP_VHL_DEF (IP_VERSION | IP_HDRLEN) + +static void +copy_buf_to_p
[dpdk-dev] [PATCH v6 00/20] Add VFIO support to DPDK
2014-06-16 09:28, Burakov, Anatoly: > 2014-06-16 11:08, Thomas Monjalon: > > The signed-off-by line disappeared from v6 patches. > > I assume to be > > Signed-off-by: Anatoly Burakov > > Please confirm. > > Yes, sorry about that, was having a rather long day :-( > Both VFIO and tailq patches assume signoff. Acked-by: Thomas Monjalon I've just reworded some titles and split or merge some patches. Applied for version 1.7.0. Thanks a lot -- Thomas
