* [PATCH 0/2] net/thunderx: add 83xx SoC support
From: Jerin Jacob @ 2016-11-08 6:31 UTC (permalink / raw)
To: dev; +Cc: thomas.monjalon, bruce.richardson, Jerin Jacob
CN83xx is 24 core version of ThunderX ARMv8 SoC with integrated
octeon style packet and crypto accelerators.
The standard NIC block used in 88xx/81xx also included in 83xx.
This patchset adds support for existing standard NIC block on 83xx by
adding new HW capability flag to select the difference in runtime.
Jerin Jacob (2):
net/thunderx: disable l3 alignment pad feature
net/thunderx: add cn83xx support
doc/guides/nics/thunderx.rst | 1 +
drivers/net/thunderx/base/nicvf_hw.c | 22 ++++++++++++++++++++++
drivers/net/thunderx/base/nicvf_hw.h | 5 +++++
drivers/net/thunderx/base/nicvf_hw_defs.h | 2 ++
drivers/net/thunderx/nicvf_ethdev.c | 17 +++++++++++++++++
5 files changed, 47 insertions(+)
--
2.5.5
^ permalink raw reply
* Re: [PATCH v3] doc: arm64: document DPDK application profiling methods
From: Jianbo Liu @ 2016-11-08 5:57 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev, Thomas Monjalon, john.mcnamara
In-Reply-To: <1478575976-12006-1-git-send-email-jerin.jacob@caviumnetworks.com>
On 8 November 2016 at 11:32, Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
> ---
> v3:
> Fixed formatting issues:
> - Remove the introduction heading and put intro text under the main heading(Thomas)
> - Fixed RST formatting issues such as enclosing technical terms in backquotes(John)
> Thanks, John for providing the updated version
> v2:
> -Addressed ARM64 specific review comments(Suggested by Thomas)
> http://dpdk.org/dev/patchwork/patch/16362/
> ---
> doc/guides/prog_guide/profile_app.rst | 64 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 63 insertions(+), 1 deletion(-)
>
Acked-by: Jianbo Liu <jianbo.liu@linaro.org>
^ permalink raw reply
* [PATCH v3] doc: arm64: document DPDK application profiling methods
From: Jerin Jacob @ 2016-11-08 3:32 UTC (permalink / raw)
To: dev; +Cc: thomas.monjalon, john.mcnamara, Jerin Jacob
In-Reply-To: <1475657009-11139-1-git-send-email-jerin.jacob@caviumnetworks.com>
Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
v3:
Fixed formatting issues:
- Remove the introduction heading and put intro text under the main heading(Thomas)
- Fixed RST formatting issues such as enclosing technical terms in backquotes(John)
Thanks, John for providing the updated version
v2:
-Addressed ARM64 specific review comments(Suggested by Thomas)
http://dpdk.org/dev/patchwork/patch/16362/
---
doc/guides/prog_guide/profile_app.rst | 64 ++++++++++++++++++++++++++++++++++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/profile_app.rst b/doc/guides/prog_guide/profile_app.rst
index 3226187..54b546a 100644
--- a/doc/guides/prog_guide/profile_app.rst
+++ b/doc/guides/prog_guide/profile_app.rst
@@ -31,8 +31,15 @@
Profile Your Application
========================
+The following sections describe methods of profiling DPDK applications on
+different architectures.
+
+
+Profiling on x86
+----------------
+
Intel processors provide performance counters to monitor events.
-Some tools provided by Intel can be used to profile and benchmark an application.
+Some tools provided by Intel, such as VTune, can be used to profile and benchmark an application.
See the *VTune Performance Analyzer Essentials* publication from Intel Press for more information.
For a DPDK application, this can be done in a Linux* application environment only.
@@ -50,3 +57,58 @@ The main situations that should be monitored through event counters are:
Refer to the
`Intel Performance Analysis Guide <http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdf>`_
for details about application profiling.
+
+
+Profiling on ARM64
+------------------
+
+Using Linux perf
+~~~~~~~~~~~~~~~~
+
+The ARM64 architecture provide performance counters to monitor events. The
+Linux ``perf`` tool can be used to profile and benchmark an application. In
+addition to the standard events, ``perf`` can be used to profile arm64
+specific PMU (Performance Monitor Unit) events through raw events (``-e``
+``-rXX``).
+
+For more derails refer to the
+`ARM64 specific PMU events enumeration <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100095_0002_04_en/way1382543438508.html>`_.
+
+
+High-resolution cycle counter
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The default ``cntvct_el0`` based ``rte_rdtsc()`` provides a portable means to
+get a wall clock counter in user space. Typically it runs at <= 100MHz.
+
+The alternative method to enable ``rte_rdtsc()`` for a high resolution wall
+clock counter is through the armv8 PMU subsystem. The PMU cycle counter runs
+at CPU frequency. However, access to the PMU cycle counter from user space is
+not enabled by default in the arm64 linux kernel. It is possible to enable
+cycle counter for user space access by configuring the PMU from the privileged
+mode (kernel space).
+
+By default the ``rte_rdtsc()`` implementation uses a portable ``cntvct_el0``
+scheme. Application can choose the PMU based implementation with
+``CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU``.
+
+The example below shows the steps to configure the PMU based cycle counter on
+an armv8 machine.
+
+.. code-block:: console
+
+ git clone https://github.com/jerinjacobk/armv8_pmu_cycle_counter_el0
+ cd armv8_pmu_cycle_counter_el0
+ make
+ sudo insmod pmu_el0_cycle_counter.ko
+ cd $DPDK_DIR
+ make config T=arm64-armv8a-linuxapp-gcc
+ echo "CONFIG_RTE_ARM_EAL_RDTSC_USE_PMU=y" >> build/.config
+ make
+
+.. warning::
+
+ The PMU based scheme is useful for high accuracy performance profiling with
+ ``rte_rdtsc()``. However, this method can not be used in conjunction with
+ Linux userspace profiling tools like ``perf`` as this scheme alters the PMU
+ registers state.
--
2.5.5
^ permalink raw reply related
* Re: [PATCH v3 1/3] lib: add information metrics library
From: Remy Horton @ 2016-11-08 3:19 UTC (permalink / raw)
To: Pattan, Reshma; +Cc: dev
In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F010C1A9E@IRSMSX109.ger.corp.intel.com>
On 07/11/2016 23:25, Pattan, Reshma wrote:
[..]
>>> + * Initialises statistic module. This only has to be explicitly
>>> +called
>>
>> Typo < Initialises>
>
> To avoid confusion, here I mean to say "Initializes" should be used (i.e. US English) .
Sorta guessed that.. :)
> Also another non-related comment, you may need to add a comment about EMWA
> near the mean bit rate calculation code.
Quite a few comments needed updating. Going to hold off the v5 until
16.11 is out as I'll also need to change all the references to 17.02..
..Remy
^ permalink raw reply
* Re: [RFC v2] Generic flow director/filtering/classification API
From: Zhang, Helin @ 2016-11-08 1:31 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev@dpdk.org, Thomas Monjalon, Lu, Wenzhuo, Zhao1, Wei
In-Reply-To: <20161102111303.GB5733@6wind.com>
Hi Adrien
Any update on the v1 APIs? We are struggling on that, as we need that for our development.
May I bring another idea to remove the blocking?
Can we send out the APIs with PMD changes based on our understaning of the RFC we discussed recenlty on community? Then you can just update any modification on top of it, or ask the submittors to change with your review comments?
Any comments on this idea? If not, then we may go this way. I guess this might be the most efficient way. Thank you very much!
Regards,
Helin
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Wednesday, November 2, 2016 7:13 PM
> To: Zhang, Helin
> Cc: dev@dpdk.org; Thomas Monjalon; Lu, Wenzhuo
> Subject: Re: [dpdk-dev] [RFC v2] Generic flow director/filtering/classification
> API
>
> Hi Helin,
>
> On Mon, Oct 31, 2016 at 07:19:18AM +0000, Zhang, Helin wrote:
> > Hi Adrien
> >
> > Just a double check, do you have any update on the v1 patch set, as now it
> is the end of October?
> > We are extremly eager to see the v1 patch set for development.
> > I don't think we need full validation on the v1 patch set for API. It should be
> together with PMD and example application.
> > If we can see the v1 API patch set earlier, we can help to validate it with
> our code changes. That's should be more efficient and helpful.
> > Any comments on my personal understanding?
> >
> > Thank you very much for the hard work and kind helps!
>
> I intend to send it shortly, likely this week. For the record, a large part of this
> task was also dedicated to implement it on the client side (I've just read Wei's
> RFC for a client-side application to which I will reply separately), in order to
> validate it from a usability standpoint that led me to make a few necessary
> adjustments to the API.
>
> My next submission will include both the updated API with several changes
> discussed on this ML and testpmd code (not a separate application) that uses
> it. Just hang on a bit longer!
>
> > > -----Original Message-----
> > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Adrien
> > > Mazarguil
> > > Sent: Friday, September 30, 2016 1:11 AM
> > > To: dev@dpdk.org
> > > Cc: Thomas Monjalon
> > > Subject: Re: [dpdk-dev] [RFC v2] Generic flow
> > > director/filtering/classification API
> > >
> > > On Fri, Aug 19, 2016 at 08:50:44PM +0200, Adrien Mazarguil wrote:
> > > > Hi All,
> > > >
> > > > Thanks to many for the positive and constructive feedback I've
> > > > received so far. Here is the updated specification (v0.7) at last.
> > > >
> > > > I've attempted to address as many comments as possible but could
> > > > not process them all just yet. A new section "Future evolutions"
> > > > has been added for the remaining topics.
> > > >
> > > > This series adds rte_flow.h to the DPDK tree. Next time I will
> > > > attempt to convert the specification as a documentation commit
> > > > part of the patchset and actually implement API functions.
> > > [...]
> > >
> > > A quick update, we initially targeted 16.11 as the DPDK release this
> > > API would be available for, turns out this goal was somewhat too
> > > optimistic as September is ending and we are about to overshoot the
> > > deadline for integration (basically everything took longer than expected,
> big surprise).
> > >
> > > So instead of rushing things now to include a botched API in 16.11
> > > with no PMD support, we simply modified the target, now set to
> > > 17.02. On the plus side this should leave developers more time to
> > > refine and test the API before applications and PMDs start to use it.
> > >
> > > I intend to send the patchset for the first non-draft version
> > > mid-October worst case (ASAP in fact). I still haven't replied to
> > > several comments but did take them into account, thanks for your
> feedback.
> > >
> > > --
> > > Adrien Mazarguil
> > > 6WIND
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply
* Re: rte_ixgbevf_pmd not reporting dropped packets
From: Lu, Wenzhuo @ 2016-11-08 1:20 UTC (permalink / raw)
To: Montorsi, Francesco, dev@dpdk.org
In-Reply-To: <a14e06895bdc4da2a2259e216f0deed5@bilemail1.empirix.com>
Hi Francesco,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Montorsi, Francesco
> Sent: Tuesday, November 8, 2016 1:17 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] rte_ixgbevf_pmd not reporting dropped packets
>
> Hi all,
>
> I'm using DPDK inside the OS of a VM that is SR-IOV-accelerated.
> I noticed however that the "rte_ixgbevf_pmd" PMD does not report drops... I
> am sending packets at TX side at 14Mpps; at the RX side I'm using "testpmd" and
> it's reporting 'just' 12Mpps, but zero drops (also through xstats).
>
> Is this a known bug?
> I found a message at
> http://dpdk.org/ml/archives/dev/2016-March/035374.html
> reporting a similar issue back in March this year...
It's a known limitation. The stats are got from HW. But there're very limited counters for VF. There's no similar counter as imiss for VF :(
>
>
> Thanks,
>
> Francesco Montorsi
^ permalink raw reply
* Re: [PATCH] lib/ip_frag: fix IP reassembly not working issue
From: Lu, Wenzhuo @ 2016-11-08 0:55 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev@dpdk.org, adrien.mazarguil@6wind.com, Ananyev, Konstantin
In-Reply-To: <67229791.hG439HiJFh@xps13>
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, November 8, 2016 4:28 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; adrien.mazarguil@6wind.com; Ananyev, Konstantin
> Subject: Re: [dpdk-dev] [PATCH] lib/ip_frag: fix IP reassembly not working issue
>
> 2016-11-06 12:16, Wenzhuo Lu:
> > After changing pkt[0] to pkt[], the example IP reassembly is not
> > working.
> > It's weird because this change is fine. There should be no difference
> > between them.
> > As a workaround, revert this change.
> >
> > Fixes: 347a1e037fd3 (lib: use C99 syntax for zero-size arrays)
> >
> > Reported-by: Huilong Xu <huilongx.xu@intel.com>
> > Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
>
> Applied, thanks
>
> Please keep us informed if you understand the issue.
Just FYI,
It's so weird, I have to work around it first.
1, I don't think there's any wrong with the code.
2, I cannot reproduce this issue on my machine, but Huilong can reproduce it on different machines. As Adrien said, it may be a compile issue. I guess it's a compiler issue. Maybe gcc 4.8.5 has its own problem. (I'm using gcc 4.8.3 which is fine.)
^ permalink raw reply
* Re: Running 2 process on the same machine
From: Wiles, Keith @ 2016-11-07 22:36 UTC (permalink / raw)
To: Keren Hochman; +Cc: dev@dpdk.org
In-Reply-To: <CAJq3SQ6Okz8ZzK2fEymgf9SoDLznBUf52QBzAHVJL=k6RaCrxQ@mail.gmail.com>
> On Nov 7, 2016, at 7:28 AM, Keren Hochman <keren.hochman@lightcyber.com> wrote:
>
> Hi,
> I need to run 2 process that uses dpdk on the same machine. One uses dpdk
> drivers, and the other just read from a pcap file. If I disable hugepages
> in the second process rte_mempool_create fails. What is the correct way to
> handle this?
If you look at the two scripts in Pktgen pktgen-master.sh and pktgen-slave.sh these two scripts setup two instances of pktgen on the same machine. Plus you can read the README.md file.
http://dpdk.org/browse/apps/pktgen-dpdk/refs/
You have to make sure you have enough memory (huge pages) allocated for both instances to run.
Then use —file-prefix XX to give each instance a different prefix for the huge page files in /dev/hugepages if that is the location of the files on your system. I would remove any files in that directory to free up the memory.
Use the —socket-mem to allocate the correct amount of memory for each instances this way DPDK does not consume all the pages for a given instance.
Make sure you blacklist the ports you do not want on the first instance using -b option and then blacklist the ports from the first instance while allowing the other ports to be used on the second one.
That should do it for most cases.
>
> Thanks, Keren
Regards,
Keith
^ permalink raw reply
* [dpdk-announce] release candidate 16.11-rc3
From: Thomas Monjalon @ 2016-11-07 21:19 UTC (permalink / raw)
To: announce
A new DPDK release candidate is ready for testing:
http://dpdk.org/browse/dpdk/tag/?id=v16.11-rc3
It will be hopefully the last release candidate for 16.11.
As it is not so small, please test it very well in order to
secure the release planned to be out at the end of this week.
Thank you everyone
^ permalink raw reply
* Re: [PATCH] doc: add limitation for L3fwd-power app
From: Thomas Monjalon @ 2016-11-07 21:06 UTC (permalink / raw)
To: De Lara Guarch, Pablo; +Cc: dev, Mcnamara, John
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264A860@IRSMSX103.ger.corp.intel.com>
> > L3fwd-power app needs vector mode to be disabled in order to work
> > properly. The app used to work previously, because it was using Rx scalar
> > function, but now it uses vector function.
> >
> > Vector mode needs to be disabled to make the app works, which has been
> > documented in release notes.
> >
> > Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v2] doc/guides: add more info about VT-d/iommu settings
From: Thomas Monjalon @ 2016-11-07 21:04 UTC (permalink / raw)
To: Trahe, Fiona; +Cc: dev, Kusztal, ArkadiuszX
In-Reply-To: <80307F746F1522479831AB1253B7024E6F9C2B@IRSMSX102.ger.corp.intel.com>
> > Add more information about VT-d/iommu settings for QAT PMD.
> > Remove limitation indicating QAT driver is not performance tuned.
> >
> > Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> Acked-by: Arek Kusztal <arkadiuszx.kusztal@intel.com>
Wrapped lines and applied.
^ permalink raw reply
* Re: [PATCH] doc: remove Intel reference from multi-process support guide
From: Thomas Monjalon @ 2016-11-07 20:54 UTC (permalink / raw)
To: Jerin Jacob; +Cc: Mcnamara, John, dev
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264A100@IRSMSX103.ger.corp.intel.com>
> > multi-process support has been verified on non IA such as ARMv8.
> >
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] doc: fix typos
From: Thomas Monjalon @ 2016-11-07 20:50 UTC (permalink / raw)
To: Alain Leon; +Cc: dev, Mcnamara, John
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264B222@IRSMSX103.ger.corp.intel.com>
> > Fixes typos present in the documentation and code comments.
> >
> > Signed-off-by: Alain Leon <xerebz@gmail.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v3] examples/ipsec-secgw: fix pointer to local outside scope
From: Thomas Monjalon @ 2016-11-07 20:48 UTC (permalink / raw)
To: Fan Zhang; +Cc: dev, Ferruh Yigit, sergio.gonzalez.monroy
In-Reply-To: <8536a227-c05f-3a1b-e8c0-599fa9cdb993@intel.com>
2016-11-07 17:31, Ferruh Yigit:
> On 11/7/2016 5:25 PM, Fan Zhang wrote:
> > Coverity issue: 137871
> > Fixes: 0d547ed03717 ("examples/ipsec-secgw: support configuration file")
> >
> > Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
>
> Although checkpatch will complain about long lines, I believe it is
> better not to wrap log messages.
>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Wrapped after "error: " to avoid too long lines
while being able to grep the rest of the message,
and applied.
^ permalink raw reply
* Re: [PATCH v2] examples/ipsec-secgw: fix copy into fixed size buffer issue
From: Thomas Monjalon @ 2016-11-07 20:40 UTC (permalink / raw)
To: Fan Zhang; +Cc: dev, Ferruh Yigit, sergio.gonzalez.monroy
In-Reply-To: <ca6e6e63-69e5-cc51-9e74-b3a510107d68@intel.com>
2016-11-07 15:59, Ferruh Yigit:
> On 11/7/2016 2:21 PM, Fan Zhang wrote:
> > Fixes: 0d547ed0 ("examples/ipsec-secgw: support configuration
> > file")
> > Coverity issue: 137875
> >
> > Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
>
> Acked-by: Ferruh Yigit <ferruh.yigit@intel.com>
Applied
^ permalink raw reply
* Re: [PATCH] ethdev: fix statistics description
From: Thomas Monjalon @ 2016-11-07 20:37 UTC (permalink / raw)
To: Dai, Wei
Cc: Morten Brørup, Mcnamara, John, Ananyev, Konstantin,
Wu, Jingjing, Zhang, Helin, Curran, Greg, dev
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC359EA906@smartserver.smartshare.dk>
2016-11-02 10:21, Morten Brørup:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2016-08-26 18:08, Wei Dai:
> > > > /**
> > > > * A structure used to retrieve statistics for an Ethernet port.
> > > > + * Not all statistics fields in struct rte_eth_stats are supported
> > > > + * by any type of network interface card (NIC). If any statistics
> > > > + * field is not supported, its value is 0 .
> > > > */
> > > > struct rte_eth_stats {
> > >
> > > I'm missing the point of this patch.
> > > Why do you think it is a fix?
> > >
> > > John, any opinion?
>
> I think the source code comment is an improvement.
[...]
Applied as an improvement (not a fix).
^ permalink raw reply
* Re: [PATCH] lib/ip_frag: fix IP reassembly not working issue
From: Thomas Monjalon @ 2016-11-07 20:27 UTC (permalink / raw)
To: Wenzhuo Lu; +Cc: dev, adrien.mazarguil, konstantin.ananyev
In-Reply-To: <1478452574-127074-1-git-send-email-wenzhuo.lu@intel.com>
2016-11-06 12:16, Wenzhuo Lu:
> After changing pkt[0] to pkt[], the example IP reassembly is not
> working.
> It's weird because this change is fine. There should be no
> difference between them.
> As a workaround, revert this change.
>
> Fixes: 347a1e037fd3 (lib: use C99 syntax for zero-size arrays)
>
> Reported-by: Huilong Xu <huilongx.xu@intel.com>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
Applied, thanks
Please keep us informed if you understand the issue.
^ permalink raw reply
* Re: [PATCH] net/bonding: only handle lacp slow packets
From: Thomas Monjalon @ 2016-11-07 20:20 UTC (permalink / raw)
To: linhaifeng; +Cc: dev, Kulasek, TomaszX, Yigit, Ferruh, Doherty, Declan
In-Reply-To: <3042915272161B4EB253DA4D77EB373A14F46AF1@IRSMSX102.ger.corp.intel.com>
> > We should not drop the slow packets which subtype is not marker or lacp.
> > Because slow packets have other subtype like OAM,OSSP,user defined and so
> > on.
> >
> > Signed-off-by: Linhaifeng <haifeng.lin@huawei.com>
>
> Reviewed-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] net/vmxnet3: fix mbuf release on reset/stop
From: Thomas Monjalon @ 2016-11-07 20:14 UTC (permalink / raw)
To: Yong Wang; +Cc: dev, stephen
In-Reply-To: <1477503907-11306-1-git-send-email-yongwang@vmware.com>
2016-10-26 10:45, Yong Wang:
> During device reset/stop, vmxnet3 releases all mbufs in tx and
> rx cmd ring. For rx, we should go over all ring descriptors and
> free using rte_pktmbuf_free_seg() instead of rte_pktmbuf_free()
> as the metadata of the mbuf might not be properly initialized
> (initialization after mempool creation is done in the rx routine)
> and the mbuf should always be a single-segment one when populated.
> For tx, we can use the existing way as mbuf, if any, will be a
> valid one stashed in the eop.
>
> Fixes: dfaff37fc46d ("vmxnet3: import new vmxnet3 poll mode driver implementation")
> Signed-off-by: Yong Wang <yongwang@vmware.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] net/qede: fix gcc compiler option checks
From: Thomas Monjalon @ 2016-11-07 20:10 UTC (permalink / raw)
To: Rasesh Mody; +Cc: dev, Dept-EngDPDKDev, Rasesh Mody
In-Reply-To: <1477636677-18041-1-git-send-email-rasesh.mody@qlogic.com>
2016-10-27 23:37, Rasesh Mody:
> From: Rasesh Mody <Rasesh.Mody@cavium.com>
>
> Using GCC_VERSION to check gcc version and decide whether to include
> that compiler option.
>
> Fixes: ec94dbc57362 ("qede: add base driver")
No need for the above line.
It is fixing the commit below (which fixes above one).
> Fixes: ecc7a5a27ffe ("net/qede/base: fix 32-bit build")
>
> Signed-off-by: Rasesh Mody <Rasesh.Mody@cavium.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] net/qede: fix gcc compiler option checks
From: Thomas Monjalon @ 2016-11-07 19:54 UTC (permalink / raw)
To: Mody, Rasesh, Rasesh Mody; +Cc: Stephen Hemminger, dev, Dept-EngDPDKDev
In-Reply-To: <BLUPR0701MB15723F83E7BF952B9CBD98859FAD0@BLUPR0701MB1572.namprd07.prod.outlook.com>
2016-10-28 22:49, Mody, Rasesh:
> > From: Stephen Hemminger
> > > ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
> > > -ifeq ($(shell gcc -Wno-unused-but-set-variable -Werror -E - < /dev/null > /dev/null 2>&1; echo $$?),0)
> > > +ifeq ($(shell test $(GCC_VERSION) -ge 44 && echo 1), 1)
> > > CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
> > > endif
> > > CFLAGS_BASE_DRIVER += -Wno-missing-declarations
> > > -ifeq ($(shell gcc -Wno-maybe-uninitialized -Werror -E - < /dev/null > /dev/null 2>&1; echo $$?),0)
> > > +ifeq ($(shell test $(GCC_VERSION) -ge 46 && echo 1), 1)
> > > CFLAGS_BASE_DRIVER += -Wno-maybe-uninitialized
> > > endif
> >
> > Does this mean that less compiler checking is done or more?
>
> With higher version of compilers more compiler checking is done, for older compilers less checking is done. As some of the older compiles do not have newly added checking capabilities. Testing with latest compilers ensures we do lot more checking.
It is basically less checking.
It disables some checks if the compiler support them because it would
make compilation failing.
Why would it fail? Because as other base drivers, the code is messy.
> > It seems lots of drivers make the excuse:
> > "the base driver comes from another group and is known buggy but can't be
> > fixed"
> > That doesn't reflect well on the quality of the DPDK.
You're right Stephen. It is an excuse which has been accepted in DPDK.
Should we be stricter?
^ permalink raw reply
* Re: [PATCH v3] net/qede: fix advertising link speed capability
From: Thomas Monjalon @ 2016-11-07 19:48 UTC (permalink / raw)
To: Rasesh Mody, Harish Patil; +Cc: bruce.richardson, dev, Dept-EngDPDKDev
In-Reply-To: <1477938901-24999-2-git-send-email-Rasesh.Mody@cavium.com>
2016-10-31 11:35, Rasesh Mody:
> From: Harish Patil <harish.patil@qlogic.com>
>
> Fix to advertise device's link speed capability based on NVM
> port configuration instead of returning driver supported speeds.
>
> Fixes: 95e67b479506 ("net/qede: add 100G link speed capability")
>
> Signed-off-by: Harish Patil <harish.patil@qlogic.com>
[...]
> + /* Fill up the native advertised speed */
> + switch (params.speed.advertised_speeds) {
> + case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_10G:
> + adv_speed = 10000;
> + break;
> + case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_25G:
> + adv_speed = 25000;
> + break;
> + case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_40G:
> + adv_speed = 40000;
> + break;
> + case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_50G:
> + adv_speed = 50000;
> + break;
> + case NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_BB_100G:
> + adv_speed = 100000;
> + break;
> + default:
> + DP_NOTICE(hwfn, false, "Unknown speed\n");
> + adv_speed = 0;
> + }
> + if_link->adv_speed = adv_speed;
The qede devices support only one speed?
I guess it is wrong but it is a step in right direction so it
will be enough for 16.11.
Applied
^ permalink raw reply
* Re: [PATCH 1/3 v3] bnxt: use appropriate data type in bnxt_alloc_vnic_attributes
From: Thomas Monjalon @ 2016-11-07 18:35 UTC (permalink / raw)
To: Ajit Khaparde; +Cc: dev, Ferruh Yigit
In-Reply-To: <20161107151204.GA24819@C02PT1RBG8WP.wifi.aus.avagotech.net>
2016-11-07 09:12, Ajit Khaparde:
> Prevent the arithmetic in bnxt_alloc_vnic_attributes from causing
> any unintentional havoc because of the usage of a signed variable.
>
> Coverity: 137874
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
Series applied, thanks
As a regular contributor, please follow the contribution guidelines:
http://dpdk.org/dev#send
^ permalink raw reply
* Re: [PATCH 0/2] update mlx5 release note and guide
From: Thomas Monjalon @ 2016-11-07 18:09 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev, Adrien Mazarguil
In-Reply-To: <20161102155808.GH5733@6wind.com>
> > Nelio Laranjeiro (2):
> > doc: update mlx5 dependencies
> > doc: add mlx5 release notes
>
> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Applied with 2/2 v2, thanks
^ permalink raw reply
* Re: [PATCH] doc: fix mlx5 features overview
From: Thomas Monjalon @ 2016-11-07 17:59 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev, Mcnamara, John
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264A6C9@IRSMSX103.ger.corp.intel.com>
> > Fixes: 75ef62a94301 ("net/mlx5: fix link speed capability information")
> > Fixes: 188408719888 ("net/mlx5: fix support for newer link speeds")
> >
> > Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, 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