[dpdk-dev] rte_eal_init() alternative?
2015-09-02 12:00, Stephen Hemminger: > On Wed, 2 Sep 2015 18:17:40 + > Don Provan wrote: > > > Thomas Monjalon: > > >Yes but please, do not create an alternative init function. > > >We just need to replace panic/exit with error codes and be sure that apps > > >and examples handle them correctly. > > > > I understand your concerns, but the panics are really just the tip of the > > iceberg of the EAL library not realizing it's a library. It really makes no > > sense to think the library should define the application's command line, or > > that the PCI bus should be probed without considering whether this > > application is going to use PCI, and or to insist that EAL work be done on > > internal EAL threads. > > > > So I'd say it's way past time to consider revamping initialization to start > > the process of ending the DPDK library's tail wagging the application's > > dog. Naturally this would have to be done while retaining the existing init > > routine on top of a real library initialization, but that's just an > > unfortunate artifact of the library's history, not a rational design > > decision for moving forward. > > > > -don provan > > > > You are welcome to submit patches with what you are proposing for review. > Theoretical requirements discussions will probably only result in more mail, > not new code. You know what you want, propose a solution. +1 Everybody agree that DPDK should be more flexible. We move from a bare metal framework to a real library. They are shortcuts in original design which can be changed. > As far as the command line. That is easily managed by realizing the > application > doesn't have to pass the original command line into EAL. If you just view the > command line as a way to pass unstructured options; the application or > infrastructure > can build up new values and pass it in. > > I agree that initialization itself should try and not fail except in the > most extreme cases. "ie I can't find /sys what is wrong" and should try > and adapt more "you asked for 128 cpu's but I see only 2, log it and continue" >
[dpdk-dev] rte_eal_init() alternative?
Stephen, Don, On Wed, Sep 2, 2015 at 9:00 PM, Stephen Hemminger < stephen at networkplumber.org> wrote: > On Wed, 2 Sep 2015 18:17:40 + > Don Provan wrote: > > > Thomas Monjalon: > > >Yes but please, do not create an alternative init function. > > >We just need to replace panic/exit with error codes and be sure that > apps and examples handle them correctly. > > > > I understand your concerns, but the panics are really just the tip of > the iceberg of the EAL library not realizing it's a library. It really > makes no sense to think the library should define the application's command > line, or that the PCI bus should be probed without considering whether this > application is going to use PCI, and or to insist that EAL work be done on > internal EAL threads. > > > > So I'd say it's way past time to consider revamping initialization to > start the process of ending the DPDK library's tail wagging the > application's dog. Naturally this would have to be done while retaining the > existing init routine on top of a real library initialization, but that's > just an unfortunate artifact of the library's history, not a rational > design decision for moving forward. > That's one of the first things I was asking in the mailing list (argv): http://dpdk.org/ml/archives/dev/2013-August/000374.html I still think the same way. > > > > -don provan > > > > You are welcome to submit patches with what you are proposing for review. > Theoretical requirements discussions will probably only result in more > mail, > not new code. You know what you want, propose a solution. > > As far as the command line. That is easily managed by realizing the > application > doesn't have to pass the original command line into EAL. If you just view > the > command line as a way to pass unstructured options; the application or > infrastructure > can build up new values and pass it in. > Yes sure, and that's what all of us who are integrating DPDK in existing applications is doing: https://github.com/bisdn/xdpd/blob/stable/src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/driver.cc#L153-L157 But that's rather a workaround. Instead, having an eal_init() API which only handles a fixed set of arguments (non-argv) that can be used by existing applications, and build a command line API on top of eal_init() that parses argv as of now (e.g. eal_init_cl) seems to me cleaner. There are users that make use of the parsing of argv (e.g. dpdk-pktgen) in DPDK, so I think it makes sense to keep it. So if you'd agree on this general proposal, I will try to allocate some time for refactoring this. Marc > > I agree that initialization itself should try and not fail except in the > most extreme cases. "ie I can't find /sys what is wrong" and should try > and adapt more "you asked for 128 cpu's but I see only 2, log it and > continue" > >
[dpdk-dev] [PATCH] librte_cfgfile (rte_cfgfile.h): modify the macros values
2015-09-02 16:53, Jasvinder Singh: > This patch refers to the ABI change proposed for librte_cfgfile > (rte_cfgfile.h). > In order to allow for longer names and values, the new values of macros > CFG_NAME_LEN and CFG_NAME_VAL are set. > > Signed-off-by: Jasvinder Singh > --- > lib/librte_cfgfile/rte_cfgfile.h | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) If the ABI is changed, the LIBABIVER number must be bumped. The release notes must also be updated and the deprecation announce must be removed. Thanks
[dpdk-dev] Poor SRIOV performance with ESXi Linux guest
Getting less than 100 packets per second throughput between VF's under my Fedora FC20 VM running under ESXi 6.0 with DPDK l2fwd (Used as ./l2fwd -c 0xf -n 4 -- -p 0x3 -T 1) Questions: --- Q1) Is DPDK + SRIOV under ESXi supposed to use the igb_uio driver or the vfio-pci driver inside Linux guest os ? Q2) What is the expected l2fwd performance when running DPDK under the Linux guest OS under ESXI with SRIOV ? Q3) Any idea what may be preventing vfio-pci driver from binding to the VF's inside the guest instance ? Q4) Why is igb_uio performing so poorly ? My hardware setup: --- HP DL380-G8 host with dual Xeon-2670 CPU 64 GB RAM Intel 82599 NIC connected to 10G switch HP onboard bnx2 NIC's. VMware Hypervisor ESXi 6.0: --- On above hardware running ESXi 6.0 hypervisor and Intel ixgbe VMware (driver version: 3.21.4.3iov). ESXi side SRIOV is setup as follows: "ixgbe_enabled = 1 options = max_vfs=0,8,8,0" (Total 16 VF's configured) VF's are pass-through to the two guest instances. First 4 VF's to one vm instance and next 2 VF's to second vm instance, remaining VF's are unused, have also tried with single guest instances having 4 VF's and remaining unused, but it did not make any difference My VMware guest instances: Have tried two different guests: Linux guest setup each with 8 cores and 8GB memory (memory is setup as locked down to vm to help with iommu). 1) Fedora FC20 OS (Linux kernel 3.19.8-100.fc20) 2) Ubuntu 15.04 Server distro (Linux kernel 3.19.0-15), On both these guests systems my Linux kernel boot line is set with "intel_iommu=on and iommu=pt" My kernel command info for Fedora guest is as follows: $cat /proc/cmdline --- BOOT_IMAGE=/vmlinuz-3.19.8-100.fc20.x86_64 root=UUID=f0cde7fc-d835-4d90-b086-82bf88f58f88 ro console=tty0 console=ttyS0,9600 rhgb quiet net.ifnames=0 biosdevname=0 intel_iommu=on iommu=pt My dmesg has message: "Intel-IOMMU: enabled" Kernel IOMMU config: -- cat /boot/config-3.19.8-100.fc20.x86_64 |grep -i iommu # CONFIG_GART_IOMMU is not set # CONFIG_CALGARY_IOMMU is not set CONFIG_IOMMU_HELPER=y CONFIG_VFIO_IOMMU_TYPE1=m CONFIG_IOMMU_API=y CONFIG_IOMMU_SUPPORT=y CONFIG_AMD_IOMMU=y CONFIG_AMD_IOMMU_STATS=y CONFIG_AMD_IOMMU_V2=m CONFIG_INTEL_IOMMU=y # CONFIG_INTEL_IOMMU_DEFAULT_ON is not set CONFIG_INTEL_IOMMU_FLOPPY_WA=y # CONFIG_IOMMU_STRESS is not set cat /boot/config-3.19.8-100.fc20.x86_64 |grep -i VIRTUAL CONFIG_FB_VIRTUAL=m # CONFIG_DEBUG_VIRTUAL is not set CONFIG_VIRTUALIZATION=y ./dpdk_nic_bind.py --status Network devices using DPDK-compatible driver :03:00.0 '82599 Ethernet Controller Virtual Function' drv=igb_uio unused=ixgbevf,vfio-pci :0b:00.0 '82599 Ethernet Controller Virtual Function' drv=igb_uio unused=ixgbevf,vfio-pci :13:00.0 '82599 Ethernet Controller Virtual Function' drv=igb_uio unused=ixgbevf,vfio-pci :1b:00.0 '82599 Ethernet Controller Virtual Function' drv=igb_uio unused=ixgbevf,vfio-pci Network devices using kernel driver === :02:00.0 '82545EM Gigabit Ethernet Controller (Copper)' if=eth4 drv=e1000 unused=igb_uio,vfio-pci *Active* Other network devices = The l2fw program is run with: ./l2fwd -c 0xf -n 4 -- -p 0x3 -T 1 [Using the default igb_uio driver shipped with Fedora Fc20] Getting around 70 packets per second with these settings: When I tried using the vfio-pci driver (again using the default vfio-pci driver from Fedora FC20), get the following errors: ./dpdk_nic_bind.py --bind vfio-pci :03:00.0 Error: bind failed for :03:00.0 - Cannot bind to driver vfio-pci dmesg shows: [ 882.685134] vfio-pci: probe of :03:00.0 failed with error -22 My guest side lspci shows: --- 03:00.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 0b:00.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 13:00.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 1b:00.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) My ESXi side VMware lscpi shows: -- :09:00.0 Network controller: Intel Corporation 82599 10 Gigabit Dual Port Network Connection [vmnic4] :09:00.1 Network controller: Intel Corporation 82599 10 Gigabit Dual Port Network Connection [vmnic5] :09:10.1 Network controller: Intel Corporation 82599 Ethernet Controller Virtual Function [PF_0.9.1_VF_0] :09:10.3 Network controller: Intel Corporation 82599 Ethernet Controller Virtual Function [PF_0.9.1_VF_1] :09:10.5 Network controller: Intel Corporation 82599 Ethernet Contro
[dpdk-dev] rte_eal_init() alternative?
On 9/2/15, 4:08 PM, "dev on behalf of Thomas Monjalon" wrote: >2015-09-02 12:00, Stephen Hemminger: >> On Wed, 2 Sep 2015 18:17:40 + >> Don Provan wrote: >> >> > Thomas Monjalon: >> > >Yes but please, do not create an alternative init function. >> > >We just need to replace panic/exit with error codes and be sure that >>apps and examples handle them correctly. >> > >> > I understand your concerns, but the panics are really just the tip of >>the iceberg of the EAL library not realizing it's a library. It really >>makes no sense to think the library should define the application's >>command line, or that the PCI bus should be probed without considering >>whether this application is going to use PCI, and or to insist that EAL >>work be done on internal EAL threads. >> > >> > So I'd say it's way past time to consider revamping initialization to >>start the process of ending the DPDK library's tail wagging the >>application's dog. Naturally this would have to be done while retaining >>the existing init routine on top of a real library initialization, but >>that's just an unfortunate artifact of the library's history, not a >>rational design decision for moving forward. >> > >> > -don provan >> > >> >> You are welcome to submit patches with what you are proposing for >>review. >> Theoretical requirements discussions will probably only result in more >>mail, >> not new code. You know what you want, propose a solution. > >+1 >Everybody agree that DPDK should be more flexible. >We move from a bare metal framework to a real library. >They are shortcuts in original design which can be changed. +1 I was also asked at one point, at DPDK summit was, if a structure based init routine would be better for applications. Instead of passing in command line argvs he wanted to setup a structure in his application to be passed into a new API. The old argvs rte_eal_init() would setup a structure and call into the new rte_eal_struct_init() routine (I guess). I could see the new API would return ERROR (plus errno) to the application if called directly or return ERROR to rte_eal_init() to be handle from the command line. That stated I am not a big fan of huge structures being passed into a init routine as that structure would need to be versioned and it will grow/change. Plus he did not really want to deal in strings, so the structure would be binary values and strings as required. He also wanted DPDK to be more dynamic, meaning some of the values we have in the config files should be more dynamic set via the structure and possible have APIs to enable/disable or set the values. Each config option would have to be looked at IMO, as some are not very easy to be dynamic and maybe not reasonable at all. I believe looking at the current problem of not doing a exit/panic is the first step, next step, if everyone wants, is to look at how to initialize DPDK from an application perspective as compared to a command line one. > >> As far as the command line. That is easily managed by realizing the >>application >> doesn't have to pass the original command line into EAL. If you just >>view the >> command line as a way to pass unstructured options; the application or >>infrastructure >> can build up new values and pass it in. >> >> I agree that initialization itself should try and not fail except in the >> most extreme cases. "ie I can't find /sys what is wrong" and should try >> and adapt more "you asked for 128 cpu's but I see only 2, log it and >>continue" >> > > > ? Regards, ++Keith Intel Corporation
[dpdk-dev] Support of LSI for vmxnet3
The problem is there is no selective disable mask. It is possible using MSIX by redirecting. I have a version with that with new rcv stuff. Still needs work On Sep 2, 2015 9:07 PM, "Dey, Souvik" wrote: > Hi, > Is there any particular reason of nor supporting the > RTE_PCI_DRV_INTR_LSC for vmxnet3. I can see we have introduced the same for > the other virtual driver virtio but not for vmxnet3. Do we have some > technical difficulties there ? Can someone throw some light on this. > > > -- > Regards, > Souvik >
[dpdk-dev] rte_eal_init() alternative?
On 02/09/15 15:08, Jay Rolette wrote: > On Wed, Sep 2, 2015 at 7:56 AM, Bruce Richardson intel.com >> wrote: > >> On Wed, Sep 02, 2015 at 12:49:40PM +, Montorsi, Francesco wrote: >>> Hi all, >>> >>> Currently it seems that the only way to initialize EAL is using >> rte_eal_init() function, correct? >>> >>> I have the problem that rte_eal_init() will call rte_panic() whenever >> something fails to initialize or in other cases it will call exit(). >>> In my application, I would rather like to attempt DPDK initialization. >> If it fails I don't want to exit. >>> Unfortunately I cannot even copy&paste the rte_eal_init() code into my >> application (removing rte_panic and exit calls) since it uses a lot of DPDK >> internal private functions. >>> >>> I think that my requirements (avoid abort/exit calls when init fails) is >> a basic requirement... would you accept a patch that adds an alternative >> rte_eal_init() function that just returns an error code upon failure, >> instead of immediately exiting? >>> >>> Thanks for your hard work! >>> >>> Francesco Montorsi >>> >> I, for one, would welcome such a patch. I think the code is overly quick in >> many places to panic or exit the app, when an error code would be more >> appropriate. >> Feel free to also look at other libraries in DPDK too, if you like :-) >> >> Regards, >> /Bruce >> > > +1 > +1
[dpdk-dev] rte_eal_init() alternative?
Thomas Monjalon: >Yes but please, do not create an alternative init function. >We just need to replace panic/exit with error codes and be sure that apps and >examples handle them correctly. I understand your concerns, but the panics are really just the tip of the iceberg of the EAL library not realizing it's a library. It really makes no sense to think the library should define the application's command line, or that the PCI bus should be probed without considering whether this application is going to use PCI, and or to insist that EAL work be done on internal EAL threads. So I'd say it's way past time to consider revamping initialization to start the process of ending the DPDK library's tail wagging the application's dog. Naturally this would have to be done while retaining the existing init routine on top of a real library initialization, but that's just an unfortunate artifact of the library's history, not a rational design decision for moving forward. -don provan
[dpdk-dev] [PATCH] librte_cfgfile (rte_cfgfile.h): modify the macros values
This patch refers to the ABI change proposed for librte_cfgfile (rte_cfgfile.h).
In order to allow for longer names and values, the new values of macros
CFG_NAME_LEN and CFG_NAME_VAL are set.
Signed-off-by: Jasvinder Singh
---
lib/librte_cfgfile/rte_cfgfile.h | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/librte_cfgfile/rte_cfgfile.h b/lib/librte_cfgfile/rte_cfgfile.h
index 7c9fc91..d443782 100644
--- a/lib/librte_cfgfile/rte_cfgfile.h
+++ b/lib/librte_cfgfile/rte_cfgfile.h
@@ -47,8 +47,13 @@ extern "C" {
*
***/
-#define CFG_NAME_LEN 32
-#define CFG_VALUE_LEN 64
+#ifndef CFG_NAME_LEN
+#define CFG_NAME_LEN 64
+#endif
+
+#ifndef CFG_VALUE_LEN
+#define CFG_VALUE_LEN 256
+#endif
/** Configuration file */
struct rte_cfgfile;
--
2.1.0
[dpdk-dev] libdpdk upstream changes for ecosystem best practices
Hi, 2015-09-02 14:49, Robie Basak: > Hi, > > We?re looking at packaging DPDK in Ubuntu. We?d like to discuss upstream Nice > changes to better integrate DPDK into Linux distributions. Here?s a > summary of what we need: > > 1) Define one library ABI (soname and sover) that we can use instead of the > split build. > > 2) Fix #includes so we don't have to include config.h > > 3) Put headers into /usr/include/dpdk instead of /usr/include > > You can see our current packaging progress at > https://git.launchpad.net/~ubuntu-server/dpdk/log/?h=ubuntu-wily and a Thanks for sharing > test PPA at https://launchpad.net/~smb/+archive/ubuntu/dpdk/ > > First, it would be easier for us to ship a single binary package that > ships a single shared library to cover all of DPDK that library > consumers might need, rather than having it split up as you do. I > understand the build system is capable of doing this already, but what > we don?t have is a well defined soname and sover (currently > parameterized in the build) for ABI compatibility purposes. As a binary No it is now fixed: http://dpdk.org/browse/dpdk/commit/?id=c3ce2ad3548 > distribution, this is something that we?d expect upstream to define, > since normally we expect to achieve binary compatibility across all > distributions at this level in the stack. > > So I have the following requests: > > So that we can get DPDK packaging into Ubuntu immediately, please could > we agree to define (and burn) libdpdk.so.0 to be the ABI that builds > with upstream release 2.0.0 when built with the native-linuxapp-gcc > template options plus the following changes: > CONFIG_RTE_MACHINE=?default? > CONFIG_RTE_APP_TEST=n > CONFIG_LIBRTE_VHOST=y > CONFIG_RTE_EAL_IGB_UIO=n > CONFIG_RTE_LIBRTE_KNI=n > CONFIG_RTE_BUILD_COMBINE_LIBS=y > CONFIG_RTE_BUILD_SHARED_LIB=y I feel this configuration is the responsibility of the distribution. What do you expect to have in the source project? > CONFIG_RTE_LIBNAME=?dpdk? not exist anymore > The combined library would be placed into /usr/lib/$(ARCH)-linux-gnu/ > where it can be found without modification to the library search path. > We want to ship it like this in Ubuntu anyway, but I?d prefer upstream > to have defined it as such since then we?ll have a proper definition of > the ABI that can be shared across distributions and other consumers any > time ABI compatibility is expected. You mean you target ABI compatibility between Linux distributons? But other libraries could have different versions so you would be lucky to have a binary application finding the same dependencies. > Though not strictly part of a shared library ABI, I also propose some > build-related upstream changes at API level below, that I?d like to also > ship in the initial Ubuntu packaging of the header files. Clearly you > cannot make this change in an existing release, but I propose that you > do this for your next release so all library consumers will see a > consistent and standard API interface. If you agree to this, then I?d > also like to ship the Ubuntu package with patches to do the same thing > in your current release. Yes cleanup patches are welcome :) > Right now, I understand that library consumers need to either: 1) use > the upstream-provided build system (.mk files etc); or 2) otherwise make > sure to include rte_config.h by specifying it as an extra CPPFLAGS > parameter as the upstream API documentation does not require its > inclusion use in source files. This is problematic because somebody > writing against multiple libraries should just expect to #include the > API-defined headers and link simply with -l for the build to work. It is > common to have a config.h type file generated at build time, but in this > case I?d expect it to be conditionally included automatically as part of > the API, for example by #include?ing it in any file the API _does_ > define that library users must include. To fix this, I propose to > #include in every header file that library users may > #include according to the API. > > That brings me to paths. To avoid polluting the /usr/include namespace, > I?d expect either a single /usr/include/dpdk.h, or everything inside > /usr/include/dpdk/, or both. Then library consumers would #include The second option seems more reasonable. > combinations of and as required, our packaging > could install into these directories without stealing any other part of > the shared filesystem namespace, and library users wouldn?t have to be > concerned about paths, configuration or build systems. This would then > match every other shared library we package. Does this sound reasonable > to you? Is this a change you will accept? Yes there is clearly a namespace issue in DPDK. I would add that libethdev should be librte_ethdev. > Thanks, Thanks for suggesting
[dpdk-dev] [PATCH 1/1] ip_frag: fix creating ipv6 fragment extension header
From: Piotr Azarewicz Previous implementation won't work on every environment. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. Solution: used bytes instead of bit fields. Signed-off-by: Piotr Azarewicz --- lib/librte_ip_frag/rte_ipv6_fragmentation.c |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/lib/librte_ip_frag/rte_ipv6_fragmentation.c b/lib/librte_ip_frag/rte_ipv6_fragmentation.c index 0e32aa8..7342421 100644 --- a/lib/librte_ip_frag/rte_ipv6_fragmentation.c +++ b/lib/librte_ip_frag/rte_ipv6_fragmentation.c @@ -65,10 +65,8 @@ __fill_ipv6hdr_frag(struct ipv6_hdr *dst, fh = (struct ipv6_extension_fragment *) ++dst; fh->next_header = src->proto; - fh->reserved1 = 0; - fh->frag_offset = rte_cpu_to_be_16(fofs); - fh->reserved2 = 0; - fh->more_frags = rte_cpu_to_be_16(mf); + fh->reserved1 = 0; + fh->frag_data = rte_cpu_to_be_16((fofs & ~IPV6_HDR_FO_MASK) | mf); fh->id = 0; } -- 1.7.9.5
[dpdk-dev] [PATCH v2 08/10] acl: remove old API
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Wednesday, September 02, 2015 2:17 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 08/10] acl: remove old API > > The functions and structures are moved to app/test in order to keep > existing unit tests. Some minor changes were done in these functions > because of library scope restrictions. > An enum is also copied in two other applications to keep existing code. > The library version is incremented. > > Signed-off-by: Thomas Monjalon > Acked-by: Stephen Hemminger > Acked-by: Neil Horman > --- Acked-by: Konstantin Ananyev > app/test-acl/main.c | 17 +++ > app/test/test_acl.c | 194 > +++ > app/test/test_acl.h | 59 +++ > doc/guides/rel_notes/deprecation.rst | 4 - > doc/guides/rel_notes/release_2_2.rst | 4 +- > examples/l3fwd-acl/main.c| 17 +++ > lib/librte_acl/Makefile | 2 +- > lib/librte_acl/rte_acl.c | 170 -- > lib/librte_acl/rte_acl.h | 104 --- > lib/librte_acl/rte_acl_version.map | 2 - > 10 files changed, 291 insertions(+), 282 deletions(-) >
[dpdk-dev] [ RFC ] performance thread example
Hi Folks, Would welcome feedback on this proposal for an example app to explore performance with different threading models. Thanks, Ian Performance thread example application This example will comprise a simple layer 3 forwarding application distributed across multiple threads. It will be possible to configure the application for, and contrast forwarding performance of different threading models, More specifically when the different threads are:- 1. EAL threads running on different physical cores 2. EAL threads running on the same physical core ( multiple lcore per physical core) 3. Lightweight threads running in an EAL thread on one more physical cores. Purpose and justification Since dpdk 2.0 it has been possible to assign multiple EAL threads to a physical core ( case 2 above ). Currently no example application has focused on demonstrating the performance constraints of differing threading models. Whilst purpose built applications that fully comprehend the DPDK single threaded programming model will always yield superior performance, the desire to preserve ROI in legacy code written for multithreaded operating environments makes lightweight threads ( case 3 above ) an option worthy of consideration. As well as aiding with legacy code reuse, it is anticipated that lightweight threads will make it possible to scale a multithreaded application with fine granularity allowing an application to more easily take advantage of headroom on EAL cores, or conversely occupy more cores, as dictated by system load. To explore performance with lightweight threads a simple cooperative scheduler subsystem is being included in this example application. If the expected benefits and use cases prove to be of value, it is anticipated that this lightweight thread subsystem would become a library in some future DPDK release. Proposed High-Level Solution(s) A layer 3 forwarding application will comprise a number of threads from rx through tx stages, and will accept command line parameters enabling the assignment of queues to threads, threads to lcores, and lcores to physical cores. In the case that the threads are to be lightweight threads then a lightweight thread scheduler will be run as the main loop of one or more EAL threads. The lightweight thread subsystem will have an API comparable in purpose to a subset of the equivalent POSIX P-thread functions. Main APIs * Thread control APIs o Lthread_create o Lthread_cancel o Lthread_join o Lthread_detach o Lthread_exit o Lthread_sleep o Lthread_yield o Lthread_set_affinity o Lthread_current * Thread local storage APIs o Lthread_set_data o Lthread_get_data o Lthread_key_create o Lthread_key_delete o Lthread_get_specific o Lthread_set_specific o PER_LTHREAD macros * Sychronization APIs o Lthread_mutex_init o Lthread_mutex_destroy o Lthread_mutex_lock o Lthread_mutex_trylock o Lthread_mutex_unlock o Lthread_cond_init o Lthread_cond_destroy o Lthread_cond_wait o Lthread_cond_signal o Lthread_cond_broadcast * Scheduler control APIs o Lthread_num_schedulers_set o Lthread_active_schedulers o Lthread_run Proposed example format The L-thread packet forwarding application, (and test code) , will be example applications under RTE_SDK/examples/. The L-thread subsystem will be a common source folder included by these applications. RTE_SDK/examples/lthread RTE_SDK/examples/lthread/common/ RTE_SDK/examples/lthread/l3fwd-lthread/ RTE_SDK/examples/lthread/test/ Ian Betts Intel Shannon Limited Registered in Ireland Registered Office Collinstown Industrial Park, Leixlip, County Kildare Registered Number:308263 Business address: Dromore House, East Park, Shannon, Co. Clare -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] Poor SRIOV performance with ESXi Linux guest
On Wed, 2 Sep 2015 22:18:27 + Ale Mansoor wrote: > Getting less than 100 packets per second throughput between VF's under my > Fedora FC20 VM running under ESXi 6.0 with DPDK l2fwd (Used as ./l2fwd -c 0xf > -n 4 -- -p 0x3 -T 1) That is many orders of magnitude less than expected. > Questions: > --- > > Q1) Is DPDK + SRIOV under ESXi supposed to use the igb_uio driver or the > vfio-pci driver inside Linux guest os ? You have to use igb_uio, there is no emulated IOMMU in ESX > Q2) What is the expected l2fwd performance when running DPDK under the Linux > guest OS under ESXI with SRIOV ? Depends on many things. With SRIOV you should reach 10Mpps or more. Did you try running Linux on baremetal on same hardware first? > Q3) Any idea what may be preventing vfio-pci driver from binding to the VF's > inside the guest instance ? vfio-pci needs IOMMU which is not available in guest. > Q4) Why is igb_uio performing so poorly ? Don't blame igb_uio. It is probably something in system or vmware.
[dpdk-dev] [PATCH v2 10/10] ring: remove deprecated functions
From: Stephen Hemminger
These were deprecated in 2.0 so remove them from 2.2.
The library version is incremented.
Signed-off-by: Stephen Hemminger
Signed-off-by: Thomas Monjalon
Acked-by: Neil Horman
---
doc/guides/rel_notes/deprecation.rst | 3 --
doc/guides/rel_notes/release_2_2.rst | 5 ++-
drivers/net/ring/Makefile | 2 +-
drivers/net/ring/rte_eth_ring.c | 56 ---
drivers/net/ring/rte_eth_ring.h | 3 --
drivers/net/ring/rte_eth_ring_version.map | 2 --
6 files changed, 5 insertions(+), 66 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index 04819fa..5f6079b 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -40,9 +40,6 @@ Deprecation Notices
the tunnel type, TNI/VNI, inner MAC and inner VLAN are monitored.
The release 2.2 will contain these changes without backwards compatibility.
-* librte_pmd_ring: The deprecated functions rte_eth_ring_pair_create and
- rte_eth_ring_pair_attach should be removed.
-
* ABI changes are planned for struct virtio_net in order to support vhost-user
multiple queues feature.
It should be integrated in release 2.2 without backward compatibility.
diff --git a/doc/guides/rel_notes/release_2_2.rst
b/doc/guides/rel_notes/release_2_2.rst
index 6dcfe88..abe57b4 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -24,6 +24,9 @@ API Changes
* The deprecated KNI functions are removed:
rte_kni_create(), rte_kni_get_port_id() and rte_kni_info_get().
+* The deprecated ring PMD functions are removed:
+ rte_eth_ring_pair_create() and rte_eth_ring_pair_attach().
+
ABI Changes
---
@@ -67,7 +70,7 @@ The libraries prepended with a plus sign were incremented in
this version.
librte_meter.so.1
librte_pipeline.so.1
librte_pmd_bond.so.1
- librte_pmd_ring.so.1
+ + librte_pmd_ring.so.2
librte_port.so.1
librte_power.so.1
librte_reorder.so.1
diff --git a/drivers/net/ring/Makefile b/drivers/net/ring/Makefile
index e442d0b..ae83505 100644
--- a/drivers/net/ring/Makefile
+++ b/drivers/net/ring/Makefile
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)
EXPORT_MAP := rte_eth_ring_version.map
-LIBABIVER := 1
+LIBABIVER := 2
#
# all source are stored in SRCS-y
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 6fd3d0a..0ba36d5 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -391,62 +391,6 @@ eth_dev_ring_create(const char *name, const unsigned
numa_node,
return 0;
}
-
-static int
-eth_dev_ring_pair_create(const char *name, const unsigned numa_node,
- enum dev_action action)
-{
- /* rx and tx are so-called from point of view of first port.
-* They are inverted from the point of view of second port
-*/
- struct rte_ring *rx[RTE_PMD_RING_MAX_RX_RINGS];
- struct rte_ring *tx[RTE_PMD_RING_MAX_TX_RINGS];
- unsigned i;
- char rx_rng_name[RTE_RING_NAMESIZE];
- char tx_rng_name[RTE_RING_NAMESIZE];
- unsigned num_rings = RTE_MIN(RTE_PMD_RING_MAX_RX_RINGS,
- RTE_PMD_RING_MAX_TX_RINGS);
-
- for (i = 0; i < num_rings; i++) {
- snprintf(rx_rng_name, sizeof(rx_rng_name), "ETH_RX%u_%s", i,
name);
- rx[i] = (action == DEV_CREATE) ?
- rte_ring_create(rx_rng_name, 1024, numa_node,
- RING_F_SP_ENQ|RING_F_SC_DEQ) :
- rte_ring_lookup(rx_rng_name);
- if (rx[i] == NULL)
- return -1;
- snprintf(tx_rng_name, sizeof(tx_rng_name), "ETH_TX%u_%s", i,
name);
- tx[i] = (action == DEV_CREATE) ?
- rte_ring_create(tx_rng_name, 1024, numa_node,
- RING_F_SP_ENQ|RING_F_SC_DEQ):
- rte_ring_lookup(tx_rng_name);
- if (tx[i] == NULL)
- return -1;
- }
-
- if (rte_eth_from_rings(rx_rng_name, rx, num_rings, tx, num_rings,
- numa_node) < 0 ||
- rte_eth_from_rings(tx_rng_name, tx, num_rings, rx,
- num_rings, numa_node) < 0)
- return -1;
-
- return 0;
-}
-
-int
-rte_eth_ring_pair_create(const char *name, const unsigned numa_node)
-{
- RTE_LOG(WARNING, PMD, "rte_eth_ring_pair_create is deprecated\n");
- return eth_dev_ring_pair_create(name, numa_node, DEV_CREATE);
-}
-
-int
-rte_eth_ring_pair_attach(const char *name, const unsigned numa_node)
-{
- RTE_LOG(WARNING, PMD, "rte_eth_ring_pair_attach is deprecated\n");
- return eth_dev_ring_pair_create(name, numa_node, DEV_ATTACH);
-}
-
struct node_action_pai
[dpdk-dev] [PATCH v2 09/10] kni: remove deprecated functions
From: Stephen Hemminger
These functions were tagged as deprecated in 2.0 so they can be
removed in 2.2.
The library version is incremented.
Signed-off-by: Stephen Hemminger
Acked-by: Helin Zhang
[Thomas: update doc and version]
Signed-off-by: Thomas Monjalon
Acked-by: Neil Horman
---
app/test/Makefile | 6 ---
app/test/test_kni.c | 36 ---
doc/guides/prog_guide/kernel_nic_interface.rst| 2 -
doc/guides/rel_notes/deprecation.rst | 3 --
doc/guides/rel_notes/release_2_2.rst | 5 ++-
doc/guides/sample_app_ug/kernel_nic_interface.rst | 9
lib/librte_kni/Makefile | 2 +-
lib/librte_kni/rte_kni.c | 51 -
lib/librte_kni/rte_kni.h | 54 ---
lib/librte_kni/rte_kni_version.map| 3 --
10 files changed, 5 insertions(+), 166 deletions(-)
diff --git a/app/test/Makefile b/app/test/Makefile
index e7f148f..7778e1c 100644
--- a/app/test/Makefile
+++ b/app/test/Makefile
@@ -146,12 +146,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_KVARGS) += test_kvargs.c
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
-# Disable warnings of deprecated-declarations in test_kni.c
-ifeq ($(CC), icc)
-CFLAGS_test_kni.o += -wd1478
-else
-CFLAGS_test_kni.o += -Wno-deprecated-declarations
-endif
CFLAGS += -D_GNU_SOURCE
# Disable VTA for memcpy test
diff --git a/app/test/test_kni.c b/app/test/test_kni.c
index 506b543..9dad988 100644
--- a/app/test/test_kni.c
+++ b/app/test/test_kni.c
@@ -398,17 +398,6 @@ test_kni_processing(uint8_t port_id, struct rte_mempool
*mp)
printf("fail to create kni\n");
return -1;
}
- if (rte_kni_get_port_id(kni) != port_id) {
- printf("fail to get port id\n");
- ret = -1;
- goto fail_kni;
- }
-
- if (rte_kni_info_get(RTE_MAX_ETHPORTS)) {
- printf("Unexpectedly get a KNI successfully\n");
- ret = -1;
- goto fail_kni;
- }
test_kni_ctx = kni;
test_kni_processing_flag = 0;
@@ -591,14 +580,6 @@ test_kni(void)
goto fail;
}
- /* test of getting port id according to NULL kni context */
- if (rte_kni_get_port_id(NULL) < RTE_MAX_ETHPORTS) {
- ret = -1;
- printf("unexpectedly get port id successfully by NULL kni "
- "pointer\n");
- goto fail;
- }
-
/* test of releasing NULL kni context */
ret = rte_kni_release(NULL);
if (ret == 0) {
@@ -645,23 +626,6 @@ test_kni(void)
goto fail;
}
- /* test the interface of creating a KNI, for backward compatibility */
- memset(&ops, 0, sizeof(ops));
- ops = kni_ops;
- kni = rte_kni_create(port_id, MAX_PACKET_SZ, mp, &ops);
- if (!kni) {
- ret = -1;
- printf("Fail to create a KNI device for port %d\n", port_id);
- goto fail;
- }
-
- ret = rte_kni_release(kni);
- if (ret < 0) {
- printf("Fail to release a KNI device\n");
- goto fail;
- }
-
- ret = 0;
fail:
rte_eth_dev_stop(port_id);
diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst
b/doc/guides/prog_guide/kernel_nic_interface.rst
index 713d30b..0d91476 100644
--- a/doc/guides/prog_guide/kernel_nic_interface.rst
+++ b/doc/guides/prog_guide/kernel_nic_interface.rst
@@ -100,8 +100,6 @@ Refer to rte_kni_common.h in the DPDK source code for more
details.
The physical addresses will be re-mapped into the kernel address space and
stored in separate KNI contexts.
-Once KNI interfaces are created, the KNI context information can be queried by
calling the rte_kni_info_get() function.
-
The KNI interfaces can be deleted by a DPDK application dynamically after
being created.
Furthermore, all those KNI interfaces not deleted will be deleted on the
release operation
of the miscellaneous device (when the DPDK application is closed).
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index e7e213c..04819fa 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -40,9 +40,6 @@ Deprecation Notices
the tunnel type, TNI/VNI, inner MAC and inner VLAN are monitored.
The release 2.2 will contain these changes without backwards compatibility.
-* librte_kni: Functions based on port id are deprecated for a long time and
- should be removed (rte_kni_create, rte_kni_get_port_id and rte_kni_info_get).
-
* librte_pmd_ring: The deprecated functions rte_eth_ring_pair_create and
rte_eth_ring_pair_attach should be removed.
diff --git a/doc/guides/rel_notes/release_2_2.rst
b/doc/guides/rel_notes/release_2_2.rst
index 6e73092..6dcfe88 100644
---
[dpdk-dev] [PATCH v2 08/10] acl: remove old API
The functions and structures are moved to app/test in order to keep
existing unit tests. Some minor changes were done in these functions
because of library scope restrictions.
An enum is also copied in two other applications to keep existing code.
The library version is incremented.
Signed-off-by: Thomas Monjalon
Acked-by: Stephen Hemminger
Acked-by: Neil Horman
---
app/test-acl/main.c | 17 +++
app/test/test_acl.c | 194 +++
app/test/test_acl.h | 59 +++
doc/guides/rel_notes/deprecation.rst | 4 -
doc/guides/rel_notes/release_2_2.rst | 4 +-
examples/l3fwd-acl/main.c| 17 +++
lib/librte_acl/Makefile | 2 +-
lib/librte_acl/rte_acl.c | 170 --
lib/librte_acl/rte_acl.h | 104 ---
lib/librte_acl/rte_acl_version.map | 2 -
10 files changed, 291 insertions(+), 282 deletions(-)
diff --git a/app/test-acl/main.c b/app/test-acl/main.c
index be3d773..72ce83c 100644
--- a/app/test-acl/main.c
+++ b/app/test-acl/main.c
@@ -162,6 +162,23 @@ enum {
NUM_FIELDS_IPV4
};
+/*
+ * That effectively defines order of IPV4VLAN classifications:
+ * - PROTO
+ * - VLAN (TAG and DOMAIN)
+ * - SRC IP ADDRESS
+ * - DST IP ADDRESS
+ * - PORTS (SRC and DST)
+ */
+enum {
+ RTE_ACL_IPV4VLAN_PROTO,
+ RTE_ACL_IPV4VLAN_VLAN,
+ RTE_ACL_IPV4VLAN_SRC,
+ RTE_ACL_IPV4VLAN_DST,
+ RTE_ACL_IPV4VLAN_PORTS,
+ RTE_ACL_IPV4VLAN_NUM
+};
+
struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
diff --git a/app/test/test_acl.c b/app/test/test_acl.c
index b4a107d..2b82790 100644
--- a/app/test/test_acl.c
+++ b/app/test/test_acl.c
@@ -45,6 +45,8 @@
#include "test_acl.h"
+#defineBIT_SIZEOF(x) (sizeof(x) * CHAR_BIT)
+
#define LEN RTE_ACL_MAX_CATEGORIES
RTE_ACL_RULE_DEF(acl_ipv4vlan_rule, RTE_ACL_IPV4VLAN_NUM_FIELDS);
@@ -100,6 +102,198 @@ bswap_test_data(struct ipv4_7tuple *data, int len, int
to_be)
}
}
+static int
+acl_ipv4vlan_check_rule(const struct rte_acl_ipv4vlan_rule *rule)
+{
+ if (rule->src_port_low > rule->src_port_high ||
+ rule->dst_port_low > rule->dst_port_high ||
+ rule->src_mask_len > BIT_SIZEOF(rule->src_addr) ||
+ rule->dst_mask_len > BIT_SIZEOF(rule->dst_addr))
+ return -EINVAL;
+ return 0;
+}
+
+static void
+acl_ipv4vlan_convert_rule(const struct rte_acl_ipv4vlan_rule *ri,
+ struct acl_ipv4vlan_rule *ro)
+{
+ ro->data = ri->data;
+
+ ro->field[RTE_ACL_IPV4VLAN_PROTO_FIELD].value.u8 = ri->proto;
+ ro->field[RTE_ACL_IPV4VLAN_VLAN1_FIELD].value.u16 = ri->vlan;
+ ro->field[RTE_ACL_IPV4VLAN_VLAN2_FIELD].value.u16 = ri->domain;
+ ro->field[RTE_ACL_IPV4VLAN_SRC_FIELD].value.u32 = ri->src_addr;
+ ro->field[RTE_ACL_IPV4VLAN_DST_FIELD].value.u32 = ri->dst_addr;
+ ro->field[RTE_ACL_IPV4VLAN_SRCP_FIELD].value.u16 = ri->src_port_low;
+ ro->field[RTE_ACL_IPV4VLAN_DSTP_FIELD].value.u16 = ri->dst_port_low;
+
+ ro->field[RTE_ACL_IPV4VLAN_PROTO_FIELD].mask_range.u8 = ri->proto_mask;
+ ro->field[RTE_ACL_IPV4VLAN_VLAN1_FIELD].mask_range.u16 = ri->vlan_mask;
+ ro->field[RTE_ACL_IPV4VLAN_VLAN2_FIELD].mask_range.u16 =
+ ri->domain_mask;
+ ro->field[RTE_ACL_IPV4VLAN_SRC_FIELD].mask_range.u32 =
+ ri->src_mask_len;
+ ro->field[RTE_ACL_IPV4VLAN_DST_FIELD].mask_range.u32 = ri->dst_mask_len;
+ ro->field[RTE_ACL_IPV4VLAN_SRCP_FIELD].mask_range.u16 =
+ ri->src_port_high;
+ ro->field[RTE_ACL_IPV4VLAN_DSTP_FIELD].mask_range.u16 =
+ ri->dst_port_high;
+}
+
+/*
+ * Add ipv4vlan rules to an existing ACL context.
+ * This function is not multi-thread safe.
+ *
+ * @param ctx
+ * ACL context to add patterns to.
+ * @param rules
+ * Array of rules to add to the ACL context.
+ * Note that all fields in rte_acl_ipv4vlan_rule structures are expected
+ * to be in host byte order.
+ * @param num
+ * Number of elements in the input array of rules.
+ * @return
+ * - -ENOMEM if there is no space in the ACL context for these rules.
+ * - -EINVAL if the parameters are invalid.
+ * - Zero if operation completed successfully.
+ */
+static int
+rte_acl_ipv4vlan_add_rules(struct rte_acl_ctx *ctx,
+ const struct rte_acl_ipv4vlan_rule *rules,
+ uint32_t num)
+{
+ int32_t rc;
+ uint32_t i;
+ struct acl_ipv4vlan_rule rv;
+
+ if (ctx == NULL || rules == NULL)
+ return -EINVAL;
+
+ /* check input rules. */
+ for (i = 0; i != num; i++) {
+ rc = acl_ipv4vlan_check_rule(rules + i);
+ if (rc != 0) {
+ RTE_LOG(ERR, ACL, "%s: rule #%u is invalid\n",
+ __func__, i + 1);
+
[dpdk-dev] [PATCH v2 07/10] lpm: remove deprecated field
The library version is incremented.
Signed-off-by: Thomas Monjalon
Acked-by: Stephen Hemminger
Acked-by: Neil Horman
---
app/test/test_func_reentrancy.c | 4 ++--
app/test/test_lpm.c | 4 ++--
doc/guides/rel_notes/deprecation.rst | 3 ---
doc/guides/rel_notes/release_2_2.rst | 4 +++-
lib/librte_lpm/Makefile | 2 +-
lib/librte_lpm/rte_lpm.h | 11 ---
6 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/app/test/test_func_reentrancy.c b/app/test/test_func_reentrancy.c
index be61773..dbecc52 100644
--- a/app/test/test_func_reentrancy.c
+++ b/app/test/test_func_reentrancy.c
@@ -366,7 +366,7 @@ lpm_create_free(__attribute__((unused)) void *arg)
/* create the same lpm simultaneously on all threads */
for (i = 0; i < MAX_ITER_TIMES; i++) {
- lpm = rte_lpm_create("fr_test_once", SOCKET_ID_ANY, 4,
RTE_LPM_HEAP);
+ lpm = rte_lpm_create("fr_test_once", SOCKET_ID_ANY, 4, 0);
if ((NULL == lpm) && (rte_lpm_find_existing("fr_test_once") ==
NULL))
return -1;
}
@@ -374,7 +374,7 @@ lpm_create_free(__attribute__((unused)) void *arg)
/* create mutiple fbk tables simultaneously */
for (i = 0; i < MAX_LPM_ITER_TIMES; i++) {
snprintf(lpm_name, sizeof(lpm_name), "fr_test_%d_%d",
lcore_self, i);
- lpm = rte_lpm_create(lpm_name, SOCKET_ID_ANY, 4, RTE_LPM_HEAP);
+ lpm = rte_lpm_create(lpm_name, SOCKET_ID_ANY, 4, 0);
if (NULL == lpm)
return -1;
diff --git a/app/test/test_lpm.c b/app/test/test_lpm.c
index 6d8823e..8b4ded9 100644
--- a/app/test/test_lpm.c
+++ b/app/test/test_lpm.c
@@ -165,7 +165,7 @@ test2(void)
{
struct rte_lpm *lpm = NULL;
- lpm = rte_lpm_create(__func__, SOCKET_ID_ANY, MAX_RULES, RTE_LPM_HEAP);
+ lpm = rte_lpm_create(__func__, SOCKET_ID_ANY, MAX_RULES, 0);
TEST_LPM_ASSERT(lpm != NULL);
rte_lpm_free(lpm);
@@ -607,7 +607,7 @@ test10(void)
/* Add rule that covers a TBL24 range previously invalid & lookup
* (& delete & lookup) */
- lpm = rte_lpm_create(__func__, SOCKET_ID_ANY, MAX_RULES, RTE_LPM_HEAP);
+ lpm = rte_lpm_create(__func__, SOCKET_ID_ANY, MAX_RULES, 0);
TEST_LPM_ASSERT(lpm != NULL);
ip = IPv4(128, 0, 0, 0);
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index 3fa4c90..c40764a 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -18,9 +18,6 @@ Deprecation Notices
* The function rte_jhash2 is deprecated and should be removed.
-* The field mem_location of the rte_lpm structure is deprecated and should be
- removed as well as the macros RTE_LPM_HEAP and RTE_LPM_MEMZONE.
-
* The following fields have been deprecated in rte_eth_stats:
imissed, ibadcrc, ibadlen, imcasts, fdirmatch, fdirmiss,
tx_pause_xon, rx_pause_xon, tx_pause_xoff, rx_pause_xoff
diff --git a/doc/guides/rel_notes/release_2_2.rst
b/doc/guides/rel_notes/release_2_2.rst
index f0f67da..2a238c5 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -34,6 +34,8 @@ ABI Changes
* The dummy malloc library is removed. The content was moved into EAL in 2.1.
+* The LPM structure is changed. The deprecated field mem_location is removed.
+
Shared Library Versions
---
@@ -54,7 +56,7 @@ The libraries prepended with a plus sign were incremented in
this version.
librte_jobstats.so.1
librte_kni.so.1
librte_kvargs.so.1
- librte_lpm.so.1
+ + librte_lpm.so.2
+ librte_mbuf.so.2
librte_mempool.so.1
librte_meter.so.1
diff --git a/lib/librte_lpm/Makefile b/lib/librte_lpm/Makefile
index 0a7a888..688cfc9 100644
--- a/lib/librte_lpm/Makefile
+++ b/lib/librte_lpm/Makefile
@@ -39,7 +39,7 @@ CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR)
EXPORT_MAP := rte_lpm_version.map
-LIBABIVER := 1
+LIBABIVER := 2
# all source are stored in SRCS-y
SRCS-$(CONFIG_RTE_LIBRTE_LPM) := rte_lpm.c rte_lpm6.c
diff --git a/lib/librte_lpm/rte_lpm.h b/lib/librte_lpm/rte_lpm.h
index 11f0c04..c299ce2 100644
--- a/lib/librte_lpm/rte_lpm.h
+++ b/lib/librte_lpm/rte_lpm.h
@@ -56,16 +56,6 @@ extern "C" {
/** Max number of characters in LPM name. */
#define RTE_LPM_NAMESIZE32
-/** @deprecated Possible location to allocate memory. This was for last
- * parameter of rte_lpm_create(), but is now redundant. The LPM table is always
- * allocated in memory using librte_malloc which uses a memzone. */
-#define RTE_LPM_HEAP0
-
-/** @deprecated Possible location to allocate memory. This was for last
- * parameter of rte_lpm_create(), but is now redundant. The LPM table is always
- * allocated in memory using librte_malloc which uses a memzone. */
-#define RTE_LPM_MEMZONE 1
-
/** Maximum depth value possible for
[dpdk-dev] [PATCH v2 06/10] mem: remove dummy malloc library
The malloc library is now part of the EAL. Signed-off-by: Thomas Monjalon Acked-by: Stephen Hemminger Acked-by: Neil Horman --- MAINTAINERS| 1 - doc/guides/prog_guide/dev_kit_build_system.rst | 2 +- doc/guides/prog_guide/env_abstraction_layer.rst| 2 +- doc/guides/prog_guide/source_org.rst | 1 - .../thread_safety_intel_dpdk_functions.rst | 2 +- doc/guides/rel_notes/deprecation.rst | 5 --- doc/guides/rel_notes/release_2_2.rst | 3 +- lib/Makefile | 1 - lib/librte_malloc/Makefile | 48 -- lib/librte_malloc/rte_malloc_empty.c | 34 --- lib/librte_malloc/rte_malloc_version.map | 3 -- mk/rte.app.mk | 1 - 12 files changed, 5 insertions(+), 98 deletions(-) delete mode 100644 lib/librte_malloc/Makefile delete mode 100644 lib/librte_malloc/rte_malloc_empty.c delete mode 100644 lib/librte_malloc/rte_malloc_version.map diff --git a/MAINTAINERS b/MAINTAINERS index 17d4265..080a8e8 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -102,7 +102,6 @@ F: lib/librte_eal/common/include/rte_malloc.h F: lib/librte_eal/common/*malloc* F: lib/librte_eal/common/eal_common_mem* F: lib/librte_eal/common/eal_hugepages.h -F: lib/librte_malloc/ F: doc/guides/prog_guide/env_abstraction_layer.rst F: app/test/test_func_reentrancy.c F: app/test/test_malloc.c diff --git a/doc/guides/prog_guide/dev_kit_build_system.rst b/doc/guides/prog_guide/dev_kit_build_system.rst index 7dc2de6..dd3e3d0 100644 --- a/doc/guides/prog_guide/dev_kit_build_system.rst +++ b/doc/guides/prog_guide/dev_kit_build_system.rst @@ -85,7 +85,7 @@ Each build directory contains include files, libraries, and applications: librte_cmdline.a librte_lpm.a librte_mempool.a librte_ring.a -librte_eal.a librte_malloc.a librte_pmd_e1000.a librte_timer.a +librte_eal.a librte_pmd_e1000.a librte_timer.a ~/DEV/DPDK$ ls i686-native-linuxapp-gcc/include/ diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst index f1b3ff1..a03e40d 100644 --- a/doc/guides/prog_guide/env_abstraction_layer.rst +++ b/doc/guides/prog_guide/env_abstraction_layer.rst @@ -115,7 +115,7 @@ The physical address of the reserved memory for that memory zone is also returne .. note:: -Memory reservations done using the APIs provided by the rte_malloc library are also backed by pages from the hugetlbfs filesystem. +Memory reservations done using the APIs provided by rte_malloc are also backed by pages from the hugetlbfs filesystem. Xen Dom0 support without hugetbls ~ diff --git a/doc/guides/prog_guide/source_org.rst b/doc/guides/prog_guide/source_org.rst index b81e965..ae11b3b 100644 --- a/doc/guides/prog_guide/source_org.rst +++ b/doc/guides/prog_guide/source_org.rst @@ -74,7 +74,6 @@ The lib directory contains:: +-- librte_kni # Kernel NIC interface +-- librte_kvargs # Argument parsing library +-- librte_lpm # Longest prefix match library -+-- librte_malloc # Malloc-like functions +-- librte_mbuf # Packet and control mbuf manipulation +-- librte_mempool # Memory pool manager (fixed sized objects) +-- librte_meter# QoS metering library diff --git a/doc/guides/prog_guide/thread_safety_intel_dpdk_functions.rst b/doc/guides/prog_guide/thread_safety_intel_dpdk_functions.rst index 0034bf4..403e5fc 100644 --- a/doc/guides/prog_guide/thread_safety_intel_dpdk_functions.rst +++ b/doc/guides/prog_guide/thread_safety_intel_dpdk_functions.rst @@ -73,7 +73,7 @@ Performance Insensitive API Outside of the performance sensitive areas described in Section 25.1, the DPDK provides a thread-safe API for most other libraries. -For example, malloc(librte_malloc) and memzone functions are safe for use in multi-threaded and multi-process environments. +For example, malloc and memzone functions are safe for use in multi-threaded and multi-process environments. The setup and configuration of the PMD is not performance sensitive, but is not thread safe either. It is possible that the multiple read/writes during PMD setup and configuration could be corrupted in a multi-thread environment. diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 604a899..3fa4c90 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -21,11 +21,6 @@ Deprecation Notices * The field mem_location of the rte_lpm structure is deprecated and should be removed as well as the macros RTE_LPM_HEAP and RTE_LPM_MEMZONE. -* librte_malloc library has been integrated into librte_eal. The 2.1 release - creates a dummy/empty malloc library to fulfill binaries with dynamic linking - dependencies o
[dpdk-dev] [PATCH v2 05/10] eal: remove deprecated function
The function rte_eal_pci_close_one() was renamed rte_eal_pci_detach().
Signed-off-by: Thomas Monjalon
Acked-by: Stephen Hemminger
Acked-by: Neil Horman
---
doc/guides/rel_notes/deprecation.rst| 3 ---
doc/guides/rel_notes/release_2_2.rst| 3 +++
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 -
lib/librte_eal/common/eal_common_pci.c | 6 --
lib/librte_eal/common/include/rte_pci.h | 2 --
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 -
6 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index cf5cd17..604a899 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -13,9 +13,6 @@ Deprecation Notices
There is no backward compatibility planned from release 2.2.
All binaries will need to be rebuilt from release 2.2.
-* The EAL function rte_eal_pci_close_one is deprecated because renamed to
- rte_eal_pci_detach.
-
* The Macros RTE_HASH_BUCKET_ENTRIES_MAX and RTE_HASH_KEY_LENGTH_MAX are
deprecated and will be removed with version 2.2.
diff --git a/doc/guides/rel_notes/release_2_2.rst
b/doc/guides/rel_notes/release_2_2.rst
index 825c612..8a5b29a 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -16,6 +16,9 @@ Known Issues
API Changes
---
+* The function rte_eal_pci_close_one() is removed.
+ It was replaced by rte_eal_pci_detach().
+
ABI Changes
---
diff --git a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
index 2758848..64fdfb1 100644
--- a/lib/librte_eal/bsdapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/bsdapp/eal/rte_eal_version.map
@@ -40,7 +40,6 @@ DPDK_2.0 {
rte_eal_mp_remote_launch;
rte_eal_mp_wait_lcore;
rte_eal_parse_devargs_str;
- rte_eal_pci_close_one;
rte_eal_pci_dump;
rte_eal_pci_probe;
rte_eal_pci_probe_one;
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 16e8629..dcfe947 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -348,12 +348,6 @@ err_return:
return -1;
}
-int __attribute__ ((deprecated))
-rte_eal_pci_close_one(const struct rte_pci_addr *addr)
-{
- return rte_eal_pci_detach(addr);
-}
-
/*
* Detach device specified by its pci address.
*/
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 3fb2d3a..83e3c28 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -426,8 +426,6 @@ int rte_eal_pci_probe_one(const struct rte_pci_addr *addr);
* - Negative on error.
*/
int rte_eal_pci_detach(const struct rte_pci_addr *addr);
-int __attribute__ ((deprecated))
-rte_eal_pci_close_one(const struct rte_pci_addr *addr);
/**
* Dump the content of the PCI bus.
diff --git a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
index 59b1717..dbb8fa1 100644
--- a/lib/librte_eal/linuxapp/eal/rte_eal_version.map
+++ b/lib/librte_eal/linuxapp/eal/rte_eal_version.map
@@ -40,7 +40,6 @@ DPDK_2.0 {
rte_eal_mp_remote_launch;
rte_eal_mp_wait_lcore;
rte_eal_parse_devargs_str;
- rte_eal_pci_close_one;
rte_eal_pci_dump;
rte_eal_pci_probe;
rte_eal_pci_probe_one;
--
2.5.1
[dpdk-dev] [PATCH v2 04/10] ethdev: remove SCTP flow entries switch
The extended SCTP flow entries are now part of the standard API. Signed-off-by: Thomas Monjalon Acked-by: Stephen Hemminger Acked-by: Neil Horman --- app/test-pmd/cmdline.c | 4 doc/guides/rel_notes/deprecation.rst | 3 --- doc/guides/rel_notes/release_2_2.rst | 3 +++ drivers/net/i40e/i40e_fdir.c | 4 lib/librte_ether/rte_eth_ctrl.h | 4 5 files changed, 3 insertions(+), 15 deletions(-) diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index 5799c9c..0f8f48f 100644 --- a/app/test-pmd/cmdline.c +++ b/app/test-pmd/cmdline.c @@ -7888,12 +7888,10 @@ cmd_flow_director_filter_parsed(void *parsed_result, IPV4_ADDR_TO_UINT(res->ip_src, entry.input.flow.sctp4_flow.ip.src_ip); /* need convert to big endian. */ -#ifdef RTE_NEXT_ABI entry.input.flow.sctp4_flow.dst_port = rte_cpu_to_be_16(res->port_dst); entry.input.flow.sctp4_flow.src_port = rte_cpu_to_be_16(res->port_src); -#endif entry.input.flow.sctp4_flow.verify_tag = rte_cpu_to_be_32(res->verify_tag_value); break; @@ -7917,12 +7915,10 @@ cmd_flow_director_filter_parsed(void *parsed_result, IPV6_ADDR_TO_ARRAY(res->ip_src, entry.input.flow.sctp6_flow.ip.src_ip); /* need convert to big endian. */ -#ifdef RTE_NEXT_ABI entry.input.flow.sctp6_flow.dst_port = rte_cpu_to_be_16(res->port_dst); entry.input.flow.sctp6_flow.src_port = rte_cpu_to_be_16(res->port_src); -#endif entry.input.flow.sctp6_flow.verify_tag = rte_cpu_to_be_32(res->verify_tag_value); break; diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 639ab18..cf5cd17 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -44,9 +44,6 @@ Deprecation Notices flow director filtering in VF. The release 2.1 does not contain these ABI changes, but release 2.2 will, and no backwards compatibility is planned. -* ABI change is planned to extend the SCTP flow's key input from release 2.1. - The change may be enabled in the release 2.1 with CONFIG_RTE_NEXT_ABI. - * ABI changes are planned for struct rte_eth_fdir_filter and rte_eth_fdir_masks in order to support new flow director modes, MAC VLAN and Cloud, on x550. The MAC VLAN mode means the MAC and diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst index 3a6d2cc..825c612 100644 --- a/doc/guides/rel_notes/release_2_2.rst +++ b/doc/guides/rel_notes/release_2_2.rst @@ -23,6 +23,9 @@ ABI Changes * The EAL and ethdev structures rte_intr_handle and rte_eth_conf were changed to support Rx interrupt. It was already done in 2.1 for CONFIG_RTE_NEXT_ABI. +* The ethdev flow director entries for SCTP were changed. + It was already done in 2.1 for CONFIG_RTE_NEXT_ABI. + * The mbuf structure was changed to support unified packet type. It was already done in 2.1 for CONFIG_RTE_NEXT_ABI. diff --git a/drivers/net/i40e/i40e_fdir.c b/drivers/net/i40e/i40e_fdir.c index 8208273..c9ce98f 100644 --- a/drivers/net/i40e/i40e_fdir.c +++ b/drivers/net/i40e/i40e_fdir.c @@ -822,7 +822,6 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf, sctp = (struct sctp_hdr *)(raw_pkt + sizeof(struct ether_hdr) + sizeof(struct ipv4_hdr)); payload = (unsigned char *)sctp + sizeof(struct sctp_hdr); -#ifdef RTE_NEXT_ABI /* * The source and destination fields in the transmitted packet * need to be presented in a reversed order with respect @@ -830,7 +829,6 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf, */ sctp->src_port = fdir_input->flow.sctp4_flow.dst_port; sctp->dst_port = fdir_input->flow.sctp4_flow.src_port; -#endif sctp->tag = fdir_input->flow.sctp4_flow.verify_tag; break; @@ -873,7 +871,6 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf, sctp = (struct sctp_hdr *)(raw_pkt + sizeof(struct ether_hdr) + sizeof(struct ipv6_hdr)); payload = (unsigned char *)sctp + sizeof(struct sctp_hdr); -#ifdef RTE_NEXT_ABI /* * The source and destination fields in the transmitted packet * need to be presented in a reversed order with respect @@ -881,7 +878,6 @@ i40e_fdir_construct_pkt(struct i40e_pf *pf, */ sctp->src_port = fdir_input->flow.sctp6_flow.dst_port; sctp->dst_port = fdir_input->flow.sctp6_flow.src_port; -#endif
[dpdk-dev] [PATCH v2 03/10] mbuf: remove packet type from offload flags
The extended unified packet type is now part of the standard ABI.
As mbuf struct is changed, the mbuf library version is incremented.
Signed-off-by: Thomas Monjalon
Acked-by: Stephen Hemminger
Acked-by: Neil Horman
---
app/test-pipeline/pipeline_hash.c | 12 -
app/test-pmd/csumonly.c| 14 -
app/test-pmd/rxonly.c | 16 --
app/test/packet_burst_generator.c | 12 -
doc/guides/rel_notes/deprecation.rst | 5 -
doc/guides/rel_notes/release_2_2.rst | 5 +-
drivers/net/cxgbe/sge.c| 16 --
drivers/net/e1000/igb_rxtx.c | 34 ---
drivers/net/enic/enic_main.c | 25 --
drivers/net/fm10k/fm10k_rxtx.c | 15 --
drivers/net/i40e/i40e_rxtx.c | 293 -
drivers/net/ixgbe/ixgbe_rxtx.c | 87 --
drivers/net/ixgbe/ixgbe_rxtx_vec.c | 111
drivers/net/mlx4/mlx4.c| 29 --
drivers/net/vmxnet3/vmxnet3_rxtx.c | 8 -
examples/ip_fragmentation/main.c | 10 -
examples/ip_reassembly/main.c | 10 -
examples/l3fwd-acl/main.c | 27 --
examples/l3fwd-power/main.c| 9 -
examples/l3fwd/main.c | 114
examples/tep_termination/vxlan.c | 5 -
.../linuxapp/eal/include/exec-env/rte_kni_common.h | 6 -
lib/librte_mbuf/Makefile | 2 +-
lib/librte_mbuf/rte_mbuf.c | 10 -
lib/librte_mbuf/rte_mbuf.h | 28 +-
25 files changed, 6 insertions(+), 897 deletions(-)
diff --git a/app/test-pipeline/pipeline_hash.c
b/app/test-pipeline/pipeline_hash.c
index aa3f9e5..548615f 100644
--- a/app/test-pipeline/pipeline_hash.c
+++ b/app/test-pipeline/pipeline_hash.c
@@ -459,33 +459,21 @@ app_main_loop_rx_metadata(void) {
signature = RTE_MBUF_METADATA_UINT32_PTR(m, 0);
key = RTE_MBUF_METADATA_UINT8_PTR(m, 32);
-#ifdef RTE_NEXT_ABI
if (RTE_ETH_IS_IPV4_HDR(m->packet_type)) {
-#else
- if (m->ol_flags & PKT_RX_IPV4_HDR) {
-#endif
ip_hdr = (struct ipv4_hdr *)
&m_data[sizeof(struct ether_hdr)];
ip_dst = ip_hdr->dst_addr;
k32 = (uint32_t *) key;
k32[0] = ip_dst & 0xFF00;
-#ifdef RTE_NEXT_ABI
} else if (RTE_ETH_IS_IPV6_HDR(m->packet_type)) {
-#else
- } else {
-#endif
ipv6_hdr = (struct ipv6_hdr *)
&m_data[sizeof(struct ether_hdr)];
ipv6_dst = ipv6_hdr->dst_addr;
memcpy(key, ipv6_dst, 16);
-#ifdef RTE_NEXT_ABI
} else
continue;
-#else
- }
-#endif
*signature = test_hash(key, 0, 0);
}
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 1bf3485..e561dde 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -202,14 +202,9 @@ parse_ethernet(struct ether_hdr *eth_hdr, struct
testpmd_offload_info *info)
/* Parse a vxlan header */
static void
-#ifdef RTE_NEXT_ABI
parse_vxlan(struct udp_hdr *udp_hdr,
struct testpmd_offload_info *info,
uint32_t pkt_type)
-#else
-parse_vxlan(struct udp_hdr *udp_hdr, struct testpmd_offload_info *info,
- uint64_t mbuf_olflags)
-#endif
{
struct ether_hdr *eth_hdr;
@@ -217,12 +212,7 @@ parse_vxlan(struct udp_hdr *udp_hdr, struct
testpmd_offload_info *info,
* (rfc7348) or that the rx offload flag is set (i40e only
* currently) */
if (udp_hdr->dst_port != _htons(4789) &&
-#ifdef RTE_NEXT_ABI
RTE_ETH_IS_TUNNEL_PKT(pkt_type) == 0)
-#else
- (mbuf_olflags & (PKT_RX_TUNNEL_IPV4_HDR |
- PKT_RX_TUNNEL_IPV6_HDR)) == 0)
-#endif
return;
info->is_tunnel = 1;
@@ -559,11 +549,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
struct udp_hdr *udp_hdr;
udp_hdr = (struct udp_hdr *)((char *)l3_hdr +
info.l3_len);
-#ifdef RTE_NEXT_ABI
parse_vxlan(udp_hdr, &info, m->packet_type);
-#else
- parse_vxlan(udp_hdr, &info, m->ol_flags);
-#endif
} else if (info.l4_proto == IPPROTO_GRE) {
struct simple_gre_hdr *gre_hdr;
[dpdk-dev] [PATCH v2 02/10] ethdev: remove Rx interrupt switch
The Rx interrupt feature is now part of the standard ABI.
Because of changes in rte_intr_handle and struct rte_eth_conf,
the eal and ethdev library versions are incremented.
Signed-off-by: Thomas Monjalon
Acked-by: Stephen Hemminger
Acked-by: Neil Horman
---
doc/guides/rel_notes/deprecation.rst | 4 --
doc/guides/rel_notes/release_2_2.rst | 7 ++-
drivers/net/e1000/igb_ethdev.c | 26 ---
drivers/net/ixgbe/ixgbe_ethdev.c | 40
examples/l3fwd-power/main.c| 2 -
lib/librte_eal/bsdapp/eal/Makefile | 2 +-
.../bsdapp/eal/include/exec-env/rte_interrupts.h | 2 -
lib/librte_eal/linuxapp/eal/Makefile | 2 +-
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 53 --
.../linuxapp/eal/include/exec-env/rte_interrupts.h | 2 -
lib/librte_ether/Makefile | 2 +-
lib/librte_ether/rte_ethdev.c | 40
lib/librte_ether/rte_ethdev.h | 4 --
13 files changed, 8 insertions(+), 178 deletions(-)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index da17880..991a777 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -13,10 +13,6 @@ Deprecation Notices
There is no backward compatibility planned from release 2.2.
All binaries will need to be rebuilt from release 2.2.
-* ABI changes are planned for struct rte_intr_handle, struct rte_eth_conf
- and struct eth_dev_ops to support interrupt mode feature from release 2.1.
- Those changes may be enabled in the release 2.1 with CONFIG_RTE_NEXT_ABI.
-
* The EAL function rte_eal_pci_close_one is deprecated because renamed to
rte_eal_pci_detach.
diff --git a/doc/guides/rel_notes/release_2_2.rst
b/doc/guides/rel_notes/release_2_2.rst
index 494b4eb..388d2e3 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -20,6 +20,9 @@ API Changes
ABI Changes
---
+* The EAL and ethdev structures rte_intr_handle and rte_eth_conf were changed
+ to support Rx interrupt. It was already done in 2.1 for CONFIG_RTE_NEXT_ABI.
+
Shared Library Versions
---
@@ -28,12 +31,12 @@ The libraries prepended with a plus sign were incremented
in this version.
.. code-block:: diff
- libethdev.so.1
+ + libethdev.so.2
librte_acl.so.1
librte_cfgfile.so.1
librte_cmdline.so.1
librte_distributor.so.1
- librte_eal.so.1
+ + librte_eal.so.2
librte_hash.so.1
librte_ip_frag.so.1
librte_ivshmem.so.1
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index c7e6d55..848ef6e 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -106,9 +106,7 @@ static int eth_igb_flow_ctrl_get(struct rte_eth_dev *dev,
static int eth_igb_flow_ctrl_set(struct rte_eth_dev *dev,
struct rte_eth_fc_conf *fc_conf);
static int eth_igb_lsc_interrupt_setup(struct rte_eth_dev *dev);
-#ifdef RTE_NEXT_ABI
static int eth_igb_rxq_interrupt_setup(struct rte_eth_dev *dev);
-#endif
static int eth_igb_interrupt_get_status(struct rte_eth_dev *dev);
static int eth_igb_interrupt_action(struct rte_eth_dev *dev);
static void eth_igb_interrupt_handler(struct rte_intr_handle *handle,
@@ -232,7 +230,6 @@ static int igb_timesync_read_rx_timestamp(struct
rte_eth_dev *dev,
uint32_t flags);
static int igb_timesync_read_tx_timestamp(struct rte_eth_dev *dev,
struct timespec *timestamp);
-#ifdef RTE_NEXT_ABI
static int eth_igb_rx_queue_intr_enable(struct rte_eth_dev *dev,
uint16_t queue_id);
static int eth_igb_rx_queue_intr_disable(struct rte_eth_dev *dev,
@@ -241,7 +238,6 @@ static void eth_igb_assign_msix_vector(struct e1000_hw *hw,
int8_t direction,
uint8_t queue, uint8_t msix_vector);
static void eth_igb_write_ivar(struct e1000_hw *hw, uint8_t msix_vector,
uint8_t index, uint8_t offset);
-#endif
static void eth_igb_configure_msix_intr(struct rte_eth_dev *dev);
/*
@@ -303,10 +299,8 @@ static const struct eth_dev_ops eth_igb_ops = {
.vlan_tpid_set= eth_igb_vlan_tpid_set,
.vlan_offload_set = eth_igb_vlan_offload_set,
.rx_queue_setup = eth_igb_rx_queue_setup,
-#ifdef RTE_NEXT_ABI
.rx_queue_intr_enable = eth_igb_rx_queue_intr_enable,
.rx_queue_intr_disable = eth_igb_rx_queue_intr_disable,
-#endif
.rx_queue_release = eth_igb_rx_queue_release,
.rx_queue_count = eth_igb_rx_queue_count,
.rx_descriptor_done = eth_igb_rx_descriptor_done,
@@ -893,9 +887,7 @@ eth_igb_start(struct rte_eth_dev *dev)
E1000_
[dpdk-dev] [PATCH v2 01/10] doc: init next release notes
Signed-off-by: Thomas Monjalon --- doc/guides/rel_notes/index.rst | 1 + doc/guides/rel_notes/release_2_2.rst | 58 2 files changed, 59 insertions(+) create mode 100644 doc/guides/rel_notes/release_2_2.rst diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst index d01cbc8..d8cadeb 100644 --- a/doc/guides/rel_notes/index.rst +++ b/doc/guides/rel_notes/index.rst @@ -40,6 +40,7 @@ Contents :numbered: rel_description +release_2_2 release_2_1 release_2_0 release_1_8 diff --git a/doc/guides/rel_notes/release_2_2.rst b/doc/guides/rel_notes/release_2_2.rst new file mode 100644 index 000..494b4eb --- /dev/null +++ b/doc/guides/rel_notes/release_2_2.rst @@ -0,0 +1,58 @@ +DPDK Release 2.2 + + +New Features + + + +Resolved Issues +--- + + +Known Issues + + + +API Changes +--- + + +ABI Changes +--- + + +Shared Library Versions +--- + +The libraries prepended with a plus sign were incremented in this version. + +.. code-block:: diff + + libethdev.so.1 + librte_acl.so.1 + librte_cfgfile.so.1 + librte_cmdline.so.1 + librte_distributor.so.1 + librte_eal.so.1 + librte_hash.so.1 + librte_ip_frag.so.1 + librte_ivshmem.so.1 + librte_jobstats.so.1 + librte_kni.so.1 + librte_kvargs.so.1 + librte_lpm.so.1 + librte_malloc.so.1 + librte_mbuf.so.1 + librte_mempool.so.1 + librte_meter.so.1 + librte_pipeline.so.1 + librte_pmd_bond.so.1 + librte_pmd_ring.so.1 + librte_port.so.1 + librte_power.so.1 + librte_reorder.so.1 + librte_ring.so.1 + librte_sched.so.1 + librte_table.so.1 + librte_timer.so.1 + librte_vhost.so.1 -- 2.5.1
[dpdk-dev] [PATCH v2 00/10] clean deprecated code
Before starting a new integration cycle (2.2.0-rc0), the deprecated code is removed. The hash library is not cleaned in this patchset and would be better done by its maintainers. Bruce, Pablo, please check the file doc/guides/rel_notes/deprecation.rst. Changes in v2: - increment KNI and ring PMD versions - list library versions in release notes - list API/ABI changes in release notes Stephen Hemminger (2): kni: remove deprecated functions ring: remove deprecated functions Thomas Monjalon (8): doc: init next release notes ethdev: remove Rx interrupt switch mbuf: remove packet type from offload flags ethdev: remove SCTP flow entries switch eal: remove deprecated function mem: remove dummy malloc library lpm: remove deprecated field acl: remove old API MAINTAINERS| 1 - app/test-acl/main.c| 17 ++ app/test-pipeline/pipeline_hash.c | 12 - app/test-pmd/cmdline.c | 4 - app/test-pmd/csumonly.c| 14 - app/test-pmd/rxonly.c | 16 -- app/test/Makefile | 6 - app/test/packet_burst_generator.c | 12 - app/test/test_acl.c| 194 ++ app/test/test_acl.h| 59 + app/test/test_func_reentrancy.c| 4 +- app/test/test_kni.c| 36 --- app/test/test_lpm.c| 4 +- doc/guides/prog_guide/dev_kit_build_system.rst | 2 +- doc/guides/prog_guide/env_abstraction_layer.rst| 2 +- doc/guides/prog_guide/kernel_nic_interface.rst | 2 - doc/guides/prog_guide/source_org.rst | 1 - .../thread_safety_intel_dpdk_functions.rst | 2 +- doc/guides/rel_notes/deprecation.rst | 33 --- doc/guides/rel_notes/index.rst | 1 + doc/guides/rel_notes/release_2_2.rst | 81 ++ doc/guides/sample_app_ug/kernel_nic_interface.rst | 9 - drivers/net/cxgbe/sge.c| 16 -- drivers/net/e1000/igb_ethdev.c | 26 -- drivers/net/e1000/igb_rxtx.c | 34 --- drivers/net/enic/enic_main.c | 25 -- drivers/net/fm10k/fm10k_rxtx.c | 15 -- drivers/net/i40e/i40e_fdir.c | 4 - drivers/net/i40e/i40e_rxtx.c | 293 - drivers/net/ixgbe/ixgbe_ethdev.c | 40 --- drivers/net/ixgbe/ixgbe_rxtx.c | 87 -- drivers/net/ixgbe/ixgbe_rxtx_vec.c | 111 drivers/net/mlx4/mlx4.c| 29 -- drivers/net/ring/Makefile | 2 +- drivers/net/ring/rte_eth_ring.c| 56 drivers/net/ring/rte_eth_ring.h| 3 - drivers/net/ring/rte_eth_ring_version.map | 2 - drivers/net/vmxnet3/vmxnet3_rxtx.c | 8 - examples/ip_fragmentation/main.c | 10 - examples/ip_reassembly/main.c | 10 - examples/l3fwd-acl/main.c | 44 ++-- examples/l3fwd-power/main.c| 11 - examples/l3fwd/main.c | 114 examples/tep_termination/vxlan.c | 5 - lib/Makefile | 1 - lib/librte_acl/Makefile| 2 +- lib/librte_acl/rte_acl.c | 170 lib/librte_acl/rte_acl.h | 104 lib/librte_acl/rte_acl_version.map | 2 - lib/librte_eal/bsdapp/eal/Makefile | 2 +- .../bsdapp/eal/include/exec-env/rte_interrupts.h | 2 - lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 - lib/librte_eal/common/eal_common_pci.c | 6 - lib/librte_eal/common/include/rte_pci.h| 2 - lib/librte_eal/linuxapp/eal/Makefile | 2 +- lib/librte_eal/linuxapp/eal/eal_interrupts.c | 53 .../linuxapp/eal/include/exec-env/rte_interrupts.h | 2 - .../linuxapp/eal/include/exec-env/rte_kni_common.h | 6 - lib/librte_eal/linuxapp/eal/rte_eal_version.map| 1 - lib/librte_ether/Makefile | 2 +- lib/librte_ether/rte_eth_ctrl.h| 4 - lib/librte_ether/rte_ethdev.c | 40 --- lib/librte_ether/rte_ethdev.h | 4 - lib/librte_kni/Makefile| 2 +- lib/librte_kni/rte_kni.c | 51 lib/librte_kni/rte_kni.h | 54 lib/librte_kni/rte_kni_version.map | 3 - lib/librte_lpm/Makefile| 2 +- lib/librte
[dpdk-dev] rte_eal_init() alternative?
2015-09-02 13:56, Bruce Richardson: > On Wed, Sep 02, 2015 at 12:49:40PM +, Montorsi, Francesco wrote: > > Hi all, > > > > Currently it seems that the only way to initialize EAL is using > > rte_eal_init() function, correct? > > > > I have the problem that rte_eal_init() will call rte_panic() whenever > > something fails to initialize or in other cases it will call exit(). > > In my application, I would rather like to attempt DPDK initialization. If > > it fails I don't want to exit. > > Unfortunately I cannot even copy&paste the rte_eal_init() code into my > > application (removing rte_panic and exit calls) since it uses a lot of DPDK > > internal private functions. > > > > I think that my requirements (avoid abort/exit calls when init fails) is a > > basic requirement... would you accept a patch that adds an alternative > > rte_eal_init() function that just returns an error code upon failure, > > instead of immediately exiting? > > > > Thanks for your hard work! > > > > Francesco Montorsi > > > I, for one, would welcome such a patch. I think the code is overly quick in > many places to panic or exit the app, when an error code would be more > appropriate. > Feel free to also look at other libraries in DPDK too, if you like :-) Yes but please, do not create an alternative init function. We just need to replace panic/exit with error codes and be sure that apps and examples handle them correctly. Thanks
[dpdk-dev] libdpdk upstream changes for ecosystem best practices
Hi, We?re looking at packaging DPDK in Ubuntu. We?d like to discuss upstream changes to better integrate DPDK into Linux distributions. Here?s a summary of what we need: 1) Define one library ABI (soname and sover) that we can use instead of the split build. 2) Fix #includes so we don't have to include config.h 3) Put headers into /usr/include/dpdk instead of /usr/include You can see our current packaging progress at https://git.launchpad.net/~ubuntu-server/dpdk/log/?h=ubuntu-wily and a test PPA at https://launchpad.net/~smb/+archive/ubuntu/dpdk/ First, it would be easier for us to ship a single binary package that ships a single shared library to cover all of DPDK that library consumers might need, rather than having it split up as you do. I understand the build system is capable of doing this already, but what we don?t have is a well defined soname and sover (currently parameterized in the build) for ABI compatibility purposes. As a binary distribution, this is something that we?d expect upstream to define, since normally we expect to achieve binary compatibility across all distributions at this level in the stack. So I have the following requests: So that we can get DPDK packaging into Ubuntu immediately, please could we agree to define (and burn) libdpdk.so.0 to be the ABI that builds with upstream release 2.0.0 when built with the native-linuxapp-gcc template options plus the following changes: CONFIG_RTE_MACHINE=?default? CONFIG_RTE_APP_TEST=n CONFIG_LIBRTE_VHOST=y CONFIG_RTE_EAL_IGB_UIO=n CONFIG_RTE_LIBRTE_KNI=n CONFIG_RTE_BUILD_COMBINE_LIBS=y CONFIG_RTE_BUILD_SHARED_LIB=y CONFIG_RTE_LIBNAME=?dpdk? The combined library would be placed into /usr/lib/$(ARCH)-linux-gnu/ where it can be found without modification to the library search path. We want to ship it like this in Ubuntu anyway, but I?d prefer upstream to have defined it as such since then we?ll have a proper definition of the ABI that can be shared across distributions and other consumers any time ABI compatibility is expected. Though not strictly part of a shared library ABI, I also propose some build-related upstream changes at API level below, that I?d like to also ship in the initial Ubuntu packaging of the header files. Clearly you cannot make this change in an existing release, but I propose that you do this for your next release so all library consumers will see a consistent and standard API interface. If you agree to this, then I?d also like to ship the Ubuntu package with patches to do the same thing in your current release. Right now, I understand that library consumers need to either: 1) use the upstream-provided build system (.mk files etc); or 2) otherwise make sure to include rte_config.h by specifying it as an extra CPPFLAGS parameter as the upstream API documentation does not require its inclusion use in source files. This is problematic because somebody writing against multiple libraries should just expect to #include the API-defined headers and link simply with -l for the build to work. It is common to have a config.h type file generated at build time, but in this case I?d expect it to be conditionally included automatically as part of the API, for example by #include?ing it in any file the API _does_ define that library users must include. To fix this, I propose to #include in every header file that library users may #include according to the API. That brings me to paths. To avoid polluting the /usr/include namespace, I?d expect either a single /usr/include/dpdk.h, or everything inside /usr/include/dpdk/, or both. Then library consumers would #include combinations of and as required, our packaging could install into these directories without stealing any other part of the shared filesystem namespace, and library users wouldn?t have to be concerned about paths, configuration or build systems. This would then match every other shared library we package. Does this sound reasonable to you? Is this a change you will accept? Thanks, Robie
[dpdk-dev] "cannot use T= with gcov target" when doing "makefile clean" with DPDK-2.1.0
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Montorsi, Francesco > Sent: Friday, August 28, 2015 10:07 AM > To: dev at dpdk.org > Subject: [dpdk-dev] "cannot use T= with gcov target" when doing "makefile > clean" with DPDK-2.1.0 > > Hi all, > > I found that after unzipping dpdk-2.1.0.tar.gz if I run: ># make T=x86_64-native-linuxapp-gcc O=x86_64-native-linuxapp-gcc > config > And then > # make V=1 T=x86_64-native-linuxapp-gcc O=x86_64-native-linuxapp-gcc > clean > > I get: > > [...] > == Clean app/proc_info > make -f /home/fmontorsi/Downloads/dpdk-2.1.0/GNUmakefile gcovclean make -f > /home/fmontorsi/Downloads/dpdk-2.1.0/mk/rte.sdkgcov.mk gcovclean > /home/fmontorsi/Downloads/dpdk-2.1.0/mk/rte.sdkgcov.mk:34: *** "Cannot use > T= with gcov target". Stop. > make[2]: *** [gcovclean] Error 2 > make[1]: *** [clean] Error 2 > make: *** [clean] Error 2 > > I guess the fix is: > Hi Francesco, That fix seems reasonable and you should submit it as a patch. There may be other ways to fix this (there are several ways to fix things within the build system) but if you submit a patch we can get some comments. John. --
[dpdk-dev] rte_eal_init() alternative?
On Wed, Sep 02, 2015 at 12:49:40PM +, Montorsi, Francesco wrote: > Hi all, > > Currently it seems that the only way to initialize EAL is using > rte_eal_init() function, correct? > > I have the problem that rte_eal_init() will call rte_panic() whenever > something fails to initialize or in other cases it will call exit(). > In my application, I would rather like to attempt DPDK initialization. If it > fails I don't want to exit. > Unfortunately I cannot even copy&paste the rte_eal_init() code into my > application (removing rte_panic and exit calls) since it uses a lot of DPDK > internal private functions. > > I think that my requirements (avoid abort/exit calls when init fails) is a > basic requirement... would you accept a patch that adds an alternative > rte_eal_init() function that just returns an error code upon failure, instead > of immediately exiting? > > Thanks for your hard work! > > Francesco Montorsi > I, for one, would welcome such a patch. I think the code is overly quick in many places to panic or exit the app, when an error code would be more appropriate. Feel free to also look at other libraries in DPDK too, if you like :-) Regards, /Bruce
[dpdk-dev] [PATCH RFC 2/2] i40e: Enlarge the number of supported queues
It enlarges the number of supported queues to hardware allowed
maximum. There was a software limitation of 64 per physical port
which is not reasonable.
Signed-off-by: Helin Zhang
---
config/common_bsdapp | 3 +-
config/common_linuxapp | 3 +-
drivers/net/i40e/i40e_ethdev.c | 138 +
drivers/net/i40e/i40e_ethdev.h | 8 +++
4 files changed, 69 insertions(+), 83 deletions(-)
diff --git a/config/common_bsdapp b/config/common_bsdapp
index b37dcf4..dac6dad 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -141,7 +141,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y
CONFIG_RTE_LIBRTE_ETHER=y
CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
CONFIG_RTE_MAX_ETHPORTS=32
-CONFIG_RTE_MAX_QUEUES_PER_PORT=256
+CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
CONFIG_RTE_LIBRTE_IEEE1588=n
CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
@@ -187,6 +187,7 @@ CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
# interval up to 8160 us, aligned to 2 (or default value)
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 0de43d5..2ce8d66 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -139,7 +139,7 @@ CONFIG_RTE_LIBRTE_KVARGS=y
CONFIG_RTE_LIBRTE_ETHER=y
CONFIG_RTE_LIBRTE_ETHDEV_DEBUG=n
CONFIG_RTE_MAX_ETHPORTS=32
-CONFIG_RTE_MAX_QUEUES_PER_PORT=256
+CONFIG_RTE_MAX_QUEUES_PER_PORT=1024
CONFIG_RTE_LIBRTE_IEEE1588=n
CONFIG_RTE_ETHDEV_QUEUE_STAT_CNTRS=16
CONFIG_RTE_ETHDEV_RXTX_CALLBACKS=y
@@ -185,6 +185,7 @@ CONFIG_RTE_LIBRTE_I40E_DEBUG_TX_FREE=n
CONFIG_RTE_LIBRTE_I40E_DEBUG_DRIVER=n
CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
+CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
# interval up to 8160 us, aligned to 2 (or default value)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index b538446..4060dcf 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2239,113 +2239,88 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
{
struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
struct i40e_hw *hw = I40E_PF_TO_HW(pf);
- uint16_t sum_queues = 0, sum_vsis, left_queues;
+ uint16_t qp_count = 0, vsi_count = 0;
- /* First check if FW support SRIOV */
if (dev->pci_dev->max_vfs && !hw->func_caps.sr_iov_1_1) {
PMD_INIT_LOG(ERR, "HW configuration doesn't support SRIOV");
return -EINVAL;
}
pf->flags = I40E_FLAG_HEADER_SPLIT_DISABLED;
- pf->max_num_vsi = RTE_MIN(hw->func_caps.num_vsis, I40E_MAX_NUM_VSIS);
- PMD_INIT_LOG(INFO, "Max supported VSIs:%u", pf->max_num_vsi);
- /* Allocate queues for pf */
- if (hw->func_caps.rss) {
- pf->flags |= I40E_FLAG_RSS;
- pf->lan_nb_qps = RTE_MIN(hw->func_caps.num_tx_qp,
- (uint32_t)(1 << hw->func_caps.rss_table_entry_width));
- pf->lan_nb_qps = i40e_align_floor(pf->lan_nb_qps);
- } else
+ pf->max_num_vsi = hw->func_caps.num_vsis;
+ pf->lan_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF;
+ pf->vmdq_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM;
+ pf->vf_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF;
+
+ /* FDir queue/VSI allocation */
+ pf->fdir_qp_offset = 0;
+ if (hw->func_caps.fd) {
+ pf->flags |= I40E_FLAG_FDIR;
+ pf->fdir_nb_qps = I40E_DEFAULT_QP_NUM_FDIR;
+ } else {
+ pf->fdir_nb_qps = 0;
+ }
+ qp_count += pf->fdir_nb_qps;
+ vsi_count += 1;
+
+ /* LAN queue/VSI allocation */
+ pf->lan_qp_offset = pf->fdir_qp_offset + pf->fdir_nb_qps;
+ if (!hw->func_caps.rss) {
pf->lan_nb_qps = 1;
- sum_queues = pf->lan_nb_qps;
- /* Default VSI is not counted in */
- sum_vsis = 0;
- PMD_INIT_LOG(INFO, "PF queue pairs:%u", pf->lan_nb_qps);
+ } else {
+ pf->flags |= I40E_FLAG_RSS;
+ pf->lan_nb_qps = pf->lan_nb_qp_max;
+ }
+ qp_count += pf->lan_nb_qps;
+ vsi_count += 1;
+ /* VF queue/VSI allocation */
+ pf->vf_qp_offset = pf->lan_qp_offset + pf->lan_nb_qps;
if (hw->func_caps.sr_iov_1_1 && dev->pci_dev->max_vfs) {
pf->flags |= I40E_FLAG_SRIOV;
pf->vf_nb_qps = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
- if (dev->pci_dev->max_vfs > hw->func_caps.num_vfs) {
- PMD_INIT_LOG(ERR, "Config VF number %u, "
-"max supported %u.",
-dev->pci_dev->max_vfs,
[dpdk-dev] [PATCH RFC 1/2] i40e: adjust the number of queues for RSS
It adjusts the number of queues for RSS from power of 2 to any as
long as it does not exceeds the hardware allowed.
Signed-off-by: Helin Zhang
---
drivers/net/i40e/i40e_ethdev.c| 8
drivers/net/i40e/i40e_ethdev_vf.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 40b0526..b538446 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -5152,12 +5152,12 @@ i40e_pf_config_rss(struct i40e_pf *pf)
* If both VMDQ and RSS enabled, not all of PF queues are configured.
* It's necessary to calulate the actual PF queues that are configured.
*/
- if (pf->dev_data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_VMDQ_FLAG) {
+ if (pf->dev_data->dev_conf.rxmode.mq_mode & ETH_MQ_RX_VMDQ_FLAG)
num = i40e_pf_calc_configured_queues_num(pf);
- num = i40e_align_floor(num);
- } else
- num = i40e_align_floor(pf->dev_data->nb_rx_queues);
+ else
+ num = pf->dev_data->nb_rx_queues;
+ num = RTE_MIN(num, I40E_MAX_Q_PER_TC);
PMD_INIT_LOG(INFO, "Max of contiguous %u PF queues are configured",
num);
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c
b/drivers/net/i40e/i40e_ethdev_vf.c
index b694400..b15ff7b 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -1915,7 +1915,7 @@ i40evf_config_rss(struct i40e_vf *vf)
return 0;
}
- num = i40e_align_floor(vf->dev_data->nb_rx_queues);
+ num = RTE_MIN(vf->dev_data->nb_rx_queues, I40E_MAX_QP_NUM_PER_VF);
/* Fill out the look up table */
for (i = 0, j = 0; i < nb_q; i++, j++) {
if (j >= num)
--
1.9.3
[dpdk-dev] [PATCH RFC 0/2] i40e: enlarge the number of supported queues
There was a software limitation of 64 queues, it should be enlarged to the hardware allowed maximum. As all the queues are shared among PF, VFs and VMDq, the number of queues supported in PF, VFs and VMDq may vary. Helin Zhang (2): i40e: adjust the number of queues for RSS i40e: Enlarge the number of supported queues config/common_bsdapp | 3 +- config/common_linuxapp| 3 +- drivers/net/i40e/i40e_ethdev.c| 146 -- drivers/net/i40e/i40e_ethdev.h| 8 +++ drivers/net/i40e/i40e_ethdev_vf.c | 2 +- 5 files changed, 74 insertions(+), 88 deletions(-) -- 1.9.3
[dpdk-dev] rte_eal_init() alternative?
Hi all, Currently it seems that the only way to initialize EAL is using rte_eal_init() function, correct? I have the problem that rte_eal_init() will call rte_panic() whenever something fails to initialize or in other cases it will call exit(). In my application, I would rather like to attempt DPDK initialization. If it fails I don't want to exit. Unfortunately I cannot even copy&paste the rte_eal_init() code into my application (removing rte_panic and exit calls) since it uses a lot of DPDK internal private functions. I think that my requirements (avoid abort/exit calls when init fails) is a basic requirement... would you accept a patch that adds an alternative rte_eal_init() function that just returns an error code upon failure, instead of immediately exiting? Thanks for your hard work! Francesco Montorsi
[dpdk-dev] rte_eal_init() alternative?
On Wed, 2 Sep 2015 18:17:40 + Don Provan wrote: > Thomas Monjalon: > >Yes but please, do not create an alternative init function. > >We just need to replace panic/exit with error codes and be sure that apps > >and examples handle them correctly. > > I understand your concerns, but the panics are really just the tip of the > iceberg of the EAL library not realizing it's a library. It really makes no > sense to think the library should define the application's command line, or > that the PCI bus should be probed without considering whether this > application is going to use PCI, and or to insist that EAL work be done on > internal EAL threads. > > So I'd say it's way past time to consider revamping initialization to start > the process of ending the DPDK library's tail wagging the application's dog. > Naturally this would have to be done while retaining the existing init > routine on top of a real library initialization, but that's just an > unfortunate artifact of the library's history, not a rational design decision > for moving forward. > > -don provan > You are welcome to submit patches with what you are proposing for review. Theoretical requirements discussions will probably only result in more mail, not new code. You know what you want, propose a solution. As far as the command line. That is easily managed by realizing the application doesn't have to pass the original command line into EAL. If you just view the command line as a way to pass unstructured options; the application or infrastructure can build up new values and pass it in. I agree that initialization itself should try and not fail except in the most extreme cases. "ie I can't find /sys what is wrong" and should try and adapt more "you asked for 128 cpu's but I see only 2, log it and continue"
[dpdk-dev] [PATCH] app/test-pmd: Detect NUMA socket count
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Stephen Hurd > Sent: Friday, August 21, 2015 3:25 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] app/test-pmd: Detect NUMA socket count > > Currently, there is a MAX_SOCKET macro which artificially limits the > number of NUMA sockets testpmd can use. Anything on a higher socket > ends up using socket zero. This patch replaces this with a variable > set during set_default_fwd_lcores_config() and uses > RTE_MAX_NUMA_NODES > where a hard-coded max number of sockets is required. > > Signed-off-by: Stephen Hurd Acked-by: Pablo de Lara
[dpdk-dev] [PATCH v2] e1000: implement igb xstats
This patch implements the extended statistics API for the e1000 igb,
adding xstats_get() and xstats_reset() functions. The implementation
is similar to that of the ixgbe driver as merged in dpdk 2.1.
Signed-off-by: Harry van Haaren
---
Version 2:
Removed stats counting fixes, will submit in seperate patch
Version 1:
Initial functionality, included stats counting fix
drivers/net/e1000/igb_ethdev.c | 130 +++--
1 file changed, 126 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index c7e6d55..f457d7a 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -96,7 +96,10 @@ static int eth_igb_link_update(struct rte_eth_dev *dev,
int wait_to_complete);
static void eth_igb_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *rte_stats);
+static int eth_igb_xstats_get(struct rte_eth_dev *dev,
+ struct rte_eth_xstats *xstats, unsigned n);
static void eth_igb_stats_reset(struct rte_eth_dev *dev);
+static void eth_igb_xstats_reset(struct rte_eth_dev *dev);
static void eth_igb_infos_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static void eth_igbvf_infos_get(struct rte_eth_dev *dev,
@@ -296,7 +299,9 @@ static const struct eth_dev_ops eth_igb_ops = {
.allmulticast_disable = eth_igb_allmulticast_disable,
.link_update = eth_igb_link_update,
.stats_get= eth_igb_stats_get,
+ .xstats_get = eth_igb_xstats_get,
.stats_reset = eth_igb_stats_reset,
+ .xstats_reset = eth_igb_xstats_reset,
.dev_infos_get= eth_igb_infos_get,
.mtu_set = eth_igb_mtu_set,
.vlan_filter_set = eth_igb_vlan_filter_set,
@@ -360,6 +365,72 @@ static const struct eth_dev_ops igbvf_eth_dev_ops = {
.get_reg = igbvf_get_regs,
};
+/* store statistics names and its offset in stats structure */
+struct rte_igb_xstats_name_off {
+ char name[RTE_ETH_XSTATS_NAME_SIZE];
+ unsigned offset;
+};
+
+static const struct rte_igb_xstats_name_off rte_igb_stats_strings[] = {
+ {"rx_crc_errors", offsetof(struct e1000_hw_stats, crcerrs)},
+ {"rx_align_errors", offsetof(struct e1000_hw_stats, algnerrc)},
+ {"rx_symbol_errors", offsetof(struct e1000_hw_stats, symerrs)},
+ {"rx_errors", offsetof(struct e1000_hw_stats, rxerrc)},
+ {"rx_missed_packets", offsetof(struct e1000_hw_stats, mpc)},
+ {"tx_single_collisions", offsetof(struct e1000_hw_stats, scc)},
+ {"tx_excessive_collisions", offsetof(struct e1000_hw_stats, ecol)},
+ {"tx_multiple_collisions", offsetof(struct e1000_hw_stats, mcc)},
+ {"tx_late_collisions", offsetof(struct e1000_hw_stats, latecol)},
+ {"tx_total_collisions", offsetof(struct e1000_hw_stats, colc)},
+ {"tx_defers", offsetof(struct e1000_hw_stats, dc)},
+ {"tx_with_no_carrier_sense", offsetof(struct e1000_hw_stats, tncrs)},
+ {"rx_carrier_ext_errors", offsetof(struct e1000_hw_stats, cexterr)},
+ {"rx_length_errors", offsetof(struct e1000_hw_stats, rlec)},
+ {"rx_xon_packets", offsetof(struct e1000_hw_stats, xonrxc)},
+ {"tx_xon_packets", offsetof(struct e1000_hw_stats, xontxc)},
+ {"rx_xoff_packets", offsetof(struct e1000_hw_stats, xoffrxc)},
+ {"tx_xoff_packets", offsetof(struct e1000_hw_stats, xofftxc)},
+ {"rx_flow_control_unsupported", offsetof(struct e1000_hw_stats, fcruc)},
+ {"rx_size_64", offsetof(struct e1000_hw_stats, prc64)},
+ {"rx_size_65_to_127", offsetof(struct e1000_hw_stats, prc127)},
+ {"rx_size_128_to_255", offsetof(struct e1000_hw_stats, prc255)},
+ {"rx_size_256_to_511", offsetof(struct e1000_hw_stats, prc511)},
+ {"rx_size_512_to_1023", offsetof(struct e1000_hw_stats, prc1023)},
+ {"rx_size_1023_to_max", offsetof(struct e1000_hw_stats, prc1522)},
+ {"rx_broadcast_packets", offsetof(struct e1000_hw_stats, bprc)},
+ {"rx_multicast_packets", offsetof(struct e1000_hw_stats, mprc)},
+ {"rx_good_packets", offsetof(struct e1000_hw_stats, gprc)},
+ {"tx_good_packets", offsetof(struct e1000_hw_stats, gptc)},
+ {"rx_good_bytes", offsetof(struct e1000_hw_stats, gorc)},
+ {"tx_good_bytes", offsetof(struct e1000_hw_stats, gotc)},
+ {"rx_no_buffer_errors", offsetof(struct e1000_hw_stats, rnbc)},
+ {"rx_undersize_packets", offsetof(struct e1000_hw_stats, ruc)},
+ {"rx_fragment_packets", offsetof(struct e1000_hw_stats, rfc)},
+ {"rx_oversize_packets", offsetof(struct e1000_hw_stats, roc)},
+ {"rx_jabber_packets", offsetof(struct e1000_hw_stats, rjc)},
+ {"rx_management_packets", offsetof(struct e1000_hw_stats, mgprc)},
+ {"rx_management_dropped", offsetof(struct e1000_hw_stats, mgpd
[dpdk-dev] Fast Failover Test Results
Am 01.09.2015 um 18:03 schrieb Declan Doherty: > > > On 01/09/15 14:31, Stefan Binna wrote: >> Hi @all, >> >> I've conducted some fast failover tests on a SDN infrastructure, whereby >> following three configurations were used for the device under test >> (DUT): >> >> - Intel 82574L with default driver e1000e >> - Intel 82574L with DPDK >> - Realtek RTL8111/8168/8411 PCI Express with default driver r8169 >> >> There were two paths connected to the DUT, e.g. Path 1 and Path 2. >> So by default Path 1 had been used. When Path 1 was disconnected, the >> time it took to switch to Path 2 had been measured by counting the lost >> packets. >> Several tests have been conducted and the median calculated. >> >> Terminology: >> >> Median FF: Median fast failover time / ms >> Median LP: Median lost packets / packet(s) >> >> Median FF Median LP >> >> DPDK17003363 >> Intel 350 690 >> Realtek 350 695 >> >> Anyone an idea why DPDK is so "slow"? >> >> Best regards, >> Stefan. > > Hey Stefan, > > A couple of questions regarding your setup which will hopefully help > me figure out what the issue is. > > - Are you just running in active backup mode or are you using one of > the other bonding modes. > - What is down stream of the DUT, is it a switch or are you just > directly connected to another system? > > I'm not sure if the 82574L has LSC interrupt support in DPDK, I'll > check that out, but if it doesn't the PMD need will be polling the > link status which could be slowing down detection of the link going > down and the fail over to the over port. > > Declan > > Hi Declan, regarding your first question I think that I use the active backup mode, but I didn't define anything special. What I did was starting OpenvSwitch with DPDK using following command(s): # Start OVS with DPDK portion using 2GB of node 0 memory ./ovs/vswitchd/ovs-vswitchd --dpdk -c 0xf -n 4 --socket-mem 2048,0 -- unix:/usr/local/var/run/openvswitch/db.sock --pidfile --detach Afterwards I added the interfaces which have been bound to the igb_uio driver as "dpdk interfaces": ./ovs/utilities/ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk sleep 0.5 ./ovs/utilities/ovs-vsctl add-port br0 dpdk1 -- set Interface dpdk1 type=dpdk sleep 0.5 ./ovs/utilities/ovs-vsctl add-port br0 dpdk2 -- set Interface dpdk2 type=dpdk sleep 0.5 The downstream of the DUT is connected to another switch. Here is a network diagram: http://abload.de/img/ff_testbed_dpdk28sah.png whereby al40-118 is the DUT, al40-115 the sender and al40-111 the receiver. Thanks very much. Stefan.
[dpdk-dev] rte_eal_init() alternative?
On Wed, Sep 2, 2015 at 7:56 AM, Bruce Richardson wrote: > On Wed, Sep 02, 2015 at 12:49:40PM +, Montorsi, Francesco wrote: > > Hi all, > > > > Currently it seems that the only way to initialize EAL is using > rte_eal_init() function, correct? > > > > I have the problem that rte_eal_init() will call rte_panic() whenever > something fails to initialize or in other cases it will call exit(). > > In my application, I would rather like to attempt DPDK initialization. > If it fails I don't want to exit. > > Unfortunately I cannot even copy&paste the rte_eal_init() code into my > application (removing rte_panic and exit calls) since it uses a lot of DPDK > internal private functions. > > > > I think that my requirements (avoid abort/exit calls when init fails) is > a basic requirement... would you accept a patch that adds an alternative > rte_eal_init() function that just returns an error code upon failure, > instead of immediately exiting? > > > > Thanks for your hard work! > > > > Francesco Montorsi > > > I, for one, would welcome such a patch. I think the code is overly quick in > many places to panic or exit the app, when an error code would be more > appropriate. > Feel free to also look at other libraries in DPDK too, if you like :-) > > Regards, > /Bruce > +1
[dpdk-dev] [PATCH] acl: Improve acl_bld.c sort_rules()
> -Original Message- > From: Mark Smith [mailto:marks439 at gmail.com] > Sent: Wednesday, August 26, 2015 8:25 PM > To: Ananyev, Konstantin; dev at dpdk.org > Cc: rsanford at akamai.com; marsmith at akamai.com > Subject: [PATCH] acl: Improve acl_bld.c sort_rules() > > Replace O(n^2) list sort with an O(n log n) merge sort. > The merge sort is based on the solution suggested in: > http://cslibrary.stanford.edu/105/LinkedListProblems.pdf > Tested sort_rules() improvement: > 100K rules: O(n^2): 31382 milliseconds; O(n log n): 10 milliseconds > 259K rules: O(n^2): 133753 milliseconds; O(n log n): 22 milliseconds > > Signed-off-by: Mark Smith Acked-by: Konstantin Ananyev > ---
[dpdk-dev] libdpdk upstream changes for ecosystem best practices
On Wed, 02 Sep 2015 16:18:33 +0200 Thomas Monjalon wrote: > Hi, > > 2015-09-02 14:49, Robie Basak: > > Hi, > > > > We?re looking at packaging DPDK in Ubuntu. We?d like to discuss upstream > > Nice This matches what we do internally. I was heading towards making this a real Debian package. Since Debian is more free and is a superset of Ubuntu. > > > changes to better integrate DPDK into Linux distributions. Here?s a > > summary of what we need: > > > > 1) Define one library ABI (soname and sover) that we can use instead of the > > split build. > > > > 2) Fix #includes so we don't have to include config.h > > > > 3) Put headers into /usr/include/dpdk instead of /usr/include > > > > You can see our current packaging progress at > > https://git.launchpad.net/~ubuntu-server/dpdk/log/?h=ubuntu-wily and a > > Thanks for sharing I have made basically the same decisions. Target is /usr/include/dpdk and the library version comes from rte config. It seems more logical to make the library shared object version equal the major version of DPDK (ie 2) rather than having shared object and source versions diverge. Just updating to 2.1 packaging now, will send patches.
[dpdk-dev] [PATCH 0/9] clean deprecated code
On Tue, Sep 01, 2015 at 10:18:08PM +0200, Thomas Monjalon wrote: > Before starting a new integration cycle (2.2.0-rc0), > the deprecated code is removed. > > The hash library is not cleaned in this patchset and would be > better done by its maintainers. Bruce, Pablo, please check the > file doc/guides/rel_notes/deprecation.rst. > > Stephen Hemminger (2): > kni: remove deprecated functions > ring: remove deprecated functions > > Thomas Monjalon (7): > ethdev: remove Rx interrupt switch > mbuf: remove packet type from offload flags > ethdev: remove SCTP flow entries switch > eal: remove deprecated function > mem: remove dummy malloc library > lpm: remove deprecated field > acl: remove old API > > MAINTAINERS| 1 - > app/test-acl/main.c| 17 ++ > app/test-pipeline/pipeline_hash.c | 12 - > app/test-pmd/cmdline.c | 4 - > app/test-pmd/csumonly.c| 14 - > app/test-pmd/rxonly.c | 16 -- > app/test/Makefile | 6 - > app/test/packet_burst_generator.c | 12 - > app/test/test_acl.c| 194 ++ > app/test/test_acl.h| 59 + > app/test/test_func_reentrancy.c| 4 +- > app/test/test_kni.c| 36 --- > app/test/test_lpm.c| 4 +- > doc/guides/prog_guide/dev_kit_build_system.rst | 2 +- > doc/guides/prog_guide/env_abstraction_layer.rst| 2 +- > doc/guides/prog_guide/kernel_nic_interface.rst | 2 - > doc/guides/prog_guide/source_org.rst | 1 - > .../thread_safety_intel_dpdk_functions.rst | 2 +- > doc/guides/rel_notes/deprecation.rst | 33 --- > doc/guides/sample_app_ug/kernel_nic_interface.rst | 9 - > drivers/net/cxgbe/sge.c| 16 -- > drivers/net/e1000/igb_ethdev.c | 26 -- > drivers/net/e1000/igb_rxtx.c | 34 --- > drivers/net/enic/enic_main.c | 25 -- > drivers/net/fm10k/fm10k_rxtx.c | 15 -- > drivers/net/i40e/i40e_fdir.c | 4 - > drivers/net/i40e/i40e_rxtx.c | 293 > - > drivers/net/ixgbe/ixgbe_ethdev.c | 40 --- > drivers/net/ixgbe/ixgbe_rxtx.c | 87 -- > drivers/net/ixgbe/ixgbe_rxtx_vec.c | 111 > drivers/net/mlx4/mlx4.c| 29 -- > drivers/net/ring/rte_eth_ring.c| 56 > drivers/net/ring/rte_eth_ring.h| 3 - > drivers/net/ring/rte_eth_ring_version.map | 2 - > drivers/net/vmxnet3/vmxnet3_rxtx.c | 8 - > examples/ip_fragmentation/main.c | 10 - > examples/ip_reassembly/main.c | 10 - > examples/l3fwd-acl/main.c | 44 ++-- > examples/l3fwd-power/main.c| 11 - > examples/l3fwd/main.c | 114 > examples/tep_termination/vxlan.c | 5 - > lib/Makefile | 1 - > lib/librte_acl/Makefile| 2 +- > lib/librte_acl/rte_acl.c | 170 > lib/librte_acl/rte_acl.h | 104 > lib/librte_acl/rte_acl_version.map | 2 - > lib/librte_eal/bsdapp/eal/Makefile | 2 +- > .../bsdapp/eal/include/exec-env/rte_interrupts.h | 2 - > lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 - > lib/librte_eal/common/eal_common_pci.c | 6 - > lib/librte_eal/common/include/rte_pci.h| 2 - > lib/librte_eal/linuxapp/eal/Makefile | 2 +- > lib/librte_eal/linuxapp/eal/eal_interrupts.c | 53 > .../linuxapp/eal/include/exec-env/rte_interrupts.h | 2 - > .../linuxapp/eal/include/exec-env/rte_kni_common.h | 6 - > lib/librte_eal/linuxapp/eal/rte_eal_version.map| 1 - > lib/librte_ether/Makefile | 2 +- > lib/librte_ether/rte_eth_ctrl.h| 4 - > lib/librte_ether/rte_ethdev.c | 40 --- > lib/librte_ether/rte_ethdev.h | 4 - > lib/librte_kni/rte_kni.c | 51 > lib/librte_kni/rte_kni.h | 54 > lib/librte_kni/rte_kni_version.map | 3 - > lib/librte_lpm/Makefile| 2 +- > lib/librte_lpm/rte_lpm.h | 11 - > lib/librte_malloc/Makefile | 48 > lib/librte_malloc/rte_malloc_empty.c | 34 -
