[dpdk-dev] [PATCH 0/2] L3FWD sample optimisation
Hi Konstantin, 2014-05-28 09:17, Ananyev, Konstantin: > Hi Thomas, > > >As you are doing optimizations, it's important to know the performance gain. > >It could help to mitigate future reworks. > >So please, could you provide some benchmarking numbers in the commit log? > > Some performance data below. > Also, forgot to mention that new code path can be switched on/off by setting > ENABLE_MULTI_BUFFER_OPTIMIZE macro to 1/0. > Do I need to resubmit the whole patch series, or just a cover letter, or ...? I think you should resubmit the whole serie after having checked it with checkpatch.pl. Please keep Acked-by and Tested-by lines from previous mails. Thanks -- Thomas
[dpdk-dev] [PATCH v2 1/3] ether: Add API to support setting TX rate for queue and VF
Hi Changchun, 2014-06-05 03:30, Ouyang, Changchun: > As we can see below, There are already 4 existing functions for vf in the > header file: > rte_ethdev.h:int rte_eth_dev_set_vf_rxmode(uint8_t port, uint16_t vf, > uint16_t rx_mode, > rte_ethdev.h:rte_eth_dev_set_vf_tx(uint8_t port,uint16_t vf, uint8_t on); > rte_ethdev.h:rte_eth_dev_set_vf_rx(uint8_t port,uint16_t vf, uint8_t on); > rte_ethdev.h:rte_eth_dev_set_vf_vlan_filter(uint8_t port, uint16_t vlan_id, > > So do we have plan to move them or remove them as they are all for VF > specifically? I'm not very happy with these functions. I feel it's too specific because only related to igb/ixgbe features. We should try to isolate these things elsewhere. The ethdev API should be generic. It's not the right time to debate about this but I'd like to have such cleanup in roadmap. > If no, why we can accept those functions, but not accept the > rte_eth_set_vf_rate_limit? :-) Let's accept it while thinking together to a future nice cleanup. -- Thomas
[dpdk-dev] using hash table in a MP environment
one more simple way would be to assign the desired hash function to the hash_func in the rte_hash structure returned by rte_hash_find_existing call at the secondary initialization phase. that way there is no difference between a primary or a secondary process. Regards, On Tue, Jun 10, 2014 at 3:25 PM, Venkat Thummala < venkat.thummala.1978 at gmail.com> wrote: > Hi Shirley, > > Please refer the section 20.3 [Multi-Process Limitations] in DPDK > Programmers Guide. > > The use of function pointers between multiple processes running based of > different > compiled binaries is not supported, since the location of a given function > in one > process may be different to its location in a second. This prevents the > librte_hash library from behaving properly as in a multi-threaded instance, > since it uses a pointer to the hash function internally. > To work around this issue, it is recommended that multi-process > applications > perform the hash calculations by directly calling the hashing function from > the code > and then using the rte_hash_add_with_hash()/ > rte_hash_lookup_with_hash() functions instead of the functions which do the > hashing internally, such as rte_hash_add()/rte_hash_lookup() > > Thanks > Venkat > > > On 10 June 2014 17:05, Neil Horman wrote: > > > On Tue, Jun 10, 2014 at 11:02:03AM +0300, Uri Sidler wrote: > > > Hi, > > > I am currently using a hash table in a multi-process environment. > > > the master process creates the hash table which is later used by other > > > secondary processes. > > > but the secondary processes fail to use the hash table since the hash > > > function address actually points to a different fucntion. (this makes > > sense > > > since the address of the hash function is in fact different per > process). > > > How can I solve this issue? > > > > > > Thanks, > > > Shirley. > > > > > > > Use shared memory. see shmget > > > > Neil > > > > >
[dpdk-dev] [PATCH] kni: fix compile errors on Oracle Linux6.4 and RHEL6.5
Hi Horman and Thomas
Thank you guys for the good comments for this patch!
The checking if a function is defined will be removed, and will use
self-defined functions no matter they have been defined somewhere or not. This
will have the same behavior of latest Linux ixgbe/igb driver.
I guess the KNI ethtool support might need to be updated soon to which is based
on the latest Linux source code.
Regards,
Helin
-Original Message-
From: Neil Horman [mailto:nhor...@tuxdriver.com]
Sent: Tuesday, June 10, 2014 7:23 PM
To: Zhang, Helin
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH] kni: fix compile errors on Oracle Linux6.4 and
RHEL6.5
On Mon, Jun 09, 2014 at 04:38:55PM +0800, Helin Zhang wrote:
> From: HELIN ZHANG
>
> The compile errors are as follows. The fixes came from standard Linux
> drivers of ixgbe-3.21.2 and igb-5.1.2.
>
> * Oracle Linux6.4
> lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h:3111:
> error: redefinition of 'ether_addr_equal'
> include/linux/etherdevice.h:180: note: previous definition of
> 'ether_addr_equal' was here
> * RHEL6.5
> lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3597:
> error: redefinition of 'mmd_eee_cap_to_ethtool_sup_t'
> include/linux/mdio.h:387: note: previous definition of
> 'mmd_eee_cap_to_ethtool_sup_t' was here
> lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3625:
> error: redefinition of 'mmd_eee_adv_to_ethtool_adv_t'
> include/linux/mdio.h:415: note: previous definition of
> 'mmd_eee_adv_to_ethtool_adv_t' was here
> lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3653:
> error: redefinition of 'ethtool_adv_to_mmd_eee_adv_t'
> include/linux/mdio.h:443: note: previous definition of
> 'ethtool_adv_to_mmd_eee_adv_t' was here
>
> Signed-off-by: Helin Zhang
> Acked-by: Cunming Liang
> Tested-by: Waterman Cao
> ---
> lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 29
> --
> .../linuxapp/kni/ethtool/ixgbe/kcompat.h | 5 ++--
> 2 files changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> index 4c27d5d..26bf0b2 100644
> --- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> +++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
> @@ -3534,12 +3534,13 @@ extern void _kc_skb_add_rx_frag(struct sk_buff
> *, int, struct page *,
> /*
> / #if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,5,0) ) #define
> skb_tx_timestamp(skb) do {} while (0) -#if !(RHEL_RELEASE_CODE &&
> RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6,4)) -static inline bool
> ether_addr_equal(const u8 *addr1, const u8 *addr2)
> +#ifndef ether_addr_equal
> +static inline bool __kc_ether_addr_equal(const u8 *addr1, const u8
> +*addr2)
> {
> return !compare_ether_addr(addr1, addr2); } -#endif
> +#define ether_addr_equal(_addr1, _addr2)
> +__kc_ether_addr_equal((_addr1),(_addr2))
> +#endif /* __kc_ether_addr_equal*/
I don't see why you're wrapping this in a macro twice, just #defining
ether_addr_equal to !compare_ether_addr should be sufficient here.
> #else
> #define HAVE_FDB_OPS
> #define HAVE_ETHTOOL_GET_TS_INFO
> @@ -3586,7 +3587,8 @@ static inline bool ether_addr_equal(const u8 *addr1,
> const u8 *addr2)
> #define ADVERTISED_4baseLR4_Full (1 << 26)
> #endif
>
> -#if defined(ETHTOOL_GEEE) || (RHEL_RELEASE_CODE && RHEL_RELEASE_CODE
> <= RHEL_RELEASE_VERSION(6,4))
> +#if defined(ETHTOOL_GEEE)
> +#ifndef mmd_eee_cap_to_ethtool_sup_t
Why are we even bothering with gating this on ETHTOOL_GEEE? Or building it in
at all for that matter? ETHTOOL_GEEE doesn't having any dependence on any
hardware feature availability, we can just enable it unilaterally (if its not
already defined, though doing an ifndef on a function thats defined as such is
a bit wierd).
Theres also an argument for not doing this compat code at all, as nothing
currently uses it. the KNI is the only code that could reach this path, and
nothing in the KNI does so at the moment. We could just remove this code and
turn off support in the igb pmd instead, it would save some useless code space.
> /**
> * mmd_eee_cap_to_ethtool_sup_t
> * @eee_cap: value of the MMD EEE Capability register @@ -3594,7
> +3596,7 @@ static inline bool ether_addr_equal(const u8 *addr1, const u8
> *addr2)
> * A small helper function that translates MMD EEE Capability (3.20) bits
> * to ethtool supported settings.
> */
> -static inline u32 mmd_eee_cap_to_ethtool_sup_t(u16 eee_cap)
> +static inline u32 __kc_mmd_eee_cap_to_ethtool_sup_t(u16 eee_cap)
> {
> u32 supported = 0;
>
> @@ -3613,7 +3615,11 @@ static inline u32
> mmd_eee_cap_to_ethtool_sup_t(u16 eee_cap)
>
> return supported;
> }
> +#define mmd_eee_cap_to_ethtool_sup_t(eee_cap) \
> + __kc_mmd_eee_cap_to_ethtool_sup_t(eee_cap)
> +#endif /* __kc_mmd_eee_cap_to_ethtool_sup_t */
>
> +#
[dpdk-dev] [PATCH] igb_uio: Remove code that blocks support of some integrated NICs
This patch removes obsolete code that prevents adding integrated copper NICs
82575EB and I350 to list of supported NICs.
---
app/test/test_pci.c |1 -
lib/librte_eal/common/include/rte_pci_dev_ids.h |8
2 files changed, 9 deletions(-)
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index 6908d04..7067dfb 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -81,7 +81,6 @@ struct rte_pci_id my_driver_id2[] = {
/* IGB & EM NICS */
#define RTE_PCI_DEV_ID_DECL_EM(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
#define RTE_PCI_DEV_ID_DECL_IGB(vend, dev) {RTE_PCI_DEVICE(vend, dev)},
-#define RTE_PCI_DEV_USE_82575EB_COPPER
#include
{ .vendor_id = 0, /* sentinel */ },
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index a51c1ef..3e27025 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -323,11 +323,7 @@ RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL,
E1000_DEV_ID_82576_NS)
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82576_NS_SERDES)
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82576_SERDES_QUAD)
-/* This device is the on-board NIC on some development boards. */
-#ifdef RTE_PCI_DEV_USE_82575EB_COPPER
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82575EB_COPPER)
-#endif
-
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82575EB_FIBER_SERDES)
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82575GB_QUAD_COPPER)
@@ -338,11 +334,7 @@ RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL,
E1000_DEV_ID_82580_SGMII)
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82580_COPPER_DUAL)
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82580_QUAD_FIBER)
-/* This device is the on-board NIC on some development boards. */
-#ifndef RTE_PCI_DEV_NO_USE_I350_COPPER
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_I350_COPPER)
-#endif
-
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_I350_FIBER)
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_I350_SERDES)
RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_I350_SGMII)
--
1.7.9.5
[dpdk-dev] About ivshmem
Hi, guys I found that the ivshmem are supported in DPDK 1.6 but has no any document about it, how do I use ivshmem? I remember that we must use a patched qemu binary for enabling ivshmem support in OVDK, does DPDK 1.6 also need do this? Also, where can I find some ivshmem docs? Best Regards John Gong
[dpdk-dev] About ivshmem
Hi, 2014-06-11 16:53, GongJinrong: > I found that the ivshmem are supported in DPDK 1.6 but has no any > document about it, how do I use ivshmem? I remember that we must use a > patched qemu binary for enabling ivshmem support in OVDK, does DPDK 1.6 also > need do this? Also, where can I find some ivshmem docs? If you're looking for information about OVDK, you should ask on the appropriate mailing list. If you are looking for a PMD using ivshmem, you should look at memnic: http://dpdk.org/doc/memnic-pmd -- Thomas
[dpdk-dev] About ivshmem
> Hi, > > 2014-06-11 16:53, GongJinrong: > > I found that the ivshmem are supported in DPDK 1.6 but has no any > > document about it, how do I use ivshmem? I remember that we must use a > > patched qemu binary for enabling ivshmem support in OVDK, does DPDK > > 1.6 also need do this? Also, where can I find some ivshmem docs? > > If you're looking for information about OVDK, you should ask on the > appropriate mailing list. ovdk mailing List: https://lists.01.org/pipermail/dpdk-ovs/ ivshmem instructions: https://github.com/01org/dpdk-ovs/blob/development/docs/04_Sample_Configurations/01_IVSHM.md > > If you are looking for a PMD using ivshmem, you should look at memnic: > http://dpdk.org/doc/memnic-pmd > > -- > Thomas -- 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] [PATCH v4] mk: allow updates to build config on make install
> > From: Bruce Richardson > > > > When running "make config", an additional config.orig file is also > > generated, which is intended to hold the original, clean configuration > > from the template. > > When running make install, we first check if there is no existing > > .config file, and run make config if not. If there is a file, we then > > check if it's unmodified, in which case we regenerate a new .config to > > take account of any possible updates to the template. Finally, in the > > case where there is an existing .config file, and it HAS been modified, > > we then do a check to see if the template has had further updates, and > > throw an error if so. If no updates, we continue with the build using > > the existing, user-modified config. > > > > Signed-off-by: Bruce Richardson > > Signed-off-by: Thomas Monjalon > > Tested-by: Bruce Richardson Previous version was acked by Olivier. It is now applied for version 1.7.0. -- Thomas
[dpdk-dev] [PATCH v3] mk: factorize config rules
> > Error message for missing template is factorized in notemplate rule. > > > > RTE_OUTPUT directory is marked as order-only prerequisite. > > > > RTE_OUTPUT is always created after having been cleaned for rte_config.h. > > > > Signed-off-by: Thomas Monjalon > > Acked-by Olivier Matz Applied for version 1.7.0. -- Thomas
[dpdk-dev] [PATCH 2/2] eal_pci: Fix compilation under FreeBSD
2014-06-10 22:00, Bruce Richardson: > On Thu, Jun 05, 2014 at 05:12:08PM +0100, Alan Carew wrote: > > I'm not sure why this has not caused an issue before, perhaps > > missing -Werror=unused-parameter or super-set > > and subsequently fixed. > > This patch adds __rte_unused to > > pci_unbind_kernel_driver(struct rte_pci_device *dev) > > > > Signed-off-by: Alan Carew > > Acked-by: Bruce Richardson Applied for version 1.7.0. Thanks -- Thomas
[dpdk-dev] [PATCH 1/2] rte_tailq.h: Fix compilation under FreeBSD
> > Recent change to rte_dump_tailq, which now uses a FILE parameter > > causes compilation to fail under FreeBSD and sourced to a > > missing include of stdio.h > > > > This and next patch(both small) allows to compile without error. > > > > Signed-off-by: Alan Carew > > Acked-by: Bruce Richardson Applied for version 1.7.0. Thanks -- Thomas
[dpdk-dev] [PATCH] fix trailing whitespace.
> > This commit removes trailing whitespace from lines in files. Almost all > > files are affected, as the BSD license copyright header had trailing > > whitespace on 4 lines in it [hence the number of files reporting 8 lines > > changed in the diffstat]. > > > > Signed-off-by: Bruce Richardson > Acked-by: Neil Horman I've completed it with these changes: - remove spaces before tabs in libs - remove more trailing spaces in non-C files Applied for version 1.7.0. Some whitespaces and indentation errors are remaining, especially in examples. But it can be fixed when examples will be updated. I'm not a big fan of such patch. I prefer to take care of not adding new spacing errors. So from now, trailing whitespaces, spaces before tabs and wrong indentation should be tracked carefully in new patches. Thanks -- Thomas
[dpdk-dev] [PATCHv2 0/4] fix for 2 consecutive rte_eth_dev_start() can cause a SIGSEGV
> Konstantin Ananyev (4): > e1000: do not release queue on alloc error > igb/ixgbe: reset queue pointers after releasing > ethdev: fix compiler warning on PMD_DEBUG_TRACE formats > ethdev: prevent from starting/stopping already started/stopped Acked-by: Thomas Monjalon Applied for version 1.7.0. Thanks -- Thomas
[dpdk-dev] [PATCH v2 0/3] Support setting link up and link down
> > This patch series contain the following 3 items: > > 1. Add API to support setting link up and down, it can be used to > > repeatedly stop and restart > > RX/TX of a port without re-allocating resources for the port and > > re-configuring the port. > > 2. Implement the functionality of setting link up and down in IXGBE PMD. > > 3. Add command in testpmd to test the functionality of setting link up and > > down of PMD. > > Acked by: Ivan Boule Applied for version 1.7.0. Thanks -- Thomas
[dpdk-dev] About ivshmem
Thanks, I want use DPDK, not OVDK, if I run l2fwd-ivshmem, do I use a patched qemu or just a normal qemu? -Original Message- From: Gray, Mark D [mailto:mark.d.g...@intel.com] Sent: Wednesday, June 11, 2014 5:24 PM To: Thomas Monjalon; GongJinrong Cc: dev at dpdk.org Subject: RE: [dpdk-dev] About ivshmem > Hi, > > 2014-06-11 16:53, GongJinrong: > > I found that the ivshmem are supported in DPDK 1.6 but has no > > any document about it, how do I use ivshmem? I remember that we must > > use a patched qemu binary for enabling ivshmem support in OVDK, does > > DPDK > > 1.6 also need do this? Also, where can I find some ivshmem docs? > > If you're looking for information about OVDK, you should ask on the > appropriate mailing list. ovdk mailing List: https://lists.01.org/pipermail/dpdk-ovs/ ivshmem instructions: https://github.com/01org/dpdk-ovs/blob/development/docs/04_Sample_Configurat ions/01_IVSHM.md > > If you are looking for a PMD using ivshmem, you should look at memnic: > http://dpdk.org/doc/memnic-pmd > > -- > Thomas -- 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] [PATCH 00/10] igb_uio patches
On Tue, Jun 10, 2014 at 01:47:09PM -0700, Stephen Hemminger wrote: > On Tue, 10 Jun 2014 19:26:08 + > "Carew, Alan" wrote: > > > One alternative for us is then to take Neil Horman's idea of scanning > > /sys/bus/pci/devices//msi_irqs/ > > This gives us at least (MSI | MSI-X) | INT-X, however the Virtio > > specification mentions MSI-X explicitly for determining the correct offset > > and might not address the underlying problem my patch set was addressing, I > > have not tried Virtio with MSI. > > MSI doesn't work with virtio. pci_enable_msi() returns error. The device > does not report MSI capability. > /sys/bus/pci/devices//irq also indicates which legacy irq is assigned to a given device Neil
[dpdk-dev] About ivshmem
> > Thanks, I want use DPDK, not OVDK, if I run l2fwd-ivshmem, do I use a > patched qemu or just a normal qemu? > Patched. -- 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] About ivshmem
Ok, thanks a lot. -Original Message- From: Gray, Mark D [mailto:mark.d.g...@intel.com] Sent: Wednesday, June 11, 2014 6:31 PM To: GongJinrong; 'Thomas Monjalon' Cc: dev at dpdk.org Subject: RE: [dpdk-dev] About ivshmem > > Thanks, I want use DPDK, not OVDK, if I run l2fwd-ivshmem, do I use a > patched qemu or just a normal qemu? > Patched. -- 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] About ivshmem
2014-06-11 10:30, Gray, Mark D: > 2014-06-11 18:13, GongJinrong: > > Thanks, I want use DPDK, not OVDK, if I run l2fwd-ivshmem, do I use a > > patched qemu or just a normal qemu? > > Patched. Not sure for l2fwd-ivshmem but you should be able to use memnic PMD with a standard Qemu (not patched). Mark, could you elaborate? Which patch are you thinking about? -- Thomas
[dpdk-dev] [PATCHv2 0/2] L3FWD sample optimisation
v2 changes: add performance data to the patch comments fix some checkpatch.pl errors/warnings Konstantin Ananyev (2): lpm: Introduce rte_lpm_lookupx4 l3fwd: reorganise and optimize l3fwd LPM code path. app/test/test_lpm.c | 70 examples/l3fwd/main.c | 471 ++-- lib/librte_eal/common/Makefile | 1 + lib/librte_eal/common/include/rte_common_vect.h | 93 + lib/librte_lpm/rte_lpm.h| 117 ++ 5 files changed, 728 insertions(+), 24 deletions(-) create mode 100644 lib/librte_eal/common/include/rte_common_vect.h -- 1.8.3.1
[dpdk-dev] [PATCHv2 1/2] lpm: Introduce rte_lpm_lookupx4
Introduce rte_lpm_lookupx4():
- Allows to lookup four IP addresses in an LPM table.
- Uses SSE instrincts.
Signed-off-by: Konstantin Ananyev
---
app/test/test_lpm.c | 70 ++
lib/librte_eal/common/Makefile | 1 +
lib/librte_eal/common/include/rte_common_vect.h | 93 +++
lib/librte_lpm/rte_lpm.h| 117
4 files changed, 281 insertions(+)
create mode 100644 lib/librte_eal/common/include/rte_common_vect.h
diff --git a/app/test/test_lpm.c b/app/test/test_lpm.c
index 0250ed0..05f0a93 100644
--- a/app/test/test_lpm.c
+++ b/app/test/test_lpm.c
@@ -310,6 +310,8 @@ test6(void)
int32_t
test7(void)
{
+ __m128i ipx4;
+ uint16_t hop[4];
struct rte_lpm *lpm = NULL;
uint32_t ip = IPv4(0, 0, 0, 0);
uint8_t depth = 32, next_hop_add = 100, next_hop_return = 0;
@@ -324,6 +326,13 @@ test7(void)
status = rte_lpm_lookup(lpm, ip, &next_hop_return);
TEST_LPM_ASSERT((status == 0) && (next_hop_return == next_hop_add));
+ ipx4 = _mm_set_epi32(ip, ip + 0x100, ip - 0x100, ip);
+ rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
+ TEST_LPM_ASSERT(hop[0] == next_hop_add);
+ TEST_LPM_ASSERT(hop[1] == UINT16_MAX);
+ TEST_LPM_ASSERT(hop[2] == UINT16_MAX);
+ TEST_LPM_ASSERT(hop[3] == next_hop_add);
+
status = rte_lpm_delete(lpm, ip, depth);
TEST_LPM_ASSERT(status == 0);
@@ -347,6 +356,8 @@ test7(void)
int32_t
test8(void)
{
+ __m128i ipx4;
+ uint16_t hop[4];
struct rte_lpm *lpm = NULL;
uint32_t ip1 = IPv4(127, 255, 255, 255), ip2 = IPv4(128, 0, 0, 0);
uint8_t depth, next_hop_add, next_hop_return;
@@ -370,6 +381,13 @@ test8(void)
status = rte_lpm_lookup(lpm, ip2, &next_hop_return);
TEST_LPM_ASSERT((status == 0) &&
(next_hop_return == next_hop_add));
+
+ ipx4 = _mm_set_epi32(ip2, ip1, ip2, ip1);
+ rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
+ TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
+ TEST_LPM_ASSERT(hop[1] == next_hop_add);
+ TEST_LPM_ASSERT(hop[2] == UINT16_MAX);
+ TEST_LPM_ASSERT(hop[3] == next_hop_add);
}
/* Loop with rte_lpm_delete. */
@@ -391,6 +409,18 @@ test8(void)
status = rte_lpm_lookup(lpm, ip1, &next_hop_return);
TEST_LPM_ASSERT(status == -ENOENT);
+
+ ipx4 = _mm_set_epi32(ip1, ip1, ip2, ip2);
+ rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
+ if (depth != 1) {
+ TEST_LPM_ASSERT(hop[0] == next_hop_add);
+ TEST_LPM_ASSERT(hop[1] == next_hop_add);
+ } else {
+ TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
+ TEST_LPM_ASSERT(hop[1] == UINT16_MAX);
+ }
+ TEST_LPM_ASSERT(hop[2] == UINT16_MAX);
+ TEST_LPM_ASSERT(hop[3] == UINT16_MAX);
}
rte_lpm_free(lpm);
@@ -822,6 +852,8 @@ test11(void)
int32_t
test12(void)
{
+ __m128i ipx4;
+ uint16_t hop[4];
struct rte_lpm *lpm = NULL;
uint32_t ip, i;
uint8_t depth, next_hop_add, next_hop_return;
@@ -842,6 +874,13 @@ test12(void)
TEST_LPM_ASSERT((status == 0) &&
(next_hop_return == next_hop_add));
+ ipx4 = _mm_set_epi32(ip, ip + 1, ip, ip - 1);
+ rte_lpm_lookupx4(lpm, ipx4, hop, UINT16_MAX);
+ TEST_LPM_ASSERT(hop[0] == UINT16_MAX);
+ TEST_LPM_ASSERT(hop[1] == next_hop_add);
+ TEST_LPM_ASSERT(hop[2] == UINT16_MAX);
+ TEST_LPM_ASSERT(hop[3] == next_hop_add);
+
status = rte_lpm_delete(lpm, ip, depth);
TEST_LPM_ASSERT(status == 0);
@@ -1237,6 +1276,37 @@ perf_test(void)
(double)total_time / ((double)ITERATIONS * BATCH_SIZE),
(count * 100.0) / (double)(ITERATIONS * BATCH_SIZE));
+ /* Measure LookupX4 */
+ total_time = 0;
+ count = 0;
+ for (i = 0; i < ITERATIONS; i++) {
+ static uint32_t ip_batch[BATCH_SIZE];
+ uint16_t next_hops[4];
+
+ /* Create array of random IP addresses */
+ for (j = 0; j < BATCH_SIZE; j++)
+ ip_batch[j] = rte_rand();
+
+ /* Lookup per batch */
+ begin = rte_rdtsc();
+ for (j = 0; j < BATCH_SIZE; j += RTE_DIM(next_hops)) {
+ unsigned k;
+ __m128i ipx4;
+
+ ipx4 = _mm_loadu_si128((__m128i *)(ip_batch + j));
+ ipx4 = *(__m128i *)(ip_batch + j);
+ rte_lpm_lookupx4(lpm, ipx4, next_hops, UINT16_MAX);
+ for (k = 0; k < RTE_D
[dpdk-dev] [PATCHv2 2/2] l3fwd: reorganise and optimize l3fwd LPM code path.
With latest HW and optimised RX/TX path there is a huge gap between
tespmd iofwd and l3fwd performance results.
So there is an attempt to optimise l3fwd LPM code path and reduce the gap:
- Instead of processing each input packet up to completion -
divide packet processing into several stages and perform
stage by stage for the whole burst.
- Unroll things by the factor of 4 whenever possible.
- Use SSE instincts for some operations (bswap, replace MAC addresses, etc).
- Avoid TX packet buffering whenever possible.
- Move some checks from RX/TX into setup phase.
Note that new(optimized) code path can be switched on/off by setting
ENABLE_MULTI_BUFFER_OPTIMIZE macro to 1/0.
Some performance data:
SUT: dual-socket board IVB 2.8GHz, 2x1GB pages.
4 ports on 4 NICs (all at socket 0) connected to the traffic generator.
kernel: 3.11.3-201.fc19.x86_64, gcc: 4.8.2.
64B packets, using the packet flooding method.
All 4 ports are managed by one logical core:
Optimised scalar PMD RX/TX was used.
DIFF % (NEW-OLD)
IPV4-CONT-BURST: +23%
IPV6-CONT-BURST : +13%
IPV4/IPV6-CONT-BURST: +8%
IPV4-4STREAMSX8: +7%
IPV4-4STREAMSX1: -2%
Test cases description:
IPV4-CONT-BURST - IPV4 packets all packets from the one input port
are destined for the same output port.
IPV6-CONT-BURST - IPV6 packets all packets from the one input port
are destined for the same output port.
IPV4/IPV6-CONT-BURST - mix of the first 2 with interleave=1
(e.g: IPV4,IPV6,IPV4,IPV6, ...)
IPV4-4STREAMSX1 - 4 streams of IPV4 packets, where all packets
from same stream are destined for the same output port
(e.g: IPV4_DST_P0, IPV4_DST_P1, IPV4_DST_P2, IPV4_DST_P3, IPV4_DST_P0, ...)
IPV4-4STREAMSX8 - same as above but packets for each stream
are coming in groups of 8
(e.g: IPV4_DST_P0 X 8, IPV4_DST_P1 X 8, IPV4_DST_P2 X 8, IPV4_DST_P3 X 8,
IPV4_DST_P0 X 8, ...)
Signed-off-by: Konstantin Ananyev
---
examples/l3fwd/main.c | 471 +++---
1 file changed, 447 insertions(+), 24 deletions(-)
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 06e6e6f..72b196c 100755
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -42,8 +42,8 @@
#include
#include
-#include
#include
+#include
#include
#include
#include
@@ -83,7 +83,16 @@
#define APP_LOOKUP_METHOD APP_LOOKUP_LPM
#endif
+/*
+ * When set to zero, simple forwaring path is eanbled.
+ * When set to one, optimized forwarding path is enabled.
+ * Note that LPM optimisation path uses SSE4.1 instructions.
+ */
+#if ((APP_LOOKUP_METHOD == APP_LOOKUP_LPM) && !defined(__SSE4_1__))
+#define ENABLE_MULTI_BUFFER_OPTIMIZE 0
+#else
#define ENABLE_MULTI_BUFFER_OPTIMIZE 1
+#endif
#if (APP_LOOKUP_METHOD == APP_LOOKUP_EXACT_MATCH)
#include
@@ -150,11 +159,21 @@
#define MAX_PKT_BURST 32
#define BURST_TX_DRAIN_US 100 /* TX drain every ~100us */
+/*
+ * Try to avoid TX buffering if we have at least MAX_TX_BURST packets to send.
+ */
+#defineMAX_TX_BURST(MAX_PKT_BURST / 2)
+
#define NB_SOCKETS 8
/* Configure how many packets ahead to prefetch, when reading packets */
#define PREFETCH_OFFSET3
+/* Used to mark destination port as 'invalid'. */
+#defineBAD_PORT((uint16_t)-1)
+
+#define FWDSTEP4
+
/*
* Configurable number of RX/TX ring descriptors
*/
@@ -166,6 +185,11 @@ static uint16_t nb_txd = RTE_TEST_TX_DESC_DEFAULT;
/* ethernet addresses of ports */
static struct ether_addr ports_eth_addr[RTE_MAX_ETHPORTS];
+static __m128i val_eth[RTE_MAX_ETHPORTS];
+
+/* replace first 12B of the ethernet header. */
+#defineMASK_ETH0x3f
+
/* mask of enabled ports */
static uint32_t enabled_port_mask = 0;
static int promiscuous_on = 0; /**< Ports set in promiscuous mode off by
default. */
@@ -562,6 +586,84 @@ send_single_packet(struct rte_mbuf *m, uint8_t port)
return 0;
}
+static inline __attribute__((always_inline)) void
+send_packetsx4(struct lcore_conf *qconf, uint8_t port,
+ struct rte_mbuf *m[], uint32_t num)
+{
+ uint32_t len, j, n;
+
+ len = qconf->tx_mbufs[port].len;
+
+ /*
+* If TX buffer for that queue is empty, and we have enough packets,
+* then send them straightway.
+*/
+ if (num >= MAX_TX_BURST && len == 0) {
+ n = rte_eth_tx_burst(port, qconf->tx_queue_id[port], m, num);
+ if (unlikely(n < num)) {
+ do {
+ rte_pktmbuf_free(m[n]);
+ } while (++n < num);
+ }
+ return;
+ }
+
+ /*
+* Put packets into TX buffer for that queue.
+*/
+
+ n = len + num;
+ n = (n > MAX_PKT_BURST) ? MAX_PKT_BURST - len : num;
+
+ j = 0;
+ switch (n % FWDSTEP) {
+ while (j < n) {
+ case 0:
+ qconf->tx_mbufs[port].m_table
[dpdk-dev] [PATCH v2] kni: fix compile errors on Oracle Linux6.4 and RHEL6.5
From: HELIN ZHANG
The compile errors are copied as follows. The fixes came from
Linux drivers of ixgbe-3.21.2 and igb-5.1.2 with modifications.
The idea is to use self-defined functions no matter they have
already been defined somewhere or not.
* Oracle Linux6.4
lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h:3111:
error: redefinition of 'ether_addr_equal'
include/linux/etherdevice.h:180: note: previous definition
of 'ether_addr_equal' was here
* RHEL6.5
lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3597:
error: redefinition of 'mmd_eee_cap_to_ethtool_sup_t'
include/linux/mdio.h:387: note: previous definition of
'mmd_eee_cap_to_ethtool_sup_t' was here
lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3625:
error: redefinition of 'mmd_eee_adv_to_ethtool_adv_t'
include/linux/mdio.h:415: note: previous definition of
'mmd_eee_adv_to_ethtool_adv_t' was here
lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h:3653:
error: redefinition of 'ethtool_adv_to_mmd_eee_adv_t'
include/linux/mdio.h:443: note: previous definition of
'ethtool_adv_to_mmd_eee_adv_t' was here
Signed-off-by: HELIN ZHANG
Acked-by: Cunming Liang
Tested-by: Waterman Cao
---
lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h | 19 +++
lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h | 5 ++---
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
index 4c27d5d..0aa15cd 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
@@ -3534,12 +3534,11 @@ extern void _kc_skb_add_rx_frag(struct sk_buff *, int,
struct page *,
/*/
#if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,5,0) )
#define skb_tx_timestamp(skb) do {} while (0)
-#if !(RHEL_RELEASE_CODE && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(6,4))
-static inline bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
+static inline bool __kc_ether_addr_equal(const u8 *addr1, const u8 *addr2)
{
return !compare_ether_addr(addr1, addr2);
}
-#endif
+#define ether_addr_equal(_addr1, _addr2)
__kc_ether_addr_equal((_addr1),(_addr2))
#else
#define HAVE_FDB_OPS
#define HAVE_ETHTOOL_GET_TS_INFO
@@ -3586,7 +3585,6 @@ static inline bool ether_addr_equal(const u8 *addr1,
const u8 *addr2)
#define ADVERTISED_4baseLR4_Full (1 << 26)
#endif
-#if defined(ETHTOOL_GEEE) || (RHEL_RELEASE_CODE && RHEL_RELEASE_CODE <=
RHEL_RELEASE_VERSION(6,4))
/**
* mmd_eee_cap_to_ethtool_sup_t
* @eee_cap: value of the MMD EEE Capability register
@@ -3594,7 +3592,7 @@ static inline bool ether_addr_equal(const u8 *addr1,
const u8 *addr2)
* A small helper function that translates MMD EEE Capability (3.20) bits
* to ethtool supported settings.
*/
-static inline u32 mmd_eee_cap_to_ethtool_sup_t(u16 eee_cap)
+static inline u32 __kc_mmd_eee_cap_to_ethtool_sup_t(u16 eee_cap)
{
u32 supported = 0;
@@ -3613,6 +3611,8 @@ static inline u32 mmd_eee_cap_to_ethtool_sup_t(u16
eee_cap)
return supported;
}
+#define mmd_eee_cap_to_ethtool_sup_t(eee_cap) \
+ __kc_mmd_eee_cap_to_ethtool_sup_t(eee_cap)
/**
* mmd_eee_adv_to_ethtool_adv_t
@@ -3622,7 +3622,7 @@ static inline u32 mmd_eee_cap_to_ethtool_sup_t(u16
eee_cap)
* and MMD EEE Link Partner Ability (7.61) bits to ethtool advertisement
* settings.
*/
-static inline u32 mmd_eee_adv_to_ethtool_adv_t(u16 eee_adv)
+static inline u32 __kc_mmd_eee_adv_to_ethtool_adv_t(u16 eee_adv)
{
u32 adv = 0;
@@ -3641,6 +3641,8 @@ static inline u32 mmd_eee_adv_to_ethtool_adv_t(u16
eee_adv)
return adv;
}
+#define mmd_eee_adv_to_ethtool_adv_t(eee_adv) \
+ __kc_mmd_eee_adv_to_ethtool_adv_t(eee_adv)
/**
* ethtool_adv_to_mmd_eee_adv_t
@@ -3650,7 +3652,7 @@ static inline u32 mmd_eee_adv_to_ethtool_adv_t(u16
eee_adv)
* to EEE advertisements for the MMD EEE Advertisement (7.60) and
* MMD EEE Link Partner Ability (7.61) registers.
*/
-static inline u16 ethtool_adv_to_mmd_eee_adv_t(u32 adv)
+static inline u16 __kc_ethtool_adv_to_mmd_eee_adv_t(u32 adv)
{
u16 reg = 0;
@@ -3669,7 +3671,8 @@ static inline u16 ethtool_adv_to_mmd_eee_adv_t(u32 adv)
return reg;
}
-#endif
+#define ethtool_adv_to_mmd_eee_adv_t(adv) \
+__kc_ethtool_adv_to_mmd_eee_adv_t(adv)
#ifndef pci_pcie_type
#if ( LINUX_VERSION_CODE < KERNEL_VERSION(2,6,24) )
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h
b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h
index 4126d14..b539315 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/ixgbe/kcompat.h
@@ -3107,12 +3107,11 @@ typedef netdev_features_t kni_netdev_features_t;
/*/
#if ( LINUX_VERSION_CODE < KERNEL_VERSION(3,5,0) )
-#if !(RHEL_RELEASE_CODE && RHEL_RELEASE
[dpdk-dev] [PATCH v2 0/3] Support setting TX rate for queue and VF
> This patch series also contain the 3 items: > 1. Add API to support setting TX rate for a queue or a VF. > 2. Implement the functionality of setting TX rate for queue or VF in IXGBE > PMD. > 3. Add commands in testpmd to test the functionality of setting TX rate for > queue or VF. Acked-by: Jijiang Liu Tested-by: Waterman Cao Acked-by: Huawei Xie Applied for version 1.7.0. Thanks -- Thomas
[dpdk-dev] [PATCH] ethdev: add RX errors counter for missed, badcrc and badlen packets
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of David Marchand
> Sent: Thursday, May 22, 2014 7:28 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] ethdev: add RX errors counter for missed,
> badcrc and badlen packets
>
> From: Ivan Boule
>
> Split input error stats to have a better understanding of why packets have
> been
> dropped.
> Keep ierrors field untouched for backward compatibility.
>
> Signed-off-by: Ivan Boule
> Signed-off-by: David Marchand
> ---
> app/test-pmd/config.c | 24 +---
> app/test-pmd/testpmd.c | 32
> examples/load_balancer/runtime.c|2 +-
> lib/librte_ether/rte_ethdev.h |3 +++
> lib/librte_pmd_e1000/em_ethdev.c|9 +++--
> lib/librte_pmd_e1000/igb_ethdev.c |9 +++--
> lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 12 +---
> 7 files changed, 64 insertions(+), 27 deletions(-)
>
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
> index 89aa8b2..d3934e5 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -126,19 +126,29 @@ nic_stats_display(portid_t port_id)
> nic_stats_border, port_id, nic_stats_border);
>
> if ((!port->rx_queue_stats_mapping_enabled) && (!port-
> >tx_queue_stats_mapping_enabled)) {
> - printf(" RX-packets: %-10"PRIu64" RX-errors: %-
> 10"PRIu64"RX-bytes: "
> -"%-"PRIu64"\n"
> -" TX-packets: %-10"PRIu64" TX-errors: %-10"PRIu64"TX-
> bytes: "
> + printf(" RX-packets: %-10"PRIu64" RX-missed: %-10"PRIu64"
> RX-bytes: "
> +"%-"PRIu64"\n",
> +stats.ipackets, stats.imissed, stats.ibytes);
> + printf(" RX-badcrc: %-10"PRIu64" RX-badlen: %-10"PRIu64"
> RX-errors: "
> +"%-"PRIu64"\n",
> +stats.ibadcrc, stats.ibadlen, stats.ierrors);
> + printf(" RX-nombuf: %-10"PRIu64"\n",
> +stats.rx_nombuf);
> + printf(" TX-packets: %-10"PRIu64" TX-errors: %-10"PRIu64"
> TX-bytes: "
> "%-"PRIu64"\n",
> -stats.ipackets, stats.ierrors, stats.ibytes,
> stats.opackets, stats.oerrors, stats.obytes);
> }
> else {
> printf(" RX-packets: %10"PRIu64"RX-errors:
> %10"PRIu64
> -"RX-bytes: %10"PRIu64"\n"
> -" TX-packets: %10"PRIu64"TX-errors:
> %10"PRIu64
> +"RX-bytes: %10"PRIu64"\n",
> +stats.ipackets, stats.ierrors, stats.ibytes);
> + printf(" RX-badcrc: %10"PRIu64"RX-badlen:
> %10"PRIu64
> +" RX-errors: %10"PRIu64"\n",
> +stats.ibadcrc, stats.ibadlen, stats.ierrors);
> + printf(" RX-nombuf: %10"PRIu64"\n",
> +stats.rx_nombuf);
> + printf(" TX-packets: %10"PRIu64"TX-errors:
> %10"PRIu64
> "TX-bytes: %10"PRIu64"\n",
> -stats.ipackets, stats.ierrors, stats.ibytes,
> stats.opackets, stats.oerrors, stats.obytes);
> }
>
> diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> index bc38305..ac8c9f3 100644
> --- a/app/test-pmd/testpmd.c
> +++ b/app/test-pmd/testpmd.c
> @@ -770,8 +770,8 @@ fwd_port_stats_display(portid_t port_id, struct
> rte_eth_stats *stats)
> if ((!port->rx_queue_stats_mapping_enabled) && (!port-
> >tx_queue_stats_mapping_enabled)) {
> printf(" RX-packets: %-14"PRIu64" RX-dropped: %-
> 14"PRIu64"RX-total: "
> "%-"PRIu64"\n",
> -stats->ipackets, stats->ierrors,
> -(uint64_t) (stats->ipackets + stats->ierrors));
> +stats->ipackets, stats->imissed,
> +(uint64_t) (stats->ipackets + stats->imissed));
>
> if (cur_fwd_eng == &csum_fwd_engine)
> printf(" Bad-ipcsum: %-14"PRIu64" Bad-l4csum: %-
> 14"PRIu64" \n",
> @@ -782,15 +782,19 @@ fwd_port_stats_display(portid_t port_id, struct
> rte_eth_stats *stats)
> stats->opackets, port->tx_dropped,
> (uint64_t) (stats->opackets + port->tx_dropped));
>
> - if (stats->rx_nombuf > 0)
> - printf(" RX-nombufs: %-14"PRIu64"\n", stats-
> >rx_nombuf);
> + if (((stats->ierrors - stats->imissed) + stats->rx_nombuf) > 0)
> {
> + printf(" RX-badcrc: %-14"PRIu64" RX-badlen: %-
> 14"PRIu64"RX-errors: %-"PRIu64"\n",
> +stats->ibadcrc, stats->ibadlen, stats->ierrors);
> + printf(" RX-nombufs: %-14"PRIu64"\n",
> +stats->rx_nombuf);
> + }
>
> }
>
[dpdk-dev] using hash table in a MP environment
The trouble is: a) how do we guarantee that the function in question is present in the secondary process at all? It could be only referenced by name in the primary process and omitted by the linker in the secondary as unused, for instance. b) how do we find out the address of the function in the secondary process if it is present? c) updating the hash function pointer in the secondary process will overwrite the value for the primary process, thereby breaking the hash function on it. This is a complicated problem. The only item for which we've solved this so far is for the physical NICs. What happens there is that we had to: * split up the rte_eth_dev structure into two, to create the shared rte_eth_dev_data structure and the process local rte_eth_dev structure * force the secondary processes to redo the exact same driver loading (now obsolete) and PCI probe scan as the primary, thereby creating the process-local matching rte_eth_dev structures in the secondary. This works, but has itself limitations. In this case, the secondary processes have to be run using the exact same parameters for PCI devices, same -d parameters to dynamically load drivers, same -b parameters to blacklist ports, etc. etc. For the hash table case, I think forcing secondary processes to use the "with_hash" versions of the API is an acceptable workaround, given the difficulties of making it work transparently in secondary processes. [The workaround may ever perform slightly better as the calls to the hash calculation are explicit and can be inlined by the compiler, saving the cost of an indirect function call per packet.] /Bruce > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Helmut Sim > Sent: Tuesday, June 10, 2014 10:24 PM > To: Venkat Thummala > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] using hash table in a MP environment > > one more simple way would be to assign the desired hash function to the > hash_func in the rte_hash structure returned by rte_hash_find_existing call > at the secondary initialization phase. that way there is no difference > between a primary or a secondary process. > > Regards, > > > > On Tue, Jun 10, 2014 at 3:25 PM, Venkat Thummala < > venkat.thummala.1978 at gmail.com> wrote: > > > Hi Shirley, > > > > Please refer the section 20.3 [Multi-Process Limitations] in DPDK > > Programmers Guide. > > > > The use of function pointers between multiple processes running based of > > different > > compiled binaries is not supported, since the location of a given function > > in one > > process may be different to its location in a second. This prevents the > > librte_hash library from behaving properly as in a multi-threaded instance, > > since it uses a pointer to the hash function internally. > > To work around this issue, it is recommended that multi-process > > applications > > perform the hash calculations by directly calling the hashing function from > > the code > > and then using the rte_hash_add_with_hash()/ > > rte_hash_lookup_with_hash() functions instead of the functions which do the > > hashing internally, such as rte_hash_add()/rte_hash_lookup() > > > > Thanks > > Venkat > > > > > > On 10 June 2014 17:05, Neil Horman wrote: > > > > > On Tue, Jun 10, 2014 at 11:02:03AM +0300, Uri Sidler wrote: > > > > Hi, > > > > I am currently using a hash table in a multi-process environment. > > > > the master process creates the hash table which is later used by other > > > > secondary processes. > > > > but the secondary processes fail to use the hash table since the hash > > > > function address actually points to a different fucntion. (this makes > > > sense > > > > since the address of the hash function is in fact different per > > process). > > > > How can I solve this issue? > > > > > > > > Thanks, > > > > Shirley. > > > > > > > > > > Use shared memory. see shmget > > > > > > Neil > > > > > > > >
[dpdk-dev] [PATCH] fix trailing whitespace.
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, June 11, 2014 3:04 AM > To: Richardson, Bruce > Cc: dev at dpdk.org; Neil Horman > Subject: Re: [dpdk-dev] [PATCH] fix trailing whitespace. > > > > This commit removes trailing whitespace from lines in files. Almost all > > > files are affected, as the BSD license copyright header had trailing > > > whitespace on 4 lines in it [hence the number of files reporting 8 lines > > > changed in the diffstat]. > > > > > > Signed-off-by: Bruce Richardson > > Acked-by: Neil Horman > > I've completed it with these changes: > - remove spaces before tabs in libs > - remove more trailing spaces in non-C files > > Applied for version 1.7.0. > > Some whitespaces and indentation errors are remaining, especially in examples. > But it can be fixed when examples will be updated. > I'm not a big fan of such patch. I prefer to take care of not adding new > spacing errors. So from now, trailing whitespaces, spaces before tabs > and wrong indentation should be tracked carefully in new patches. > Just FYI: my reasoning for cleaning it up now is that it allows us to write rules for our editors or IDEs to automatically fix whitespace errors on save (the patch I generated was created by using a vim rule on file save). Without having things cleaned up ahead of time, having a vim rule such as this will cleanup each file as it is modified, leading to lots of extra whitespace changes in our diffs, which are irrelevant to the code being changed. This then makes our lives harder when working on patches. /Bruce
[dpdk-dev] [PATCH v2 0/4] NIC filters support for generic filter
Hi Jingjing, Please reply below the question. 2014-05-28 01:12, Wu, Jingjing: > You are discussing whether the APIs provide for NIC filters is generic > or not. About that we can use same API for a type of filter. For example, > if we want to configure ethertype filter, we can use the same API, no > matter the NIC is 82580, i350, 82576 or 82599. We think these NICs may be > most common used. I was wondering if this API can apply to non-Intel devices. But nobody talked about it. So let's forget it. My main concern is that Vladimir Medvedkin suggested another API and I'd like you give your opinion about it: http://dpdk.org/ml/archives/dev/2014-June/003053.html It offers pool number in configuration of the filters. Last comment: patches would be more pleasant to read with right alignment and spaces in comments. This is an extract to illustrate what I'm talking about: + uint16_t priority; /**< used when more than one filter matches */ + uint8_t dst_port_mask : 1, /**
[dpdk-dev] [PATCH] fix trailing whitespace.
On Wed, Jun 11, 2014 at 03:24:04PM +, Richardson, Bruce wrote: > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Wednesday, June 11, 2014 3:04 AM > > To: Richardson, Bruce > > Cc: dev at dpdk.org; Neil Horman > > Subject: Re: [dpdk-dev] [PATCH] fix trailing whitespace. > > > > > > This commit removes trailing whitespace from lines in files. Almost all > > > > files are affected, as the BSD license copyright header had trailing > > > > whitespace on 4 lines in it [hence the number of files reporting 8 lines > > > > changed in the diffstat]. > > > > > > > > Signed-off-by: Bruce Richardson > > > Acked-by: Neil Horman > > > > I've completed it with these changes: > > - remove spaces before tabs in libs > > - remove more trailing spaces in non-C files > > > > Applied for version 1.7.0. > > > > Some whitespaces and indentation errors are remaining, especially in > > examples. > > But it can be fixed when examples will be updated. > > I'm not a big fan of such patch. I prefer to take care of not adding new > > spacing errors. So from now, trailing whitespaces, spaces before tabs > > and wrong indentation should be tracked carefully in new patches. > > > Just FYI: my reasoning for cleaning it up now is that it allows us to write > rules for our editors or IDEs to automatically fix whitespace errors on save > (the patch I generated was created by using a vim rule on file save). Without > having things cleaned up ahead of time, having a vim rule such as this will > cleanup each file as it is modified, leading to lots of extra whitespace > changes in our diffs, which are irrelevant to the code being changed. This > then makes our lives harder when working on patches. > This sort of change should probably be accompanied by a script to do patch checking prior to submission (something like checkpatch.pl in the linux kernel). Not every contributor will have a whitespace cleaning rule set, and such a checker will be allow users to clean patches prior to submission, both for whitepace errors and any other errors you want to enforce (trailing whtespace, leading spaces, parenthetical spaces, etc). Neil > /Bruce >
[dpdk-dev] [PATCH] igb_uio: Remove code that blocks support of some integrated NICs
2014-06-11 08:20, Pawel Wodkowski: > This patch removes obsolete code that prevents adding integrated copper NICs > 82575EB and I350 to list of supported NICs. Applied for version 1.7.0 with following addition: - remove conditions for I218 As you were only removing some lines, I assumed Signed-off-by line. Please, next time, provide it as described here: http://dpdk.org/dev#send Thanks -- Thomas
[dpdk-dev] eth dev doesn't free mbufs for 82575EB
2014-05-30 15:44, Helmut Sim: > I am trying to verify that the 82575EB NIC functions well. > The file rte_pci_dev_ids.h includes the following lines: > > #ifdef RTE_PCI_DEV_USE_82575EB_COPPER > RTE_PCI_DEV_ID_DECL_IGB(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82575EB_COPPER) > #endif > > so I defined the RTE_PCI_DEV_USE_82575EB_COPPER and hoped it will work well. This commit could interest you: http://dpdk.org/browse/dpdk/commit/?id=cc333208d5658fea6420 -- Thomas
[dpdk-dev] [PATCH v2 0/4] Link Bonding Library
Hi Declan, Do you think you can send another version of your serie soon? Some comments need to be addressed. 2 formatting comments: - I saw some strange alignments of comments - you should send your patches as children of the cover letter Thanks -- Thomas
[dpdk-dev] [PATCH v2 09/10] igbuio: show irq mode in sysfs
> -Original Message-
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> Sent: Sunday, June 08, 2014 4:37 PM
> To: Stephen Hemminger
> Cc: Carew, Alan; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 09/10] igbuio: show irq mode in sysfs
>
> On Fri, Jun 06, 2014 at 04:50:37PM -0700, Stephen Hemminger wrote:
> > Since irq mode is determined dynamically on a per-device
> > basis, and virtio needs to know if using intx or msi-x,
> > make it a sysfs attribute.
> >
> > --- a/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > +++ b/lib/librte_eal/linuxapp/igb_uio/igb_uio.c
> > @@ -43,6 +43,10 @@
> > IGBUIO_MSIX_INTR_MODE
> > };
> >
> > +static const char *igbuio_intr_modes[] = {
> > + "legacy", "msi", "msix"
> > +};
> > +
> > /**
> > * A structure describing the private information for a uio device.
> > */
> > @@ -128,8 +132,20 @@
> > }
> >
> > static DEVICE_ATTR(max_vfs, S_IRUGO | S_IWUSR, show_max_vfs,
> store_max_vfs);
> > +
> > +static ssize_t irq_mode_show(struct device *dev,
> > +struct device_attribute *attr, char *buf)
> > +{
> > + struct uio_info *info = pci_get_drvdata(to_pci_dev(dev));
> > + struct rte_uio_pci_dev *udev = igbuio_get_uio_pci_dev(info);
> > +
> > + return sprintf(buf, "%s\n", igbuio_intr_modes[udev->mode]);
> > +}
> > +static DEVICE_ATTR(irq_mode, S_IRUGO, irq_mode_show, NULL);
> > +
> > static struct attribute *dev_attrs[] = {
> > &dev_attr_max_vfs.attr,
> > + &dev_attr_irq_mode.attr,
> > NULL,
> > };
> >
> >
> >
> Do you really need this attribute? The pci bus sysfs tree already exports irq
> mode information for each device allocated already in
> /sys/bus/pci/device/msi_irqs
>
> Neil
Hi Neil,
After some digging around, I now realise what you mean, it is a good suggestion.
/sys/bus/pci/devices//msi_irqs//mode, where "msi_irqs" directory
only exists for msi/msix and not for int-x. Also the "mode" file contains
string of configured interrupt mode.
Thanks,
Alan
[dpdk-dev] [PATCH v2 09/10] igbuio: show irq mode in sysfs
This is what I am testing, along with 10 other virtio patches.
Subject: virtio: check for using msix interrupt
Fix how the device driver detects MSI-X vs INTX mode.
Look in sysfs to find if MSI-X is enabled.
Suggested-by: Neil Horman
Signed-off-by: Stephen Hemminger
--- a/lib/librte_pmd_virtio/virtio_ethdev.c
+++ b/lib/librte_pmd_virtio/virtio_ethdev.c
@@ -709,6 +709,28 @@
return 0;
}
+/*
+ * Detect if using INTX or MSI-X by looking for:
+ * /sys/bus/pci/devices//msi_irqs/
+ * if directory exists, must be using msi-x
+ */
+static int
+has_msix(const struct rte_pci_addr *loc)
+{
+ DIR *d;
+ char dirname[PATH_MAX];
+
+ rte_snprintf(dirname, sizeof(dirname),
+SYSFS_PCI_DEVICES "/" PCI_PRI_FMT "/msi_irqs",
+loc->domain, loc->bus, loc->devid, loc->function);
+
+ d = opendir(dirname);
+ if (d)
+ closedir(d);
+
+ return (d != NULL);
+}
+
static int get_uio_dev(struct rte_pci_addr *loc, char *buf, unsigned int
buflen)
{
unsigned int uio_num;
@@ -872,6 +894,8 @@
PMD_INIT_LOG(DEBUG,
"PCI Port IO found start=0x%lx with size=0x%lx\n",
start, size);
+
+ hw->use_msix = has_msix(&pci_dev->addr);
}
#endif
hw->io_base = (uint32_t)(uintptr_t)pci_dev->mem_resource[0].addr;
--- a/lib/librte_pmd_virtio/virtio_pci.h
+++ b/lib/librte_pmd_virtio/virtio_pci.h
@@ -177,6 +177,7 @@
uint16_tsubsystem_device_id;
uint16_tsubsystem_vendor_id;
uint8_t revision_id;
+ uint8_t use_msix;
uint8_t mac_addr[ETHER_ADDR_LEN];
int adapter_stopped;
};
@@ -194,13 +195,11 @@
uint16_t max_virtqueue_pairs;
} __attribute__((packed));
-/* Value indicated in device config */
-#define VIRTIO_PCI_FLAG_MSIX 0x0020
/*
* The remaining space is defined by each driver as the per-driver
* configuration space.
*/
-#define VIRTIO_PCI_CONFIG(hw) (((hw)->guest_features & VIRTIO_PCI_FLAG_MSIX) ?
24 : 20)
+#define VIRTIO_PCI_CONFIG(hw) (((hw)->use_msix) ? 24 : 20)
/*
* How many bits to shift physical queue address written to QUEUE_PFN.
[dpdk-dev] [PATCH] Add an API to query enabled core index
EAL -c option allows the user to enable any lcore in the system.
Oftentimes, the user app wants to know 1st enabled core, 2nd
enabled core, etc, rather than phyical core ID (rte_lcore_id().)
The new API rte_lcore_id2() will return an index from enabled lcores
starting from zero.
---
lib/librte_eal/common/include/rte_lcore.h| 12
lib/librte_eal/linuxapp/eal/eal.c| 1 +
lib/librte_eal/linuxapp/eal/include/exec-env/rte_lcore.h | 1 +
3 files changed, 14 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_lcore.h
b/lib/librte_eal/common/include/rte_lcore.h
index 3802a28..f0682ce 100644
--- a/lib/librte_eal/common/include/rte_lcore.h
+++ b/lib/librte_eal/common/include/rte_lcore.h
@@ -92,6 +92,18 @@ rte_lcore_count(void)
#include
/**
+ * Return the index of the enabled lcore starting from zero.
+ *
+ * @return
+ * the ID of current lcoreid's index
+ */
+static inline unsigned
+rte_lcore_id2(void)
+{
+ return lcore_config[rte_lcore_id()].core_id2;
+}
+
+/**
* Return the ID of the physical socket of the logical core we are
* running on.
* @return
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 070bdc9..a9c9e6c 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -444,6 +444,7 @@ eal_parse_coremask(const char *coremask)
return -1;
}
cfg->lcore_role[idx] = ROLE_RTE;
+ lcore_config[idx].core_id2 = count;
if(count == 0)
cfg->master_lcore = idx;
count++;
diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_lcore.h
b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_lcore.h
index e19ab54..9316b05 100644
--- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_lcore.h
+++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_lcore.h
@@ -57,6 +57,7 @@ struct lcore_config {
volatile enum rte_lcore_state_t state; /**< lcore state */
unsigned socket_id;/**< physical socket id for this lcore */
unsigned core_id; /**< core number on socket for this lcore */
+ unsigned core_id2; /**< DPDK core index, starting from 0 */
};
/**
--
2.0.0
[dpdk-dev] [PATCH] Add an API to query enabled core index
Hi, 2014-06-11 13:45, Patrick Lu: > EAL -c option allows the user to enable any lcore in the system. > Oftentimes, the user app wants to know 1st enabled core, 2nd > enabled core, etc, rather than phyical core ID (rte_lcore_id().) > > The new API rte_lcore_id2() will return an index from enabled lcores > starting from zero. I think core_id2 is not a representative name. What do you think of renaming core_id as lcore_hwid and core_id2 as lcore_index? -- Thomas
[dpdk-dev] [PATCH] Add an API to query enabled core index
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Wednesday, June 11, 2014 2:51 PM > To: Lu, Patrick > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] Add an API to query enabled core index > > Hi, > > 2014-06-11 13:45, Patrick Lu: > > EAL -c option allows the user to enable any lcore in the system. > > Oftentimes, the user app wants to know 1st enabled core, 2nd > > enabled core, etc, rather than phyical core ID (rte_lcore_id().) > > > > The new API rte_lcore_id2() will return an index from enabled lcores > > starting from zero. > > I think core_id2 is not a representative name. > What do you think of renaming core_id as lcore_hwid and core_id2 as > lcore_index? > > -- I like lcore_index as the name for the new function. However, I'm not sure in that case that we want/need to rename the old one.
[dpdk-dev] [PATCH] Add an API to query enabled core index
-Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Wednesday, June 11, 2014 2:51 PM To: Lu, Patrick Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH] Add an API to query enabled core index Hi, 2014-06-11 13:45, Patrick Lu: > EAL -c option allows the user to enable any lcore in the system. > Oftentimes, the user app wants to know 1st enabled core, 2nd enabled > core, etc, rather than phyical core ID (rte_lcore_id().) > > The new API rte_lcore_id2() will return an index from enabled lcores > starting from zero. I think core_id2 is not a representative name. What do you think of renaming core_id as lcore_hwid and core_id2 as lcore_index? -- Thomas I think this is a good idea. Except core_id is used in 13 other places. Should I resubmit the patch with core_id renamed it lcore_hwid? Patrick
[dpdk-dev] [PATCH v2 0/2] 10G PMD: vectorized RX and TX functions
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, June 11, 2014 3:19 PM > To: Richardson, Bruce > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 0/2] 10G PMD: vectorized RX and TX > functions > > Hi Bruce, > > You are introducing a new option CONFIG_RTE_IXGBE_RX_OLFLAGS_DISABLE. > I feel a comment in the code would be helpful here. Comment in the code, or in the config file where the option is defined? > > Sorry for not having checked before but there are some checkpatch issues > in this PMD. > Other simple cleanup: I think some include directives are useless. > > Could you rework a new version please? > Ack. I'll see what I can do.
[dpdk-dev] [PATCH] Add an API to query enabled core index
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, June 11, 2014 3:50 PM > To: Richardson, Bruce > Cc: Lu, Patrick; dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH] Add an API to query enabled core index > > 2014-06-11 21:57, Richardson, Bruce: > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > > 2014-06-11 13:45, Patrick Lu: > > > > The new API rte_lcore_id2() will return an index from enabled lcores > > > > starting from zero. > > > > > > I think core_id2 is not a representative name. > > > What do you think of renaming core_id as lcore_hwid and core_id2 as > > > lcore_index? > > > > I like lcore_index as the name for the new function. However, I'm not sure > > in that case that we want/need to rename the old one. > > I think it would be not easy to distinguish id and index. So I prefer > hwid/index. And lcore is more precise than core. > The function is already called "rte_lcore_id()" so there is no need to change it to make it an "lcore" function. That function has been around for a long time and is commonly used, so I'd prefer it not be changed unless it really is necessary. "rte_lcore_index" is a sufficiently different function name, in my opinion. The API documentation should clear up any confusion for the user anyway.
