* Re: [PATCH v1 1/2] net/i40e: fix incorrect xstats value mapping
From: Kevin Traynor @ 2016-11-14 17:59 UTC (permalink / raw)
To: Remy Horton, dev; +Cc: Helin Zhang, Jingjing Wu, stable, Yuanhan Liu
In-Reply-To: <1479104089-27862-2-git-send-email-remy.horton@intel.com>
On 11/14/2016 06:14 AM, Remy Horton wrote:
> The offsets used in rte_i40evf_stats_strings for transmission
> statistics were wrong, returning the total byte count rather than
> the respective (unicast, multicast, broadcast, drop, & error)
> packet counts.
>
> Fixes: da61cd084976 ("i40evf: add extended stats")
This should go to the LTS branch also.
Acked-by: Kevin Traynor <ktraynor@redhat.com>
>
> Signed-off-by: Remy Horton <remy.horton@intel.com>
> ---
> drivers/net/i40e/i40e_ethdev_vf.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
> index aa306d6..afae2ec 100644
> --- a/drivers/net/i40e/i40e_ethdev_vf.c
> +++ b/drivers/net/i40e/i40e_ethdev_vf.c
> @@ -176,11 +176,11 @@ static const struct rte_i40evf_xstats_name_off rte_i40evf_stats_strings[] = {
> {"rx_unknown_protocol_packets", offsetof(struct i40e_eth_stats,
> rx_unknown_protocol)},
> {"tx_bytes", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_unicast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_multicast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_broadcast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_dropped_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> - {"tx_error_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
> + {"tx_unicast_packets", offsetof(struct i40e_eth_stats, tx_unicast)},
> + {"tx_multicast_packets", offsetof(struct i40e_eth_stats, tx_multicast)},
> + {"tx_broadcast_packets", offsetof(struct i40e_eth_stats, tx_broadcast)},
> + {"tx_dropped_packets", offsetof(struct i40e_eth_stats, tx_discards)},
> + {"tx_error_packets", offsetof(struct i40e_eth_stats, tx_errors)},
> };
>
> #define I40EVF_NB_XSTATS (sizeof(rte_i40evf_stats_strings) / \
>
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: Ferruh Yigit @ 2016-11-14 17:38 UTC (permalink / raw)
To: Shreyansh Jain, David Marchand; +Cc: dev@dpdk.org
In-Reply-To: <DB5PR0401MB2054B1B4C5EC1BA8412E8B4090BA0@DB5PR0401MB2054.eurprd04.prod.outlook.com>
On 11/12/2016 5:44 PM, Shreyansh Jain wrote:
> Hello Ferruh,
>
> (Please ignore if line wrappings are not correct. Using a possibly
> unconfigured mail client).
>
>> -----Original Message-----
>> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
>> Sent: Saturday, November 12, 2016 12:46 AM
>> To: Shreyansh Jain <shreyansh.jain@nxp.com>; David Marchand
>> <david.marchand@6wind.com>
>> Cc: dev@dpdk.org
>> Subject: Re: [dpdk-dev] Clarification for eth_driver changes
>>
>> On 11/10/2016 11:05 AM, Shreyansh Jain wrote:
>>> Hello David,
>>>
>>> On Thursday 10 November 2016 01:46 PM, David Marchand wrote:
>>>> Hello Shreyansh,
>>>>
>>>> On Thu, Nov 10, 2016 at 8:26 AM, Shreyansh Jain <shreyansh.jain@nxp.com>
>> wrote:
>>>>> I need some help and clarification regarding some changes I am doing to
>>>>> cleanup the EAL code.
>>>>>
>>>>> There are some changes which should be done for eth_driver/rte_eth_device
>>>>> structures:
>>>>>
>>>>> 1. most obvious, eth_driver should be renamed to rte_eth_driver.
>>>>> 2. eth_driver currently has rte_pci_driver embedded in it
>>>>> - there can be ethernet devices which are _not_ PCI
>>>>> - in which case, this structure should be removed.
>>>>
>>>> Do we really need to keep a eth_driver ?
>>>
>>> No. As you have rightly mentioned below (as well as in your Jan'16
>>> post), it is a mere convenience.
>>
>> Isn't it good to separate the logic related which bus device connected
>> and what functionality it provides. Because these two can be flexible:
>
> Indeed. The very idea of a Bus model is to make a hierarchy which allows
> for pluggability/flexibility in terms of devices being used. But, until now I
> have only considered placement hierarchy and not functional hierarchy. (more
> below)
>
>>
>> device -> virtual_bus -> ethernet_functionality
>> device -> pci_bus -> crypto_functionality
>> device -> x_bus -> y_function
>>
>
> Ok.
>
>>
>> what about:
>>
>> create generic bus driver/device and all eal level deal with generic
>> bus. different buses inherit from generic bus logic
>
> From what I had in mind: (and very much similar to what you have already
> mentioned in this email)
> - a generic bus (not a driver, not a device). I don't know how to categorize
> a bus. It is certainly not a device, and then handler for a bus (physical)
> can be considered a 'bus driver'. So, just 'rte_bus'.
> - there is a bus for each physical implementation (or virtual). So, a rte_bus
> Object for PCI, VDEV, ABC, DEF and so on.
> - Buses are registered just like a PMD - RTE_PMD_BUS_REGISTER()
> -- There is a problem of making sure the constructor for bus registration is
> executed before drivers. Probably by putting the bus code within lib*
> - Each registered bus is part of a doubly list.
> - Each device inherits rte_bus
> - Each driver inherits rte_bus
> - Existing Device and Drivers lists would be moved into rte_bus
>
> (more below)
>
>>
>> create generic functionality device/driver and pmd level deal with
>> these. different functionalities inherit from generic functionality logic
>>
>> and use rte_device/rte_driver as glue logic for all these.
>>
>> This makes easy to add new bus or functionality device/drivers without
>> breaking existing logic.
>>
>>
>> Something like this:
>>
>> struct rte_device {
>> char *name;
>> struct rte_driver *drv;
>> struct rte_bus_device *bus_dev;
>> struct rte_funcional_device *func_dev;
>> *devargs
>> }
>>
>> struct rte_bus_device {
>> struct rte_device *dev;
>> /* generic bus device */
>> }
>
> This is where you lost me. From what I understood from your text:
> (CMIIW)
>
> - Most abstract class is 'rte_device'.
> - A bus is a device. So, it points to a rte_device
> - But, a rte_device belongs to a bus, so it points to a rte_bus_device.
>
> Isn't that contradictory?
What I was thinking is:
rte_device/driver are not abstract classes.
rte_bus device/driver is an abstract class and any bus inherited from
this class.
rte_func device/driver is and abstract class and eth/crypto inherited
from this class.
eal layer only deal with rte_bus
pmd's only deal with functional device/driver
but still, it is required to know device <-> driver, and functional <->
bus, relations. rte_dev/rte_driver are to provide this links.
But yes this add extra layer and with second thought I am not sure if it
is really possible to separate bus and functionality, this was just an
idea ..
>
> This is how I view the physical layout of devices on which DPDK works:
>
> +---------+ +----------+
> |Driver 1A| |Driver 2B |
> |servicing| |servicing | (*)
> |Bus A | |Bus B |
> +---------+ +----------+
> \ /
> +---------+ +-------+
> | bus A |---| bus B |--- ...
> +---------+ +-------+
> / \ \ \
> / \_ \ \
> +---------+ / / \
> | device 1| / +--------+ \
> | on Bus A| / |Device 3| |
> +---------+ / |on bus B| |
> +---------+ +--------+ |
> | device 2| +--------+
> | on Bus A| |Device 4|
> +---------+ |on bus B|
> +--------+
>
> (*) Multiple drivers servicing a Bus.
>
> Now, if we introduce the abstraction for functionality (assuming net/crypto) as
> two functionalities currently applicable:
>
> +---------+ +----------+
> |Driver 1A| |Driver 2B |
> |servicing| |servicing | (*)
> |Bus A | |Bus B |
> +---------' +---.------+
> \ /
> +---------+ +-------+
> | bus A |---| bus B |--- ...
> +---------+ +-------+
> / \ \ \
> / \_ \ \
> +---------' / / \
> | device 1| / +--------' \
> | on Bus A| / |Device 3| |
> +---------+ / |on bus B| |
> / +---------' +-|------+ |
> | | device 2| / +-------'+
> | | on Bus A| / |Device 4|
> \ +--|------+ _____/ |on bus B|
> \ \_____ / +--------+
> | .--\' /
> | / \ ___/
> +-'----'-+ +'------'+
> |Func X | |Func Y |
> |(Net) | |(Crypto)|
> +--------| +--------+
>
> So that means, a device would be a 'net' or 'crypto' device bases on the
> Functionality it attaches to.
>
> From a physical layout view, is that correct understanding of your argument?
>
>>
>> struct rte_pci_device {
>> struct rte_bus_device bus_dev;
>> /* generic pci bus */
>> }
>>
>> struct rte_vdev_device {
>> struct rte_bus_device bus_dev;
>> /* generic vdev bus */
>> }
>>
>> struct rte_funcional_device {
>> struct rte_device *dev;
>> }
>
> I understand your point of 'pluggable' functionality. It would be helpful if
> same driver would like to move between being a crypto and net. But is that a
> plausible use case for DPDK right now?
>
> To me, it seems as one more layer of redirection/abstraction.
>
> This is what the view I have as of now:
>
> __ rte_bus_list
> /
> +----------'---+
> |rte_bus |
> | driver_list |
> | device_list |
> | scan |
> | match |
> | remove |
> | ..some refcnt|
> +--|------|----+
> _________/ \_________
> +--------/----+ +-\--------------+
> |rte_device | |rte_driver |
> | rte_bus | | rte_bus |
> | flags (3*) | | probe (1*) |
> | init | | remove |
> | uninit | | ... |
> +---||--------+ | drv_flags |
> || | intr_handle(2*)|
> | \ +----------\\\---+
> | \_____________ \\\
> | \ |||
> +------|---------+ +----|----------+ |||
> |rte_pci_device | |rte_xxx_device | (4*) |||
> | PCI specific | | xxx device | |||
> | info (mem,) | | specific fns | / | \
> +----------------+ +---------------+ / | \
> _____________________/ / \
> / ___/ \
> +-------------'--+ +------------'---+ +--'------------+
> |rte_pci_driver | |rte_vdev_driver | |rte_xxx_driver |
> | PCI id table, | | <probably, | | .... |
> | other driver | | nothing> | +---------------+
> | data | +----------------+
> +----------------+
>
> (1*) Problem is that probe functions have different arguments. So,
> generalizing them might be some rework in the respective device
> layers
probe() is now done in bus level, right? pci_probe(), vdev_probe(), ...
And I guess, eth_dev and crypto_dev are created during probe(), how
probe() knows if to create eth_dev or crypto_dev?
> (2*) Interrupt handling for each driver type might be different. I am not
> sure how to generalize that either. This is grey area for me.
> (3*) Probably exposing a bitmask for device capabilities. Nothing similar
> exists now to relate it. Don't know if that is useful. Allowing
> applications to question a device about what it supports and what it
> doesn't - making it more flexible at application layer (but more code
> as well.)
> (4*) Even vdev would be an instantiated as a device. It is not being done
> currently.
I think it is good to add this to be consistent.
>
> So, unlike your model, rte_bus remains the topmost class which is neither a
> device, not a driver. It is just a class.
> Further, as specific information exists in each specific device and driver,
> that is not generalized.
>
<...>
>
> I am not against what you have stated. Creating a functional device is just
> one more layer of abstraction in my view. Mostly abstraction/classification
> makes life easier for applications to visualize underlying hierarchy. If this
> serves a purpose, I am OK with that. At least right now, I think it would
> only end up being like eth_driver which is just a holder.
I agree with you, mine was more like a brain exercise, may have gaps and
I need to think more, thanks for your comments.
Thanks,
ferruh
^ permalink raw reply
* Re: Running 2 process on the same machine
From: Bruce Richardson @ 2016-11-14 15:44 UTC (permalink / raw)
To: Keren Hochman; +Cc: Wiles, Keith, dev@dpdk.org
In-Reply-To: <CAJq3SQ50kKbdVkdzFk5UiDVEaUWaHJpgNAQHPnKCBAeKNwLiEQ@mail.gmail.com>
On Tue, Nov 08, 2016 at 02:02:32PM +0200, Keren Hochman wrote:
> Also, I can't understand how to define socket-mem. I did not see anything
> related to hugepages in /etc/sysctl.conf. Can i mount hugepages to 2
> different dirs instead and use --huge-dir ?
> Thank you.
>
Doing so would be a replacement for using the --file-prefix option,
because even with two different hugepage mount points all pages can be
used via each one, meaning the first process can still use all hugepage
memory. The only exception to this that I know of is if the two mountpoints
are for two different sizes of hugepages.
With regards to the process failing if you use the --no-huge option: did
you try running with --no-huge and a -m or --socket-mem option? By
default, I think the --no-huge option only allocates a relatively small
amount of memory for DPDK use. Try "--no-huge -m 2048" and see if that
helps.
Regards,
/Bruce
^ permalink raw reply
* Re: pmdinfogen issues: cross compilation for ARM fails with older host compiler
From: Neil Horman @ 2016-11-14 14:48 UTC (permalink / raw)
To: Jerin Jacob
Cc: Hemant Agrawal, dev@dpdk.org, users@dpdk.org, Jacob, Jerin,
Jan Viktorin
In-Reply-To: <20161113205924.GA11392@localhost.localdomain>
On Mon, Nov 14, 2016 at 02:29:24AM +0530, Jerin Jacob wrote:
> On Fri, Nov 11, 2016 at 10:34:39AM +0000, Hemant Agrawal wrote:
> > 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?
>
> IMO, It is a HOST build infrastructure issue. If a host app is using the
> dpdk service then it should compile and link against HOST target(in this
> specific case, build/x86_64-native-linuxapp-gcc). I think, introducing the
> HOSTTARGET kind of scheme is a clean solution.
>
> /Jerin
>
>
That would be accurate. That is to say, pmdinfogen is a tool that should only
be run on the host doing the build, by the host doing the build, and so should
be compiled to run on the host, not on the target being built for.
Yeah, so what we need is a way to get to the host version of rte_byteorder.h
when building in a cross environment
Neil
^ permalink raw reply
* Re: [PATCH v1] doc: add template release notes for 17.02
From: Thomas Monjalon @ 2016-11-14 14:19 UTC (permalink / raw)
To: John McNamara; +Cc: dev, Remy Horton
In-Reply-To: <aead5c8b-c3b8-fdef-6209-d811bdfb84b8@intel.com>
> > Add template release notes for DPDK 17.02 with inline
> > comments and explanations of the various sections.
> >
> > Signed-off-by: John McNamara <john.mcnamara@intel.com>
>
> Acked-by: Remy Horton <remy.horton@intel.com>
Applied, thanks
We are ready to start a new release cycle.
The version in the master branch is now 17.02-rc0.
^ permalink raw reply
* Re: [PATCH v2] doc: add sub-repositories information
From: Thomas Monjalon @ 2016-11-14 14:10 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, John McNamara, Pablo de Lara, Yuanhan Liu
In-Reply-To: <20161111133417.3894-1-ferruh.yigit@intel.com>
2016-11-11 13:34, Ferruh Yigit:
> 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>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] maintainers: add staging tree for network drivers
From: Thomas Monjalon @ 2016-11-14 14:04 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, Bruce Richardson
In-Reply-To: <1986049.tQAIGLVUYf@xps13>
> > Networking Drivers
> > ------------------
> > +M: Ferruh Yigit <ferruh.yigit@intel.com>
> > +T: git://dpdk.org/next/dpdk-next-net
>
> Acked-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>
> It will be applied at the beginning of 17.02 cycle to reflect the change.
Applied, thanks.
So from now, Ferruh will be responsible of the next-net tree.
Thank you for your commitment.
^ permalink raw reply
* Re: [PATCH v1] doc: add template release notes for 17.02
From: Remy Horton @ 2016-11-14 13:50 UTC (permalink / raw)
To: John McNamara, dev
In-Reply-To: <1479126698-11316-1-git-send-email-john.mcnamara@intel.com>
On 14/11/2016 20:31, John McNamara wrote:
> Add template release notes for DPDK 17.02 with inline
> comments and explanations of the various sections.
>
> Signed-off-by: John McNamara <john.mcnamara@intel.com>
Acked-by: Remy Horton <remy.horton@intel.com>
^ permalink raw reply
* [PATCH v1] doc: add template release notes for 17.02
From: John McNamara @ 2016-11-14 12:31 UTC (permalink / raw)
To: dev; +Cc: John McNamara
Add template release notes for DPDK 17.02 with inline
comments and explanations of the various sections.
Signed-off-by: John McNamara <john.mcnamara@intel.com>
---
doc/guides/rel_notes/index.rst | 1 +
doc/guides/rel_notes/release_17_02.rst | 223 +++++++++++++++++++++++++++++++++
2 files changed, 224 insertions(+)
create mode 100644 doc/guides/rel_notes/release_17_02.rst
diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst
index 7e51b2c..cf8f167 100644
--- a/doc/guides/rel_notes/index.rst
+++ b/doc/guides/rel_notes/index.rst
@@ -36,6 +36,7 @@ Release Notes
:numbered:
rel_description
+ release_17_02
release_16_11
release_16_07
release_16_04
diff --git a/doc/guides/rel_notes/release_17_02.rst b/doc/guides/rel_notes/release_17_02.rst
new file mode 100644
index 0000000..d251752
--- /dev/null
+++ b/doc/guides/rel_notes/release_17_02.rst
@@ -0,0 +1,223 @@
+DPDK Release 17.02
+==================
+
+.. **Read this first.**
+
+ The text below explains how to update the release notes.
+
+ Use proper spelling, capitalization and punctuation in all sections.
+
+ Variable and config names should be quoted as fixed width text: ``LIKE_THIS``.
+
+ Build the docs and view the output file to ensure the changes are correct::
+
+ make doc-guides-html
+
+ firefox build/doc/html/guides/rel_notes/release_17_02.html
+
+
+New Features
+------------
+
+.. This section should contain new features added in this release. Sample format:
+
+ * **Add a title in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description in the past tense. The description
+ should be enough to allow someone scanning the release notes to understand
+ the new feature.
+
+ If the feature adds a lot of sub-features you can use a bullet list like this.
+
+ * Added feature foo to do something.
+ * Enhanced feature bar to do something else.
+
+ Refer to the previous release notes for examples.
+
+ This section is a comment. do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+Resolved Issues
+---------------
+
+.. This section should contain bug fixes added to the relevant sections. Sample format:
+
+ * **code/section Fixed issue in the past tense with a full stop.**
+
+ Add a short 1-2 sentence description of the resolved issue in the past tense.
+ The title should contain the code/lib section like a commit message.
+ Add the entries in alphabetic order in the relevant sections below.
+
+ This section is a comment. do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+EAL
+~~~
+
+
+Drivers
+~~~~~~~
+
+
+Libraries
+~~~~~~~~~
+
+
+Examples
+~~~~~~~~
+
+
+Other
+~~~~~
+
+
+Known Issues
+------------
+
+.. This section should contain new known issues in this release. Sample format:
+
+ * **Add title in present tense with full stop.**
+
+ Add a short 1-2 sentence description of the known issue in the present
+ tense. Add information on any known workarounds.
+
+ This section is a comment. do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+API Changes
+-----------
+
+.. This section should contain API changes. Sample format:
+
+ * Add a short 1-2 sentence description of the API change. Use fixed width
+ quotes for ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+
+ This section is a comment. do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+ABI Changes
+-----------
+
+.. This section should contain ABI changes. Sample format:
+
+ * Add a short 1-2 sentence description of the ABI change that was announced in
+ the previous releases and made in this release. Use fixed width quotes for
+ ``rte_function_names`` or ``rte_struct_names``. Use the past tense.
+
+ This section is a comment. do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+
+Shared Library Versions
+-----------------------
+
+.. Update any library version updated in this release and prepend with a ``+``
+ sign, like this:
+
+ librte_acl.so.2
+ + librte_cfgfile.so.2
+ librte_cmdline.so.2
+
+ This section is a comment. do not overwrite or remove it.
+ =========================================================
+
+
+The libraries prepended with a plus sign were incremented in this version.
+
+.. code-block:: diff
+
+ librte_acl.so.2
+ librte_cfgfile.so.2
+ librte_cmdline.so.2
+ librte_cryptodev.so.2
+ librte_distributor.so.1
+ librte_eal.so.3
+ librte_ethdev.so.5
+ librte_hash.so.2
+ librte_ip_frag.so.1
+ librte_jobstats.so.1
+ librte_kni.so.2
+ librte_kvargs.so.1
+ librte_lpm.so.2
+ librte_mbuf.so.2
+ librte_mempool.so.2
+ librte_meter.so.1
+ librte_net.so.1
+ librte_pdump.so.1
+ librte_pipeline.so.3
+ librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
+ librte_port.so.3
+ librte_power.so.1
+ librte_reorder.so.1
+ librte_ring.so.1
+ librte_sched.so.1
+ librte_table.so.2
+ librte_timer.so.1
+ librte_vhost.so.3
+
+
+Tested Platforms
+----------------
+
+.. This section should contain a list of platforms that were tested with this release.
+
+ The format is:
+
+ #. Platform name.
+
+ * Platform details.
+ * Platform details.
+
+ This section is a comment. do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+Tested NICs
+-----------
+
+.. This section should contain a list of NICs that were tested with this release.
+
+ The format is:
+
+ #. NIC name.
+
+ * NIC details.
+ * NIC details.
+
+ This section is a comment. do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
+
+
+Tested OSes
+-----------
+
+.. This section should contain a list of OSes that were tested with this release.
+ The format is as follows, in alphabetical order:
+
+ * CentOS 7.0
+ * Fedora 23
+ * Fedora 24
+ * FreeBSD 10.3
+ * Red Hat Enterprise Linux 7.2
+ * SUSE Enterprise Linux 12
+ * Ubuntu 15.10
+ * Ubuntu 16.04 LTS
+ * Wind River Linux 8
+
+ This section is a comment. do not overwrite or remove it.
+ Also, make sure to start the actual text at the margin.
+ =========================================================
--
2.7.4
^ permalink raw reply related
* [PATCH] vmxnet3: fix Rx deadlock
From: Stefan Puiu @ 2016-11-14 10:46 UTC (permalink / raw)
To: dev; +Cc: mac_leehk, yongwang, Stefan Puiu
Our use case is that we have an app that needs to keep mbufs around
for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
descriptors (where it returns -err). Since there are no mbufs that the
virtual hardware can use, and since nobody calls
vmxnet3_post_rx_bufs() after that, no packets will be received after
this. I call this a deadlock for lack of a better term - the virtual
HW waits for free mbufs, while the app waits for the hardware to
notify it for data. Note that after this, the app can't recover.
This fix is a rework of this patch by Marco Lee:
http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port it,
address review comments and also reverted the allocation failure
handing to the first version of the patch
(http://dpdk.org/ml/archives/dev/2015-July/022079.html), since that's
the only approach that seems to work, and seems to be what other
drivers are doing (I checked ixgbe and em). Reusing the mbuf that's
getting passed to the application doesn't seem to make sense, and it
was causing weird issues in our app. Also, reusing rxm without
checking if it's NULL could cause the code to crash.
Signed-off-by: Stefan Puiu <stefan.puiu@gmail.com>
---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 38 ++++++++++++++++++++++++++++++++++++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index b109168..c9d2488 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -518,6 +518,32 @@
return nb_tx;
}
+static inline void
+vmxnet3_renew_desc(vmxnet3_rx_queue_t *rxq, uint8_t ring_id,
+ struct rte_mbuf *mbuf)
+{
+ uint32_t val = 0;
+ struct vmxnet3_cmd_ring *ring = &rxq->cmd_ring[ring_id];
+ struct Vmxnet3_RxDesc *rxd =
+ (struct Vmxnet3_RxDesc *)(ring->base + ring->next2fill);
+ vmxnet3_buf_info_t *buf_info = &ring->buf_info[ring->next2fill];
+
+ if (ring_id == 0)
+ val = VMXNET3_RXD_BTYPE_HEAD;
+ else
+ val = VMXNET3_RXD_BTYPE_BODY;
+
+ buf_info->m = mbuf;
+ buf_info->len = (uint16_t)(mbuf->buf_len - RTE_PKTMBUF_HEADROOM);
+ buf_info->bufPA = rte_mbuf_data_dma_addr_default(mbuf);
+
+ rxd->addr = buf_info->bufPA;
+ rxd->btype = val;
+ rxd->len = buf_info->len;
+ rxd->gen = ring->gen;
+
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+}
/*
* Allocates mbufs and clusters. Post rx descriptors with buffer details
* so that device can receive packets in those buffers.
@@ -657,9 +683,17 @@
}
while (rcd->gen == rxq->comp_ring.gen) {
+ struct rte_mbuf *newm;
if (nb_rx >= nb_pkts)
break;
+ newm = rte_mbuf_raw_alloc(rxq->mp);
+ if (unlikely(newm == NULL)) {
+ PMD_RX_LOG(ERR, "Error allocating mbuf");
+ rxq->stats.rx_buf_alloc_failure++;
+ break;
+ }
+
idx = rcd->rxdIdx;
ring_idx = (uint8_t)((rcd->rqID == rxq->qid1) ? 0 : 1);
rxd = (Vmxnet3_RxDesc *)rxq->cmd_ring[ring_idx].base + idx;
@@ -759,8 +793,8 @@
VMXNET3_INC_RING_IDX_ONLY(rxq->cmd_ring[ring_idx].next2comp,
rxq->cmd_ring[ring_idx].size);
- /* It's time to allocate some new buf and renew descriptors */
- vmxnet3_post_rx_bufs(rxq, ring_idx);
+ /* It's time to renew descriptors */
+ vmxnet3_renew_desc(rxq, ring_idx, newm);
if (unlikely(rxq->shared->ctrl.updateRxProd)) {
VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] + (rxq->queue_id * VMXNET3_REG_ALIGN),
rxq->cmd_ring[ring_idx].next2fill);
--
1.9.1
^ permalink raw reply related
* [PATCH] vmxnet3: fix Rx deadlock
From: Stefan Puiu @ 2016-11-14 10:40 UTC (permalink / raw)
To: dev; +Cc: mac_leehk, yongwang, Stefan Puiu
Our use case is that we have an app that needs to keep mbufs around
for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
descriptors (where it returns -err). Since there are no mbufs that the
virtual hardware can use, and since nobody calls
vmxnet3_post_rx_bufs() after that, no packets will be received after
this. I call this a deadlock for lack of a better term - the virtual
HW waits for free mbufs, while the app waits for the hardware to
notify it for data. Note that after this, the app can't recover.
This fix is a rework of this patch by Marco Lee:
http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port it,
address review comments and also reverted the allocation failure
handing to the first version of the patch
(http://dpdk.org/ml/archives/dev/2015-July/022079.html), since that's
the only approach that seems to work, and seems to be what other
drivers are doing (I checked ixgbe and em). Reusing the mbuf that's
getting passed to the application doesn't seem to make sense, and it
was causing weird issues in our app. Also, reusing rxm without
checking if it's NULL could cause the code to crash.
---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 38 ++++++++++++++++++++++++++++++++++++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index b109168..c9d2488 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -518,6 +518,32 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
return nb_tx;
}
+static inline void
+vmxnet3_renew_desc(vmxnet3_rx_queue_t *rxq, uint8_t ring_id,
+ struct rte_mbuf *mbuf)
+{
+ uint32_t val = 0;
+ struct vmxnet3_cmd_ring *ring = &rxq->cmd_ring[ring_id];
+ struct Vmxnet3_RxDesc *rxd =
+ (struct Vmxnet3_RxDesc *)(ring->base + ring->next2fill);
+ vmxnet3_buf_info_t *buf_info = &ring->buf_info[ring->next2fill];
+
+ if (ring_id == 0)
+ val = VMXNET3_RXD_BTYPE_HEAD;
+ else
+ val = VMXNET3_RXD_BTYPE_BODY;
+
+ buf_info->m = mbuf;
+ buf_info->len = (uint16_t)(mbuf->buf_len - RTE_PKTMBUF_HEADROOM);
+ buf_info->bufPA = rte_mbuf_data_dma_addr_default(mbuf);
+
+ rxd->addr = buf_info->bufPA;
+ rxd->btype = val;
+ rxd->len = buf_info->len;
+ rxd->gen = ring->gen;
+
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+}
/*
* Allocates mbufs and clusters. Post rx descriptors with buffer details
* so that device can receive packets in those buffers.
@@ -657,9 +683,17 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
}
while (rcd->gen == rxq->comp_ring.gen) {
+ struct rte_mbuf *newm;
if (nb_rx >= nb_pkts)
break;
+ newm = rte_mbuf_raw_alloc(rxq->mp);
+ if (unlikely(newm == NULL)) {
+ PMD_RX_LOG(ERR, "Error allocating mbuf");
+ rxq->stats.rx_buf_alloc_failure++;
+ break;
+ }
+
idx = rcd->rxdIdx;
ring_idx = (uint8_t)((rcd->rqID == rxq->qid1) ? 0 : 1);
rxd = (Vmxnet3_RxDesc *)rxq->cmd_ring[ring_idx].base + idx;
@@ -759,8 +793,8 @@ rcd_done:
VMXNET3_INC_RING_IDX_ONLY(rxq->cmd_ring[ring_idx].next2comp,
rxq->cmd_ring[ring_idx].size);
- /* It's time to allocate some new buf and renew descriptors */
- vmxnet3_post_rx_bufs(rxq, ring_idx);
+ /* It's time to renew descriptors */
+ vmxnet3_renew_desc(rxq, ring_idx, newm);
if (unlikely(rxq->shared->ctrl.updateRxProd)) {
VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] + (rxq->queue_id * VMXNET3_REG_ALIGN),
rxq->cmd_ring[ring_idx].next2fill);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] lib/librte_mempool: a redundant word in comment
From: Mcnamara, John @ 2016-11-14 10:29 UTC (permalink / raw)
To: Zhao1, Wei, dev@dpdk.org; +Cc: olivier.matz@6wind.com, Zhao1, Wei
In-Reply-To: <1479091635-4288-1-git-send-email-wei.zhao1@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wei Zhao
> Sent: Monday, November 14, 2016 2:47 AM
> To: dev@dpdk.org
> Cc: olivier.matz@6wind.com; Zhao1, Wei <wei.zhao1@intel.com>
> Subject: [dpdk-dev] [PATCH] lib/librte_mempool: a redundant word in
> comment
>
> From: zhao wei <wei.zhao1@intel.com>
I think you need to add your name to gitconfig file on the sending machine
to avoid this "From:"
>
> There is a redundant repetition word "for" in commnet line the file
> rte_mempool.h after the definition of RTE_MEMPOOL_OPS_NAMESIZE.
> The word "for"appear twice in line 359 and 360.One of them is redundant,
> so delete it.
>
> Fixes: 449c49b93a6b ("lib/librte_mempool: mempool: support handler
> operations")
>
> Signed-off-by: zhao wei <wei.zhao1@intel.com>
/commnet/comment/
And same comment as before about the title. Apart from that:
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: XL710 with DELOCK 86256 qsfp+
From: Nagaprabhanjan Bellaru @ 2016-11-14 10:26 UTC (permalink / raw)
To: dev
In-Reply-To: <CABDVJk_1VOkBsLUCU2NYt3BSRU7Mi3+O6MknP-pHe=8ZPdb9MQ@mail.gmail.com>
I just upgraded the XL710 cards with "FW 5.0 API 1.5 NVM 05.00.04 eetrack
80002505" firmware which, I believe, is the latest.
Thanks,
-nagp
On Mon, Nov 14, 2016 at 3:49 PM, Nagaprabhanjan Bellaru <
nagp.lists@gmail.com> wrote:
> Though the ports of XL710 are getting detected by DPDK, when I insert the
> above QSFP twinax cable and try to bring up the port, I get a "Operation
> not supported" error. When I looked further, I see that trying to bring up
> the port is resulting in I40E_AQ_RC_EIO and returning I40E_ERR_UNKNOWN_PHY.
>
> Can somebody help me in understanding whether this is a genuine error?
>
> Thanks,
> -nagp
>
^ permalink raw reply
* Re: [PATCH] lib/librte_mempool: a redundant of socket_id assignment
From: Mcnamara, John @ 2016-11-14 10:25 UTC (permalink / raw)
To: Zhao1, Wei, dev@dpdk.org; +Cc: olivier.matz@6wind.com, Zhao1, Wei
In-Reply-To: <1479089737-1966-1-git-send-email-wei.zhao1@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wei Zhao
> Sent: Monday, November 14, 2016 2:16 AM
> To: dev@dpdk.org
> Cc: olivier.matz@6wind.com; Zhao1, Wei <wei.zhao1@intel.com>
> Subject: [dpdk-dev] [PATCH] lib/librte_mempool: a redundant of socket_id
> assignment
>
> From: zhao wei <wei.zhao1@intel.com>
>
> There is a redundant repetition mempool socket_id assignment in the file
> rte_mempool.c in function rte_mempool_create_empty.The statement "mp-
> >socket_id = socket_id;"appear twice in line 821 and 824.One of them is
> redundant, so delete it.
>
> Fixes: 85226f9c526b ("lib/librte_mempool: mempool:introduce a function to
> create an empty pool")
>
> Signed-off-by: zhao wei <wei.zhao1@intel.com>
Titles should generally start with a verb to indicate what is being done.
Something like:
lib/librte_mempool: remove redundant socket_id assignment
Apart from that.
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* XL710 with DELOCK 86256 qsfp+
From: Nagaprabhanjan Bellaru @ 2016-11-14 10:19 UTC (permalink / raw)
To: dev
Though the ports of XL710 are getting detected by DPDK, when I insert the
above QSFP twinax cable and try to bring up the port, I get a "Operation
not supported" error. When I looked further, I see that trying to bring up
the port is resulting in I40E_AQ_RC_EIO and returning I40E_ERR_UNKNOWN_PHY.
Can somebody help me in understanding whether this is a genuine error?
Thanks,
-nagp
^ permalink raw reply
* Re: Clarification for eth_driver changes
From: David Marchand @ 2016-11-14 9:07 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: Shreyansh Jain, dev@dpdk.org
In-Reply-To: <1a19615c-1121-fed4-b34f-aa0f4b654085@intel.com>
On Fri, Nov 11, 2016 at 8:16 PM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On 11/10/2016 11:05 AM, Shreyansh Jain wrote:
>> On Thursday 10 November 2016 01:46 PM, David Marchand wrote:
>>> Do we really need to keep a eth_driver ?
>>
>> No. As you have rightly mentioned below (as well as in your Jan'16
>> post), it is a mere convenience.
>
> Isn't it good to separate the logic related which bus device connected
> and what functionality it provides. Because these two can be flexible:
>
> device -> virtual_bus -> ethernet_functionality
> device -> pci_bus -> crypto_functionality
> device -> x_bus -> y_function
"a device is linked to a bus" (fine)
"a bus knows what a device does" (?!)
Not sure I follow you.
--
David Marchand
^ permalink raw reply
* Re: [PATCH 2/2] net: align ethdev and eal driver names
From: David Marchand @ 2016-11-14 8:41 UTC (permalink / raw)
To: Ferruh Yigit
Cc: Thomas Monjalon, dev@dpdk.org, John Linville, Declan Doherty, zlu,
lsun, Alejandro.Lucero, mtetsuyah, nicolas.pernas.maradei,
Harish Patil, Rasesh Mody, Sony Chacko, Richardson, Bruce,
Xie, Huawei, Yuanhan Liu, Tan Jianfeng
In-Reply-To: <9fcfff29-fc8f-b61b-dc72-0763fe559556@intel.com>
Hello Ferruh,
On Thu, Nov 10, 2016 at 7:46 PM, Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> On 11/10/2016 1:51 PM, David Marchand wrote:
>> Some virtual pmds report a different name than the vdev driver name
>> registered in eal.
>> While it does not hurt, let's try to be consistent.
>>
>> Signed-off-by: David Marchand <david.marchand@6wind.com>
>> ---
>
> Since you did all the work, instead of second patch what do you think
> doing something like [1] (basically adding eth_dev->rte_driver link) and
> when done for all vdevs, remove eth_dev->data->drv_name completely?
Hum, in the end, it is better to wait for Shreyansh 17.02 patches.
Either I will rebase this patchset, or it won't be necessary anymore.
--
David Marchand
^ permalink raw reply
* Re: two different threads polls the same port, different queues, why the throughput is the same
From: 张伟 @ 2016-11-14 6:34 UTC (permalink / raw)
To: Kyle Larose; +Cc: dev
In-Reply-To: <CAMFWN9=sA9v3-PwC_WnSdRYSNnR=Pe-k9PeMib2enwr-9bPh5A@mail.gmail.com>
I do not have any lock/critical sections in my code.
I have logs to print out the core id, src port, dst port and queue id. worker 0 runs on core 1, run macswap very light, the throughput is 4.5Mpps. worker 1 runs on core2, is a load balancer heavy, the throughput is also 4.5Mpps. This does not make sense at all.
***thread core_id=1, src_port=0, dst_port=0, rx_queue_id=0, tx_queue_id=0
***thread core_id=2, src_port=0, dst_port=0, rx_queue_id=1, tx_queue_id=1
Core 0: Running stat thread
worker_id=0, core_id=1, pkt_rate=4418972
worker_id=1, core_id=2, pkt_rate=4419808
worker_id=0, core_id=1, pkt_rate=4631684
worker_id=1, core_id=2, pkt_rate=4632928
At 2016-11-14 14:13:25, "Kyle Larose" <eomereadig@gmail.com> wrote:
>On Mon, Nov 14, 2016 at 2:28 PM, 张伟 <zhangwqh@126.com> wrote:
>> Hi all,
>>
>>
>> I have two threads process the packets with different ways. thread A (core 0) is very heavy, thread B (core 1) is very light. If I just run each of them, their throughput is huge different with small packet. Thread A polls queue 0 of port 0, thread B polls queue 1 of port 0. If I run them at the same time, why thread A and thread B get same throughput. This makes me very confused. Does anyone have the same experience or know some possible reasons?
>>
>
>Can you give some examples with numbers? My first thought is that
>maybe the two threads are contending for the same physical core. You
>don't have any locking/critical sections, do you?
>>
>> Thanks,
>> wei
^ permalink raw reply
* [PATCH v1 2/2] net/i40e: fix spelling errors
From: Remy Horton @ 2016-11-14 6:14 UTC (permalink / raw)
To: dev; +Cc: Helin Zhang, Jingjing Wu
In-Reply-To: <1479104089-27862-1-git-send-email-remy.horton@intel.com>
Fixes: da61cd084976 ("i40evf: add extended stats")
Fixes: 0eedec25ea36 ("i40e: clean log messages")
Signed-off-by: Remy Horton <remy.horton@intel.com>
---
drivers/net/i40e/i40e_ethdev.c | 2 +-
drivers/net/i40e/i40e_ethdev_vf.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 67778ba..f102328 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -4107,7 +4107,7 @@ i40e_veb_setup(struct i40e_pf *pf, struct i40e_vsi *vsi)
ret = i40e_aq_get_veb_parameters(hw, veb->seid, NULL, NULL,
&veb->stats_idx, NULL, NULL, NULL);
if (ret != I40E_SUCCESS) {
- PMD_DRV_LOG(ERR, "Get veb statics index failed, aq_err: %d",
+ PMD_DRV_LOG(ERR, "Get veb statistics index failed, aq_err: %d",
hw->aq.asq_last_status);
goto fail;
}
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index afae2ec..1431b6e 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -952,7 +952,7 @@ i40evf_update_stats(struct rte_eth_dev *dev, struct i40e_eth_stats **pstats)
}
static int
-i40evf_get_statics(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
+i40evf_get_statistics(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
{
int ret;
struct i40e_eth_stats *pstats = NULL;
@@ -2277,8 +2277,8 @@ i40evf_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
static void
i40evf_dev_stats_get(struct rte_eth_dev *dev, struct rte_eth_stats *stats)
{
- if (i40evf_get_statics(dev, stats))
- PMD_DRV_LOG(ERR, "Get statics failed");
+ if (i40evf_get_statistics(dev, stats))
+ PMD_DRV_LOG(ERR, "Get statistics failed");
}
static void
--
2.5.5
^ permalink raw reply related
* [PATCH v1 1/2] net/i40e: fix incorrect xstats value mapping
From: Remy Horton @ 2016-11-14 6:14 UTC (permalink / raw)
To: dev; +Cc: Helin Zhang, Jingjing Wu
In-Reply-To: <1479104089-27862-1-git-send-email-remy.horton@intel.com>
The offsets used in rte_i40evf_stats_strings for transmission
statistics were wrong, returning the total byte count rather than
the respective (unicast, multicast, broadcast, drop, & error)
packet counts.
Fixes: da61cd084976 ("i40evf: add extended stats")
Signed-off-by: Remy Horton <remy.horton@intel.com>
---
drivers/net/i40e/i40e_ethdev_vf.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev_vf.c b/drivers/net/i40e/i40e_ethdev_vf.c
index aa306d6..afae2ec 100644
--- a/drivers/net/i40e/i40e_ethdev_vf.c
+++ b/drivers/net/i40e/i40e_ethdev_vf.c
@@ -176,11 +176,11 @@ static const struct rte_i40evf_xstats_name_off rte_i40evf_stats_strings[] = {
{"rx_unknown_protocol_packets", offsetof(struct i40e_eth_stats,
rx_unknown_protocol)},
{"tx_bytes", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_unicast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_multicast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_broadcast_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_dropped_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
- {"tx_error_packets", offsetof(struct i40e_eth_stats, tx_bytes)},
+ {"tx_unicast_packets", offsetof(struct i40e_eth_stats, tx_unicast)},
+ {"tx_multicast_packets", offsetof(struct i40e_eth_stats, tx_multicast)},
+ {"tx_broadcast_packets", offsetof(struct i40e_eth_stats, tx_broadcast)},
+ {"tx_dropped_packets", offsetof(struct i40e_eth_stats, tx_discards)},
+ {"tx_error_packets", offsetof(struct i40e_eth_stats, tx_errors)},
};
#define I40EVF_NB_XSTATS (sizeof(rte_i40evf_stats_strings) / \
--
2.5.5
^ permalink raw reply related
* [PATCH v1 0/2] XStats fixes
From: Remy Horton @ 2016-11-14 6:14 UTC (permalink / raw)
To: dev; +Cc: Helin Zhang, Jingjing Wu
The offsets used in rte_i40evf_stats_strings for transmission
statistics were wrong, returning the total byte count rather than
the respective (unicast, multicast, broadcast, drop, & error)
packet counts.
This patchset also fixes some spelling errors.
Fixes: da61cd084976 ("i40evf: add extended stats")
Fixes: 0eedec25ea36 ("i40e: clean log messages")
Remy Horton (2):
net/i40e: fix incorrect xstats value mapping
net/i40e: fix spelling errors
drivers/net/i40e/i40e_ethdev.c | 2 +-
drivers/net/i40e/i40e_ethdev_vf.c | 16 ++++++++--------
2 files changed, 9 insertions(+), 9 deletions(-)
--
2.5.5
^ permalink raw reply
* Re: two different threads polls the same port, different queues, why the throughput is the same
From: Kyle Larose @ 2016-11-14 6:13 UTC (permalink / raw)
To: 张伟; +Cc: dev
In-Reply-To: <6a6fff02.604d.158614ef009.Coremail.zhangwqh@126.com>
On Mon, Nov 14, 2016 at 2:28 PM, 张伟 <zhangwqh@126.com> wrote:
> Hi all,
>
>
> I have two threads process the packets with different ways. thread A (core 0) is very heavy, thread B (core 1) is very light. If I just run each of them, their throughput is huge different with small packet. Thread A polls queue 0 of port 0, thread B polls queue 1 of port 0. If I run them at the same time, why thread A and thread B get same throughput. This makes me very confused. Does anyone have the same experience or know some possible reasons?
>
Can you give some examples with numbers? My first thought is that
maybe the two threads are contending for the same physical core. You
don't have any locking/critical sections, do you?
>
> Thanks,
> wei
^ permalink raw reply
* two different threads polls the same port, different queues, why the throughput is the same
From: 张伟 @ 2016-11-14 5:28 UTC (permalink / raw)
To: dev
Hi all,
I have two threads process the packets with different ways. thread A (core 0) is very heavy, thread B (core 1) is very light. If I just run each of them, their throughput is huge different with small packet. Thread A polls queue 0 of port 0, thread B polls queue 1 of port 0. If I run them at the same time, why thread A and thread B get same throughput. This makes me very confused. Does anyone have the same experience or know some possible reasons?
Thanks,
wei
^ permalink raw reply
* [PATCH] lib/librte_mempool: a redundant word in comment
From: Wei Zhao @ 2016-11-14 2:47 UTC (permalink / raw)
To: dev; +Cc: olivier.matz, zhao wei
From: zhao wei <wei.zhao1@intel.com>
There is a redundant repetition word "for" in commnet line the
file rte_mempool.h after the definition of RTE_MEMPOOL_OPS_NAMESIZE.
The word "for"appear twice in line 359 and 360.One of them is
redundant, so delete it.
Fixes: 449c49b93a6b ("lib/librte_mempool: mempool: support handler
operations")
Signed-off-by: zhao wei <wei.zhao1@intel.com>
---
lib/librte_mempool/rte_mempool.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_mempool/rte_mempool.h
index 440f3b1..911102b 100644
--- a/lib/librte_mempool/rte_mempool.h
+++ b/lib/librte_mempool/rte_mempool.h
@@ -357,7 +357,7 @@ void rte_mempool_check_cookies(const struct rte_mempool *mp,
* Prototype for implementation specific data provisioning function.
*
* The function should provide the implementation specific memory for
- * for use by the other mempool ops functions in a given mempool ops struct.
+ * use by the other mempool ops functions in a given mempool ops struct.
* E.g. the default ops provides an instance of the rte_ring for this purpose.
* it will most likely point to a different type of data structure, and
* will be transparent to the application programmer.
--
2.5.5
^ permalink raw reply related
* [PATCH] lib/librte_mempool: a redundant of socket_id assignment
From: Wei Zhao @ 2016-11-14 2:15 UTC (permalink / raw)
To: dev; +Cc: olivier.matz, zhao wei
From: zhao wei <wei.zhao1@intel.com>
There is a redundant repetition mempool socket_id assignment in the
file rte_mempool.c in function rte_mempool_create_empty.The
statement "mp->socket_id = socket_id;"appear twice in line 821
and 824.One of them is redundant, so delete it.
Fixes: 85226f9c526b ("lib/librte_mempool: mempool:introduce
a function to create an empty pool")
Signed-off-by: zhao wei <wei.zhao1@intel.com>
---
lib/librte_mempool/rte_mempool.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index aa513b9..1c2aed8 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -818,7 +818,6 @@ rte_mempool_create_empty(const char *name, unsigned n, unsigned elt_size,
goto exit_unlock;
}
mp->mz = mz;
- mp->socket_id = socket_id;
mp->size = n;
mp->flags = flags;
mp->socket_id = socket_id;
--
2.5.5
^ permalink raw reply related
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