[dpdk-dev] [PATCH v2] i40e: workaround for XL710 performance
On XL710, performance number is far from the expectation on recent
firmware versions, if promiscuous mode is disabled, or promiscuous
mode is enabled and port MAC address is equal to the packet
destination MAC address. The fix for this issue may not be
integrated in the following firmware version. So the workaround in
software driver is needed. For XL710, it needs to modify the initial
values of 3 internal only registers, which are the same as X710.
Note that the values for X710 and XL710 registers could be different,
and the workaround can be removed when it is fixed in firmware in
the future.
Signed-off-by: Helin Zhang
---
lib/librte_pmd_i40e/i40e_ethdev.c | 44 ++-
1 file changed, 30 insertions(+), 14 deletions(-)
v2 changes:
* Supported modifying the address of 0x269FBC of XL710 during
initialization, to fix the minor performance gap to expectation.
That means XL710 can meet the performance expectation with this
workaround.
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
b/lib/librte_pmd_i40e/i40e_ethdev.c
index b47a3d2..8982920 100644
--- a/lib/librte_pmd_i40e/i40e_ethdev.c
+++ b/lib/librte_pmd_i40e/i40e_ethdev.c
@@ -5327,38 +5327,54 @@ i40e_debug_read_register(struct i40e_hw *hw, uint32_t
addr, uint64_t *val)
/*
* On X710, performance number is far from the expectation on recent firmware
- * versions. The fix for this issue may not be integrated in the following
+ * versions; on XL710, performance number is also far from the expectation on
+ * recent firmware versions, if promiscuous mode is disabled, or promiscuous
+ * mode is enabled and port MAC address is equal to the packet destination MAC
+ * address. The fix for this issue may not be integrated in the following
* firmware version. So the workaround in software driver is needed. It needs
- * to modify the initial values of 3 internal only registers. Note that the
+ * to modify the initial values of 3 internal only registers for both X710 and
+ * XL710. Note that the values for X710 or XL710 could be different, and the
* workaround can be removed when it is fixed in firmware in the future.
*/
-static void
-i40e_configure_registers(struct i40e_hw *hw)
-{
+
+/* For both X710 and XL710 */
+#define I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE 0x1200
#define I40E_GL_SWR_PRI_JOIN_MAP_0 0x26CE00
+
+#define I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE 0x011f0200
#define I40E_GL_SWR_PRI_JOIN_MAP_2 0x26CE08
+
+/* For X710 */
+#define I40E_GL_SWR_PM_UP_THR_EF_VALUE 0x03030303
+/* For XL710 */
+#define I40E_GL_SWR_PM_UP_THR_SF_VALUE 0x06060606
#define I40E_GL_SWR_PM_UP_THR0x269FBC
-#define I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE 0x1200
-#define I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE 0x011f0200
-#define I40E_GL_SWR_PM_UP_THR_VALUE 0x03030303
- static const struct {
+static void
+i40e_configure_registers(struct i40e_hw *hw)
+{
+ static struct {
uint32_t addr;
uint64_t val;
} reg_table[] = {
{I40E_GL_SWR_PRI_JOIN_MAP_0, I40E_GL_SWR_PRI_JOIN_MAP_0_VALUE},
{I40E_GL_SWR_PRI_JOIN_MAP_2, I40E_GL_SWR_PRI_JOIN_MAP_2_VALUE},
- {I40E_GL_SWR_PM_UP_THR, I40E_GL_SWR_PM_UP_THR_VALUE},
+ {I40E_GL_SWR_PM_UP_THR, 0}, /* Compute value dynamically */
};
uint64_t reg;
uint32_t i;
int ret;
- /* Below fix is for X710 only */
- if (i40e_is_40G_device(hw->device_id))
- return;
-
for (i = 0; i < RTE_DIM(reg_table); i++) {
+ if (reg_table[i].addr == I40E_GL_SWR_PM_UP_THR) {
+ if (i40e_is_40G_device(hw->device_id)) /* For XL710 */
+ reg_table[i].val =
+ I40E_GL_SWR_PM_UP_THR_SF_VALUE;
+ else /* For X710 */
+ reg_table[i].val =
+ I40E_GL_SWR_PM_UP_THR_EF_VALUE;
+ }
+
ret = i40e_debug_read_register(hw, reg_table[i].addr, ®);
if (ret < 0) {
PMD_DRV_LOG(ERR, "Failed to read from 0x%"PRIx32,
--
1.9.3
[dpdk-dev] [PATCH v6 5/6] enicpmd: DPDK-ENIC PMD interface
Hi, ssujith
> + .tx_queue_release = enicpmd_dev_tx_queue_release,
> + .dev_led_on = NULL,
> + .dev_led_off = NULL,
> + .flow_ctrl_get= NULL,
> + .flow_ctrl_set= NULL,
> + .priority_flow_ctrl_set = NULL,
> + .mac_addr_add = enicpmd_add_mac_addr,
> + .mac_addr_remove = enicpmd_remove_mac_addr,
> + .fdir_add_signature_filter= NULL,
> + .fdir_update_signature_filter = NULL,
> + .fdir_remove_signature_filter = NULL,
> + .fdir_infos_get = enicpmd_fdir_info_get,
> + .fdir_add_perfect_filter = enicpmd_fdir_add_perfect_filter,
> + .fdir_update_perfect_filter = enicpmd_fdir_add_perfect_filter,
> + .fdir_remove_perfect_filter = enicpmd_fdir_remove_perfect_filter,
> + .fdir_set_masks = NULL,
> +};
> +
I found that in perfect fdir is also supported in enic driver.
During the R1.8 development, we defined a new dev_ops call filter_ctrl, which
can be used to control kinds of filters, flow director is included too. Which
is mentioned in http://www.dpdk.org/ml/archives/dev/2014-September/005179.html
.
In R1.8, filter_ctrl is only used by i40e driver. And we also planned use it in
the existing ixgbe/e1000 driver in the next days. The old APIs such as
fdir_add_perfect_filter, fdir_remove_perfect_filter can be replaced then.
So, do you have any plan to migrate the fdir in enic to the filter_ctrl API?
Jingjing
Thanks!
> +struct enic *enicpmd_list_head = NULL;
> +/* Initialize the driver
> + * It returns 0 on success.
> + */
> +static int eth_enicpmd_dev_init(
> + __attribute__((unused))struct eth_driver *eth_drv,
> + struct rte_eth_dev *eth_dev)
> +{
> + struct rte_pci_device *pdev;
> + struct rte_pci_addr *addr;
> + struct enic *enic = pmd_priv(eth_dev);
> +
> + ENICPMD_FUNC_TRACE();
> +
> + enic->rte_dev = eth_dev;
> + eth_dev->dev_ops = &enicpmd_eth_dev_ops;
> + eth_dev->rx_pkt_burst = &enicpmd_recv_pkts;
> + eth_dev->tx_pkt_burst = &enicpmd_xmit_pkts;
> +
> + pdev = eth_dev->pci_dev;
> + enic->pdev = pdev;
> + addr = &pdev->addr;
> +
> + snprintf(enic->bdf_name, ENICPMD_BDF_LENGTH,
> "%04x:%02x:%02x.%x",
> + addr->domain, addr->bus, addr->devid, addr->function);
> +
> + return enic_probe(enic);
> +}
> +
> +static struct eth_driver rte_enic_pmd = {
> + {
> + .name = "rte_enic_pmd",
> + .id_table = pci_id_enic_map,
> + .drv_flags = RTE_PCI_DRV_NEED_MAPPING,
> + },
> + .eth_dev_init = eth_enicpmd_dev_init,
> + .dev_private_size = sizeof(struct enic), };
> +
> +/* Driver initialization routine.
> + * Invoked once at EAL init time.
> + * Register as the [Poll Mode] Driver of Cisco ENIC device.
> + */
> +int rte_enic_pmd_init(const char *name __rte_unused,
> + const char *params __rte_unused)
> +{
> + ENICPMD_FUNC_TRACE();
> +
> + rte_eth_driver_register(&rte_enic_pmd);
> + return 0;
> +}
> +
> +static struct rte_driver rte_enic_driver = {
> + .type = PMD_PDEV,
> + .init = rte_enic_pmd_init,
> +};
> +
> +PMD_REGISTER_DRIVER(rte_enic_driver);
> +
> --
> 1.9.1
[dpdk-dev] [PATCH 0/7] Move EAL common functions
Hi Ravi, On 12/25/2014 04:33 PM, Ravi Kerur wrote: > Common functions in linuxapp and bsdapp are moved into > librte_eal/common directory. > New files added follow _common_ naming conventions. > Tested against ubuntu and FreeBSD. Trying to factorize the common code goes in the good direction. However I'm wondering if "common" is the proper place. Initially, the common directory was for code common to linuxapp and baremetal. Now that baremetal does not exist anymore, a lot of code is common to the 2 OSes that are supported (linux and FreeBSD). What about moving this code in "common-posix" instead? It would let the door open for future ports (Windows? or any other real time OS? Or back in baremetal?). Regards, Olivier
[dpdk-dev] TSO with chained imbues
Hi Gal, On 12/25/2014 04:55 PM, Gal Sagie wrote: > Does the TSO offload option works for chained mbufs? > What i mean is, if i have a chain representing a big TCP buffer, and i only > set the first mbuf with > TSO flags and tso_segsz (mss) and L4 size, will that work ? (or only > applied on the first mbuf) This should work indeed. In a mbuf chain, only the first mbuf carries the flags for the whole chain. Regards, Olivier
[dpdk-dev] [PATCH 0/7] Move EAL common functions
On Mon, Dec 29, 2014 at 09:47:05AM +0100, Olivier MATZ wrote: > Hi Ravi, > > On 12/25/2014 04:33 PM, Ravi Kerur wrote: > > Common functions in linuxapp and bsdapp are moved into > > librte_eal/common directory. > > New files added follow _common_ naming conventions. > > Tested against ubuntu and FreeBSD. > > Trying to factorize the common code goes in the good direction. > > However I'm wondering if "common" is the proper place. Initially, > the common directory was for code common to linuxapp and baremetal. > Now that baremetal does not exist anymore, a lot of code is common > to the 2 OSes that are supported (linux and FreeBSD). > > What about moving this code in "common-posix" instead? > It would let the door open for future ports (Windows? or any > other real time OS? Or back in baremetal?). > Posix doesn't make sense IMO, in that a large segment of the functions embodied in the common directory have nothing to do with posix API's, and are simply just useful functions that have not OS specific dependency (the entire eal_common_memory.c file for example, to name just one). If you wanted to rename the directory, I would say generic-os would be more appropriate. Neil > Regards, > Olivier >
[dpdk-dev] [PATCH 0/7] Move EAL common functions
Hi Neil, On 12/29/2014 01:47 PM, Neil Horman wrote: > On Mon, Dec 29, 2014 at 09:47:05AM +0100, Olivier MATZ wrote: >> Trying to factorize the common code goes in the good direction. >> >> However I'm wondering if "common" is the proper place. Initially, >> the common directory was for code common to linuxapp and baremetal. >> Now that baremetal does not exist anymore, a lot of code is common >> to the 2 OSes that are supported (linux and FreeBSD). >> >> What about moving this code in "common-posix" instead? >> It would let the door open for future ports (Windows? or any >> other real time OS? Or back in baremetal?). >> > Posix doesn't make sense IMO, in that a large segment of the functions > embodied > in the common directory have nothing to do with posix API's, and are simply > just > useful functions that have not OS specific dependency (the entire > eal_common_memory.c file for example, to name just one). > > If you wanted to rename the directory, I would say generic-os would be more > appropriate. That's probably right for most of the code in the patch. I just wanted to point out that "common" is sometimes a bit vague (common to archs, common to OSes, common to all). >From a quick look, these 2 files could be concerned and could go to a common-posix directory: - eal.c (use fopen/ftruncate/fcntl/mmap/...) - eal_thread.c (use pipe/read/write) There's no urgency to do that now and maybe we should wait it's really needed. I was just seizing the opportunity as the code is moved. Regards, Olivier
[dpdk-dev] [PATCH v2 1/6] Move EAL common functions
I will change the subject and make it more explicit. In addition, I was
thinking of adding function names which are moved as part of commit message
so that it is easier for everyone to check what is moved rather than going
through the patch. Do you think it would be helpful??
Thanks.
On Sun, Dec 28, 2014 at 12:42 PM, Neil Horman wrote:
> On Sat, Dec 27, 2014 at 10:33:17AM -0500, Ravi Kerur wrote:
> > Changes in v2
> > 1. Remove rte_dump_registers() function since it is not implemented.
> > 2. Fix comment for _rte_exit()
> >
> > eal_debug.c has no difference between Linux and BSD, move
> > into common directory.
> > Rename eal_debug.c to eal_common_debug.c
> > Makefile changes to reflect file move and name change.
> > Fix checkpatch warnings.
> >
> > Signed-off-by: Ravi Kerur
> The subject matter for all of the patches in the series should be more
> detailed.
> Just posting move EAL components to common directly isn't overly
> informative
> Neil
>
> > ---
> > app/test/test_debug.c | 1 -
> > lib/librte_eal/bsdapp/eal/Makefile| 2 +-
> > lib/librte_eal/bsdapp/eal/eal_debug.c | 113
> --
> > lib/librte_eal/common/eal_common_debug.c | 106
>
> > lib/librte_eal/common/include/rte_debug.h | 7 --
> > lib/librte_eal/linuxapp/eal/Makefile | 2 +-
> > lib/librte_eal/linuxapp/eal/eal_debug.c | 113
> --
> > 7 files changed, 108 insertions(+), 236 deletions(-)
> > delete mode 100644 lib/librte_eal/bsdapp/eal/eal_debug.c
> > create mode 100644 lib/librte_eal/common/eal_common_debug.c
> > delete mode 100644 lib/librte_eal/linuxapp/eal/eal_debug.c
> >
> > diff --git a/app/test/test_debug.c b/app/test/test_debug.c
> > index 7c3ee92..01d4b76 100644
> > --- a/app/test/test_debug.c
> > +++ b/app/test/test_debug.c
> > @@ -136,7 +136,6 @@ static int
> > test_debug(void)
> > {
> > rte_dump_stack();
> > - rte_dump_registers();
> > if (test_panic() < 0)
> > return -1;
> > if (test_exit() < 0)
> > diff --git a/lib/librte_eal/bsdapp/eal/Makefile
> b/lib/librte_eal/bsdapp/eal/Makefile
> > index d434882..9b83e11 100644
> > --- a/lib/librte_eal/bsdapp/eal/Makefile
> > +++ b/lib/librte_eal/bsdapp/eal/Makefile
> > @@ -53,7 +53,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) +=
> eal_hugepage_info.c
> > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_thread.c
> > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_log.c
> > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_pci.c
> > -SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_debug.c
> > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_lcore.c
> > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_timer.c
> > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_interrupts.c
> > @@ -73,6 +72,7 @@ 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_dev.c
> > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_options.c
> > +SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_debug.c
> >
> > CFLAGS_eal.o := -D_GNU_SOURCE
> > #CFLAGS_eal_thread.o := -D_GNU_SOURCE
> > diff --git a/lib/librte_eal/bsdapp/eal/eal_debug.c
> b/lib/librte_eal/bsdapp/eal/eal_debug.c
> > deleted file mode 100644
> > index 44fc4f3..000
> > --- a/lib/librte_eal/bsdapp/eal/eal_debug.c
> > +++ /dev/null
> > @@ -1,113 +0,0 @@
> > -/*-
> > - * 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,
> > - * DAT
[dpdk-dev] [PATCH 0/7] Move EAL common functions
On Mon, Dec 29, 2014 at 02:16:16PM +0100, Olivier MATZ wrote: > Hi Neil, > > On 12/29/2014 01:47 PM, Neil Horman wrote: > > On Mon, Dec 29, 2014 at 09:47:05AM +0100, Olivier MATZ wrote: > >> Trying to factorize the common code goes in the good direction. > >> > >> However I'm wondering if "common" is the proper place. Initially, > >> the common directory was for code common to linuxapp and baremetal. > >> Now that baremetal does not exist anymore, a lot of code is common > >> to the 2 OSes that are supported (linux and FreeBSD). > >> > >> What about moving this code in "common-posix" instead? > >> It would let the door open for future ports (Windows? or any > >> other real time OS? Or back in baremetal?). > >> > > Posix doesn't make sense IMO, in that a large segment of the functions > > embodied > > in the common directory have nothing to do with posix API's, and are simply > > just > > useful functions that have not OS specific dependency (the entire > > eal_common_memory.c file for example, to name just one). > > > > If you wanted to rename the directory, I would say generic-os would be more > > appropriate. > > That's probably right for most of the code in the patch. I just wanted > to point out that "common" is sometimes a bit vague (common to archs, > common to OSes, common to all). > Agreed, common isn't explicitly common to everything > From a quick look, these 2 files could be concerned and could go to a > common-posix directory: > - eal.c (use fopen/ftruncate/fcntl/mmap/...) > - eal_thread.c (use pipe/read/write) > Thats what they use, sure, but they don't export any POSIX mapped API, nor are they guaranteed to only use POSIX library calls in the future (e.g. eal.c exports functions like eal_parse_sysfs_value, which is completely unrelated to POSIX, and may be implemented using zzip_file_read, though I wouldn't recommend it :)). Point being naming the directory common-posix, is not a descriptor of either its exported API, nor a guarantee of its internal implementation. I would be more comfortable with something that is descriptive of the fact that this code exports an API that is common to all operating systems (something like generic-eal). If the implementation of a given function in common isn't supported on a newly added operating system, then we need to either remove the function from the common directory and do specific implementations of it for each os, or develop an override mechanism (something like marking the common function as weak, and implementing an override version in any OS that doesn't support its implementation. > There's no urgency to do that now and maybe we should wait it's really > needed. I was just seizing the opportunity as the code is moved. > No, no urgency, but its been my experience that this sort of work doesn't get done unless theres a motivator to make it so. We have a contributor here that is willing to do the work, so this seems like an opportune time to suggest stuff like this. If he doesn't want to do it, so be it, this collapsing is definately better that what is there now, but if he's willing, I think this would be another great step forward. Neil > Regards, > Olivier >
[dpdk-dev] [PATCH v2 1/6] Move EAL common functions
On Mon, Dec 29, 2014 at 07:34:22AM -0800, Ravi Kerur wrote:
> I will change the subject and make it more explicit. In addition, I was
> thinking of adding function names which are moved as part of commit message
> so that it is easier for everyone to check what is moved rather than going
> through the patch. Do you think it would be helpful??
>
yeah, adding that detail in the changelog, as well as the files updated in the
subject would be a big help for historical purposes. Thanks!
Neil
> Thanks.
>
> On Sun, Dec 28, 2014 at 12:42 PM, Neil Horman
> wrote:
>
> > On Sat, Dec 27, 2014 at 10:33:17AM -0500, Ravi Kerur wrote:
> > > Changes in v2
> > > 1. Remove rte_dump_registers() function since it is not implemented.
> > > 2. Fix comment for _rte_exit()
> > >
> > > eal_debug.c has no difference between Linux and BSD, move
> > > into common directory.
> > > Rename eal_debug.c to eal_common_debug.c
> > > Makefile changes to reflect file move and name change.
> > > Fix checkpatch warnings.
> > >
> > > Signed-off-by: Ravi Kerur
> > The subject matter for all of the patches in the series should be more
> > detailed.
> > Just posting move EAL components to common directly isn't overly
> > informative
> > Neil
> >
> > > ---
> > > app/test/test_debug.c | 1 -
> > > lib/librte_eal/bsdapp/eal/Makefile| 2 +-
> > > lib/librte_eal/bsdapp/eal/eal_debug.c | 113
> > --
> > > lib/librte_eal/common/eal_common_debug.c | 106
> >
> > > lib/librte_eal/common/include/rte_debug.h | 7 --
> > > lib/librte_eal/linuxapp/eal/Makefile | 2 +-
> > > lib/librte_eal/linuxapp/eal/eal_debug.c | 113
> > --
> > > 7 files changed, 108 insertions(+), 236 deletions(-)
> > > delete mode 100644 lib/librte_eal/bsdapp/eal/eal_debug.c
> > > create mode 100644 lib/librte_eal/common/eal_common_debug.c
> > > delete mode 100644 lib/librte_eal/linuxapp/eal/eal_debug.c
> > >
> > > diff --git a/app/test/test_debug.c b/app/test/test_debug.c
> > > index 7c3ee92..01d4b76 100644
> > > --- a/app/test/test_debug.c
> > > +++ b/app/test/test_debug.c
> > > @@ -136,7 +136,6 @@ static int
> > > test_debug(void)
> > > {
> > > rte_dump_stack();
> > > - rte_dump_registers();
> > > if (test_panic() < 0)
> > > return -1;
> > > if (test_exit() < 0)
> > > diff --git a/lib/librte_eal/bsdapp/eal/Makefile
> > b/lib/librte_eal/bsdapp/eal/Makefile
> > > index d434882..9b83e11 100644
> > > --- a/lib/librte_eal/bsdapp/eal/Makefile
> > > +++ b/lib/librte_eal/bsdapp/eal/Makefile
> > > @@ -53,7 +53,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) +=
> > eal_hugepage_info.c
> > > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_thread.c
> > > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_log.c
> > > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_pci.c
> > > -SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_debug.c
> > > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_lcore.c
> > > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_timer.c
> > > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_interrupts.c
> > > @@ -73,6 +72,7 @@ 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_dev.c
> > > SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_options.c
> > > +SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_debug.c
> > >
> > > CFLAGS_eal.o := -D_GNU_SOURCE
> > > #CFLAGS_eal_thread.o := -D_GNU_SOURCE
> > > diff --git a/lib/librte_eal/bsdapp/eal/eal_debug.c
> > b/lib/librte_eal/bsdapp/eal/eal_debug.c
> > > deleted file mode 100644
> > > index 44fc4f3..000
> > > --- a/lib/librte_eal/bsdapp/eal/eal_debug.c
> > > +++ /dev/null
> > > @@ -1,113 +0,0 @@
> > > -/*-
> > > - * 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, INCLUDIN
[dpdk-dev] [PATCH v3 1/4] compat: Add infrastructure to support symbol versioning
On Tue, Dec 23, 2014 at 10:51:50AM -0500, Neil Horman wrote: > Add initial pass header files to support symbol versioning. > > Signed-off-by: Neil Horman > CC: Thomas Monjalon > CC: "Richardson, Bruce" > CC: "Gonzalez Monroy, Sergio" > > Change Notes: > V2) > Moved ifeq to _INSTALL target > > V3) > Undo V2 changes and make librte_compat use the rte.install.mk file > instead > --- > lib/Makefile | 1 + > lib/librte_compat/Makefile | 38 + > lib/librte_compat/rte_compat.h | 96 > ++ > mk/rte.lib.mk | 4 ++ > 4 files changed, 139 insertions(+) > create mode 100644 lib/librte_compat/Makefile > create mode 100644 lib/librte_compat/rte_compat.h > Acked-by: Sergio Gonzalez Monroy
[dpdk-dev] [PATCH v3 2/4] Provide initial versioning for all DPDK libraries
On Tue, Dec 23, 2014 at 10:51:51AM -0500, Neil Horman wrote: > Add linker version script files to each DPDK library to put a stake in the > ground from which we can start cleaning up API's > > Signed-off-by: Neil Horman > CC: Thomas Monjalon > CC: "Richardson, Bruce" > > --- > Change Notes: > > v2) > * Updated export map to not require full path > --- Acked-by: Sergio Gonzalez Monroy
[dpdk-dev] [PATCH v3 3/4] Add library version extenstion
On Tue, Dec 23, 2014 at 10:51:52AM -0500, Neil Horman wrote: > To differentiate libraries that break ABI, we add a library version number > suffix to the library, which must be incremented when a given libraries ABI is > broken. This patch enforces that addition, sets the initial abi soname > extension to 1 for each library and creates a symlink to the base SONAME so > that > the test applications will link properly. > > Signed-off-by: Neil Horman > CC: Thomas Monjalon > CC: "Richardson, Bruce" > > Change Notes: > v3) > Made symlinking of libraries conditional on a DSO build > --- Acked-by: Sergio Gonzalez Monroy
[dpdk-dev] [PATCH v3 4/4] docs: Add ABI documentation
On Tue, Dec 23, 2014 at 10:51:53AM -0500, Neil Horman wrote: > Adding a document describing rudimentary ABI policy and adding notice space > for > any deprecation announcements > > Signed-off-by: Neil Horman > CC: Thomas Monjalon > CC: "Richardson, Bruce" > --- > doc/abi.txt | 17 + > 1 file changed, 17 insertions(+) > create mode 100644 doc/abi.txt > > diff --git a/doc/abi.txt b/doc/abi.txt > new file mode 100644 > index 000..b6dcc7d > --- /dev/null > +++ b/doc/abi.txt > @@ -0,0 +1,17 @@ > +ABI policy: > + ABI versions are set at the time of major release labeling, and ABI may > +change multiple times between the last labeling and the HEAD label of the git > +tree without warning > + > + ABI versions, once released are available until such time as their > +deprecation has been noted here for at least one major release cycle, after > it > +has been tagged. E.g. the ABI for DPDK 1.8 is shipped, and then the > decision to > +remove it is made during the development of DPDK 1.9. The decision will be > +recorded here, shipped with the DPDK 1.9 release, and actually removed when > DPDK > +1.10 ships. > + > + ABI versions may be deprecated in whole, or in part as needed by a given > +update. > + > +Deprecation Notices: > + > -- > 1.9.3 > Acked-by: Sergio Gonzalez Monroy
[dpdk-dev] [PATCH 0/7] Move EAL common functions
Thanks Olivier and Neil. I will make a note on this and will work on it after initial common code movement is completed. On Mon, Dec 29, 2014 at 5:16 AM, Olivier MATZ wrote: > Hi Neil, > > On 12/29/2014 01:47 PM, Neil Horman wrote: > > On Mon, Dec 29, 2014 at 09:47:05AM +0100, Olivier MATZ wrote: > >> Trying to factorize the common code goes in the good direction. > >> > >> However I'm wondering if "common" is the proper place. Initially, > >> the common directory was for code common to linuxapp and baremetal. > >> Now that baremetal does not exist anymore, a lot of code is common > >> to the 2 OSes that are supported (linux and FreeBSD). > >> > >> What about moving this code in "common-posix" instead? > >> It would let the door open for future ports (Windows? or any > >> other real time OS? Or back in baremetal?). > >> > > Posix doesn't make sense IMO, in that a large segment of the functions > embodied > > in the common directory have nothing to do with posix API's, and are > simply just > > useful functions that have not OS specific dependency (the entire > > eal_common_memory.c file for example, to name just one). > > > > If you wanted to rename the directory, I would say generic-os would be > more > > appropriate. > > That's probably right for most of the code in the patch. I just wanted > to point out that "common" is sometimes a bit vague (common to archs, > common to OSes, common to all). > > From a quick look, these 2 files could be concerned and could go to a > common-posix directory: > - eal.c (use fopen/ftruncate/fcntl/mmap/...) > - eal_thread.c (use pipe/read/write) > > There's no urgency to do that now and maybe we should wait it's really > needed. I was just seizing the opportunity as the code is moved. > > Regards, > Olivier >
[dpdk-dev] l3fwd error, port 0 is not present on the board
Hello all, Rangeley platform (1 CPU with 8 cores, 4x1 GbE, 2x10 GbE, Intel PCIe card with 2x10 GbE fiber) FC20 with hugepages enabled DPDK 1.8.0 built with T=x86_64-ivshmem-linuxapp-gcc */usr/src/dpdk/tools/dpdk_nic_bind.py --status* Network devices using DPDK-compatible driver :09:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio unused=ixgbe :09:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio unused=ixgbe Network devices using kernel driver === :00:14.0 'Ethernet Connection I354' if=enp0s20f0 drv=igb unused=igb_uio :00:14.1 'Ethernet Connection I354' if=enp0s20f1 drv=igb unused=igb_uio :00:14.2 'Ethernet Connection I354' if=enp0s20f2 drv=igb unused=igb_uio :00:14.3 'Ethernet Connection I354' if=enp0s20f3 drv=igb unused=igb_uio :07:00.0 'Ethernet Controller 10-Gigabit X540-AT2' if=p5p1 drv=ixgbe unused=igb_uio *Active* :07:00.1 'Ethernet Controller 10-Gigabit X540-AT2' if=p5p2 drv=ixgbe unused=igb_uio Other network devices = The DPDK helloworld example seems to run OK, other than the warning about IVSHMEM configuration not found: *./helloworld -c 0x3 -n 4* EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 EAL: Detected lcore 2 as core 2 on socket 0 EAL: Detected lcore 3 as core 3 on socket 0 EAL: Detected lcore 4 as core 4 on socket 0 EAL: Detected lcore 5 as core 5 on socket 0 EAL: Detected lcore 6 as core 6 on socket 0 EAL: Detected lcore 7 as core 7 on socket 0 EAL: Support maximum 128 logical core(s) by configuration. EAL: Detected 8 lcore(s) EAL: Searching for IVSHMEM devices... EAL: No IVSHMEM configuration found! EAL: Setting up memory... EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fcca2c0 (size = 0x20) EAL: Ask a virtual area of 0x2940 bytes EAL: Virtual area found at 0x7fcc7960 (size = 0x2940) EAL: Ask a virtual area of 0x40 bytes EAL: Virtual area found at 0x7fcca340 (size = 0x40) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fcca300 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fcc7920 (size = 0x20) EAL: Ask a virtual area of 0x14d00 bytes EAL: Virtual area found at 0x7fcb2c00 (size = 0x14d00) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7fcb2bc0 (size = 0x20) EAL: Requesting 3000 pages of size 2MB from socket 0 EAL: TSC frequency is ~2393997 KHz EAL: Master core 0 is ready (tid=a4ca2840) EAL: Core 1 is ready (tid=2bbff700) hello from core 1 hello from core 0 I want to run the l3fwd example app, per Appendix A.2 (pg 35-36) in the DPDK 1.2 Release Benchmark Test Report .pdf: *./build/l3fwd -c 0x6 -n 4 --socket-mem 1024,0 -- -p 0x3 -config="(0,0,1),(1,0,2)"* where the "-p option is the hexadecimal bit mask of the ports to configure" I am running this command: *./build/l3fwd -c 0x3 -n 4 --socket-mem 1024,0 -- -p 0x3 --config="(0,0,0),(1,0,1)" --no-numa* EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 EAL: Detected lcore 2 as core 2 on socket 0 EAL: Detected lcore 3 as core 3 on socket 0 EAL: Detected lcore 4 as core 4 on socket 0 EAL: Detected lcore 5 as core 5 on socket 0 EAL: Detected lcore 6 as core 6 on socket 0 EAL: Detected lcore 7 as core 7 on socket 0 EAL: Support maximum 128 logical core(s) by configuration. EAL: Detected 8 lcore(s) EAL: Searching for IVSHMEM devices... EAL: No IVSHMEM configuration found! EAL: Setting up memory... EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f321260 (size = 0x20) EAL: Ask a virtual area of 0x2940 bytes EAL: Virtual area found at 0x7f31e900 (size = 0x2940) EAL: Ask a virtual area of 0x40 bytes EAL: Virtual area found at 0x7f3212e0 (size = 0x40) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f3212a0 (size = 0x20) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f31e8c0 (size = 0x20) EAL: Ask a virtual area of 0x14d00 bytes EAL: Virtual area found at 0x7f309ba0 (size = 0x14d00) EAL: Ask a virtual area of 0x20 bytes EAL: Virtual area found at 0x7f309b60 (size = 0x20) EAL: Requesting 512 pages of size 2MB from socket 0 EAL: TSC frequency is ~2393998 KHz EAL: Master core 0 is ready (tid=14734840) EAL: Core 1 is ready (tid=e8bff700) numa is disabled port 0 is not present on the board EAL: Error - exiting with code: 1 Cause: check_port_config failed Perhaps the 0x3 (0011) hex portmask is incorrect? What Linux command, or combination of commands, would help show the appropriate hex portmask to use in my case? Thanks for your time, Lyn
[dpdk-dev] l3fwd error, port 0 is not present on the board
On Mon, Dec 29, 2014 at 02:18:09PM -0600, Lyn M wrote: > Hello all, > > Rangeley platform (1 CPU with 8 cores, 4x1 GbE, 2x10 GbE, Intel PCIe card > with 2x10 GbE fiber) > FC20 with hugepages enabled > DPDK 1.8.0 built with T=x86_64-ivshmem-linuxapp-gcc > > */usr/src/dpdk/tools/dpdk_nic_bind.py --status* > > > > Network devices using DPDK-compatible driver > > > > :09:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio > unused=ixgbe > > :09:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio > unused=ixgbe > > > > Network devices using kernel driver > > === > > :00:14.0 'Ethernet Connection I354' if=enp0s20f0 drv=igb unused=igb_uio > > :00:14.1 'Ethernet Connection I354' if=enp0s20f1 drv=igb unused=igb_uio > > :00:14.2 'Ethernet Connection I354' if=enp0s20f2 drv=igb unused=igb_uio > > :00:14.3 'Ethernet Connection I354' if=enp0s20f3 drv=igb unused=igb_uio > > :07:00.0 'Ethernet Controller 10-Gigabit X540-AT2' if=p5p1 drv=ixgbe > unused=igb_uio *Active* > > :07:00.1 'Ethernet Controller 10-Gigabit X540-AT2' if=p5p2 drv=ixgbe > unused=igb_uio > > > > Other network devices > > = > > > > The DPDK helloworld example seems to run OK, other than the warning about > IVSHMEM configuration not found: > *./helloworld -c 0x3 -n 4* > EAL: Detected lcore 0 as core 0 on socket 0 > EAL: Detected lcore 1 as core 1 on socket 0 > EAL: Detected lcore 2 as core 2 on socket 0 > EAL: Detected lcore 3 as core 3 on socket 0 > EAL: Detected lcore 4 as core 4 on socket 0 > EAL: Detected lcore 5 as core 5 on socket 0 > EAL: Detected lcore 6 as core 6 on socket 0 > EAL: Detected lcore 7 as core 7 on socket 0 > EAL: Support maximum 128 logical core(s) by configuration. > EAL: Detected 8 lcore(s) > EAL: Searching for IVSHMEM devices... > EAL: No IVSHMEM configuration found! > EAL: Setting up memory... > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7fcca2c0 (size = 0x20) > EAL: Ask a virtual area of 0x2940 bytes > EAL: Virtual area found at 0x7fcc7960 (size = 0x2940) > EAL: Ask a virtual area of 0x40 bytes > EAL: Virtual area found at 0x7fcca340 (size = 0x40) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7fcca300 (size = 0x20) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7fcc7920 (size = 0x20) > EAL: Ask a virtual area of 0x14d00 bytes > EAL: Virtual area found at 0x7fcb2c00 (size = 0x14d00) > EAL: Ask a virtual area of 0x20 bytes > EAL: Virtual area found at 0x7fcb2bc0 (size = 0x20) > EAL: Requesting 3000 pages of size 2MB from socket 0 > EAL: TSC frequency is ~2393997 KHz > EAL: Master core 0 is ready (tid=a4ca2840) > EAL: Core 1 is ready (tid=2bbff700) > hello from core 1 > hello from core 0 > > > I want to run the l3fwd example app, per Appendix A.2 (pg 35-36) in the > DPDK 1.2 Release Benchmark Test Report .pdf: > *./build/l3fwd -c 0x6 -n 4 --socket-mem 1024,0 -- -p 0x3 > -config="(0,0,1),(1,0,2)"* > where the "-p option is the hexadecimal bit mask of the ports to configure" > > I am running this command: > > *./build/l3fwd -c 0x3 -n 4 --socket-mem 1024,0 -- -p 0x3 > --config="(0,0,0),(1,0,1)" --no-numa* > > EAL: Detected lcore 0 as core 0 on socket 0 > > EAL: Detected lcore 1 as core 1 on socket 0 > > EAL: Detected lcore 2 as core 2 on socket 0 > > EAL: Detected lcore 3 as core 3 on socket 0 > > EAL: Detected lcore 4 as core 4 on socket 0 > > EAL: Detected lcore 5 as core 5 on socket 0 > > EAL: Detected lcore 6 as core 6 on socket 0 > > EAL: Detected lcore 7 as core 7 on socket 0 > > EAL: Support maximum 128 logical core(s) by configuration. > > EAL: Detected 8 lcore(s) > > EAL: Searching for IVSHMEM devices... > > EAL: No IVSHMEM configuration found! > > EAL: Setting up memory... > > EAL: Ask a virtual area of 0x20 bytes > > EAL: Virtual area found at 0x7f321260 (size = 0x20) > > EAL: Ask a virtual area of 0x2940 bytes > > EAL: Virtual area found at 0x7f31e900 (size = 0x2940) > > EAL: Ask a virtual area of 0x40 bytes > > EAL: Virtual area found at 0x7f3212e0 (size = 0x40) > > EAL: Ask a virtual area of 0x20 bytes > > EAL: Virtual area found at 0x7f3212a0 (size = 0x20) > > EAL: Ask a virtual area of 0x20 bytes > > EAL: Virtual area found at 0x7f31e8c0 (size = 0x20) > > EAL: Ask a virtual area of 0x14d00 bytes > > EAL: Virtual area found at 0x7f309ba0 (size = 0x14d00) > > EAL: Ask a virtual area of 0x20 bytes > > EAL: Virtual area found at 0x7f309b60 (size = 0x20) > > EAL: Requesting 512 pages of size 2MB from socket 0 > > EAL: TSC frequency is ~2393998 KHz > > EAL: Master core 0 is ready (tid=14734840) > > EAL: Core 1 is ready (tid=e8bff700) > > numa is disabled > > port 0 is n
