* Re: [PATCH v1] doc: rearrange the high level documentation index
From: Thomas Monjalon @ 2016-11-11 16:48 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264D84C@IRSMSX103.ger.corp.intel.com>
2016-11-11 13:53, Mcnamara, John:
> I would prefer not to have some of these are highest level items such as
> "Xen Guide", and possibly "Crypto Device Drivers". Perhaps we could push
> them down a level with "Network Interface Controller Drivers" under a
> "Devices and Drivers" (or similar) section like:
>
> * ...
> * Programmer's Guide
> * HowTo Guides
> * DPDK Tools User Guides
> * Devices and Drivers
> * Network Interface Controller Drivers
> * Crypto Device Drivers
> * Xen Guide
Yes it may be an idea.
But as we will continue to support Xen Dom0, I think Xen should have
a special place somewhere (in Linux guide or separated)?
^ permalink raw reply
* Re: [PATCH] improve git diff
From: Thomas Monjalon @ 2016-11-11 16:21 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <969aae35-9129-d26c-70a7-fb61f0f985d1@intel.com>
2016-11-11 11:22, Ferruh Yigit:
> On 11/9/2016 3:44 PM, Thomas Monjalon wrote:
> > Sometimes git does not print the name of the function being changed
> > after @@. It happens especially after a goto label which is not indented.
> > Giving a hint about the languages of files .c, .h and .py
> > will improve hunk headers of "git diff" rendering.
> >
> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
[...]
> > --- /dev/null
> > +++ b/.gitattributes
> > @@ -0,0 +1,3 @@
> > +*.c diff=cpp
> > +*.h diff=cpp
>
> Can't git auto detect to use C/C++ language diff use for .c/.h files?
No
> Do you have a sample that generates bad hunk header, just to test?
Yes, you'll find a lot of them with "git log -p | grep '@@.*:'"
Example:
git show bb6722f | grep '@@.*:'
Without the patch, it is a goto label in the hunk header.
^ permalink raw reply
* Re: [PATCH] doc: announce API and ABI changes for librte_eal
From: Pattan, Reshma @ 2016-11-11 15:02 UTC (permalink / raw)
To: Shreyansh Jain
Cc: Neil Horman, dev@dpdk.org, Thomas Monjalon, Yigit, Ferruh,
David Marchand
In-Reply-To: <878e582b-07e3-9bb5-7de9-063b1d76fc95@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, November 11, 2016 1:05 PM
> To: David Marchand <david.marchand@6wind.com>; Shreyansh Jain
> <shreyansh.jain@nxp.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>; dev@dpdk.org; Thomas
> Monjalon <thomas.monjalon@6wind.com>
> Subject: Re: [dpdk-dev] [PATCH] doc: announce API and ABI changes for
> librte_eal
>
> On 11/10/2016 3:51 PM, David Marchand wrote:
> > On Thu, Nov 10, 2016 at 12:17 PM, Shreyansh Jain
> <shreyansh.jain@nxp.com> wrote:
> >> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
> >> ---
> >> doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> >> index 1a9e1ae..2af2476 100644
> >> --- a/doc/guides/rel_notes/deprecation.rst
> >> +++ b/doc/guides/rel_notes/deprecation.rst
> >> @@ -35,3 +35,13 @@ Deprecation Notices
> >> * mempool: The functions for single/multi producer/consumer are
> deprecated
> >> and will be removed in 17.02.
> >> It is replaced by ``rte_mempool_generic_get/put`` functions.
> >> +
> >> +* ABI/API changes are planned for 17.02: ``rte_device``, ``rte_driver`` will
> be
> >> + impacted because of introduction of a new ``rte_bus`` hierarchy. This
> would
> >> + also impact the way devices are identified by EAL. A bus-device-driver
> model
> >> + will be introduced providing a hierarchical view of devices.
> >> +
> >> +* ``eth_driver`` is planned to be removed in 17.02. This currently serves
> as
> >> + a placeholder for PMDs to register themselves. Changes for ``rte_bus``
> will
> >> + provide a way to handle device initialization currently being done in
> >> + ``eth_driver``.
> >> --
> >> 2.7.4
> >>
> >
> > Acked-by: David Marchand <david.marchand@6wind.com>
>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: Reshma Pattan <reshma.pattan@intel.com>
^ permalink raw reply
* Re: [PATCH v2] mempool: Free memzone if mempool populate phys fails
From: Olivier Matz @ 2016-11-11 14:35 UTC (permalink / raw)
To: Hemant Agrawal; +Cc: dev, Nipun Gupta
In-Reply-To: <1478879230-15729-1-git-send-email-hemant.agrawal@nxp.com>
Hi Hemant,
On 11/11/2016 04:47 PM, Hemant Agrawal wrote:
> From: Nipun Gupta <nipun.gupta@nxp.com>
>
> This patch fixes the issue of memzone not being freed incase the
> rte_mempool_populate_phys fails in the rte_mempool_populate_default
>
> This issue was identified when testing with OVS ~2.6
> - configure the system with low memory (e.g. < 500 MB)
> - add bridge and dpdk interfaces
> - delete brigde
> - keep on repeating the above sequence.
>
> Fixes: d1d914ebbc25 ("mempool: allocate in several memory chunks by default")
>
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
> lib/librte_mempool/rte_mempool.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
> index e94e56f..aa513b9 100644
> --- a/lib/librte_mempool/rte_mempool.c
> +++ b/lib/librte_mempool/rte_mempool.c
> @@ -578,8 +578,10 @@ rte_mempool_populate_default(struct rte_mempool *mp)
> mz->len, pg_sz,
> rte_mempool_memchunk_mz_free,
> (void *)(uintptr_t)mz);
> - if (ret < 0)
> + if (ret < 0) {
> + rte_memzone_free(mz);
> goto fail;
> + }
> }
>
> return mp->size;
>
Acked-by: Olivier Matz <olivier.matz@6wind.com>
Thanks
Olivier
^ permalink raw reply
* Re: [PATCH] i40e: Fix eth_i40e_dev_init sequence on ThunderX
From: Zhang, Helin @ 2016-11-11 13:54 UTC (permalink / raw)
To: Satha Rao
Cc: Wu, Jingjing, jerin.jacob@caviumnetworks.com,
jianbo.liu@linaro.org, dev@dpdk.org
In-Reply-To: <1478779467-35123-1-git-send-email-skoteshwar@caviumnetworks.com>
Hi Rao
The existing rule is to try best not modify source files in the folder of base/ for each PMD. The exceptions are *_osdep.h or *_osdep.c.
So for your case, please redefine the rd32/wr32 in i40e_osdep.h. (with condition compiles for ARM?, as other CPU structures may not need that.)
Regards,
Helin
> -----Original Message-----
> From: Satha Rao [mailto:skoteshwar@caviumnetworks.com]
> Sent: Thursday, November 10, 2016 8:04 PM
> To: Zhang, Helin
> Cc: Wu, Jingjing; jerin.jacob@caviumnetworks.com; jianbo.liu@linaro.org;
> dev@dpdk.org; Satha Rao
> Subject: [PATCH] i40e: Fix eth_i40e_dev_init sequence on ThunderX
>
> i40e_asq_send_command: rd32 & wr32 under ThunderX gives unpredictable
> results. To solve this include rte memory barriers
>
> Signed-off-by: Satha Rao <skoteshwar@caviumnetworks.com>
> ---
> drivers/net/i40e/base/i40e_adminq.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/i40e/base/i40e_adminq.c
> b/drivers/net/i40e/base/i40e_adminq.c
> index 0d3a83f..1038a95 100644
> --- a/drivers/net/i40e/base/i40e_adminq.c
> +++ b/drivers/net/i40e/base/i40e_adminq.c
> @@ -832,6 +832,7 @@ enum i40e_status_code
> i40e_asq_send_command(struct i40e_hw *hw,
> }
>
> val = rd32(hw, hw->aq.asq.head);
> + rte_rmb();
> if (val >= hw->aq.num_asq_entries) {
> i40e_debug(hw, I40E_DEBUG_AQ_MESSAGE,
> "AQTX: head overrun at %d\n", val); @@ -929,8
> +930,10 @@ enum i40e_status_code i40e_asq_send_command(struct
> i40e_hw *hw,
> (hw->aq.asq.next_to_use)++;
> if (hw->aq.asq.next_to_use == hw->aq.asq.count)
> hw->aq.asq.next_to_use = 0;
> - if (!details->postpone)
> + if (!details->postpone) {
> wr32(hw, hw->aq.asq.tail, hw->aq.asq.next_to_use);
> + rte_wmb();
> + }
>
> /* if cmd_details are not defined or async flag is not set,
> * we need to wait for desc write back
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH v1] doc: rearrange the high level documentation index
From: Mcnamara, John @ 2016-11-11 13:53 UTC (permalink / raw)
To: dev@dpdk.org
In-Reply-To: <1478871955-6106-1-git-send-email-john.mcnamara@intel.com>
> -----Original Message-----
> From: Mcnamara, John
> Sent: Friday, November 11, 2016 1:46 PM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>
> Subject: [PATCH v1] doc: rearrange the high level documentation index
>
> Rearrange the order of the high level documenation index into a more
> logical sequence for a new user.
>
> Also, improve some of the high-level document names.
>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
> ---
>
> After this patch the high-level index will look like this:
>
> DPDK documentation
>
> * Getting Started Guide for Linux
> * Getting Started Guide for FreeBSD
> * Sample Applications User Guides
> * Programmer's Guide
> * HowTo Guides
> * DPDK Tools User Guides
> * Testpmd Application User Guide
> * Network Interface Controller Drivers
> * Crypto Device Drivers
> * Xen Guide
> * Contributor's Guidelines
> * Release Notes
> * FAQ
P.S.,
I would prefer not to have some of these are highest level items such as
"Xen Guide", and possibly "Crypto Device Drivers". Perhaps we could push
them down a level with "Network Interface Controller Drivers" under a
"Devices and Drivers" (or similar) section like:
* ...
* Programmer's Guide
* HowTo Guides
* DPDK Tools User Guides
* Devices and Drivers
* Network Interface Controller Drivers
* Crypto Device Drivers
* Xen Guide
* ...
^ permalink raw reply
* Re: pmdinfogen issues: cross compilation for ARM fails with older host compiler
From: Jan Viktorin @ 2016-11-11 13:48 UTC (permalink / raw)
To: Hemant Agrawal; +Cc: Neil Horman, dev@dpdk.org, users@dpdk.org, Jacob, Jerin
In-Reply-To: <DB5PR04MB1605F64CF0D986E0B2B26AF089BB0@DB5PR04MB1605.eurprd04.prod.outlook.com>
Hello all,
On Fri, 11 Nov 2016 10:34:39 +0000
Hemant Agrawal <hemant.agrawal@nxp.com> wrote:
> Hi Neil,
> Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
This seems wierd to me... why is it so? I couldn't find any usage of rte_byteorder.h in the source of pmdinfogen
(what am I missing?). Why is it included there?
The pmdinfogen executes on the host but works with the (cross-compiled) target binaries. Is that right? If the tool
needs to know endianity then we probably need a header telling just the target's endianity (or other metadata).
> However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
> e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.
This is not the actual issue. Consider an ARM build server that cross-compiles DPDK for Intel x86 (I admit that this
is quite a ridiculous situation, so take it easy ;)). Then we have just opposite issues... Would we like to fill the
DPDK x86 code base with #ifdef...#endif everytime there is some assembly code? I'd just like to point out that this
single instruction is not the true source of the problem. It is like complaining that nasm cannot compile Thumb2
instructions... No it cannot, sorry.
>
> /* fix missing __builtin_bswap16 for gcc older then 4.8 */
> #if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
> register uint16_t x = _x;
> asm volatile ("rev16 %0,%1"
> : "=r" (x)
> : "r" (x)
> );
> return x;
> }
> #endif
>
> One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
> e.g
> #if !(defined __arm__ || defined __aarch64__)
> static inline uint16_t rte_arch_bswap16(uint16_t _x)
> {
> return (_x >> 8) | ((_x << 8) & 0xff00);
> }
> #else ….
>
> Is there a better way to fix it?
In my opinion, this would work as a hotfix but not as a solution.
Kind regards
Jan
>
> Regards,
> Hemant
>
>
> From: Michael Wildt [mailto:michael.wildt@broadcom.com]
> Sent: Wednesday, September 14, 2016 7:18 PM
> To: Hemant Agrawal <hemant.agrawal@nxp.com>
> Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; users@dpdk.org
> Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and pmdinfogen issues
>
> Hi Hemant,
>
> Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 but good to know.
>
> I gave that one a try and that works as well but as with the 5.3 I have to be on a Ubuntu not RHEL6 to make it work.
>
> Thanks,
> Michael
>
> On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal <hemant.agrawal@nxp.com<mailto:hemant.agrawal@nxp.com>> wrote:
> Hi Michael,
> One of the problem, I found with Linaro gcc 4.9 toolchain for i686 (default one), that it seems to be built with older kernel headers (<3.8). This usages older linux/vhost.h file.
>
> However, we have not observed this issue with x86_64 based toolchain on 64 bit m/c.
> https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
>
> Regards,
> Hemant
>
> > -----Original Message-----
> > From: users [mailto:users-bounces@dpdk.org<mailto:users-bounces@dpdk.org>] On Behalf Of Michael Wildt
> > Sent: Wednesday, September 14, 2016 12:05 AM
> > To: Thomas Monjalon <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> > Cc: users@dpdk.org<mailto:users@dpdk.org>
> > Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and
> > pmdinfogen issues
> >
> > Hi Thomas,
> >
> > The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a test
> > application. Its actually 4.9.2.
> >
> > Tried a newer Linaro tool chain, turned out to be a bit more complicated since
> > that does not work on RHEL6, is however a success. With Linaro 5.3 one can
> > cross compile dpdk fine with no errors, though the rte_byteorder.h file still
> > points to arm's version, but pmdinfogen builds.
> >
> > Probably should still fix both issues just to keep the base clean.
> >
> > At least I have a workaround in the interim.
> >
> > Thanks for the help.
> >
> > Thanks,
> > Michael
> >
> >
> > On Tue, Sep 13, 2016 at 11:07 AM, Thomas Monjalon
> > <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>
> > > wrote:
> >
> > > 2016-09-13 07:45, Michael Wildt:
> > > > Hi Thomas,
> > > >
> > > > Appreciate the assistance. Please see inline.
> > > >
> > > >
> > > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <
> > > thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > 2016-09-12 22:20, Michael Wildt:
> > > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 target.
> > > This
> > > > > > fails in the following areas, using latest dpdk as of 9/12. When
> > > > > compiling
> > > > > > natively there are no issues.
> > > > >
> > > > > Your analysis below seems good.
> > > > > Interestingly, I do not see such error (don't know why).
> > > > > Please could you share the commands you are using?
> > > > >
> > > >
> > > > Sure can.
> > > >
> > > > make config T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > > bin/aarch64-linux-gnu-
> > > > ARCH=arm64
> > > >
> > > > make T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > > bin/aarch64-linux-gnu-
> > > > ARCH=arm64 RTE_KERNELDIR=/projects/kernel
> > > >
> > > > > > - librte_vhost, fails with:
> > > > > >
> > > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-
> > > > > net-user.c:250:23:
> > > > > > error: array subscript is above array bounds [-Werror=array-bounds]
> > > > > > rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];
> > > > > [...]
> > > > > > - buildtools/pmdinfogen, fails with:
> > > > > >
> > > > > > == Build buildtools/pmdinfogen
> > > > > > HOSTCC pmdinfogen.o
> > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_byteorder.h:
> > > > > > Assembler messages:
> > > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_
> > > byteorder.h:53:
> > > > > > Error: no such instruction: `rev16 %bx,%bx'
> > > > > [...]
> > > > > > - The issue is due to the rte_byteorder.h file which gets
> > > > > > symlink'ed with the ARM version at the beginning of the build.
> > > > > > The pmdinfogen is always compiled for x86 thus the asm is failing.
> > >
> > > It is definitely something to fix.
> > > In the meantime, you should be able to compile DPDK by using a more
> > > recent toolchain. This error is in:
> > >
> > > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> > >
> > > I know you are using gcc-4.9 but maybe __GNUC_MINOR__ is wrong in yours.
> > >
> > >
>
--
Jan Viktorin E-mail: Viktorin@RehiveTech.com
System Architect Web: www.RehiveTech.com
RehiveTech
Brno, Czech Republic
^ permalink raw reply
* [PATCH v1] doc: rearrange the high level documentation index
From: John McNamara @ 2016-11-11 13:45 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Rearrange the order of the high level documenation index into
a more logical sequence for a new user.
Also, improve some of the high-level document names.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
After this patch the high-level index will look like this:
DPDK documentation
* Getting Started Guide for Linux
* Getting Started Guide for FreeBSD
* Sample Applications User Guides
* Programmer's Guide
* HowTo Guides
* DPDK Tools User Guides
* Testpmd Application User Guide
* Network Interface Controller Drivers
* Crypto Device Drivers
* Xen Guide
* Contributor's Guidelines
* Release Notes
* FAQ
doc/guides/howto/index.rst | 4 ++--
doc/guides/index.rst | 14 +++++++-------
doc/guides/sample_app_ug/index.rst | 4 ++--
doc/guides/tools/index.rst | 4 ++--
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/doc/guides/howto/index.rst b/doc/guides/howto/index.rst
index aa6d3e2..5575b27 100644
--- a/doc/guides/howto/index.rst
+++ b/doc/guides/howto/index.rst
@@ -28,8 +28,8 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-How To User Guides
-==================
+HowTo Guides
+============
.. toctree::
:maxdepth: 2
diff --git a/doc/guides/index.rst b/doc/guides/index.rst
index 57570f6..82b00e9 100644
--- a/doc/guides/index.rst
+++ b/doc/guides/index.rst
@@ -36,14 +36,14 @@ DPDK documentation
linux_gsg/index
freebsd_gsg/index
- xen/index
- prog_guide/index
- nics/index
- cryptodevs/index
sample_app_ug/index
+ prog_guide/index
+ howto/index
tools/index
testpmd_app_ug/index
- faq/index
- howto/index
- rel_notes/index
+ nics/index
+ cryptodevs/index
+ xen/index
contributing/index
+ rel_notes/index
+ faq/index
diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst
index cce0a9b..775e2f7 100644
--- a/doc/guides/sample_app_ug/index.rst
+++ b/doc/guides/sample_app_ug/index.rst
@@ -28,8 +28,8 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-Sample Applications User Guide
-==============================
+Sample Applications User Guides
+===============================
.. toctree::
:maxdepth: 2
diff --git a/doc/guides/tools/index.rst b/doc/guides/tools/index.rst
index cbe98b2..513221c 100644
--- a/doc/guides/tools/index.rst
+++ b/doc/guides/tools/index.rst
@@ -28,8 +28,8 @@
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-Tool User Guides
-================
+DPDK Tools User Guides
+======================
.. toctree::
:maxdepth: 2
--
2.7.4
^ permalink raw reply related
* [PATCH v2] doc: add sub-repositories information
From: Ferruh Yigit @ 2016-11-11 13:34 UTC (permalink / raw)
To: dev
Cc: John McNamara, Thomas Monjalon, Pablo de Lara, Ferruh Yigit,
Yuanhan Liu
In-Reply-To: <20161110172718.2292-1-ferruh.yigit@intel.com>
DPDK switched to main and sub-repositories approach, this patch
documents new approach and updates development process according.
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/contributing/patches.rst | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
index 729aea7..fabddbe 100644
--- a/doc/guides/contributing/patches.rst
+++ b/doc/guides/contributing/patches.rst
@@ -20,7 +20,14 @@ The DPDK development process has the following features:
* There is a mailing list where developers submit patches.
* There are maintainers for hierarchical components.
* Patches are reviewed publicly on the mailing list.
-* Successfully reviewed patches are merged to the master branch of the repository.
+* Successfully reviewed patches are merged to the repository.
+
+|
+
+* There are main repository ``dpdk`` and sub-repositories ``dpdk-next-*``.
+* A patch should be sent for its target repository. Like net drivers should be on top of dpdk-next-net repository.
+* All sub-repositories are merged into main repository for -rc1 and -rc2 versions of the release.
+* After -rc2 release all patches should target main repository.
The mailing list for DPDK development is `dev@dpdk.org <http://dpdk.org/ml/archives/dev/>`_.
Contributors will need to `register for the mailing list <http://dpdk.org/ml/listinfo/dev>`_ in order to submit patches.
@@ -33,12 +40,17 @@ Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further informat
Getting the Source Code
-----------------------
-The source code can be cloned using either of the following::
+The source code can be cloned using either of the following:
- git clone git://dpdk.org/dpdk
+main repository::
+ git clone git://dpdk.org/dpdk
git clone http://dpdk.org/git/dpdk
+sub-repositories (`list <http://dpdk.org/browse/next>`_)::
+
+ git clone git://dpdk.org/next/dpdk-next-*
+ git clone http://dpdk.org/git/next/dpdk-next-*
Make your Changes
-----------------
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v1] doc: fix release notes for 16.11
From: Shreyansh Jain @ 2016-11-11 13:21 UTC (permalink / raw)
To: John McNamara; +Cc: dev
In-Reply-To: <1478865882-15315-1-git-send-email-john.mcnamara@intel.com>
On Friday 11 November 2016 05:34 PM, John McNamara wrote:
[...]
> -* **Improved device/driver hierarchy and generalized hotplugging**
> +* **Improved device/driver hierarchy and generalized hotplugging.**
>
> - Device and driver relationship has been restructured by introducing generic
> - classes. This paves way for having PCI, VDEV and other device types as
> - just instantiated objects rather than classes in themselves. Hotplugging too
> - has been generalized into EAL so that ethernet or crypto devices can use the
> + The device and driver relationship has been restructured by introducing generic
> + classes. This paves the way for having PCI, VDEV and other device types as
> + instantiated objects rather than classes in themselves. Hotplugging has also
> + been generalized into EAL so that Ethernet or crypto devices can use the
> common infrastructure.
>
> - * removed ``pmd_type`` as way of segregation of devices
> - * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
> + * Removed ``pmd_type`` as a way of segregation of devices.
> + * Moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
> ``rte_pci_driver``. These can now be used by any instantiated object of
> ``rte_driver``.
> - * added ``rte_device`` class and all PCI and VDEV devices inherit from it
> - * renamed devinit/devuninit handlers to probe/remove to make it more
> - semantically correct with respect to device<=>driver relationship
> - * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
> + * Added ``rte_device`` class and all PCI and VDEV devices inherit from it
> + * Renamed devinit/devuninit handlers to probe/remove to make it more
> + semantically correct with respect to the device <=> driver relationship.
> + * Moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
> APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
> - * helpers and support macros have been renamed to make them more synonymous
> + * Renamed helpers and support macros to make them more synonymous
> with their device types
> - (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``)
> + (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``).
> * Device naming functions have been generalized from ethdev and cryptodev
> to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
> unique device name from PCI Domain-BDF description.
If it is possible to have a Reviewed-by for a particular part of a patch:
Reviewed-by: Shreyansh Jain <shreyansh.jain@nxp.com>
^ permalink raw reply
* Re: [PATCH] doc: add sub-repositories information
From: Ferruh Yigit @ 2016-11-11 13:16 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: dev, John McNamara, Thomas Monjalon
In-Reply-To: <d9fa5cc2-1047-73e7-5bd6-08e119f21409@nxp.com>
Hi Shreyansh,
On 11/11/2016 1:15 PM, Shreyansh Jain wrote:
>> +* All sub-repositories merged into main repository for -rc1 and -rc2 versions of the release.
> 'All sub-repositories *are* merged into ...'?
I will send a fixed version.
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH] doc: add sub-repositories information
From: Shreyansh Jain @ 2016-11-11 13:15 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, John McNamara, Thomas Monjalon
In-Reply-To: <20161110172718.2292-1-ferruh.yigit@intel.com>
Hello Ferruh,
Trivial comment/suggestion:
On Thursday 10 November 2016 10:57 PM, Ferruh Yigit wrote:
> DPDK switched to main and sub-repositories approach, this patch
> documents new approach and updates development process according.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> ---
> doc/guides/contributing/patches.rst | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst
> index 729aea7..bec9bfc 100644
> --- a/doc/guides/contributing/patches.rst
> +++ b/doc/guides/contributing/patches.rst
> @@ -20,7 +20,14 @@ The DPDK development process has the following features:
> * There is a mailing list where developers submit patches.
> * There are maintainers for hierarchical components.
> * Patches are reviewed publicly on the mailing list.
> -* Successfully reviewed patches are merged to the master branch of the repository.
> +* Successfully reviewed patches are merged to the repository.
> +
> +|
> +
> +* There are main repository ``dpdk`` and sub-repositories ``dpdk-next-*``.
> +* A patch should be sent for its target repository. Like net drivers should be on top of dpdk-next-net repository.
> +* All sub-repositories merged into main repository for -rc1 and -rc2 versions of the release.
'All sub-repositories *are* merged into ...'?
> +* After -rc2 release all patches should target main repository.
>
> The mailing list for DPDK development is `dev@dpdk.org <http://dpdk.org/ml/archives/dev/>`_.
> Contributors will need to `register for the mailing list <http://dpdk.org/ml/listinfo/dev>`_ in order to submit patches.
> @@ -33,12 +40,17 @@ Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further informat
> Getting the Source Code
> -----------------------
>
> -The source code can be cloned using either of the following::
> +The source code can be cloned using either of the following:
>
> - git clone git://dpdk.org/dpdk
> +main repository::
>
> + git clone git://dpdk.org/dpdk
> git clone http://dpdk.org/git/dpdk
>
> +sub-repositories (`list <http://dpdk.org/browse/next>`_)::
> +
> + git clone git://dpdk.org/next/dpdk-next-*
> + git clone http://dpdk.org/git/next/dpdk-next-*
>
> Make your Changes
> -----------------
>
-
Shreyansh
^ permalink raw reply
* Re: [PATCH] doc: announce API and ABI changes for librte_eal
From: Ferruh Yigit @ 2016-11-11 13:05 UTC (permalink / raw)
To: David Marchand, Shreyansh Jain; +Cc: Neil Horman, dev@dpdk.org, Thomas Monjalon
In-Reply-To: <CALwxeUshpJY1k5b9OmLEU7PnWTZDRJT7k8YE7WdUb8NG+6zq5w@mail.gmail.com>
On 11/10/2016 3:51 PM, David Marchand wrote:
> On Thu, Nov 10, 2016 at 12:17 PM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
>> ---
>> doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
>> index 1a9e1ae..2af2476 100644
>> --- a/doc/guides/rel_notes/deprecation.rst
>> +++ b/doc/guides/rel_notes/deprecation.rst
>> @@ -35,3 +35,13 @@ Deprecation Notices
>> * mempool: The functions for single/multi producer/consumer are deprecated
>> and will be removed in 17.02.
>> It is replaced by ``rte_mempool_generic_get/put`` functions.
>> +
>> +* ABI/API changes are planned for 17.02: ``rte_device``, ``rte_driver`` will be
>> + impacted because of introduction of a new ``rte_bus`` hierarchy. This would
>> + also impact the way devices are identified by EAL. A bus-device-driver model
>> + will be introduced providing a hierarchical view of devices.
>> +
>> +* ``eth_driver`` is planned to be removed in 17.02. This currently serves as
>> + a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will
>> + provide a way to handle device initialization currently being done in
>> + ``eth_driver``.
>> --
>> 2.7.4
>>
>
> Acked-by: David Marchand <david.marchand@6wind.com>
Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
^ permalink raw reply
* [PATCH v1] doc: fix release notes for 16.11
From: John McNamara @ 2016-11-11 12:04 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Fix grammar, spelling and formatting of DPDK 16.11 release notes.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/release_16_11.rst | 171 ++++++++++++++++-----------------
1 file changed, 83 insertions(+), 88 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index 365b5a3..6f40f59 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -42,7 +42,7 @@ New Features
* Added a new function ``rte_pktmbuf_read()`` to read the packet data from an
mbuf chain, linearizing if required.
* Added a new function ``rte_net_get_ptype()`` to parse an Ethernet packet
- in an mbuf chain and retrieve its packet type by software.
+ in an mbuf chain and retrieve its packet type from software.
* Added new functions ``rte_get_ptype_*()`` to dump a packet type as a string.
* **Improved offloads support in mbuf.**
@@ -52,102 +52,108 @@ New Features
* Added new Rx checksum flags in mbufs to describe more states: unknown,
good, bad, or not present (useful for virtual drivers). This modification
was done for IP and L4.
- * Added a new RX LRO mbuf flag, used when packets are coalesced. This
+ * Added a new Rx LRO mbuf flag, used when packets are coalesced. This
flag indicates that the segment size of original packets is known.
-* **Added vhost-user dequeue zero copy support**
+* **Added vhost-user dequeue zero copy support.**
- The copy in dequeue path is saved, which is meant to improve the performance.
+ The copy in the dequeue path is avoided in order to improve the performance.
In the VM2VM case, the boost is quite impressive. The bigger the packet size,
- the bigger performance boost you may get. However, for VM2NIC case, there
- are some limitations, yet the boost is not that impressive as VM2VM case.
+ the bigger performance boost you may get. However, for the VM2NIC case, there
+ are some limitations, so the boost is not as impressive as the VM2VM case.
It may even drop quite a bit for small packets.
- For such reason, this feature is disabled by default. It can be enabled when
- ``RTE_VHOST_USER_DEQUEUE_ZERO_COPY`` flag is given. Check the vhost section
- at programming guide for more information.
+ For that reason, this feature is disabled by default. It can be enabled when
+ the ``RTE_VHOST_USER_DEQUEUE_ZERO_COPY`` flag is set. Check the VHost section
+ of the Programming Guide for more information.
* **Added vhost-user indirect descriptors support.**
- If indirect descriptor feature is negotiated, each packet sent by the guest
- will take exactly one slot in the enqueue virtqueue. Without the feature, in
- current version, even 64 bytes packets take two slots with Virtio PMD on guest
+ If the indirect descriptor feature is enabled, each packet sent by the guest
+ will take exactly one slot in the enqueue virtqueue. Without this feature, as in
+ the current version, even 64 bytes packets take two slots with Virtio PMD on guest
side.
The main impact is better performance for 0% packet loss use-cases, as it
behaves as if the virtqueue size was enlarged, so more packets can be buffered
- in case of system perturbations. On the downside, small performance degradation
- is measured when running micro-benchmarks.
+ in the case of system perturbations. On the downside, small performance degradations
+ were measured when running micro-benchmarks.
* **Added vhost PMD xstats.**
- Added extended statistics to vhost PMD from per port perspective.
+ Added extended statistics to vhost PMD from a per port perspective.
* **Supported offloads with virtio.**
- * Rx/Tx checksums
- * LRO
- * TSO
+ Added support for the following offloads in virtio:
+
+ * Rx/Tx checksums.
+ * LRO.
+ * TSO.
* **Added virtio NEON support for ARM.**
+ Added NEON support for ARM based virtio.
+
* **Updated the ixgbe base driver.**
Updated the ixgbe base driver, including the following changes:
- * add X550em_a 10G PHY support
- * support flow control auto negotiation for X550em_a 1G PHY
- * add X550em_a FW ALEF support
- * increase mailbox version to ixgbe_mbox_api_13
- * add two MAC ops for Hyper-V support
+ * Added X550em_a 10G PHY support.
+ * Added support for flow control auto negotiation for X550em_a 1G PHY.
+ * Added X550em_a FW ALEF support.
+ * Increased mailbox version to ``ixgbe_mbox_api_13``.
+ * Added two MAC operations for Hyper-V support.
-* **Added API's for VF management to the ixgbe PMD.**
+* **Added APIs for VF management to the ixgbe PMD.**
- Eight new API's have been added to the ixgbe PMD for VF management from the PF.
+ Eight new APIs have been added to the ixgbe PMD for VF management from the PF.
The declarations for the API's can be found in ``rte_pmd_ixgbe.h``.
* **Updated the enic driver.**
- * Use interrupt for link status checking instead of polling
- * More flow director modes on UCS Blade with firmware version >= 2.0(13e)
- * Full support for MTU update
- * Support for rte_eth_rx_queue_count function
+ * Added update to use interrupt for link status checking instead of polling.
+ * Added more flow director modes on UCS Blade with firmware version >= 2.0(13e).
+ * Added full support for MTU update.
+ * Added support for the ``rte_eth_rx_queue_count`` function.
* **Updated the mlx5 driver.**
- * Add support for RSS hash result
- * Several performance improvements
- * Several bug fixes
+ * Added support for RSS hash results.
+ * Added several performance improvements.
+ * Added several bug fixes.
* **Updated the QAT PMD.**
- The QAT PMD was updated with following support:
+ The QAT PMD was updated with additional support for:
- * MD5_HMAC algorithm
- * SHA224-HMAC algorithm
- * SHA384-HMAC algorithm
- * GMAC algorithm
- * KASUMI (F8 and F9) algorithm
- * 3DES algorithm
- * NULL algorithm
- * C3XXX device
- * C62XX device
+ * MD5_HMAC algorithm.
+ * SHA224-HMAC algorithm.
+ * SHA384-HMAC algorithm.
+ * GMAC algorithm.
+ * KASUMI (F8 and F9) algorithm.
+ * 3DES algorithm.
+ * NULL algorithm.
+ * C3XXX device.
+ * C62XX device.
* **Added openssl PMD.**
- A new crypto PMD has been added, which provides several ciphering and hashing.
- All cryptography operations are using Openssl library crypto API.
+ A new crypto PMD has been added, which provides several ciphering and hashing algorithms.
+ All cryptography operations use the Openssl library crypto API.
+
+* **Updated the IPsec example.**
-* **Updated the IPsec example with following support:**
+ Updated the IPsec example with the following support:
- * configuration file
- * AES CBC IV generation with cipher forward function
- * AES GCM/CTR mode
+ * Configuration file support.
+ * AES CBC IV generation with cipher forward function.
+ * AES GCM/CTR mode.
* **Added support for new gcc -march option.**
The GCC 4.9 ``-march`` option supports the Intel processor code names.
- The config option ``RTE_MACHINE`` can be used to pass code names to the compiler as ``-march`` flag.
+ The config option ``RTE_MACHINE`` can be used to pass code names to the compiler via the ``-march`` flag.
Resolved Issues
@@ -164,10 +170,6 @@ Resolved Issues
This section is a comment. Make sure to start the actual text at the margin.
-EAL
-~~~
-
-
Drivers
~~~~~~~
@@ -178,17 +180,6 @@ Drivers
* **enic: Fixed high driver overhead when servicing Rx queues beyond the first.**
-Libraries
-~~~~~~~~~
-
-
-Examples
-~~~~~~~~
-
-
-Other
-~~~~~
-
Known Issues
------------
@@ -204,14 +195,14 @@ Known Issues
* **L3fwd-power app does not work properly when Rx vector is enabled.**
- Using some drivers with vector enabled, makes L3fwd-power app not work
- properly, since the queue monitoring works differently when using
- scalar compared to vector, making the frequency scaling not to work correctly.
- In addition, L3fwd-power requires the mbuf to have correct packet type,
- but in some drivers, the vector mode must be disabled for this.
+ The L3fwd-power app doesn't work properly with some drivers in vector mode
+ since the queue monitoring works differently between scalar and vector modes
+ leading to incorrect frequency scaling. In addition, L3fwd-power application
+ requires the mbuf to have correct packet type set but in some drivers the
+ vector mode must be disabled for this.
Therefore, in order to use L3fwd-power, vector mode should be disabled
- from the config file.
+ via the config file.
API Changes
@@ -224,38 +215,42 @@ API Changes
This section is a comment. Make sure to start the actual text at the margin.
-* The driver names have been changed. It especially impacts ``--vdev`` arguments.
- Examples: ``eth_pcap`` becomes ``net_pcap``
- and ``cryptodev_aesni_mb_pmd`` becomes ``crypto_aesni_mb``.
+* The driver naming convention has been changed to make them more
+ consistent. It especially impacts ``--vdev`` arguments. For example
+ ``eth_pcap`` becomes ``net_pcap`` and ``cryptodev_aesni_mb_pmd`` becomes
+ ``crypto_aesni_mb``.
+
+ For backward compatibility an alias feature has been enabled to support the
+ original names.
-* The log history is removed.
+* The log history has been removed.
* The ``rte_ivshmem`` feature (including library and EAL code) has been removed
in 16.11 because it had some design issues which were not planned to be fixed.
* The ``file_name`` data type of ``struct rte_port_source_params`` and
- ``struct rte_port_sink_params`` is changed from `char *`` to ``const char *``.
+ ``struct rte_port_sink_params`` is changed from ``char *`` to ``const char *``.
-* **Improved device/driver hierarchy and generalized hotplugging**
+* **Improved device/driver hierarchy and generalized hotplugging.**
- Device and driver relationship has been restructured by introducing generic
- classes. This paves way for having PCI, VDEV and other device types as
- just instantiated objects rather than classes in themselves. Hotplugging too
- has been generalized into EAL so that ethernet or crypto devices can use the
+ The device and driver relationship has been restructured by introducing generic
+ classes. This paves the way for having PCI, VDEV and other device types as
+ instantiated objects rather than classes in themselves. Hotplugging has also
+ been generalized into EAL so that Ethernet or crypto devices can use the
common infrastructure.
- * removed ``pmd_type`` as way of segregation of devices
- * moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
+ * Removed ``pmd_type`` as a way of segregation of devices.
+ * Moved ``numa_node`` and ``devargs`` into ``rte_driver`` from
``rte_pci_driver``. These can now be used by any instantiated object of
``rte_driver``.
- * added ``rte_device`` class and all PCI and VDEV devices inherit from it
- * renamed devinit/devuninit handlers to probe/remove to make it more
- semantically correct with respect to device<=>driver relationship
- * moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
+ * Added ``rte_device`` class and all PCI and VDEV devices inherit from it
+ * Renamed devinit/devuninit handlers to probe/remove to make it more
+ semantically correct with respect to the device <=> driver relationship.
+ * Moved hotplugging support to EAL. Hereafter, PCI and vdev can use the
APIs ``rte_eal_dev_attach`` and ``rte_eal_dev_detach``.
- * helpers and support macros have been renamed to make them more synonymous
+ * Renamed helpers and support macros to make them more synonymous
with their device types
- (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``)
+ (e.g. ``PMD_REGISTER_DRIVER`` => ``RTE_PMD_REGISTER_PCI``).
* Device naming functions have been generalized from ethdev and cryptodev
to EAL. ``rte_eal_pci_device_name`` has been introduced for obtaining
unique device name from PCI Domain-BDF description.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] improve git diff
From: Ferruh Yigit @ 2016-11-11 11:22 UTC (permalink / raw)
To: Thomas Monjalon, dev
In-Reply-To: <1478706261-31261-1-git-send-email-thomas.monjalon@6wind.com>
On 11/9/2016 3:44 PM, Thomas Monjalon wrote:
> Sometimes git does not print the name of the function being changed
> after @@. It happens especially after a goto label which is not indented.
> Giving a hint about the languages of files .c, .h and .py
> will improve hunk headers of "git diff" rendering.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> ---
> .gitattributes | 3 +++
> 1 file changed, 3 insertions(+)
> create mode 100644 .gitattributes
>
> diff --git a/.gitattributes b/.gitattributes
> new file mode 100644
> index 0000000..fe555f8
> --- /dev/null
> +++ b/.gitattributes
> @@ -0,0 +1,3 @@
> +*.c diff=cpp
> +*.h diff=cpp
Can't git auto detect to use C/C++ language diff use for .c/.h files?
Do you have a sample that generates bad hunk header, just to test?
> +*.py diff=python
>
^ permalink raw reply
* Re: [PATCH v4] latencystats: added new library for latency stats
From: Pattan, Reshma @ 2016-11-11 11:15 UTC (permalink / raw)
To: Horton, Remy, dev@dpdk.org
In-Reply-To: <5b715ac1-b9e8-f7fc-33a1-a430208c4fe4@intel.com>
Hi
> -----Original Message-----
> From: Horton, Remy
> Sent: Friday, November 11, 2016 2:22 AM
> To: Pattan, Reshma <reshma.pattan@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4] latencystats: added new library for
> latency stats
>
>
> On 07/11/2016 21:14, Reshma Pattan wrote:
> [..]
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
>
> Reviewed-by: Remy Horton <remy.horton@intel.com>
>
>
> > +static void
> > +metrics_display(int port_id)
> > +{
> > + struct rte_stat_value *stats;
> > + struct rte_metric_name *names;
>
> Note that rte_stats_value is being renamed to rte_metric_value in the next
> version of the metrics library..
>
Ok.
>
> > +int
> > +rte_latencystats_init(uint64_t samp_intvl,
> > + rte_latency_stats_flow_type_fn user_cb)
> > +{
>
> Far as I can tell, user_cb is always NULL, and the two callbacks it
> eventually get passed to don't use it. There any reason the function
> signature has it at all?
>
Yes, with the possibility of getting flow based latency stats requiments in future, user callback is added to signature.
With this user callback, it is up to the application to identify the flow type and return the flow type. Library will maintain latency calculation per flow type
in a separate table. Basically for future enhancement.
>
> > +++ b/lib/librte_latencystats/rte_latencystats_version.map
> > @@ -0,0 +1,10 @@
> > +DPDK_16.11 {
>
> This will need to change to 17.02 once new release cycle starts. :)
>
> Will also need to add entry to release_17_02.rst once it becomes available..
>
Ok.
Thanks,
Reshma
^ permalink raw reply
* pmdinfogen issues: cross compilation for ARM fails with older host compiler
From: Hemant Agrawal @ 2016-11-11 10:34 UTC (permalink / raw)
To: Neil Horman; +Cc: dev@dpdk.org, users@dpdk.org, Jacob, Jerin, Jan Viktorin
Hi Neil,
Pmdinfogen compiles with host compiler. It usages rte_byteorder.h of the target platform.
However, if the host compiler is older than 4.8, it will be an issue during cross compilation for some platforms.
e.g. if we are compiling on x86 host for ARM, x86 host compiler will not understand the arm asm instructions.
/* fix missing __builtin_bswap16 for gcc older then 4.8 */
#if !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
static inline uint16_t rte_arch_bswap16(uint16_t _x)
{
register uint16_t x = _x;
asm volatile ("rev16 %0,%1"
: "=r" (x)
: "r" (x)
);
return x;
}
#endif
One easy solution is that we add compiler platform check in this code section of rte_byteorder.h
e.g
#if !(defined __arm__ || defined __aarch64__)
static inline uint16_t rte_arch_bswap16(uint16_t _x)
{
return (_x >> 8) | ((_x << 8) & 0xff00);
}
#else ….
Is there a better way to fix it?
Regards,
Hemant
From: Michael Wildt [mailto:michael.wildt@broadcom.com]
Sent: Wednesday, September 14, 2016 7:18 PM
To: Hemant Agrawal <hemant.agrawal@nxp.com>
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>; users@dpdk.org
Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and pmdinfogen issues
Hi Hemant,
Thanks for the pointer to the 4.9.3 version. Haven't had issues with 4.9.2 but good to know.
I gave that one a try and that works as well but as with the 5.3 I have to be on a Ubuntu not RHEL6 to make it work.
Thanks,
Michael
On Wed, Sep 14, 2016 at 3:25 AM, Hemant Agrawal <hemant.agrawal@nxp.com<mailto:hemant.agrawal@nxp.com>> wrote:
Hi Michael,
One of the problem, I found with Linaro gcc 4.9 toolchain for i686 (default one), that it seems to be built with older kernel headers (<3.8). This usages older linux/vhost.h file.
However, we have not observed this issue with x86_64 based toolchain on 64 bit m/c.
https://releases.linaro.org/14.11/components/toolchain/binaries/aarch64-linux-gnu/
Regards,
Hemant
> -----Original Message-----
> From: users [mailto:users-bounces@dpdk.org<mailto:users-bounces@dpdk.org>] On Behalf Of Michael Wildt
> Sent: Wednesday, September 14, 2016 12:05 AM
> To: Thomas Monjalon <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> Cc: users@dpdk.org<mailto:users@dpdk.org>
> Subject: Re: [dpdk-users] Cross compile for ARM64 fails due to librte_vhost and
> pmdinfogen issues
>
> Hi Thomas,
>
> The Linaro gcc 4.9 is correct when it gets to __GNUC_MINOR__, used a test
> application. Its actually 4.9.2.
>
> Tried a newer Linaro tool chain, turned out to be a bit more complicated since
> that does not work on RHEL6, is however a success. With Linaro 5.3 one can
> cross compile dpdk fine with no errors, though the rte_byteorder.h file still
> points to arm's version, but pmdinfogen builds.
>
> Probably should still fix both issues just to keep the base clean.
>
> At least I have a workaround in the interim.
>
> Thanks for the help.
>
> Thanks,
> Michael
>
>
> On Tue, Sep 13, 2016 at 11:07 AM, Thomas Monjalon
> <thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>
> > wrote:
>
> > 2016-09-13 07:45, Michael Wildt:
> > > Hi Thomas,
> > >
> > > Appreciate the assistance. Please see inline.
> > >
> > >
> > > On Tue, Sep 13, 2016 at 5:03 AM, Thomas Monjalon <
> > thomas.monjalon@6wind.com<mailto:thomas.monjalon@6wind.com>>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > 2016-09-12 22:20, Michael Wildt:
> > > > > I'm attempting to cross compile DPDK on an x86 for an ARM64 target.
> > This
> > > > > fails in the following areas, using latest dpdk as of 9/12. When
> > > > compiling
> > > > > natively there are no issues.
> > > >
> > > > Your analysis below seems good.
> > > > Interestingly, I do not see such error (don't know why).
> > > > Please could you share the commands you are using?
> > > >
> > >
> > > Sure can.
> > >
> > > make config T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > bin/aarch64-linux-gnu-
> > > ARCH=arm64
> > >
> > > make T=arm64-armv8a-linuxapp-gcc CROSS=/projects/ccxsw/
> > > toolchains/gcc-linaro-aarch64-linux-gnu-4.9-2014.09_linux/
> > bin/aarch64-linux-gnu-
> > > ARCH=arm64 RTE_KERNELDIR=/projects/kernel
> > >
> > > > > - librte_vhost, fails with:
> > > > >
> > > > > /projects/dpdk_latest/lib/librte_vhost/vhost_user/virtio-
> > > > net-user.c:250:23:
> > > > > error: array subscript is above array bounds [-Werror=array-bounds]
> > > > > rvq = dev->virtqueue[i * VIRTIO_QNUM + VIRTIO_RXQ];
> > > > [...]
> > > > > - buildtools/pmdinfogen, fails with:
> > > > >
> > > > > == Build buildtools/pmdinfogen
> > > > > HOSTCC pmdinfogen.o
> > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_byteorder.h:
> > > > > Assembler messages:
> > > > > /projects/dpdk_test_wget/dpdk-16.07/build/include/rte_
> > byteorder.h:53:
> > > > > Error: no such instruction: `rev16 %bx,%bx'
> > > > [...]
> > > > > - The issue is due to the rte_byteorder.h file which gets
> > > > > symlink'ed with the ARM version at the beginning of the build.
> > > > > The pmdinfogen is always compiled for x86 thus the asm is failing.
> >
> > It is definitely something to fix.
> > In the meantime, you should be able to compile DPDK by using a more
> > recent toolchain. This error is in:
> >
> > /* fix missing __builtin_bswap16 for gcc older then 4.8 */ #if
> > !(__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 8))
> >
> > I know you are using gcc-4.9 but maybe __GNUC_MINOR__ is wrong in yours.
> >
> >
^ permalink raw reply
* Re: [PATCH] doc: add sub-repositories information
From: Mcnamara, John @ 2016-11-11 10:27 UTC (permalink / raw)
To: Yigit, Ferruh, dev@dpdk.org; +Cc: Thomas Monjalon
In-Reply-To: <20161110172718.2292-1-ferruh.yigit@intel.com>
> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Thursday, November 10, 2016 5:27 PM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Subject: [PATCH] doc: add sub-repositories information
>
> DPDK switched to main and sub-repositories approach, this patch documents
> new approach and updates development process according.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* [PATCH v2] mempool: Free memzone if mempool populate phys fails
From: Hemant Agrawal @ 2016-11-11 15:47 UTC (permalink / raw)
To: olivier.matz; +Cc: dev, Nipun Gupta
In-Reply-To: <1478875378-15398-1-git-send-email-hemant.agrawal@nxp.com>
From: Nipun Gupta <nipun.gupta@nxp.com>
This patch fixes the issue of memzone not being freed incase the
rte_mempool_populate_phys fails in the rte_mempool_populate_default
This issue was identified when testing with OVS ~2.6
- configure the system with low memory (e.g. < 500 MB)
- add bridge and dpdk interfaces
- delete brigde
- keep on repeating the above sequence.
Fixes: d1d914ebbc25 ("mempool: allocate in several memory chunks by default")
Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
lib/librte_mempool/rte_mempool.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index e94e56f..aa513b9 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -578,8 +578,10 @@ rte_mempool_populate_default(struct rte_mempool *mp)
mz->len, pg_sz,
rte_mempool_memchunk_mz_free,
(void *)(uintptr_t)mz);
- if (ret < 0)
+ if (ret < 0) {
+ rte_memzone_free(mz);
goto fail;
+ }
}
return mp->size;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Bert van Leeuwen @ 2016-11-11 9:48 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Alejandro Lucero, dev
In-Reply-To: <1630834.YGmmObtqnA@xps13>
> On 11 Nov 2016, at 11:29 AM, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
>
> 2016-11-11 09:16, Alejandro Lucero:
>> Thomas,
>>
>> We are wondering if you realize this patch fixes a bug with current ethdev
>> code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS.
>>
>> Maybe the commit message is giving the wrong impression and as you
>> commented, it should just focus on the bug it fixes and to leave for
>> another email thread the discussion of how to solve the
>> RTE_ETHDEV_QUEUE_STAT_CNTRS
>> problem.
>>
>> Should we remove this from patchwork and to send another patch that way?
>
> Yes please. It was my first comment, we don't understand the exact issue
> you are fixing.
In a nutshell, the rte_eth_xstats_get function was reading memory beyond what was stored in the internal arrays (and thus returning junk values). The patch simply prevents it from going out of bounds, it does not address the issue that the rest of the counters are lost though. This issue is not specific to our device, in fact we found it while using a multiqueue virtio device (32 queues), and traced the issue into this core ethdev functionality.
> And I have a bad feeling it could break something else (really just a feeling).
> It is not the kind of patch we can apply the last day of a release.
> That's why I think it should wait 17.02.
>
> Of course you can try to convince me and others to apply it as a last minute
> patch. But why are you sending a patch on the generic API in the last days?
>
> Last argument: it is not fixing a regression of 16.11, so it is not so urgent.
Yes, it looks like this bug was present in DPDK 2.2 even, and possibly before that too.
^ permalink raw reply
* Re: [PATCH] mempool: Free memzone if mempool populate phys fails
From: Thomas Monjalon @ 2016-11-11 9:33 UTC (permalink / raw)
To: Hemant Agrawal; +Cc: dev, olivier.matz, Nipun Gupta
In-Reply-To: <1478875378-15398-1-git-send-email-hemant.agrawal@nxp.com>
2016-11-11 20:12, Hemant Agrawal:
> From: Nipun Gupta <nipun.gupta@nxp.com>
>
> This fixes the issue of memzone not being freed, if the
> rte_mempool_populate_phys fails in the rte_mempool_populate_default
>
> This issue was identified when testing with OVS ~2.6
> - configure the system with low memory (e.g. < 500 MB)
> - add bridge and dpdk interfaces
> - delete brigde
> - keep on repeating the above sequence.
>
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
You forgot the "Fixes:" line to give a tip on the release introducing this bug.
^ permalink raw reply
* Re: [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Alejandro Lucero @ 2016-11-11 9:32 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bert van Leeuwen
In-Reply-To: <1630834.YGmmObtqnA@xps13>
On Fri, Nov 11, 2016 at 9:29 AM, Thomas Monjalon <thomas.monjalon@6wind.com>
wrote:
> 2016-11-11 09:16, Alejandro Lucero:
> > Thomas,
> >
> > We are wondering if you realize this patch fixes a bug with current
> ethdev
> > code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS.
> >
> > Maybe the commit message is giving the wrong impression and as you
> > commented, it should just focus on the bug it fixes and to leave for
> > another email thread the discussion of how to solve the
> > RTE_ETHDEV_QUEUE_STAT_CNTRS
> > problem.
> >
> > Should we remove this from patchwork and to send another patch that way?
>
> Yes please. It was my first comment, we don't understand the exact issue
> you are fixing.
>
OK
> And I have a bad feeling it could break something else (really just a
> feeling).
> It is not the kind of patch we can apply the last day of a release.
> That's why I think it should wait 17.02.
>
>
Fine.
> Of course you can try to convince me and others to apply it as a last
> minute
> patch. But why are you sending a patch on the generic API in the last days?
>
>
We just found it a couple of days ago.
> Last argument: it is not fixing a regression of 16.11, so it is not so
> urgent.
>
^ permalink raw reply
* Re: [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Thomas Monjalon @ 2016-11-11 9:29 UTC (permalink / raw)
To: Alejandro Lucero; +Cc: dev, Bert van Leeuwen
In-Reply-To: <CAD+H992Uafy1JtjEKSxDmV8FK6Qm9ahiB_bof1A=4MGZqb0d6w@mail.gmail.com>
2016-11-11 09:16, Alejandro Lucero:
> Thomas,
>
> We are wondering if you realize this patch fixes a bug with current ethdev
> code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS.
>
> Maybe the commit message is giving the wrong impression and as you
> commented, it should just focus on the bug it fixes and to leave for
> another email thread the discussion of how to solve the
> RTE_ETHDEV_QUEUE_STAT_CNTRS
> problem.
>
> Should we remove this from patchwork and to send another patch that way?
Yes please. It was my first comment, we don't understand the exact issue
you are fixing.
And I have a bad feeling it could break something else (really just a feeling).
It is not the kind of patch we can apply the last day of a release.
That's why I think it should wait 17.02.
Of course you can try to convince me and others to apply it as a last minute
patch. But why are you sending a patch on the generic API in the last days?
Last argument: it is not fixing a regression of 16.11, so it is not so urgent.
^ permalink raw reply
* Re: [PATCH] Revert "bonding: use existing enslaved device queues"
From: Ilya Maximets @ 2016-11-11 9:16 UTC (permalink / raw)
To: Jan Blunck, Declan Doherty, bruce.richardson
Cc: dev, Heetae Ahn, Yuanhan Liu, Eric Kinzie, Bernard Iremonger,
stable, Dyasly Sergey, Thomas Monjalon
In-Reply-To: <8507e1f4-328e-a13d-cee2-69db06fe30be@samsung.com>
Ping.
On 28.10.2016 09:14, Ilya Maximets wrote:
> On 25.10.2016 09:26, Ilya Maximets wrote:
>> On 24.10.2016 17:54, Jan Blunck wrote:
>>> On Wed, Oct 19, 2016 at 5:47 AM, Ilya Maximets <i.maximets@samsung.com> wrote:
>>>> On 18.10.2016 18:19, Jan Blunck wrote:
>>>>> On Tue, Oct 18, 2016 at 2:49 PM, Ilya Maximets <i.maximets@samsung.com> wrote:
>>>>>> On 18.10.2016 15:28, Jan Blunck wrote:
>>>>>>> If the application already configured queues the PMD should not
>>>>>>> silently claim ownership and reset them.
>>>>>>>
>>>>>>> What exactly is the problem when changing MTU? This works fine from
>>>>>>> what I can tell.
>>>>>>
>>>>>> Following scenario leads to APP PANIC:
>>>>>>
>>>>>> 1. mempool_1 = rte_mempool_create()
>>>>>> 2. rte_eth_rx_queue_setup(bond0, ..., mempool_1);
>>>>>> 3. rte_eth_dev_start(bond0);
>>>>>> 4. mempool_2 = rte_mempool_create();
>>>>>> 5. rte_eth_dev_stop(bond0);
>>>>>> 6. rte_eth_rx_queue_setup(bond0, ..., mempool_2);
>>>>>> 7. rte_eth_dev_start(bond0);
>>>>>> * RX queues still use 'mempool_1' because reconfiguration doesn't affect them. *
>>>>>> 8. rte_mempool_free(mempool_1);
>>>>>> 9. On any rx operation we'll get PANIC because of using freed 'mempool_1':
>>>>>> PANIC in rte_mempool_get_ops():
>>>>>> assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed
>>>>>>
>>>>>> You may just start OVS 2.6 with DPDK bonding device and attempt to change MTU via 'mtu_request'.
>>>>>> Bug is easily reproducible.
>>>>>>
>>>>>
>>>>> I see. I'm not 100% that this is expected to work without leaking the
>>>>> driver's queues though. The driver is allowed to do allocations in
>>>>> its rx_queue_setup() function that are being freed via
>>>>> rx_queue_release() later. But rx_queue_release() is only called if you
>>>>> reconfigure the
>>>>> device with 0 queues.
>>
>> It's not true. Drivers usually calls 'rx_queue_release()' inside
>> 'rx_queue_setup()' function while reallocating the already allocated
>> queue. (See ixgbe driver for example). Also all HW queues are
>> usually destroyed inside 'eth_dev_stop()' and reallocated in
>> 'eth_dev_start()' or '{rx,tx}_queue_setup()'.
>> So, there is no leaks at all.
>>
>>>>> From what I understand there is no other way to
>>>>> reconfigure a device to use another mempool.
>>>>>
>>>>> But ... even that wouldn't work with the bonding driver right now: the
>>>>> bonding master only configures the slaves during startup. I can put
>>>>> that on my todo list.
>>
>> No, bonding master reconfigures new slaves in 'rte_eth_bond_slave_add()'
>> if needed.
>>
>>>>> Coming back to your original problem: changing the MTU for the bond
>>>>> does work through rte_eth_dev_set_mtu() for slaves supporting that. In
>>>>> any other case you could (re-)configure rxmode.max_rx_pkt_len (and
>>>>> jumbo_frame / enable_scatter accordingly). This does work without a
>>>>> call to rte_eth_rx_queue_setup().
>>>>
>>>> Thanks for suggestion, but using of rte_eth_dev_set_mtu() without
>>>> reconfiguration will require to have mempools with huge mbufs (9KB)
>>>> for all ports from the start. This is unacceptable because leads to
>>>> significant performance regressions because of fast cache exhausting.
>>>> Also this will require big work to rewrite OVS reconfiguration code
>>>> this way.
>>>> Anyway, it isn't the MTU only problem. Number of rx/tx descriptors
>>>> also can't be changed in runtime.
>>>>
>>>>
>>>> I'm not fully understand what is the use case for this 'reusing' code.
>>>> Could you, please, describe situation where this behaviour is necessary?
>>>
>>> The device that is added to the bond was used before and therefore
>>> already has allocated queues. Therefore we reuse the existing queues
>>> of the devices instead of borrowing the queues of the bond device. If
>>> the slave is removed from the bond again there is no need to allocate
>>> the queues again.
>>>
>>> Hope that clarifies the usecase
>>
>> So, As I see, this is just an optimization that leads to differently
>> configured queues of same device and possible application crash if the
>> old configuration doesn't valid any more.
>>
>> With revert applied in your usecase while adding the device to bond
>> it's queues will be automatically reconfigured according to configuration
>> of the bond device. If the slave is removed from the bond all its'
>> queues will remain as configured by bond. You can reconfigure them if
>> needed. I guess, that in your case configuration of slave devices,
>> actually, matches configuration of bond device. In that case slave
>> will remain in the same state after removing from bond as it was
>> before adding.
>
> So, Jan, Declan, what do you think about this?
>
> Best regards, Ilya Maximets.
>
^ permalink raw reply
* Re: [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Alejandro Lucero @ 2016-11-11 9:16 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bert van Leeuwen
In-Reply-To: <CAD+H990smsF169DngzuEAzSScDqqmkPJrnjB_U19hfc=bSpEew@mail.gmail.com>
Thomas,
We are wondering if you realize this patch fixes a bug with current ethdev
code as a device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS.
Maybe the commit message is giving the wrong impression and as you
commented, it should just focus on the bug it fixes and to leave for
another email thread the discussion of how to solve the
RTE_ETHDEV_QUEUE_STAT_CNTRS
problem.
Should we remove this from patchwork and to send another patch that way?
On Thu, Nov 10, 2016 at 4:04 PM, Alejandro Lucero <
alejandro.lucero@netronome.com> wrote:
>
>
> On Thu, Nov 10, 2016 at 4:01 PM, Thomas Monjalon <
> thomas.monjalon@6wind.com> wrote:
>
>> 2016-11-10 15:43, Alejandro Lucero:
>> > On Thu, Nov 10, 2016 at 2:42 PM, Thomas Monjalon <
>> thomas.monjalon@6wind.com>
>> > wrote:
>> >
>> > > 2016-11-10 14:00, Alejandro Lucero:
>> > > > From: Bert van Leeuwen <bert.vanleeuwen@netronome.com>
>> > > >
>> > > > A device can have more than RTE_ETHDEV_QUEUE_STAT_CNTRS queues which
>> > > > is used inside struct rte_eth_stats. Ideally, DPDK should be built
>> with
>> > > > RTE_ETHDEV_QUEUE_STAT_CNTRS to the maximum number of queues a device
>> > > > can support, 65536, as uint16_t is used for keeping those values for
>> > > > RX and TX. But of course, having such big arrays inside struct
>> > > rte_eth_stats
>> > > > is not a good idea.
>> > >
>> > > RTE_ETHDEV_QUEUE_STAT_CNTRS come from a limitation in Intel devices.
>> > > They have limited number of registers to store the stats per queue.
>> > >
>> > > > Current default value is 16, which could likely be changed to 32 or
>> 64
>> > > > without too much opposition. And maybe it would be a good idea to
>> modify
>> > > > struct rte_eth_stats for allowing dynamically allocated arrays and
>> maybe
>> > > > some extra fields for keeping the array sizes.
>> > >
>> > > Yes
>> > > and? what is your issue exactly? with which device?
>> > > Please explain the idea brought by your patch.
>> > >
>> >
>> > Netronome NFP devices support 128 queues and future version will support
>> > 1024.
>> >
>> > A particular VF, our PMD just supports VFs, could get as much as 128.
>> > Although that is not likely, that could be an option for some client.
>> >
>> > Clients want to use a DPDK coming with a distribution, so changing the
>> > RTE_ETHDEV_QUEUE_STAT_CNTRS depending on the present devices is not an
>> > option.
>> >
>> > We would be happy if RTE_ETHDEV_QUEUE_STAT_CNTRS could be set to 1024,
>> > covering current and future requirements for our cards, but maybe having
>> > such big arrays inside struct rte_eth_stats is something people do not
>> want
>> > to have.
>> >
>> > A solution could be to create such arrays dynamically based on the
>> device
>> > to get the stats from. For example, call to rte_eth_dev_configure could
>> > have ax extra field for allocating a rte_eth_stats struct, which will be
>> > based on nb_rx_q and nb_tx_q params already given to that function.
>> >
>> > Maybe the first thing to know is what people think about just
>> incrementing
>> > RTE_ETHDEV_QUEUE_STAT_CNTRS to 1024.
>> >
>> > So Thomas, what do you think about this?
>>
>> I think this patch is doing something else :)
>>
>>
> Sure. But the problem the patch solves is pointing to this, IMHO, bigger
> issue.
>
>
>> I'm not sure what is better between big arrays and variable size.
>> I think you must explain these 2 options in another thread,
>> because I'm not sure you will have enough attention in a thread starting
>> with
>> "check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS".
>>
>
> Agree. I'll do that then.
>
> Thanks
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox