[dpdk-dev] [dpdk-announce] DPDK 1.6.0r2 released
The new release can be downloaded here: http://dpdk.org/browse/dpdk/tag/?id=v1.6.0r2 Changelog - fixes for: * various build errors * initialization with NUMA * rbx register corruption * offload flags were lost when cloning packets * igb/ixgbe ports locked and skipped * ixgbe port failed to initialize due to wrong timer * vmxnet3 and virtio failed to initialize - enhancements: * core mask is checked * devargs handles PCI and virtual devices arguments * vdev replaces nonpci registration * no dynamic library loading forced in current directory * dump commands in testpmd * flow director support for X540 * vmxnet3 and virtio libraries suffixed with _uio * igb_uio_bind.py renamed pci_unbind.py * RPM recipe Next release will be 1.7.0. New features, design changes and big reworks must be sent in the next 2 weeks to have a chance to be accepted in 1.7. Thank you to everyone, -- Thomas
[dpdk-dev] [dpdk-announce] memnic 1.1 released
The new release can be downloaded here: http://dpdk.org/browse/memnic/tag/?id=v1.1 Changelog - fixes for: * race condition when transmitting to host * build for Linux >= 3.3 - enhancements: * statistics in PMD * multiple segments transmission (PMD only) * compiler optimizations * various cleanups * RPM recipe Thank you to everyone, -- Thomas
[dpdk-dev] [dpdk-announce] vmxnet3-usermap 1.2 released
The new release can be downloaded here: http://dpdk.org/browse/vmxnet3-usermap/tag/?id=v1.2 Changelog - enhancements: * various cleanups * RPM recipe -- Thomas
[dpdk-dev] [dpdk-announce] virtio-net-pmd 1.2 released
The new release can be downloaded here: http://dpdk.org/browse/virtio-net-pmd/tag/?id=v1.2 Changelog - fixes for: * probing failed for PCI id having letters * Tx queue header was wrongly initialized - enhancements: * various cleanups * RPM recipe Thank you to everyone, -- Thomas
[dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation
Hi again David/Didier, > Can I suggest to do an RTE_MAX between (internal_config.memory - > total_mem) and (internal_config.memory * cpu_per_socket[socket_id] + > rte_lcore_count() - 1) / rte_lcore_count() ? I don't think it's a good idea > to go > over the requested amount. Let the last core have a chance of reserving > slightly less memory than other cores, but don't let it go over the limit. If > specific memory constraints are required, let the user use --socket-mem > instead. Sorry for spamming, but now that I think of it, I don't believe this change makes much sense. If the user wants memory on specific sockets, there's already --socket-mem option. If the user doesn't care, there's -m option, which gives the user memory from whatever sockets it is available. With this change applied, DPDK will fail when run with -m switch under certain circumstances (e.g. cores from socket 0 present in the coremask but no memory left on socket 0), which is quite the opposite of a simple "give me n megs, I don't care where it comes from" option -m is providing. Best regards, Anatoly Burakov DPDK SW Engineer -- 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
[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK
Hi Stephen, > Will this work in guest? or only on bare metal? VFIO is Linux-only, and in theory will be able to work on the guest, but not at the moment, since it requires IOMMU. There was a GSoC proposal for KVM to do IOMMU implementation, and there were a few AMD IOMMU-emulation patches floating around the KVM lists for some time, but nothing has made it into release yet. Best regards, Anatoly Burakov DPDK SW Engineer -- 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
[dpdk-dev] [PATCH 00/16] [RFC] [VFIO] Add VFIO support to DPDK
Hi Chris, > hmm, vfio requires iommu support, however virtio pmd? That's correct, virtio will not work with VFIO as it stands. However it's not the fault of this patch but rather lack of emulated IOMMU on the guest :-) Best regards, Anatoly Burakov DPDK SW Engineer -- 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
[dpdk-dev] [PATCH 16/16] [RFC] [VFIO] Adding support for VFIO to setup.sh
Hi Stephen,
> >
> > #
> > +# Unloads VFIO modules.
> > +#
> > +remove_vfio_module()
> > +{
> > + echo "Unloading any existing VFIO module"
> > + /sbin/lsmod | grep -s vfio > /dev/null
> > + if [ $? -eq 0 ] ; then
> > + sudo /sbin/rmmod vfio-pci
> > + sudo /sbin/rmmod vfio_iommu_type1
> > + sudo /sbin/rmmod vfio
> > + fi
> > +}
> > +
>
> Won't this break if KVM is using vfio and running DPDK application as well.
Yes, just as if you would try to unload igb_uio while DPDK apps are running.
Presumably, the user isn't going to try that just as he's not going to try that
with igb_uio. So I see no issue here.
Best regards,
Anatoly Burakov
DPDK SW Engineer
--
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
[dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation
Agree with Anatoly - I would much rather not change legacy option behaviour that has existed for a while, especially when --socket-mem is available to do exactly what is needed. -Venky -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Burakov, Anatoly Sent: Friday, May 02, 2014 1:54 AM To: Burakov, Anatoly; David Marchand; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH RFC] eal: change default per socket memory allocation Hi again David/Didier, > Can I suggest to do an RTE_MAX between (internal_config.memory - > total_mem) and (internal_config.memory * cpu_per_socket[socket_id] + > rte_lcore_count() - 1) / rte_lcore_count() ? I don't think it's a good > idea to go over the requested amount. Let the last core have a chance > of reserving slightly less memory than other cores, but don't let it > go over the limit. If specific memory constraints are required, let > the user use --socket-mem instead. Sorry for spamming, but now that I think of it, I don't believe this change makes much sense. If the user wants memory on specific sockets, there's already --socket-mem option. If the user doesn't care, there's -m option, which gives the user memory from whatever sockets it is available. With this change applied, DPDK will fail when run with -m switch under certain circumstances (e.g. cores from socket 0 present in the coremask but no memory left on socket 0), which is quite the opposite of a simple "give me n megs, I don't care where it comes from" option -m is providing. Best regards, Anatoly Burakov DPDK SW Engineer -- 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
[dpdk-dev] [PATCH 01/15 v2] makefiles: Fixed -share command line option error
On Wed, Apr 30, 2014 at 01:42:12AM +0200, Thomas Monjalon wrote: > 2014-04-16 09:51, Neil Horman: > > The shared libraries built with the current makefile set produce static > > libraries rather than actual shared objects. This is due to several missing > > options that are required to correctly build shared objects using ld, as > > well as a mis-specified -share option (which should be -shared). Switching > > to the use of CC rather than LD and fixing the -shared option corrects > > these problems and builds the DSOs correctly. > > > > Signed-off-by: Neil Horman > > Applied for version 1.6.0r2. > > Thanks > -- > Thomas > So, I just went and looked at 1.6.0r2 and noted that you applied this patch, but the rest of the series is still missing. This is what I was talking about earlier when I said you weren't applying patch series atomically. It makes it impossible to have any clue what the upstream development head is going to look like. On top of that, since you're clearly integrating other changes ahead of this, theres every likelyhood the rest of my v5 series won't apply. the v5 series has sat out here for a few weeks now without comment. If there aren't any objections to it, apply it. Whats the problem here? I'm not going to package the DPDK until this series (or the functionality it offers) is in place. Neil
[dpdk-dev] [PATCH 01/15 v2] makefiles: Fixed -share command line option error
2014-05-02 07:09, Neil Horman: > On Wed, Apr 30, 2014 at 01:42:12AM +0200, Thomas Monjalon wrote: > > 2014-04-16 09:51, Neil Horman: > > > The shared libraries built with the current makefile set produce static > > > libraries rather than actual shared objects. This is due to several > > > missing options that are required to correctly build shared objects > > > using ld, as well as a mis-specified -share option (which should be > > > -shared). Switching to the use of CC rather than LD and fixing the > > > -shared option corrects these problems and builds the DSOs correctly. > > > > > > Signed-off-by: Neil Horman > > > > Applied for version 1.6.0r2. > > So, I just went and looked at 1.6.0r2 and noted that you applied this patch, > but the rest of the series is still missing. This is what I was talking > about earlier when I said you weren't applying patch series atomically. It > makes it impossible to have any clue what the upstream development head is > going to look like. On top of that, since you're clearly integrating other > changes ahead of this, theres every likelyhood the rest of my v5 series > won't apply. > > the v5 series has sat out here for a few weeks now without comment. If there > aren't any objections to it, apply it. Whats the problem here? I'm not > going to package the DPDK until this series (or the functionality it > offers) is in place. This patch is clearly an important fix. So I took it for release 1.6.0r2. The other patches of the serie are enhancements which will be in 1.7.0. The goal is to change the integration model. Now we'll stop integrating enhancements and big changes when first release candidate is out. Then it will be clear that only fixes and mandatory changes will be integrated in the last part of the release cycle. I hope you agree we're improving the workflow. -- Thomas
[dpdk-dev] [PATCH 01/15 v2] makefiles: Fixed -share command line option error
On Fri, May 02, 2014 at 02:22:17PM +0200, Thomas Monjalon wrote: > 2014-05-02 07:09, Neil Horman: > > On Wed, Apr 30, 2014 at 01:42:12AM +0200, Thomas Monjalon wrote: > > > 2014-04-16 09:51, Neil Horman: > > > > The shared libraries built with the current makefile set produce static > > > > libraries rather than actual shared objects. This is due to several > > > > missing options that are required to correctly build shared objects > > > > using ld, as well as a mis-specified -share option (which should be > > > > -shared). Switching to the use of CC rather than LD and fixing the > > > > -shared option corrects these problems and builds the DSOs correctly. > > > > > > > > Signed-off-by: Neil Horman > > > > > > Applied for version 1.6.0r2. > > > > So, I just went and looked at 1.6.0r2 and noted that you applied this patch, > > but the rest of the series is still missing. This is what I was talking > > about earlier when I said you weren't applying patch series atomically. It > > makes it impossible to have any clue what the upstream development head is > > going to look like. On top of that, since you're clearly integrating other > > changes ahead of this, theres every likelyhood the rest of my v5 series > > won't apply. > > > > the v5 series has sat out here for a few weeks now without comment. If there > > aren't any objections to it, apply it. Whats the problem here? I'm not > > going to package the DPDK until this series (or the functionality it > > offers) is in place. > > This patch is clearly an important fix. So I took it for release 1.6.0r2. > The other patches of the serie are enhancements which will be in 1.7.0. > > The goal is to change the integration model. > Now we'll stop integrating enhancements and big changes when first release > candidate is out. Then it will be clear that only fixes and mandatory changes > will be integrated in the last part of the release cycle. > > I hope you agree we're improving the workflow. Apologies to you Thomas, and the rest of the 6wind list. He just explained to me that patch applications ni 1.6.0r2 aren't inherited by 1.7.0 so the entire patch series will need to be reapplied to 1.7.0. The workflow is atypical to me, but I should have seen that, given there is no master branch. Sorry for the outburst. Neil > -- > Thomas >
[dpdk-dev] [PATCH 01/15 v2] makefiles: Fixed -share command line option error
2014-05-02 09:01, Neil Horman: > On Fri, May 02, 2014 at 02:22:17PM +0200, Thomas Monjalon wrote: > > 2014-05-02 07:09, Neil Horman: > > > On Wed, Apr 30, 2014 at 01:42:12AM +0200, Thomas Monjalon wrote: > > > > 2014-04-16 09:51, Neil Horman: > > > > > The shared libraries built with the current makefile set produce > > > > > static > > > > > libraries rather than actual shared objects. This is due to several > > > > > missing options that are required to correctly build shared objects > > > > > using ld, as well as a mis-specified -share option (which should be > > > > > -shared). Switching to the use of CC rather than LD and fixing the > > > > > -shared option corrects these problems and builds the DSOs > > > > > correctly. > > > > > > > > > > Signed-off-by: Neil Horman > > > > > > > > Applied for version 1.6.0r2. > > > > > > So, I just went and looked at 1.6.0r2 and noted that you applied this > > > patch, but the rest of the series is still missing. This is what I was > > > talking about earlier when I said you weren't applying patch series > > > atomically. It makes it impossible to have any clue what the upstream > > > development head is going to look like. On top of that, since you're > > > clearly integrating other changes ahead of this, theres every > > > likelyhood the rest of my v5 series won't apply. > > > > > > the v5 series has sat out here for a few weeks now without comment. If > > > there aren't any objections to it, apply it. Whats the problem here? > > > I'm not going to package the DPDK until this series (or the > > > functionality it offers) is in place. > > > > This patch is clearly an important fix. So I took it for release 1.6.0r2. > > The other patches of the serie are enhancements which will be in 1.7.0. > > > > The goal is to change the integration model. > > Now we'll stop integrating enhancements and big changes when first release > > candidate is out. Then it will be clear that only fixes and mandatory > > changes will be integrated in the last part of the release cycle. > > > > I hope you agree we're improving the workflow. > > Apologies to you Thomas, and the rest of the 6wind list. He just explained > to me that patch applications ni 1.6.0r2 aren't inherited by 1.7.0 so the > entire patch series will need to be reapplied to 1.7.0. Sorry, you misunderstood :) I'm starting a master branch from 1.6.0r2. So the rest of you serie will be applied on master branch where 1.7.0 is going to live. I won't split patch serie anymore. Apologies for the confusion. -- Thomas
[dpdk-dev] [PATCH] mk: sort config templates listing
The config templates can be seen with "make showconfigs", "make config" or "make help". It's easier to read if it's sorted. Signed-off-by: Thomas Monjalon --- mk/rte.sdkconfig.mk | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk index b4e45f2..a96beeb 100644 --- a/mk/rte.sdkconfig.mk +++ b/mk/rte.sdkconfig.mk @@ -35,9 +35,9 @@ showversion: $(RTE_SRCDIR)/lib/librte_eal/common/include/rte_version.h | \ tr '\n' '.' | sed -r 's,\.([0-9]+)\.$$,r\1\n,' -INSTALL_CONFIGS := $(filter-out %~,\ +INSTALL_CONFIGS := $(sort $(filter-out %~,\ $(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\ - $(wildcard $(RTE_SRCDIR)/config/defconfig_*))) + $(wildcard $(RTE_SRCDIR)/config/defconfig_* INSTALL_TARGETS := $(addsuffix _install,$(INSTALL_CONFIGS)) .PHONY: showconfigs -- 1.9.2
[dpdk-dev] [PATCH] mk: sort config templates listing
On 05/02/2014 03:28 PM, Thomas Monjalon wrote: > The config templates can be seen with "make showconfigs", "make config" or > "make help". It's easier to read if it's sorted. > > Signed-off-by: Thomas Monjalon > --- > mk/rte.sdkconfig.mk | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mk/rte.sdkconfig.mk b/mk/rte.sdkconfig.mk > index b4e45f2..a96beeb 100644 > --- a/mk/rte.sdkconfig.mk > +++ b/mk/rte.sdkconfig.mk > @@ -35,9 +35,9 @@ showversion: > $(RTE_SRCDIR)/lib/librte_eal/common/include/rte_version.h | \ > tr '\n' '.' | sed -r 's,\.([0-9]+)\.$$,r\1\n,' > > -INSTALL_CONFIGS := $(filter-out %~,\ > +INSTALL_CONFIGS := $(sort $(filter-out %~,\ > $(patsubst $(RTE_SRCDIR)/config/defconfig_%,%,\ > - $(wildcard $(RTE_SRCDIR)/config/defconfig_*))) > + $(wildcard $(RTE_SRCDIR)/config/defconfig_* > INSTALL_TARGETS := $(addsuffix _install,$(INSTALL_CONFIGS)) > > .PHONY: showconfigs > Acked-by: Olivier Matz
[dpdk-dev] [PATCH 0/5] Various patches to 1.6.0r2
These are updated versions of some of the earlier patches I sent. Plus some more changes that are helpful when interacting with mempool/zone etc.
[dpdk-dev] [PATCH 1/5] spelling fixes
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/bsdapp/eal/eal.c |2 +-
lib/librte_eal/bsdapp/eal/include/exec-env/rte_kni_common.h |2 +-
lib/librte_eal/common/include/i686/arch/rte_atomic.h | 10 +-
lib/librte_eal/common/include/rte_atomic.h| 10 +-
lib/librte_eal/common/include/rte_eal.h |2 +-
lib/librte_eal/common/include/rte_interrupts.h|2 +-
lib/librte_eal/linuxapp/eal/eal.c |2 +-
lib/librte_eal/linuxapp/eal/eal_interrupts.c |4 ++--
lib/librte_eal/linuxapp/eal/eal_memory.c |2 +-
lib/librte_eal/linuxapp/eal/eal_xen_memory.c |2 +-
lib/librte_eal/linuxapp/eal/include/exec-env/rte_kni_common.h |2 +-
lib/librte_eal/linuxapp/igb_uio/igb_uio.c |2 +-
lib/librte_eal/linuxapp/kni/ethtool/igb/e1000_mbx.c |2 +-
lib/librte_eal/linuxapp/kni/ethtool/igb/igb.h |2 +-
lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c|2 +-
lib/librte_eal/linuxapp/kni/ethtool/igb/igb_ptp.c |2 +-
lib/librte_eal/linuxapp/kni/ethtool/igb/igb_vmdq.c|4 ++--
lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h |2 +-
lib/librte_eal/linuxapp/xen_dom0/dom0_mm_misc.c |2 +-
lib/librte_kni/rte_kni.h |4 ++--
lib/librte_mempool/rte_mempool.c |4 ++--
lib/librte_mempool/rte_mempool.h |8
lib/librte_pmd_e1000/e1000/e1000_82571.c |2 +-
lib/librte_pmd_e1000/e1000/e1000_mbx.c|4 ++--
lib/librte_pmd_e1000/em_ethdev.c |2 +-
lib/librte_pmd_e1000/em_rxtx.c|2 +-
lib/librte_pmd_e1000/igb_ethdev.c |2 +-
lib/librte_pmd_ixgbe/ixgbe/ixgbe_mbx.c|4 ++--
lib/librte_pmd_ixgbe/ixgbe_bypass.c |6 +++---
lib/librte_pmd_ixgbe/ixgbe_bypass_api.h |4 ++--
lib/librte_pmd_ixgbe/ixgbe_ethdev.c |2 +-
lib/librte_pmd_ixgbe/ixgbe_rxtx.c |2 +-
lib/librte_pmd_ixgbe/ixgbe_rxtx.h |4 ++--
lib/librte_pmd_ring/rte_eth_ring.c|2 +-
lib/librte_pmd_virtio/virtio_rxtx.c |2 +-
lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c |2 +-
lib/librte_pmd_xenvirt/rte_eth_xenvirt.c |2 +-
lib/librte_ring/rte_ring.h|2 +-
38 files changed, 59 insertions(+), 59 deletions(-)
--- a/lib/librte_eal/bsdapp/eal/eal.c 2014-05-02 16:31:11.287562789 -0700
+++ b/lib/librte_eal/bsdapp/eal/eal.c 2014-05-02 16:31:11.279562742 -0700
@@ -782,7 +782,7 @@ int rte_eal_has_hugepages(void)
return !internal_config.no_hugetlbfs;
}
-/* Abstraction for port I/0 privilage */
+/* Abstraction for port I/0 privilege */
static int
rte_eal_iopl_init(void)
{
--- a/lib/librte_eal/bsdapp/eal/include/exec-env/rte_kni_common.h
2014-05-02 16:31:11.287562789 -0700
+++ b/lib/librte_eal/bsdapp/eal/include/exec-env/rte_kni_common.h
2014-05-02 16:31:11.279562742 -0700
@@ -92,7 +92,7 @@ struct rte_kni_request {
/*
* Fifo struct mapped in a shared memory. It describes a circular buffer FIFO
- * Write and read should wrap arround. Fifo is empty when write == read
+ * Write and read should wrap around. Fifo is empty when write == read
* Writing should never overwrite the read position
*/
struct rte_kni_fifo {
--- a/lib/librte_eal/common/include/i686/arch/rte_atomic.h 2014-05-02
16:31:11.287562789 -0700
+++ b/lib/librte_eal/common/include/i686/arch/rte_atomic.h 2014-05-02
16:31:11.279562742 -0700
@@ -216,7 +216,7 @@ rte_atomic64_add(rte_atomic64_t *v, int6
* @param v
* A pointer to the atomic counter.
* @param dec
- * The value to be substracted from the counter.
+ * The value to be subtracted from the counter.
*/
static inline void
rte_atomic64_sub(rte_atomic64_t *v, int64_t dec)
@@ -287,14 +287,14 @@ rte_atomic64_add_return(rte_atomic64_t *
* Subtract a 64-bit value from an atomic counter and return the result.
*
* Atomically subtracts the 64-bit value (dec) from the atomic counter (v)
- * and returns the value of v after the substraction.
+ * and returns the value of v after the subtraction.
*
* @param v
* A pointer to the atomic counter.
* @param dec
- * The value to be substracted from the counter.
+ * The value to be subtracted from the counter.
* @return
- * The value of v after the substraction.
+ * The value of v after the subtraction.
*/
static inline int64_t
rte
[dpdk-dev] [PATCH 2/5] dont inline string functions
It makes no sense to inline string functions, in fact snprintf
can't be inlined because the function supports variable number of
arguments.
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/bsdapp/eal/Makefile |1
lib/librte_eal/common/eal_common_string_fns.c | 96 +
lib/librte_eal/common/include/rte_string_fns.h | 57 +-
lib/librte_eal/linuxapp/eal/Makefile |1
4 files changed, 102 insertions(+), 53 deletions(-)
--- a/lib/librte_eal/bsdapp/eal/Makefile2014-05-02 16:31:12.519570116
-0700
+++ b/lib/librte_eal/bsdapp/eal/Makefile2014-05-02 16:31:12.519570116
-0700
@@ -67,6 +67,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) +=
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_tailqs.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_errno.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_cpuflags.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_string_fns.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_hexdump.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_devargs.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_vdev.c
--- /dev/null 1970-01-01 00:00:00.0 +
+++ b/lib/librte_eal/common/eal_common_string_fns.c 2014-05-02
16:31:12.519570116 -0700
@@ -0,0 +1,96 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+
+#include
+
+/* safe version os snprintf */
+int
+rte_snprintf(char *buffer, int buflen, const char *format, ...)
+{
+ int len;
+ va_list ap;
+
+ if (buffer == NULL && buflen != 0)
+ goto einval_error;
+ if (format == NULL) {
+ if (buflen > 0)
+ buffer[0] = '\0';
+ goto einval_error;
+ }
+
+ va_start(ap, format);
+ len = vsnprintf(buffer, buflen, format, ap);
+ va_end(ap);
+ if (len >= buflen && buflen > 0)
+ buffer[buflen - 1] = '\0';
+
+ return len;
+
+einval_error:
+ errno = EINVAL;
+ return -1;
+}
+
+/* split string into tokens */
+int
+rte_strsplit(char *string, int stringlen,
+char **tokens, int maxtokens, char delim)
+{
+ int i, tok = 0;
+ int tokstart = 1; /* first token is right at start of string */
+
+ if (string == NULL || tokens == NULL)
+ goto einval_error;
+
+ for (i = 0; i < stringlen; i++) {
+ if (string[i] == '\0' || tok >= maxtokens)
+ break;
+ if (tokstart) {
+ tokstart = 0;
+ tokens[tok++] = &string[i];
+ }
+ if (string[i] == delim) {
+ string[i] = '\0';
+ tokstart = 1;
+ }
+ }
+ return tok;
+
+einval_error:
+ errno = EINVAL;
+ return -1;
+}
--- a/lib/librte_eal/common/include/rte_string_fns.h2014-05-02
16:31:12.519570116 -0700
+++ b/lib/librte_eal/common/include/rte_string_fns.h2014-05-02
16:31:12.519570116 -0700
@@ -72,33 +72,9 @@ extern "C" {
* buffer been sufficiently big.
*
*/
-static inline int
-rte_snprintf(char *buffer, int buflen, const char *format, ...)
-{
- int len;
- va_list ap;
-
- if (buffer == NULL && buflen != 0)
-
[dpdk-dev] [PATCH 3/5] mempool: add walk iterator
Add function to iterate over mempool.
Useful for diagnostic code that wants to look at mempool usage patterns.
Signed-off-by: Stephen Hemminger
--- a/lib/librte_mempool/rte_mempool.c 2014-05-02 16:31:13.279574637 -0700
+++ b/lib/librte_mempool/rte_mempool.c 2014-05-02 16:31:13.279574637 -0700
@@ -857,3 +857,24 @@ rte_mempool_lookup(const char *name)
return mp;
}
+
+void rte_mempool_walk(void (*func)(const struct rte_mempool *, void *),
+ void *arg)
+{
+ struct rte_mempool *mp = NULL;
+ struct rte_mempool_list *mempool_list;
+
+ if ((mempool_list =
+RTE_TAILQ_LOOKUP_BY_IDX(RTE_TAILQ_MEMPOOL, rte_mempool_list)) ==
NULL) {
+ rte_errno = E_RTE_NO_TAILQ;
+ return;
+ }
+
+ rte_rwlock_read_lock(RTE_EAL_MEMPOOL_RWLOCK);
+
+ TAILQ_FOREACH(mp, mempool_list, next) {
+ (*func)(mp, arg);
+ }
+
+ rte_rwlock_read_unlock(RTE_EAL_MEMPOOL_RWLOCK);
+}
--- a/lib/librte_mempool/rte_mempool.h 2014-05-02 16:31:13.279574637 -0700
+++ b/lib/librte_mempool/rte_mempool.h 2014-05-02 16:31:13.279574637 -0700
@@ -1374,6 +1374,17 @@ size_t rte_mempool_xmem_size(uint32_t el
ssize_t rte_mempool_xmem_usage(void *vaddr, uint32_t elt_num, size_t elt_sz,
const phys_addr_t paddr[], uint32_t pg_num, uint32_t pg_shift);
+/**
+ * Walk list of all memory pools
+ *
+ * @param func
+ * Iterator function
+ * @param arg
+ * Argument passed to iterator
+ */
+void rte_mempool_walk(void (*func)(const struct rte_mempool *, void *arg),
+ void *arg);
+
#ifdef __cplusplus
}
#endif
[dpdk-dev] [PATCH 4/5] memzone: add iterator function
When doing diagnostic function, it is useful to have a ability
to iterate over all memzones.
Signed-off-by: Stephen Hemminger
--- a/lib/librte_eal/common/eal_common_memzone.c2014-05-02
16:31:15.375587103 -0700
+++ b/lib/librte_eal/common/eal_common_memzone.c2014-05-02
16:31:15.375587103 -0700
@@ -505,3 +505,20 @@ rte_eal_memzone_init(void)
return 0;
}
+
+/* Walk all reserved memory zones */
+void rte_memzone_walk(void (*func)(const struct rte_memzone *, void *),
+ void *arg)
+{
+ struct rte_mem_config *mcfg;
+ unsigned i;
+
+ mcfg = rte_eal_get_configuration()->mem_config;
+
+ rte_rwlock_read_lock(&mcfg->mlock);
+ for (i=0; imemzone[i].addr != NULL)
+ (*func)(&mcfg->memzone[i], arg);
+ }
+ rte_rwlock_read_unlock(&mcfg->mlock);
+}
--- a/lib/librte_eal/common/include/rte_memzone.h 2014-05-02
16:31:15.375587103 -0700
+++ b/lib/librte_eal/common/include/rte_memzone.h 2014-05-02
16:31:15.375587103 -0700
@@ -248,6 +248,17 @@ const struct rte_memzone *rte_memzone_lo
*/
void rte_memzone_dump(void);
+/**
+ * Walk list of all memzones
+ *
+ * @param func
+ * Iterator function
+ * @param arg
+ * Argument passed to iterator
+ */
+void rte_memzone_walk(void (*func)(const struct rte_memzone *, void *arg),
+ void *arg);
+
#ifdef __cplusplus
}
#endif
[dpdk-dev] [PATCH 5/5] add FILE arguement to debug functions
The DPDK dump functions are useful for remote debugging of an
applications. But when application runs as a daemon, stdout
is typically routed to /dev/null.
Instead change all these functions to take a stdio FILE * handle
instead. An application can then use open_memstream() to capture
the output.
Signed-off-by: Stephen Hemminger
---
app/dump_cfg/main.c |6 +-
app/test-pmd/cmdline.c | 16 +++---
app/test-pmd/testpmd.c |2
app/test/commands.c | 16 +++---
app/test/test_common.c |4 -
app/test/test_ivshmem.c |4 -
app/test/test_logs.c|2
app/test/test_malloc.c |8 +--
app/test/test_mbuf.c| 14 ++---
app/test/test_memory.c |2
app/test/test_mempool.c | 14 ++---
app/test/test_mempool_perf.c|6 +-
app/test/test_memzone.c | 32 ++--
app/test/test_pci.c |2
app/test/test_ring.c| 42
app/test/test_timer.c |2
examples/l2fwd-ivshmem/host/host.c |2
lib/librte_eal/common/eal_common_devargs.c | 12 ++--
lib/librte_eal/common/eal_common_hexdump.c | 20 +++
lib/librte_eal/common/eal_common_log.c |8 +--
lib/librte_eal/common/eal_common_memory.c |4 -
lib/librte_eal/common/eal_common_memzone.c |4 -
lib/librte_eal/common/eal_common_pci.c | 12 ++--
lib/librte_eal/common/eal_common_tailqs.c |4 -
lib/librte_eal/common/include/rte_devargs.h |6 +-
lib/librte_eal/common/include/rte_hexdump.h |8 ++-
lib/librte_eal/common/include/rte_log.h |7 +-
lib/librte_eal/common/include/rte_memory.h |5 +
lib/librte_eal/common/include/rte_memzone.h |6 +-
lib/librte_eal/common/include/rte_pci.h |5 +
lib/librte_eal/common/include/rte_tailq.h |5 +
lib/librte_eal/linuxapp/eal/eal_ivshmem.c |4 -
lib/librte_ivshmem/rte_ivshmem.c|9 +--
lib/librte_ivshmem/rte_ivshmem.h|4 +
lib/librte_malloc/rte_malloc.c | 16 +++---
lib/librte_malloc/rte_malloc.h |5 +
lib/librte_mbuf/rte_mbuf.c | 10 +--
lib/librte_mbuf/rte_mbuf.h |4 +
lib/librte_mempool/rte_mempool.c| 72 ++--
lib/librte_mempool/rte_mempool.h| 10 +++
lib/librte_ring/rte_ring.c | 52 ++--
lib/librte_ring/rte_ring.h | 10 +++
lib/librte_timer/rte_timer.c| 14 ++---
lib/librte_timer/rte_timer.h|6 +-
44 files changed, 271 insertions(+), 225 deletions(-)
--- a/app/test/commands.c 2014-05-02 16:31:16.431593380 -0700
+++ b/app/test/commands.c 2014-05-02 16:31:16.423593331 -0700
@@ -275,19 +275,19 @@ static void cmd_dump_parsed(void *parsed
struct cmd_dump_result *res = parsed_result;
if (!strcmp(res->dump, "dump_physmem"))
- rte_dump_physmem_layout();
+ rte_dump_physmem_layout(stdout);
else if (!strcmp(res->dump, "dump_memzone"))
- rte_memzone_dump();
+ rte_memzone_dump(stdout);
else if (!strcmp(res->dump, "dump_log_history"))
- rte_log_dump_history();
+ rte_log_dump_history(stdout);
else if (!strcmp(res->dump, "dump_struct_sizes"))
dump_struct_sizes();
else if (!strcmp(res->dump, "dump_ring"))
- rte_ring_list_dump();
+ rte_ring_list_dump(stdout);
else if (!strcmp(res->dump, "dump_mempool"))
- rte_mempool_list_dump();
+ rte_mempool_list_dump(stdout);
else if (!strcmp(res->dump, "dump_devargs"))
- rte_eal_devargs_dump();
+ rte_eal_devargs_dump(stdout);
}
cmdline_parse_token_string_t cmd_dump_dump =
@@ -325,7 +325,7 @@ static void cmd_dump_one_parsed(void *pa
cmdline_printf(cl, "Cannot find ring\n");
return;
}
- rte_ring_dump(r);
+ rte_ring_dump(stdout, r);
}
else if (!strcmp(res->dump, "dump_mempool")) {
struct rte_mempool *mp;
@@ -334,7 +334,7 @@ static void cmd_dump_one_parsed(void *pa
cmdline_printf(cl, "Cannot find mempool\n");
return;
}
- rte_mempool_dump(mp);
+ rte_mempool_dump(stdout, mp);
}
}
--- a/app/test/test_ivshmem.c 2014-05-02 16:31:16.431593380 -0700
+++ b/app/test/test_ivshmem.c 2014-05-02 16:31:16.423593331 -0700
@@ -263,10 +263,10 @@ test_ivshmem_api_test(void)
ASSERT(strnlen(buf, sizeof(buf)) != 0, "Buffer is
