* 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
* [PATCH] mempool: Free memzone if mempool populate phys fails
From: Hemant Agrawal @ 2016-11-11 14:42 UTC (permalink / raw)
To: olivier.matz; +Cc: dev, Nipun Gupta
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>
---
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
* [xen][dpdk][question] Does dpdk support xenserver 7.0 now?
From: Ethan Lynn @ 2016-11-11 7:08 UTC (permalink / raw)
To: dev
Hi,
I’m not sure if this is the right mailing list to ask this question, if not, please let me know.
I try to compile dpdk-2.2.0 and dpdk-16.07.1 on xenserver, compilation finished, but I got error when using command `insmod rte_dom0_mm.ko`.
insmod: ERROR: could not insert module ./rte_dom0_mm.ko: No such device
I’m not sure if there’s some special configuration I was missing or DPDK doesn’t support xenserver 7.0 yet.
Best Regards,
Ethan Lynn
xuanlangjian@gmail.com
^ permalink raw reply
* Re: [PATCH v7 11/21] eal/soc: implement probing of drivers
From: Shreyansh Jain @ 2016-11-11 6:04 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Jianbo Liu, dev, Jan Viktorin, david.marchand
In-Reply-To: <1506578.S1InCtPeL4@xps13>
On Thursday 10 November 2016 02:56 PM, Thomas Monjalon wrote:
> 2016-11-10 14:40, Shreyansh Jain:
>> On Thursday 10 November 2016 01:11 PM, Jianbo Liu wrote:
>>> On 10 November 2016 at 14:10, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>>>> On Thursday 10 November 2016 09:00 AM, Jianbo Liu wrote:
>>>>> I'm still not sure about the purpose of soc_scan, and how to use it.
>>>>
>>>>
>>>> For each device to be used by DPDK, which cannot be scanned/identified using
>>>> the existing PCI/VDEV methods (sysfs/bus/pci), 'soc_scan_t' provides a way
>>>> for driver to make those devices part of device lists.
>>>>
>>>> Ideally, 'scan' is not a function of a driver. It is a bus function - which
>>>> is missing in this case.
>>>>
>>>>> If it's for each driver, it should at least struct rte_soc_driver * as
>>>>> its parameter.
>>>>
>>>>
>>>> Its for each driver - assuming that each non-PCI driver which implements it
>>>> knows how to find devices which it can control (for example, special area in
>>>> sysfs, or even platform bus).
>>>>
>>>
>>> Considering there are several drivers in a platform bus, each driver
>>> call the scan function, like the rte_eal_soc_scan_platform_bus() you
>>> implemented.
>>> The first will add soc devices to the list, but the remaining calls
>>> are redundant.
>>
>> Indeed. This is exactly the issue we will face if we try and move this
>> scan/match logic to PCI - all devices are identified in one step.
>>
>> There is a difference in principle here:
>> A SoC device/driver combination is essentially focused towards a single
>> type of bus<->devices. For example, a NXP PMD would implement a scan
>> function which would scan for all devices on NXP's bus. This would not
>> conflict with another XYZ SoC PMD which scans its specific bus.
>>
>> There is caveat to this - the platform bus. There can be multiple
>> drivers which can serve platform bus compliant devices. First
>> PMD->scan() initiated for such a bus/device would leave all other scans
>> redundant.
>>
>> More similar caveats will come if we consider somewhat generic buses. At
>> least I couldn't find any interest for such devices in the ML when I
>> picked this series (from where Jan left it).
>>
>> Probably when more common type of PMDs come in, some default scan
>> implementation can check for skipping those devices which are already
>> added. It would be redundant but harmless.
>
> If several drivers use the same bus, it means the bus is standard enough
> to be implemented in EAL. So the scan function of this bus should be
> called only once when calling the generic EAL scan function.
>
In the current model, without a bus like object, this can only be
implemented as a hack. This is because:
- If each driver has its scan, some of them (those on a common bus)
would have their scan nullified
- Then, EAL would initiate the scan on their behalf. (rte_eal_init)
- Whereas, for those drivers which are 'special' scan, EAL would have to
call each driver's scan.
- This selection is manual code change (nullifying the scan function).
- And then, EAL would have various 'generic' scan's chained together
other than driver->scan().
A cleaner model would have been that EAL always calls the drivers->scan().
Obviously, this issue vanishes as soon as we have the bus->scan() like
implementation where a bus would represent multiple devices/drivers.
_________
Shreyansh
^ permalink raw reply
* Re: [PATCH v4] latencystats: added new library for latency stats
From: Remy Horton @ 2016-11-11 2:22 UTC (permalink / raw)
To: Reshma Pattan, dev
In-Reply-To: <1478524474-7154-1-git-send-email-reshma.pattan@intel.com>
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..
> +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?
> +++ 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..
..Remy
^ permalink raw reply
* Re: [PATCH] doc: remove iomem and ioport handling in igb_uio
From: Remy Horton @ 2016-11-11 2:12 UTC (permalink / raw)
To: Jianfeng Tan, dev; +Cc: ferruh.yigit, david.marchand, thomas.monjalon
In-Reply-To: <1474523045-2674-1-git-send-email-jianfeng.tan@intel.com>
On 22/09/2016 13:44, Jianfeng Tan wrote:
[..]
>
> Suggested-by: Yigit, Ferruh <ferruh.yigit@intel.com>
> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
Acked-by: Remy Horton <remy.horton@intel.com>
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -57,3 +57,8 @@ Deprecation Notices
> * API will change for ``rte_port_source_params`` and ``rte_port_sink_params``
> structures. The member ``file_name`` data type will be changed from
> ``char *`` to ``const char *``. This change targets release 16.11.
As an aside I don't think changing a structure entry to const will
affect its binary layout, so this ought not be an ABI break..
^ permalink raw reply
* Re: [PATCH v7 11/21] eal/soc: implement probing of drivers
From: Jianbo Liu @ 2016-11-11 1:58 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Shreyansh Jain, dev, Jan Viktorin, David Marchand
In-Reply-To: <1506578.S1InCtPeL4@xps13>
On 10 November 2016 at 17:26, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> 2016-11-10 14:40, Shreyansh Jain:
>> On Thursday 10 November 2016 01:11 PM, Jianbo Liu wrote:
>> > On 10 November 2016 at 14:10, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
>> >> On Thursday 10 November 2016 09:00 AM, Jianbo Liu wrote:
>> >>> I'm still not sure about the purpose of soc_scan, and how to use it.
>> >>
>> >>
>> >> For each device to be used by DPDK, which cannot be scanned/identified using
>> >> the existing PCI/VDEV methods (sysfs/bus/pci), 'soc_scan_t' provides a way
>> >> for driver to make those devices part of device lists.
>> >>
>> >> Ideally, 'scan' is not a function of a driver. It is a bus function - which
>> >> is missing in this case.
>> >>
>> >>> If it's for each driver, it should at least struct rte_soc_driver * as
>> >>> its parameter.
>> >>
>> >>
>> >> Its for each driver - assuming that each non-PCI driver which implements it
>> >> knows how to find devices which it can control (for example, special area in
>> >> sysfs, or even platform bus).
>> >>
>> >
>> > Considering there are several drivers in a platform bus, each driver
>> > call the scan function, like the rte_eal_soc_scan_platform_bus() you
>> > implemented.
>> > The first will add soc devices to the list, but the remaining calls
>> > are redundant.
>>
>> Indeed. This is exactly the issue we will face if we try and move this
>> scan/match logic to PCI - all devices are identified in one step.
>>
>> There is a difference in principle here:
>> A SoC device/driver combination is essentially focused towards a single
>> type of bus<->devices. For example, a NXP PMD would implement a scan
>> function which would scan for all devices on NXP's bus. This would not
>> conflict with another XYZ SoC PMD which scans its specific bus.
>>
>> There is caveat to this - the platform bus. There can be multiple
>> drivers which can serve platform bus compliant devices. First
>> PMD->scan() initiated for such a bus/device would leave all other scans
>> redundant.
>>
>> More similar caveats will come if we consider somewhat generic buses. At
>> least I couldn't find any interest for such devices in the ML when I
>> picked this series (from where Jan left it).
>>
>> Probably when more common type of PMDs come in, some default scan
>> implementation can check for skipping those devices which are already
>> added. It would be redundant but harmless.
>
> If several drivers use the same bus, it means the bus is standard enough
> to be implemented in EAL. So the scan function of this bus should be
> called only once when calling the generic EAL scan function.
Agree. rte_eal_soc_scan_platform_bus can be the scanning func for platform bus.
^ permalink raw reply
* Re: [PATCH] doc: announce ABI change for ethtool app enhance
From: Zhang, Helin @ 2016-11-11 1:26 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org; +Cc: Yang, Qiming
In-Reply-To: <1475983002-72869-1-git-send-email-qiming.yang@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiming Yang
> Sent: Sunday, October 9, 2016 11:17 AM
> To: dev@dpdk.org
> Cc: Yang, Qiming
> Subject: [dpdk-dev] [PATCH] doc: announce ABI change for ethtool app
> enhance
>
> This patch adds a notice that the ABI change for ethtool app to get the NIC
> firmware version in the 17.02 release.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
Acked-by: Helin Zhang <helin.zhang@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst
> b/doc/guides/rel_notes/deprecation.rst
> index 845d2aa..60bd7ed 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -62,3 +62,7 @@ Deprecation Notices
> * API will change for ``rte_port_source_params`` and
> ``rte_port_sink_params``
> structures. The member ``file_name`` data type will be changed from
> ``char *`` to ``const char *``. This change targets release 16.11.
> +
> +* In 17.02 ABI change is planned: the ``rte_eth_dev_info`` structure
> + will be extended with a new member ``fw_version`` in order to store
> + the NIC firmware version.
> --
> 2.7.4
^ permalink raw reply
* Re: [PATCH] net/ixgbe: fix link never come up problem with x552
From: Thomas Monjalon @ 2016-11-10 23:49 UTC (permalink / raw)
To: Zhao1, Wei; +Cc: dev, Lu, Wenzhuo
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093934229A@shsmsx102.ccr.corp.intel.com>
> > From: zhao wei <wei.zhao1@intel.com>
> >
> > The links never coming up with DPDK16.11 when bring up x552 NIC, device id is
> > 15ac.This is caused by delete some code which casing removes X550em SFP iXFI
> > setup for the drivers in function ixgbe_setup_mac_link_sfp_x550em().Fix
> > methord is recover the deleted code.
> >
> > Fixes: 1726b9cd9c40 ("net/ixgbe/base: remove X550em SFP iXFI setup")
> >
> > Signed-off-by: zhao wei <wei.zhao1@intel.com>
> Acked-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Thanks for the patch. It's a critical issue. We need to fix it. I'll report it to our kernel driver developers.
Applied, thanks
^ permalink raw reply
* Re: [PATCH 0/2] net/thunderx: add 83xx SoC support
From: Thomas Monjalon @ 2016-11-10 23:44 UTC (permalink / raw)
To: Jerin Jacob; +Cc: dev, bruce.richardson
In-Reply-To: <1478586686-14109-1-git-send-email-jerin.jacob@caviumnetworks.com>
2016-11-08 12:01, 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
Applied, thanks
^ permalink raw reply
* Re: [PATCH v3] doc: arm64: document DPDK application profiling methods
From: Thomas Monjalon @ 2016-11-10 23:41 UTC (permalink / raw)
To: Jerin Jacob; +Cc: Jianbo Liu, dev, john.mcnamara
In-Reply-To: <CAP4Qi39vTFqWpP5_0j-Hka3AJ1MD9uNzLFAcN1P4Wx0p0QA8iA@mail.gmail.com>
> > Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> > Signed-off-by: John McNamara <john.mcnamara@intel.com>
>
> Acked-by: Jianbo Liu <jianbo.liu@linaro.org>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] doc: postpone ABI changes for Tx prepare
From: Thomas Monjalon @ 2016-11-10 23:33 UTC (permalink / raw)
To: Kulasek, TomaszX; +Cc: dev
In-Reply-To: <3042915272161B4EB253DA4D77EB373A14F47186@IRSMSX102.ger.corp.intel.com>
> > The changes for the feature "Tx prepare" should be made in version 17.02.
> >
> > Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
>
> Acked-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
Applied
^ permalink raw reply
* Re: [PATCH] doc: move testpmd guide with other tools
From: Thomas Monjalon @ 2016-11-10 23:32 UTC (permalink / raw)
To: Wiles, Keith; +Cc: Mcnamara, John, dev, Christian Ehrhardt, Richardson, Bruce
In-Reply-To: <87C731C3-474F-4C2D-9526-13CFDD1172E1@intel.com>
2016-11-10 23:18, Wiles, Keith:
> > On Nov 10, 2016, at 5:02 PM, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
> > 2016-11-10 16:11, Mcnamara, John:
> >> The problem is that TestPMD is a bit of an outlier. It isn't a sample application and it isn't really a test application despite the name (it is more of a tester application). Also I don't think that it is a tool/utility like the other apps in the target directory (if it is seen as a tool then it should be renamed to something like dpdk-tester for consistency). Testpmd also has quite a lot of documentation, more than any of our other apps or utilities, which again makes it an outlier.
> >
> > Yes testpmd is not the same kind of tool as others. It helps for tests,
> > debugging and demos.
> >
> > About the name, as it is packaged as part of the runtime, I think we should
> > find a better name. As you said it should start with "dpdk-" and it should
> > contain "net" as it does not test the crypto drivers.
> > Something like dpdk-testpmd-net.
>
> To me the name dpdk-testpmd-net is a bit long and does testpmd really just test PMDs. I was thinking of the name dpdk-tester is really pretty short and descriptive IMO. Adding net or pmd to the name does not really add anything as dpdk is kind of networking. Just my $0.04 worth.
I tend to agree. dpdk-tester is not so bad.
So this application could be able to test the crypto engines?
^ permalink raw reply
* [PATCH v3] mempool: Add sanity check when secondary link-in less mempools than primary
From: Jean Tourrilhes @ 2016-11-10 23:25 UTC (permalink / raw)
To: dev, Thomas Monjalon, David Marchand, Sergio Gonzalez Monroy
If the mempool ops the caller wants to use is not registered, the
library will segfault in an obscure way when trying to use that
mempool. It's better to catch it early and warn the user.
If the primary and secondary process were build using different build
systems, the list of constructors included by the linker in each
binary might be different. Mempools are registered via constructors, so
the linker magic will directly impact which mempools are registered with
the primary and the secondary.
DPDK currently assumes that the secondary has a superset of the
mempools registered at the primary, and they are in the same order
(same index in primary and secondary). In some build scenario, the
secondary might not initialise any mempools at all.
This would also catch cases where there is a bug in the mempool
registration, or some memory corruptions, but this has not been
observed.
Signed-off-by: Jean Tourrilhes <jt@labs.hpe.com>
---
lib/librte_mempool/rte_mempool.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/lib/librte_mempool/rte_mempool.c b/lib/librte_mempool/rte_mempool.c
index e94e56f..bbb6723 100644
--- a/lib/librte_mempool/rte_mempool.c
+++ b/lib/librte_mempool/rte_mempool.c
@@ -1273,6 +1273,29 @@ rte_mempool_lookup(const char *name)
return NULL;
}
+ /* Sanity check : secondary may have initialised less mempools
+ * than primary due to linker and constructor magic. Or maybe
+ * there is a mempool corruption or bug. In any case, we can't
+ * go on, we will segfault in an obscure way.
+ * This does not detect the cases where the constructor order
+ * is different between primary and secondary or where the
+ * index points to the wrong ops. This would require more
+ * extensive changes, and is much less likely. Jean II */
+ if (mp->ops_index >= (int32_t) rte_mempool_ops_table.num_ops) {
+ unsigned i;
+ /* Dump list of mempool ops for further investigation.
+ * In most cases, list is empty... */
+ for (i = 0; i < rte_mempool_ops_table.num_ops; i++) {
+ RTE_LOG(ERR, EAL, "Registered mempool[%d] is %s\n",
+ i, rte_mempool_ops_table.ops[i].name);
+ }
+ /* Do not dump mempool list itself, it will segfault. */
+ rte_panic("Cannot find ops for mempool, ops_index %d, "
+ "num_ops %d - maybe due to build process or "
+ "linker configuration\n",
+ mp->ops_index, rte_mempool_ops_table.num_ops);
+ }
+
return mp;
}
^ permalink raw reply related
* Re: [PATCH] doc: fix l3fwd mode selection from compile to run time
From: Thomas Monjalon @ 2016-11-10 23:25 UTC (permalink / raw)
To: Pattan, Reshma; +Cc: dev, Mcnamara, John
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264D12A@IRSMSX103.ger.corp.intel.com>
> > The l3fwd application route lookup mode can be selected at run time but
> > not at compile time. This patch corrects the statement in the doc.
> >
> > Fixes: d0dff9ba ("doc: sample application user guide")
> >
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] doc: move testpmd guide with other tools
From: Wiles, Keith @ 2016-11-10 23:18 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Mcnamara, John, dev, Christian Ehrhardt, Richardson, Bruce
In-Reply-To: <2696537.77E6llNtKT@xps13>
> On Nov 10, 2016, at 5:02 PM, Thomas Monjalon <thomas.monjalon@6wind.com> wrote:
>
> 2016-11-10 16:11, Mcnamara, John:
>> I had a look at the html output before and after this patch and I don't quite agree with it. I see that you are trying to clean up and make the documentation more consistent but I don't know if this is the right way to do it.
>>
>> The problem is that TestPMD is a bit of an outlier. It isn't a sample application and it isn't really a test application despite the name (it is more of a tester application). Also I don't think that it is a tool/utility like the other apps in the target directory (if it is seen as a tool then it should be renamed to something like dpdk-tester for consistency). Testpmd also has quite a lot of documentation, more than any of our other apps or utilities, which again makes it an outlier.
>
> Yes testpmd is not the same kind of tool as others. It helps for tests,
> debugging and demos.
>
> About the name, as it is packaged as part of the runtime, I think we should
> find a better name. As you said it should start with "dpdk-" and it should
> contain "net" as it does not test the crypto drivers.
> Something like dpdk-testpmd-net.
To me the name dpdk-testpmd-net is a bit long and does testpmd really just test PMDs. I was thinking of the name dpdk-tester is really pretty short and descriptive IMO. Adding net or pmd to the name does not really add anything as dpdk is kind of networking. Just my $0.04 worth.
>
>> So my preference is to leave TestPMD in the high level index.
>
> OK I understand your opinion.
>
>> However, I do think the High level index should be cleaned up a bit and the items re-ordered into a more logical sequence. I'll submit a patch for that.
>
> OK thanks
Regards,
Keith
^ permalink raw reply
* Re: [PATCH] doc: move testpmd guide with other tools
From: Thomas Monjalon @ 2016-11-10 23:02 UTC (permalink / raw)
To: Mcnamara, John; +Cc: dev, Christian Ehrhardt, Richardson, Bruce
In-Reply-To: <B27915DBBA3421428155699D51E4CFE20264D07D@IRSMSX103.ger.corp.intel.com>
2016-11-10 16:11, Mcnamara, John:
> I had a look at the html output before and after this patch and I don't quite agree with it. I see that you are trying to clean up and make the documentation more consistent but I don't know if this is the right way to do it.
>
> The problem is that TestPMD is a bit of an outlier. It isn't a sample application and it isn't really a test application despite the name (it is more of a tester application). Also I don't think that it is a tool/utility like the other apps in the target directory (if it is seen as a tool then it should be renamed to something like dpdk-tester for consistency). Testpmd also has quite a lot of documentation, more than any of our other apps or utilities, which again makes it an outlier.
Yes testpmd is not the same kind of tool as others. It helps for tests,
debugging and demos.
About the name, as it is packaged as part of the runtime, I think we should
find a better name. As you said it should start with "dpdk-" and it should
contain "net" as it does not test the crypto drivers.
Something like dpdk-testpmd-net.
> So my preference is to leave TestPMD in the high level index.
OK I understand your opinion.
> However, I do think the High level index should be cleaned up a bit and the items re-ordered into a more logical sequence. I'll submit a patch for that.
OK thanks
^ permalink raw reply
* Re: [PATCH] maintainers: claim responsability for xen
From: Tan, Jianfeng @ 2016-11-10 20:49 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Thomas Monjalon
Cc: dev, bruce.richardson, yuanhan.liu, Konrad Rzeszutek Wilk,
Xen-devel
In-Reply-To: <CACJDEmqC7T5O=zF6SOsmfOizRXYM+e7nmbY=2VA4aJ13tkAS-w@mail.gmail.com>
Hi Thomas and Konrad,
On 11/11/2016 2:59 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon
> <thomas.monjalon@6wind.com> wrote:
>> 2016-11-07 07:38, Jianfeng Tan:
>>> As some users are still using xen as the hypervisor, I suggest to
>>> continue support for xen in DPDK. And from 16.11, I will be the
>>> maintainer of all xen-related files.
>>>
>>> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
>> Applied
>>
>> Please Jianfeng, could you start your new role by sending a status
>> of Xen dom0 support in DPDK? I think there are some issues in latest releases.
Yes, I'm on this. And hope to send out update in the next week.
>>
> Pls also CC me and xen-devel@lists.xenproject.org if possible.
Glad to do that.
Thanks,
Jianfeng
>
> Thanks!
^ permalink raw reply
* Re: [PATCH] maintainers: claim responsability for xen
From: Konrad Rzeszutek Wilk @ 2016-11-10 18:59 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Jianfeng Tan, dev, bruce.richardson, yuanhan.liu,
Konrad Rzeszutek Wilk, Xen-devel
In-Reply-To: <10491202.nlFsPbIJhh@xps13>
On Wed, Nov 9, 2016 at 5:03 PM, Thomas Monjalon
<thomas.monjalon@6wind.com> wrote:
> 2016-11-07 07:38, Jianfeng Tan:
>> As some users are still using xen as the hypervisor, I suggest to
>> continue support for xen in DPDK. And from 16.11, I will be the
>> maintainer of all xen-related files.
>>
>> Signed-off-by: Jianfeng Tan <jianfeng.tan@intel.com>
>
> Applied
>
> Please Jianfeng, could you start your new role by sending a status
> of Xen dom0 support in DPDK? I think there are some issues in latest releases.
>
Pls also CC me and xen-devel@lists.xenproject.org if possible.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/2] net: align ethdev and eal driver names
From: Ferruh Yigit @ 2016-11-10 18:46 UTC (permalink / raw)
To: David Marchand, thomas.monjalon
Cc: dev, linville, declan.doherty, zlu, lsun, alejandro.lucero,
mtetsuyah, nicolas.pernas.maradei, harish.patil, rasesh.mody,
sony.chacko, bruce.richardson, huawei.xie, yuanhan.liu,
jianfeng.tan
In-Reply-To: <1478785884-29273-2-git-send-email-david.marchand@6wind.com>
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?
[1]
diff --git a/drivers/net/null/rte_eth_null.c
b/drivers/net/null/rte_eth_null.c
index e4fd68f..d657133 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -553,9 +553,9 @@ eth_dev_null_create(const char *name,
TAILQ_INIT(ð_dev->link_intr_cbs);
eth_dev->driver = NULL;
+ eth_dev->rte_driver = &pmd_null_drv.driver;
data->dev_flags = RTE_ETH_DEV_DETACHABLE;
data->kdrv = RTE_KDRV_NONE;
- data->drv_name = pmd_null_drv.driver.name;
data->numa_node = numa_node;
/* finally assign rx and tx ops */
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index fde8112..0527c4a 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -259,6 +259,7 @@ rte_eth_dev_pci_probe(struct rte_pci_driver *pci_drv,
}
eth_dev->pci_dev = pci_dev;
eth_dev->driver = eth_drv;
+ eth_dev->rte_driver = pci_drv->driver.name;
eth_dev->data->rx_mbuf_alloc_failed = 0;
/* init user callbacks */
@@ -1557,7 +1558,7 @@ rte_eth_dev_info_get(uint8_t port_id, struct
rte_eth_dev_info *dev_info)
RTE_FUNC_PTR_OR_RET(*dev->dev_ops->dev_infos_get);
(*dev->dev_ops->dev_infos_get)(dev, dev_info);
dev_info->pci_dev = dev->pci_dev;
- dev_info->driver_name = dev->data->drv_name;
+ dev_info->driver_name = dev->rte_driver->name;
dev_info->nb_rx_queues = dev->data->nb_rx_queues;
dev_info->nb_tx_queues = dev->data->nb_tx_queues;
}
@@ -3214,7 +3215,6 @@ rte_eth_copy_pci_info(struct rte_eth_dev *eth_dev,
struct rte_pci_device *pci_de
eth_dev->data->kdrv = pci_dev->kdrv;
eth_dev->data->numa_node = pci_dev->device.numa_node;
- eth_dev->data->drv_name = pci_dev->driver->driver.name;
}
int
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 9678179..63e7931 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1642,6 +1642,7 @@ struct rte_eth_dev {
*/
struct rte_eth_rxtx_callback
*pre_tx_burst_cbs[RTE_MAX_QUEUES_PER_PORT];
uint8_t attached; /**< Flag indicating the port is attached */
+ struct rte_driver *rte_driver;
} __rte_cache_aligned;
struct rte_eth_dev_sriov {
^ permalink raw reply related
* Re: [PATCH v2] doc: add known issue on QAT PMD into release notes
From: John Griffin @ 2016-11-10 18:13 UTC (permalink / raw)
To: Fiona Trahe, dev; +Cc: pablo.de.lara.guarch
In-Reply-To: <1478798841-6194-1-git-send-email-fiona.trahe@intel.com>
On 10/11/16 17:27, Fiona Trahe wrote:
> Issue is with the digest appended feature on QAT PMD.
> A workaround is also documented.
>
> Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> Acked-by: John McNamara <john.mcnamara@intel.com>
> ---
> v2
> - fixed trailing whitespace checkpatch errors
>
Acked-by: John Griffin <john.griffin@intel.com>
^ permalink raw reply
* [PATCH v2] doc: add known issue on QAT PMD into release notes
From: Fiona Trahe @ 2016-11-10 17:27 UTC (permalink / raw)
To: dev; +Cc: pablo.de.lara.guarch, fiona.trahe, john.griffin
In-Reply-To: <1478796410-15004-1-git-send-email-fiona.trahe@intel.com>
Issue is with the digest appended feature on QAT PMD.
A workaround is also documented.
Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
---
v2
- fixed trailing whitespace checkpatch errors
doc/guides/rel_notes/release_16_11.rst | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index 365b5a3..5f925b5 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -213,7 +213,18 @@ Known Issues
Therefore, in order to use L3fwd-power, vector mode should be disabled
from the config file.
-
+* **Digest address must be supplied for crypto auth operation on QAT PMD.**
+
+ The cryptodev API specifies that if the rte_crypto_sym_op.digest.data field,
+ and by inference the digest.phys_addr field which points to the same location,
+ is not set for an auth operation the driver is to understand that the digest
+ result is located immediately following the region over which the digest is
+ computed. The QAT PMD doesn't correctly handle this case and reads and writes
+ to an incorrect location.
+
+ Callers can workaround this by always supplying the digest virtual and
+ physical address fields in the rte_crypto_sym_op for an auth operation.
+
API Changes
-----------
--
2.5.0
^ permalink raw reply related
* [PATCH] doc: add sub-repositories information
From: Ferruh Yigit @ 2016-11-10 17:27 UTC (permalink / raw)
To: dev; +Cc: John McNamara, Thomas Monjalon
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.
+* 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] doc: add known issue on QAT PMD into release notes
From: Trahe, Fiona @ 2016-11-10 17:22 UTC (permalink / raw)
To: dev@dpdk.org; +Cc: De Lara Guarch, Pablo, Griffin, John, Trahe, Fiona
In-Reply-To: <1478796410-15004-1-git-send-email-fiona.trahe@intel.com>
> -----Original Message-----
> From: Trahe, Fiona
> Sent: Thursday, November 10, 2016 4:47 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Griffin, John <john.griffin@intel.com>
> Subject: [PATCH] doc: add known issue on QAT PMD into release notes
>
> Issue is with the digest appended feature on QAT PMD.
> A workaround is also documented.
>
> Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> ---
Self-nack
Checkpatch white space errors - will send an update shortly
^ permalink raw reply
* Re: [PATCH] doc: add known issue on QAT PMD into release notes
From: Mcnamara, John @ 2016-11-10 16:52 UTC (permalink / raw)
To: Trahe, Fiona, dev@dpdk.org
Cc: De Lara Guarch, Pablo, Trahe, Fiona, Griffin, John
In-Reply-To: <1478796410-15004-1-git-send-email-fiona.trahe@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Fiona Trahe
> Sent: Thursday, November 10, 2016 4:47 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; Griffin, John <john.griffin@intel.com>
> Subject: [dpdk-dev] [PATCH] doc: add known issue on QAT PMD into release
> notes
>
> Issue is with the digest appended feature on QAT PMD.
> A workaround is also documented.
>
> Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ 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