* 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
* [PATCH] doc: add known issue on QAT PMD into release notes
From: Fiona Trahe @ 2016-11-10 16:46 UTC (permalink / raw)
To: dev; +Cc: pablo.de.lara.guarch, fiona.trahe, john.griffin
Issue is with the digest appended feature on QAT PMD.
A workaround is also documented.
Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
---
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
* Re: [PATCH] pdump: fix log message to display correct error number
From: De Lara Guarch, Pablo @ 2016-11-10 16:48 UTC (permalink / raw)
To: Pattan, Reshma, dev@dpdk.org; +Cc: Reshma Pattan
In-Reply-To: <1478795380-16975-1-git-send-email-reshma.pattan@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Thursday, November 10, 2016 4:30 PM
> To: dev@dpdk.org
> Cc: Reshma Pattan
> Subject: [dpdk-dev] [PATCH] pdump: fix log message to display correct error
> number
>
> The ethdev Rx/Tx remove callback apis doesn't set rte_errno during
> failures, instead they just return negative error number, so using
> that number in logs instead of rte_errno upon Rx and Tx callback
> removal failures.
>
> Fixes: 278f9454 ("pdump: add new library for packet capture")
>
> Signed-off-by: Reshma Pattan <reshma.pattan@gmail.com>
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
^ permalink raw reply
* Re: [PATCH] pdump: fix log message to display correct error number
From: Mcnamara, John @ 2016-11-10 16:47 UTC (permalink / raw)
To: Pattan, Reshma, dev@dpdk.org; +Cc: Reshma Pattan
In-Reply-To: <1478795380-16975-1-git-send-email-reshma.pattan@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Thursday, November 10, 2016 4:30 PM
> To: dev@dpdk.org
> Cc: Reshma Pattan <reshma.pattan@gmail.com>
> Subject: [dpdk-dev] [PATCH] pdump: fix log message to display correct
> error number
>
> The ethdev Rx/Tx remove callback apis doesn't set rte_errno during
> failures, instead they just return negative error number, so using that
> number in logs instead of rte_errno upon Rx and Tx callback removal
> failures.
>
> Fixes: 278f9454 ("pdump: add new library for packet capture")
>
> Signed-off-by: Reshma Pattan <reshma.pattan@gmail.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH] doc: fix l3fwd mode selection from compile to run time
From: Mcnamara, John @ 2016-11-10 16:46 UTC (permalink / raw)
To: Pattan, Reshma, dev@dpdk.org; +Cc: Pattan, Reshma
In-Reply-To: <1478795390-17014-1-git-send-email-reshma.pattan@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Thursday, November 10, 2016 4:30 PM
> To: dev@dpdk.org
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [dpdk-dev] [PATCH] doc: fix l3fwd mode selection from compile to
> run time
>
> 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>
^ permalink raw reply
* [PATCH] doc: fix l3fwd mode selection from compile to run time
From: Reshma Pattan @ 2016-11-10 16:29 UTC (permalink / raw)
To: dev; +Cc: Reshma Pattan
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>
---
doc/guides/sample_app_ug/l3_forward.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/guides/sample_app_ug/l3_forward.rst b/doc/guides/sample_app_ug/l3_forward.rst
index e2e6223..ab916b9 100644
--- a/doc/guides/sample_app_ug/l3_forward.rst
+++ b/doc/guides/sample_app_ug/l3_forward.rst
@@ -42,7 +42,7 @@ The initialization and run-time paths are very similar to those of the :doc:`l2_
The main difference from the L2 Forwarding sample application is that the forwarding decision
is made based on information read from the input packet.
-The lookup method is either hash-based or LPM-based and is selected at compile time. When the selected lookup method is hash-based,
+The lookup method is either hash-based or LPM-based and is selected at run time. When the selected lookup method is hash-based,
a hash object is used to emulate the flow classification stage.
The hash object is used in correlation with a flow table to map each input packet to its flow at runtime.
--
2.7.4
^ permalink raw reply related
* [PATCH] pdump: fix log message to display correct error number
From: Reshma Pattan @ 2016-11-10 16:29 UTC (permalink / raw)
To: dev; +Cc: Reshma Pattan
The ethdev Rx/Tx remove callback apis doesn't set rte_errno during
failures, instead they just return negative error number, so using
that number in logs instead of rte_errno upon Rx and Tx callback
removal failures.
Fixes: 278f9454 ("pdump: add new library for packet capture")
Signed-off-by: Reshma Pattan <reshma.pattan@gmail.com>
---
lib/librte_pdump/rte_pdump.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_pdump/rte_pdump.c b/lib/librte_pdump/rte_pdump.c
index 504a1ce..5968683 100644
--- a/lib/librte_pdump/rte_pdump.c
+++ b/lib/librte_pdump/rte_pdump.c
@@ -269,7 +269,7 @@ pdump_regitser_rx_callbacks(uint16_t end_q, uint8_t port, uint16_t queue,
if (ret < 0) {
RTE_LOG(ERR, PDUMP,
"failed to remove rx callback, errno=%d\n",
- rte_errno);
+ -ret);
return ret;
}
cbs->cb = NULL;
@@ -324,7 +324,7 @@ pdump_regitser_tx_callbacks(uint16_t end_q, uint8_t port, uint16_t queue,
if (ret < 0) {
RTE_LOG(ERR, PDUMP,
"failed to remove tx callback, errno=%d\n",
- rte_errno);
+ -ret);
return ret;
}
cbs->cb = NULL;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] doc: move testpmd guide with other tools
From: Mcnamara, John @ 2016-11-10 16:11 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev@dpdk.org, Christian Ehrhardt, Richardson, Bruce
In-Reply-To: <1478599358-15921-1-git-send-email-thomas.monjalon@6wind.com>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, November 8, 2016 10:03 AM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org; Christian Ehrhardt <christian.ehrhardt@canonical.com>
> Subject: [PATCH] doc: move testpmd guide with other tools
>
> The guide testpmd_app_ug/ is moved inside the new tools/ guide as a
> section.
>
> Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
> ---
> MAINTAINERS | 2 +-
> doc/guides/conf.py | 2 +-
> doc/guides/contributing/documentation.rst | 1 -
> doc/guides/index.rst | 1 -
> doc/guides/tools/index.rst | 2 +-
> doc/guides/{testpmd_app_ug => tools/testpmd}/build_app.rst | 0
> doc/guides/{testpmd_app_ug => tools/testpmd}/index.rst | 4 ++--
> doc/guides/{testpmd_app_ug => tools/testpmd}/intro.rst | 0
> doc/guides/{testpmd_app_ug => tools/testpmd}/run_app.rst | 0
> doc/guides/{testpmd_app_ug => tools/testpmd}/testpmd_funcs.rst | 0
> 10 files changed, 5 insertions(+), 7 deletions(-) rename
> doc/guides/{testpmd_app_ug => tools/testpmd}/build_app.rst (100%) rename
> doc/guides/{testpmd_app_ug => tools/testpmd}/index.rst (96%) rename
> doc/guides/{testpmd_app_ug => tools/testpmd}/intro.rst (100%) rename
> doc/guides/{testpmd_app_ug => tools/testpmd}/run_app.rst (100%) rename
> doc/guides/{testpmd_app_ug => tools/testpmd}/testpmd_funcs.rst (100%)
Hi,
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.
So my preference is to leave TestPMD in the high level index.
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.
John
^ permalink raw reply
* Re: [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Alejandro Lucero @ 2016-11-10 16:04 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bert van Leeuwen
In-Reply-To: <14529976.iPBWLuWW87@xps13>
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
* Re: [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Thomas Monjalon @ 2016-11-10 16:01 UTC (permalink / raw)
To: Alejandro Lucero; +Cc: dev, Bert van Leeuwen
In-Reply-To: <CAD+H992CDrSOow_pmhcSmM4n5mGUmUM+8rTzDaC+r7eV95LSog@mail.gmail.com>
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 :)
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".
^ permalink raw reply
* Re: [PATCH] doc: announce API and ABI changes for librte_eal
From: David Marchand @ 2016-11-10 15:51 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: Neil Horman, dev@dpdk.org, Thomas Monjalon
In-Reply-To: <1478776678-16328-1-git-send-email-shreyansh.jain@nxp.com>
On Thu, Nov 10, 2016 at 12:17 PM, Shreyansh Jain <shreyansh.jain@nxp.com> wrote:
> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 1a9e1ae..2af2476 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -35,3 +35,13 @@ Deprecation Notices
> * mempool: The functions for single/multi producer/consumer are deprecated
> and will be removed in 17.02.
> It is replaced by ``rte_mempool_generic_get/put`` functions.
> +
> +* ABI/API changes are planned for 17.02: ``rte_device``, ``rte_driver`` will be
> + impacted because of introduction of a new ``rte_bus`` hierarchy. This would
> + also impact the way devices are identified by EAL. A bus-device-driver model
> + will be introduced providing a hierarchical view of devices.
> +
> +* ``eth_driver`` is planned to be removed in 17.02. This currently serves as
> + a placeholder for PMDs to register themselves. Changes for ``rte_bus`` will
> + provide a way to handle device initialization currently being done in
> + ``eth_driver``.
> --
> 2.7.4
>
Acked-by: David Marchand <david.marchand@6wind.com>
--
David Marchand
^ permalink raw reply
* Re: [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Alejandro Lucero @ 2016-11-10 15:43 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Bert van Leeuwen
In-Reply-To: <3059112.zVgrzqmBCq@xps13>
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?
^ permalink raw reply
* Re: [PATCH 0/2] enables vhost/virtio any layout feature
From: Michael S. Tsirkin @ 2016-11-10 15:18 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev, Stephen Hemminger, Maxime Coquelin
In-Reply-To: <1474872056-24665-1-git-send-email-yuanhan.liu@linux.intel.com>
On Mon, Sep 26, 2016 at 02:40:54PM +0800, Yuanhan Liu wrote:
> The feature is actually supported both in virtio PMD and vhost lib.
> We just haven't enabled it yet. This patchset simply enables it.
Any input on handling versioning? Do people prefer to handle it
completely at the backend, or through libvirt?
> ---
> Yuanhan Liu (2):
> vhost: enable any layout feature
> net/virtio: enable any layout feature
>
> drivers/net/virtio/virtio_ethdev.h | 1 +
> lib/librte_vhost/vhost.c | 1 +
> lib/librte_vhost/vhost.h | 3 +++
> 3 files changed, 5 insertions(+)
>
> --
> 1.9.0
^ permalink raw reply
* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Mori, Naoyuki @ 2016-11-10 14:43 UTC (permalink / raw)
To: Thomas Monjalon
Cc: dev@dpdk.org, bjorn.topel@gmail.com, Yao, Lei A, Topel, Bjorn,
Zhang, Helin, Ananyev, Konstantin, Xu, Qian Q, Wu, Jingjing
In-Reply-To: <50996464.o08F9XFMCf@xps13>
Hi Thomas,
> 2016-11-10 13:50, Mori, Naoyuki:
> > > Thomas wrote:
> > > > Just to make it sure, you mean returning an error in the driver when
> > > > a configuration cannot be applied, right?
> > >
> > > Yes, as in 1bbcc5d21129 ("i40evf: report error for unsupported CRC
> > > stripping config"), where -EINVAL is returned.
> > >
> > > Bj?rn
> >
> > On my experience, OvS+DPDK has same issue.
> > You cannot run OvS on i40evf due to this CRC config mismatch, while OvS on
> ixgbevf works fine.
> > So, changing on i40evf PMD side would have more benefit, I believe.
>
> No I think OVS should handle the configuration error.
> We could also add a function to query this capability before configuring.
That would be fine, as long as it became a well-known standard.
But at least, hope i40evf and ixgbevf to be consistent in this CRC handling.
Thanks,
Mori
^ permalink raw reply
* Re: [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Thomas Monjalon @ 2016-11-10 14:42 UTC (permalink / raw)
To: Alejandro Lucero; +Cc: dev, Bert van Leeuwen
In-Reply-To: <1478786449-44745-1-git-send-email-alejandro.lucero@netronome.com>
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.
^ permalink raw reply
* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Thomas Monjalon @ 2016-11-10 14:32 UTC (permalink / raw)
To: Mori, Naoyuki
Cc: dev, bjorn.topel@gmail.com, Yao, Lei A, Topel, Bjorn,
Zhang, Helin, Ananyev, Konstantin, Xu, Qian Q, Wu, Jingjing
In-Reply-To: <5952EEAD-ED55-4C0B-86EB-945B87637CD2@intel.com>
2016-11-10 13:50, Mori, Naoyuki:
> Hi,
>
> > Thomas wrote:
> > > Just to make it sure, you mean returning an error in the driver when
> > > a configuration cannot be applied, right?
> >
> > Yes, as in 1bbcc5d21129 ("i40evf: report error for unsupported CRC
> > stripping config"), where -EINVAL is returned.
> >
> > Bj?rn
>
> On my experience, OvS+DPDK has same issue.
> You cannot run OvS on i40evf due to this CRC config mismatch, while OvS on ixgbevf works fine.
> So, changing on i40evf PMD side would have more benefit, I believe.
No I think OVS should handle the configuration error.
We could also add a function to query this capability before configuring.
^ permalink raw reply
* [PATCH] ethdev: check number of queues less than RTE_ETHDEV_QUEUE_STAT_CNTRS
From: Alejandro Lucero @ 2016-11-10 14:00 UTC (permalink / raw)
To: dev; +Cc: Bert van Leeuwen
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.
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.
Signed-off-by: Alejandro Lucero <alejandro.lucero@netronome.com>
---
lib/librte_ether/rte_ethdev.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index fde8112..4209ad0 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1343,8 +1343,10 @@ get_xstats_count(uint8_t port_id)
} else
count = 0;
count += RTE_NB_STATS;
- count += dev->data->nb_rx_queues * RTE_NB_RXQ_STATS;
- count += dev->data->nb_tx_queues * RTE_NB_TXQ_STATS;
+ count += RTE_MIN(dev->data->nb_rx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS) *
+ RTE_NB_RXQ_STATS;
+ count += RTE_MIN(dev->data->nb_tx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS) *
+ RTE_NB_TXQ_STATS;
return count;
}
@@ -1358,6 +1360,7 @@ rte_eth_xstats_get_names(uint8_t port_id,
int cnt_expected_entries;
int cnt_driver_entries;
uint32_t idx, id_queue;
+ uint16_t num_q;
cnt_expected_entries = get_xstats_count(port_id);
if (xstats_names == NULL || cnt_expected_entries < 0 ||
@@ -1374,7 +1377,8 @@ rte_eth_xstats_get_names(uint8_t port_id,
"%s", rte_stats_strings[idx].name);
cnt_used_entries++;
}
- for (id_queue = 0; id_queue < dev->data->nb_rx_queues; id_queue++) {
+ num_q = RTE_MIN(dev->data->nb_rx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS);
+ for (id_queue = 0; id_queue < num_q; id_queue++) {
for (idx = 0; idx < RTE_NB_RXQ_STATS; idx++) {
snprintf(xstats_names[cnt_used_entries].name,
sizeof(xstats_names[0].name),
@@ -1384,7 +1388,8 @@ rte_eth_xstats_get_names(uint8_t port_id,
}
}
- for (id_queue = 0; id_queue < dev->data->nb_tx_queues; id_queue++) {
+ num_q = RTE_MIN(dev->data->nb_tx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS);
+ for (id_queue = 0; id_queue < num_q; id_queue++) {
for (idx = 0; idx < RTE_NB_TXQ_STATS; idx++) {
snprintf(xstats_names[cnt_used_entries].name,
sizeof(xstats_names[0].name),
@@ -1420,14 +1425,18 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstat *xstats,
unsigned count = 0, i, q;
signed xcount = 0;
uint64_t val, *stats_ptr;
+ uint16_t nb_rxqs, nb_txqs;
RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
dev = &rte_eth_devices[port_id];
+ nb_rxqs = RTE_MIN(dev->data->nb_rx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS);
+ nb_txqs = RTE_MIN(dev->data->nb_tx_queues, RTE_ETHDEV_QUEUE_STAT_CNTRS);
+
/* Return generic statistics */
- count = RTE_NB_STATS + (dev->data->nb_rx_queues * RTE_NB_RXQ_STATS) +
- (dev->data->nb_tx_queues * RTE_NB_TXQ_STATS);
+ count = RTE_NB_STATS + (nb_rxqs * RTE_NB_RXQ_STATS) +
+ (nb_txqs * RTE_NB_TXQ_STATS);
/* implemented by the driver */
if (dev->dev_ops->xstats_get != NULL) {
@@ -1458,7 +1467,7 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstat *xstats,
}
/* per-rxq stats */
- for (q = 0; q < dev->data->nb_rx_queues; q++) {
+ for (q = 0; q < nb_rxqs; q++) {
for (i = 0; i < RTE_NB_RXQ_STATS; i++) {
stats_ptr = RTE_PTR_ADD(ð_stats,
rte_rxq_stats_strings[i].offset +
@@ -1469,7 +1478,7 @@ rte_eth_xstats_get(uint8_t port_id, struct rte_eth_xstat *xstats,
}
/* per-txq stats */
- for (q = 0; q < dev->data->nb_tx_queues; q++) {
+ for (q = 0; q < nb_txqs; q++) {
for (i = 0; i < RTE_NB_TXQ_STATS; i++) {
stats_ptr = RTE_PTR_ADD(ð_stats,
rte_txq_stats_strings[i].offset +
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] net: align ethdev and eal driver names
From: David Marchand @ 2016-11-10 13:51 UTC (permalink / raw)
To: thomas.monjalon
Cc: dev, linville, declan.doherty, zlu, lsun, alejandro.lucero,
mtetsuyah, nicolas.pernas.maradei, ferruh.yigit, harish.patil,
rasesh.mody, sony.chacko, bruce.richardson, huawei.xie,
yuanhan.liu, jianfeng.tan
In-Reply-To: <1478785884-29273-1-git-send-email-david.marchand@6wind.com>
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>
---
drivers/net/af_packet/rte_eth_af_packet.c | 4 +++-
drivers/net/bonding/rte_eth_bond_api.c | 7 +++----
drivers/net/bonding/rte_eth_bond_pmd.c | 4 ++--
drivers/net/bonding/rte_eth_bond_private.h | 2 +-
drivers/net/mpipe/mpipe_tilegx.c | 21 ++++++++++++++++-----
drivers/net/null/rte_eth_null.c | 4 +++-
drivers/net/pcap/rte_eth_pcap.c | 4 +++-
drivers/net/ring/rte_eth_ring.c | 4 +++-
drivers/net/vhost/rte_eth_vhost.c | 4 +++-
drivers/net/virtio/virtio_ethdev.c | 6 +++++-
drivers/net/virtio/virtio_ethdev.h | 2 ++
drivers/net/virtio/virtio_user_ethdev.c | 2 +-
drivers/net/xenvirt/rte_eth_xenvirt.c | 3 ++-
13 files changed, 47 insertions(+), 20 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
index a66a657..8cae165 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -437,6 +437,8 @@ open_packet_iface(const char *key __rte_unused,
return 0;
}
+static struct rte_vdev_driver pmd_af_packet_drv;
+
static int
rte_pmd_init_internals(const char *name,
const int sockfd,
@@ -690,7 +692,7 @@ rte_pmd_init_internals(const char *name,
(*eth_dev)->dev_ops = &ops;
(*eth_dev)->driver = NULL;
(*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
- (*eth_dev)->data->drv_name = "AF_PACKET PMD";
+ (*eth_dev)->data->drv_name = pmd_af_packet_drv.driver.name;
(*eth_dev)->data->kdrv = RTE_KDRV_NONE;
(*eth_dev)->data->numa_node = numa_node;
diff --git a/drivers/net/bonding/rte_eth_bond_api.c b/drivers/net/bonding/rte_eth_bond_api.c
index 2a3893a..a4e86ae 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -37,6 +37,7 @@
#include <rte_malloc.h>
#include <rte_ethdev.h>
#include <rte_tcp.h>
+#include <rte_vdev.h>
#include "rte_eth_bond.h"
#include "rte_eth_bond_private.h"
@@ -44,8 +45,6 @@
#define DEFAULT_POLLING_INTERVAL_10_MS (10)
-const char pmd_bond_driver_name[] = "rte_bond_pmd";
-
int
check_for_bonded_ethdev(const struct rte_eth_dev *eth_dev)
{
@@ -54,7 +53,7 @@ check_for_bonded_ethdev(const struct rte_eth_dev *eth_dev)
return -1;
/* return 0 if driver name matches */
- return eth_dev->data->drv_name != pmd_bond_driver_name;
+ return eth_dev->data->drv_name != pmd_bond_drv.driver.name;
}
int
@@ -221,7 +220,7 @@ rte_eth_bond_create(const char *name, uint8_t mode, uint8_t socket_id)
RTE_ETH_DEV_DETACHABLE;
eth_dev->driver = NULL;
eth_dev->data->kdrv = RTE_KDRV_NONE;
- eth_dev->data->drv_name = pmd_bond_driver_name;
+ eth_dev->data->drv_name = pmd_bond_drv.driver.name;
eth_dev->data->numa_node = socket_id;
rte_spinlock_init(&internals->lock);
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c
index a80b6fa..9bfd9f6 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2566,12 +2566,12 @@ bond_ethdev_configure(struct rte_eth_dev *dev)
return 0;
}
-static struct rte_vdev_driver bond_drv = {
+struct rte_vdev_driver pmd_bond_drv = {
.probe = bond_probe,
.remove = bond_remove,
};
-RTE_PMD_REGISTER_VDEV(net_bonding, bond_drv);
+RTE_PMD_REGISTER_VDEV(net_bonding, pmd_bond_drv);
RTE_PMD_REGISTER_ALIAS(net_bonding, eth_bond);
RTE_PMD_REGISTER_PARAM_STRING(net_bonding,
diff --git a/drivers/net/bonding/rte_eth_bond_private.h b/drivers/net/bonding/rte_eth_bond_private.h
index d95d440..5a411e2 100644
--- a/drivers/net/bonding/rte_eth_bond_private.h
+++ b/drivers/net/bonding/rte_eth_bond_private.h
@@ -63,7 +63,7 @@
extern const char *pmd_bond_init_valid_arguments[];
-extern const char pmd_bond_driver_name[];
+extern struct rte_vdev_driver pmd_bond_drv;
/** Port Queue Mapping Structure */
struct bond_rx_queue {
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index fbbbb00..f0ba91e 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -87,7 +87,6 @@ struct mpipe_local {
static __thread struct mpipe_local mpipe_local;
static struct mpipe_context mpipe_contexts[GXIO_MPIPE_INSTANCE_MAX];
static int mpipe_instances;
-static const char *drivername = "MPIPE PMD";
/* Per queue statistics. */
struct mpipe_queue_stats {
@@ -1549,7 +1548,7 @@ mpipe_link_mac(const char *ifname, uint8_t *mac)
}
static int
-rte_pmd_mpipe_probe(const char *ifname,
+rte_pmd_mpipe_probe_common(struct rte_vdev_driver *drv, const char *ifname,
const char *params __rte_unused)
{
gxio_mpipe_context_t *context;
@@ -1606,7 +1605,7 @@ rte_pmd_mpipe_probe(const char *ifname,
eth_dev->data->dev_flags = 0;
eth_dev->data->kdrv = RTE_KDRV_NONE;
eth_dev->driver = NULL;
- eth_dev->data->drv_name = drivername;
+ eth_dev->data->drv_name = drv->driver.name;
eth_dev->data->numa_node = instance;
eth_dev->dev_ops = &mpipe_dev_ops;
@@ -1623,12 +1622,24 @@ rte_pmd_mpipe_probe(const char *ifname,
return 0;
}
+static int
+rte_pmd_mpipe_xgbe_probe(const char *ifname, const char *params __rte_unused)
+{
+ return rte_pmd_mpipe_probe_common(&pmd_mpipe_xgbe_drv, ifname, params);
+}
+
+static int
+rte_pmd_mpipe_gbe_probe(const char *ifname, const char *params __rte_unused)
+{
+ return rte_pmd_mpipe_probe_common(&pmd_mpipe_gbe_drv, ifname, params);
+}
+
static struct rte_vdev_driver pmd_mpipe_xgbe_drv = {
- .probe = rte_pmd_mpipe_probe,
+ .probe = rte_pmd_mpipe_xgbe_probe,
};
static struct rte_vdev_driver pmd_mpipe_gbe_drv = {
- .probe = rte_pmd_mpipe_probe,
+ .probe = rte_pmd_mpipe_gbe_probe,
};
RTE_PMD_REGISTER_VDEV(net_mpipe_xgbe, pmd_mpipe_xgbe_drv);
diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 09d77fd..e4fd68f 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -478,6 +478,8 @@ static const struct eth_dev_ops ops = {
.rss_hash_conf_get = eth_rss_hash_conf_get
};
+static struct rte_vdev_driver pmd_null_drv;
+
int
eth_dev_null_create(const char *name,
const unsigned numa_node,
@@ -553,7 +555,7 @@ eth_dev_null_create(const char *name,
eth_dev->driver = NULL;
data->dev_flags = RTE_ETH_DEV_DETACHABLE;
data->kdrv = RTE_KDRV_NONE;
- data->drv_name = "Null PMD";
+ data->drv_name = pmd_null_drv.driver.name;
data->numa_node = numa_node;
/* finally assign rx and tx ops */
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 8b4fba7..58c326a 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -788,6 +788,8 @@ open_tx_iface(const char *key, const char *value, void *extra_args)
return 0;
}
+static struct rte_vdev_driver pmd_pcap_drv;
+
static int
pmd_init_internals(const char *name, const unsigned int nb_rx_queues,
const unsigned int nb_tx_queues,
@@ -840,7 +842,7 @@ pmd_init_internals(const char *name, const unsigned int nb_rx_queues,
(*eth_dev)->driver = NULL;
data->dev_flags = RTE_ETH_DEV_DETACHABLE;
data->kdrv = RTE_KDRV_NONE;
- data->drv_name = "Pcap PMD";
+ data->drv_name = pmd_pcap_drv.driver.name;
data->numa_node = numa_node;
return 0;
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index 56afaf2..31034cf 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -257,6 +257,8 @@ static const struct eth_dev_ops ops = {
.mac_addr_add = eth_mac_addr_add,
};
+static struct rte_vdev_driver pmd_ring_drv;
+
static int
do_eth_dev_ring_create(const char *name,
struct rte_ring * const rx_queues[], const unsigned nb_rx_queues,
@@ -341,7 +343,7 @@ do_eth_dev_ring_create(const char *name,
eth_dev->dev_ops = &ops;
data->dev_flags = RTE_ETH_DEV_DETACHABLE;
data->kdrv = RTE_KDRV_NONE;
- data->drv_name = "Rings PMD";
+ data->drv_name = pmd_ring_drv.driver.name;
data->numa_node = numa_node;
TAILQ_INIT(&(eth_dev->link_intr_cbs));
diff --git a/drivers/net/vhost/rte_eth_vhost.c b/drivers/net/vhost/rte_eth_vhost.c
index 96bf391..059a74f 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -984,6 +984,8 @@ static const struct eth_dev_ops ops = {
.xstats_get_names = vhost_dev_xstats_get_names,
};
+static struct rte_vdev_driver pmd_vhost_drv;
+
static int
eth_dev_vhost_create(const char *name, char *iface_name, int16_t queues,
const unsigned numa_node, uint64_t flags)
@@ -1071,7 +1073,7 @@ eth_dev_vhost_create(const char *name, char *iface_name, int16_t queues,
data->dev_flags =
RTE_ETH_DEV_DETACHABLE | RTE_ETH_DEV_INTR_LSC;
data->kdrv = RTE_KDRV_NONE;
- data->drv_name = internal->dev_name;
+ data->drv_name = pmd_vhost_drv.driver.name;
data->numa_node = numa_node;
/* finally assign rx and tx ops */
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 741688e..dbc4ddb 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -52,6 +52,7 @@
#include <rte_memory.h>
#include <rte_eal.h>
#include <rte_dev.h>
+#include <rte_vdev.h>
#include "virtio_ethdev.h"
#include "virtio_pci.h"
@@ -1210,7 +1211,10 @@ virtio_init_device(struct rte_eth_dev *eth_dev, uint64_t req_features)
else
eth_dev->data->dev_flags |= RTE_ETH_DEV_INTR_LSC;
- rte_eth_copy_pci_info(eth_dev, pci_dev);
+ if (pci_dev)
+ rte_eth_copy_pci_info(eth_dev, pci_dev);
+ else
+ eth_dev->data->drv_name = virtio_user_driver.driver.name;
rx_func_get(eth_dev);
diff --git a/drivers/net/virtio/virtio_ethdev.h b/drivers/net/virtio/virtio_ethdev.h
index 27d9a19..94b4f43 100644
--- a/drivers/net/virtio/virtio_ethdev.h
+++ b/drivers/net/virtio/virtio_ethdev.h
@@ -104,4 +104,6 @@ uint16_t virtio_xmit_pkts_simple(void *tx_queue, struct rte_mbuf **tx_pkts,
int eth_virtio_dev_init(struct rte_eth_dev *eth_dev);
+extern struct rte_vdev_driver virtio_user_driver;
+
#endif /* _VIRTIO_ETHDEV_H_ */
diff --git a/drivers/net/virtio/virtio_user_ethdev.c b/drivers/net/virtio/virtio_user_ethdev.c
index 406beea..d3b595b 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -473,7 +473,7 @@ virtio_user_pmd_remove(const char *name)
return 0;
}
-static struct rte_vdev_driver virtio_user_driver = {
+struct rte_vdev_driver virtio_user_driver = {
.probe = virtio_user_pmd_probe,
.remove = virtio_user_pmd_remove,
};
diff --git a/drivers/net/xenvirt/rte_eth_xenvirt.c b/drivers/net/xenvirt/rte_eth_xenvirt.c
index f74d72c..8321a0b 100644
--- a/drivers/net/xenvirt/rte_eth_xenvirt.c
+++ b/drivers/net/xenvirt/rte_eth_xenvirt.c
@@ -617,6 +617,7 @@ enum dev_action {
DEV_ATTACH
};
+static struct rte_vdev_driver pmd_xenvirt_drv;
static int
eth_dev_xenvirt_create(const char *name, const char *params,
@@ -672,7 +673,7 @@ eth_dev_xenvirt_create(const char *name, const char *params,
eth_dev->data->dev_flags = RTE_PCI_DRV_DETACHABLE;
eth_dev->data->kdrv = RTE_KDRV_NONE;
- eth_dev->data->drv_name = "xen virtio PMD";
+ eth_dev->data->drv_name = pmd_xenvirt_drv.driver.name;
eth_dev->driver = NULL;
eth_dev->data->numa_node = numa_node;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] net: remove dead driver names
From: David Marchand @ 2016-11-10 13:51 UTC (permalink / raw)
To: thomas.monjalon
Cc: dev, linville, declan.doherty, zlu, lsun, alejandro.lucero,
mtetsuyah, nicolas.pernas.maradei, ferruh.yigit, harish.patil,
rasesh.mody, sony.chacko, bruce.richardson, huawei.xie,
yuanhan.liu, jianfeng.tan
Since b1fb53a39d88 ("ethdev: remove some PCI specific handling"),
rte_eth_dev_info_get() relies on dev->data->drv_name to report the driver
name to caller.
Having the pmds set driver_info->driver_name in the pmds is useless,
since ethdev overwrites it right after.
The only thing the pmd must do is:
- for pci drivers, call rte_eth_copy_pci_info() which then sets
data->drv_name
- for vdev drivers, manually set data->drv_name
At this stage, virtio-user does not properly report a driver name (fixed in
next commit).
Signed-off-by: David Marchand <david.marchand@6wind.com>
---
drivers/net/af_packet/rte_eth_af_packet.c | 5 +----
drivers/net/nfp/nfp_net.c | 1 -
drivers/net/null/rte_eth_null.c | 4 +---
drivers/net/pcap/rte_eth_pcap.c | 4 +---
drivers/net/qede/qede_ethdev.c | 1 -
drivers/net/ring/rte_eth_ring.c | 4 +---
drivers/net/vhost/rte_eth_vhost.c | 3 ---
drivers/net/virtio/virtio_ethdev.c | 4 ----
drivers/net/xenvirt/rte_eth_xenvirt.c | 5 +----
9 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c b/drivers/net/af_packet/rte_eth_af_packet.c
index ff45068..a66a657 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -115,8 +115,6 @@ static const char *valid_arguments[] = {
NULL
};
-static const char *drivername = "AF_PACKET PMD";
-
static struct rte_eth_link pmd_link = {
.link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
@@ -280,7 +278,6 @@ eth_dev_info(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
{
struct pmd_internals *internals = dev->data->dev_private;
- dev_info->driver_name = drivername;
dev_info->if_index = internals->if_index;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)ETH_FRAME_LEN;
@@ -693,7 +690,7 @@ rte_pmd_init_internals(const char *name,
(*eth_dev)->dev_ops = &ops;
(*eth_dev)->driver = NULL;
(*eth_dev)->data->dev_flags = RTE_ETH_DEV_DETACHABLE;
- (*eth_dev)->data->drv_name = drivername;
+ (*eth_dev)->data->drv_name = "AF_PACKET PMD";
(*eth_dev)->data->kdrv = RTE_KDRV_NONE;
(*eth_dev)->data->numa_node = numa_node;
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index c6b1587..0c342ab 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -1006,7 +1006,6 @@ nfp_net_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
hw = NFP_NET_DEV_PRIVATE_TO_HW(dev->data->dev_private);
- dev_info->driver_name = dev->driver->pci_drv.driver.name;
dev_info->max_rx_queues = (uint16_t)hw->max_rx_queues;
dev_info->max_tx_queues = (uint16_t)hw->max_tx_queues;
dev_info->min_rx_bufsize = ETHER_MIN_MTU;
diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 836d982..09d77fd 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -88,7 +88,6 @@ struct pmd_internals {
static struct ether_addr eth_addr = { .addr_bytes = {0} };
-static const char *drivername = "Null PMD";
static struct rte_eth_link pmd_link = {
.link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
@@ -295,7 +294,6 @@ eth_dev_info(struct rte_eth_dev *dev,
return;
internals = dev->data->dev_private;
- dev_info->driver_name = drivername;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)-1;
dev_info->max_rx_queues = RTE_DIM(internals->rx_null_queues);
@@ -555,7 +553,7 @@ eth_dev_null_create(const char *name,
eth_dev->driver = NULL;
data->dev_flags = RTE_ETH_DEV_DETACHABLE;
data->kdrv = RTE_KDRV_NONE;
- data->drv_name = drivername;
+ data->drv_name = "Null PMD";
data->numa_node = numa_node;
/* finally assign rx and tx ops */
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 0162f44..8b4fba7 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -119,7 +119,6 @@ static struct ether_addr eth_addr = {
.addr_bytes = { 0, 0, 0, 0x1, 0x2, 0x3 }
};
-static const char *drivername = "Pcap PMD";
static struct rte_eth_link pmd_link = {
.link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
@@ -552,7 +551,6 @@ eth_dev_info(struct rte_eth_dev *dev,
{
struct pmd_internals *internals = dev->data->dev_private;
- dev_info->driver_name = drivername;
dev_info->if_index = internals->if_index;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t) -1;
@@ -842,7 +840,7 @@ pmd_init_internals(const char *name, const unsigned int nb_rx_queues,
(*eth_dev)->driver = NULL;
data->dev_flags = RTE_ETH_DEV_DETACHABLE;
data->kdrv = RTE_KDRV_NONE;
- data->drv_name = drivername;
+ data->drv_name = "Pcap PMD";
data->numa_node = numa_node;
return 0;
diff --git a/drivers/net/qede/qede_ethdev.c b/drivers/net/qede/qede_ethdev.c
index 59129f2..a56ba90 100644
--- a/drivers/net/qede/qede_ethdev.c
+++ b/drivers/net/qede/qede_ethdev.c
@@ -662,7 +662,6 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
dev_info->max_vfs = 0;
else
dev_info->max_vfs = (uint16_t)NUM_OF_VFS(&qdev->edev);
- dev_info->driver_name = qdev->drv_ver;
dev_info->reta_size = ECORE_RSS_IND_TABLE_SIZE;
dev_info->flow_type_rss_offloads = (uint64_t)QEDE_RSS_OFFLOAD_ALL;
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index c1767c4..56afaf2 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -75,7 +75,6 @@ struct pmd_internals {
};
-static const char *drivername = "Rings PMD";
static struct rte_eth_link pmd_link = {
.link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
@@ -173,7 +172,6 @@ eth_dev_info(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info)
{
struct pmd_internals *internals = dev->data->dev_private;
- dev_info->driver_name = drivername;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)-1;
dev_info->max_rx_queues = (uint16_t)internals->max_rx_queues;
@@ -343,7 +341,7 @@ do_eth_dev_ring_create(const char *name,
eth_dev->dev_ops = &ops;
data->dev_flags = RTE_ETH_DEV_DETACHABLE;
data->kdrv = RTE_KDRV_NONE;
- data->drv_name = drivername;
+ data->drv_name = "Rings PMD";
data->numa_node = numa_node;
TAILQ_INIT(&(eth_dev->link_intr_cbs));
diff --git a/drivers/net/vhost/rte_eth_vhost.c b/drivers/net/vhost/rte_eth_vhost.c
index 766d4ef..96bf391 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -53,8 +53,6 @@
#define ETH_VHOST_CLIENT_ARG "client"
#define ETH_VHOST_DEQUEUE_ZERO_COPY "dequeue-zero-copy"
-static const char *drivername = "VHOST PMD";
-
static const char *valid_arguments[] = {
ETH_VHOST_IFACE_ARG,
ETH_VHOST_QUEUES_ARG,
@@ -861,7 +859,6 @@ eth_dev_info(struct rte_eth_dev *dev,
return;
}
- dev_info->driver_name = drivername;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)-1;
dev_info->max_rx_queues = internal->max_queues;
diff --git a/drivers/net/virtio/virtio_ethdev.c b/drivers/net/virtio/virtio_ethdev.c
index 079fd6c..741688e 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -1624,10 +1624,6 @@ virtio_dev_info_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *dev_info)
uint64_t tso_mask;
struct virtio_hw *hw = dev->data->dev_private;
- if (dev->pci_dev)
- dev_info->driver_name = dev->driver->pci_drv.driver.name;
- else
- dev_info->driver_name = "virtio_user PMD";
dev_info->max_rx_queues =
RTE_MIN(hw->max_queue_pairs, VIRTIO_MAX_RX_QUEUES);
dev_info->max_tx_queues =
diff --git a/drivers/net/xenvirt/rte_eth_xenvirt.c b/drivers/net/xenvirt/rte_eth_xenvirt.c
index c08a056..f74d72c 100644
--- a/drivers/net/xenvirt/rte_eth_xenvirt.c
+++ b/drivers/net/xenvirt/rte_eth_xenvirt.c
@@ -70,8 +70,6 @@
/* virtio_idx is increased after new device is created.*/
static int virtio_idx = 0;
-static const char *drivername = "xen virtio PMD";
-
static struct rte_eth_link pmd_link = {
.link_speed = ETH_SPEED_NUM_10G,
.link_duplex = ETH_LINK_FULL_DUPLEX,
@@ -331,7 +329,6 @@ eth_dev_info(struct rte_eth_dev *dev,
struct pmd_internals *internals = dev->data->dev_private;
RTE_SET_USED(internals);
- dev_info->driver_name = drivername;
dev_info->max_mac_addrs = 1;
dev_info->max_rx_pktlen = (uint32_t)2048;
dev_info->max_rx_queues = (uint16_t)1;
@@ -675,7 +672,7 @@ eth_dev_xenvirt_create(const char *name, const char *params,
eth_dev->data->dev_flags = RTE_PCI_DRV_DETACHABLE;
eth_dev->data->kdrv = RTE_KDRV_NONE;
- eth_dev->data->drv_name = drivername;
+ eth_dev->data->drv_name = "xen virtio PMD";
eth_dev->driver = NULL;
eth_dev->data->numa_node = numa_node;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] maintainers: add staging tree for network drivers
From: Thomas Monjalon @ 2016-11-10 13:50 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, Bruce Richardson
In-Reply-To: <20161110121440.17360-1-ferruh.yigit@intel.com>
> 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.
^ permalink raw reply
* Re: [PATCH] examples/l3fwd: force CRC stripping for i40evf
From: Mori, Naoyuki @ 2016-11-10 13:50 UTC (permalink / raw)
To: dev@dpdk.org, bjorn.topel@gmail.com, Yao, Lei A, Topel, Bjorn,
Zhang, Helin, Ananyev, Konstantin
Cc: Xu, Qian Q, Wu, Jingjing, thomas.monjalon@6wind.com
Hi,
Re:
> Subject: Re: [dpdk-dev] [PATCH] examples/l3fwd: force CRC stripping
> for i40evf
> Message-ID: <cce4d31c-8a84-07aa-3361-327dba1ec77a@intel.com>
> Thomas wrote:
> > Just to make it sure, you mean returning an error in the driver when
> > a configuration cannot be applied, right?
>
> Yes, as in 1bbcc5d21129 ("i40evf: report error for unsupported CRC
> stripping config"), where -EINVAL is returned.
>
> Bj?rn
On my experience, OvS+DPDK has same issue.
You cannot run OvS on i40evf due to this CRC config mismatch, while OvS on ixgbevf works fine.
So, changing on i40evf PMD side would have more benefit, I believe.
[Details below]
ovs-vswitchd.log:
2016-11-10T08:53:31.290Z|00054|netdev_dpdk|WARN|Interface dpdk0 eth_dev setup error Invalid argument
because of
i40evf_dev_configure() returns –EINVAL.
At here
---
i40evf_dev_configure(struct rte_eth_dev *dev)
{
<snip>
/* For non-DPDK PF drivers, VF has no ability to disable HW
* CRC strip, and is implicitly enabled by the PF.
*/
if (!conf->rxmode.hw_strip_crc) {
vf = I40EVF_DEV_PRIVATE_TO_VF(dev->data->dev_private);
if ((vf->version_major == I40E_VIRTCHNL_VERSION_MAJOR) &&
(vf->version_minor <= I40E_VIRTCHNL_VERSION_MINOR)) {
/* Peer is running non-DPDK PF driver. */
PMD_INIT_LOG(ERR, "VF can't disable HW CRC Strip");
return -EINVAL;
}
}
<snip>
}
---
ixgbevf is same Intel NIC but implementation is different. It won’t return error.
ixgbevf_dev_configure(struct rte_eth_dev *dev)
{
<snip>
/*
* VF has no ability to enable/disable HW CRC
* Keep the persistent behavior the same as Host PF
*/
#ifndef RTE_LIBRTE_IXGBE_PF_DISABLE_STRIP_CRC
if (!conf->rxmode.hw_strip_crc) {
PMD_INIT_LOG(NOTICE, "VF can't disable HW CRC Strip");
conf->rxmode.hw_strip_crc = 1;
}
#else
if (conf->rxmode.hw_strip_crc) {
PMD_INIT_LOG(NOTICE, "VF can't enable HW CRC Strip");
conf->rxmode.hw_strip_crc = 0;
}
#endif
<snip>
}
Regards and Thanks,
Mori
^ permalink raw reply
* Re: disable hugepages
From: Olivier Matz @ 2016-11-10 13:34 UTC (permalink / raw)
To: Wiles, Keith, Keren Hochman; +Cc: Christian Ehrhardt, dev
In-Reply-To: <6BBBABF1-45E1-4260-BE26-9C556C47B825@intel.com>
On 11/10/2016 02:10 PM, Wiles, Keith wrote:
>
>> On Nov 10, 2016, at 6:32 AM, Keren Hochman <keren.hochman@lightcyber.com> wrote:
>>
>> I tried using the following dpdk options:
>> --no-huge --vdev eth_pcap0 ,rx_pcap=/t1,tx_pcap=/t2
>> *It's worked but the number of elements is limited, although the machine
>> has enough free memory. *rte_mempool_create is failed when I'm trying to
>> allocate more memory. Is there any limitation on the memory beside the
>> machine?
>
> DPDK will just use the standard linux memory allocator, so no limitation in DPDK. Now you could be hitting the limit as a user, need to check your system to make sure you can allocate that much memory to a user. Try using the command ulimit and see what it reports.
>
> I do not remember exactly how to change limits except with ulimit command. I may have modified /etc/security/limits.conf file.
I don't think it's a ulimit issue.
Actually, the memory is reserved once at startup. The -m EAL
option allows to specify the amount of memory allocated:
-m MB Memory to allocate (see also --socket-mem)
So I guess setting it to an higher value (256?) would do the job.
Regards,
Olivier
^ permalink raw reply
* Re: disable hugepages
From: Wiles, Keith @ 2016-11-10 13:10 UTC (permalink / raw)
To: Keren Hochman; +Cc: Olivier Matz, Christian Ehrhardt, dev
In-Reply-To: <CAJq3SQ77Ty-OjuCi-dk6kcFYYG-iJaFrxSPSdtv6-OTnNq8U=g@mail.gmail.com>
> On Nov 10, 2016, at 6:32 AM, Keren Hochman <keren.hochman@lightcyber.com> wrote:
>
> I tried using the following dpdk options:
> --no-huge --vdev eth_pcap0 ,rx_pcap=/t1,tx_pcap=/t2
> *It's worked but the number of elements is limited, although the machine
> has enough free memory. *rte_mempool_create is failed when I'm trying to
> allocate more memory. Is there any limitation on the memory beside the
> machine?
DPDK will just use the standard linux memory allocator, so no limitation in DPDK. Now you could be hitting the limit as a user, need to check your system to make sure you can allocate that much memory to a user. Try using the command ulimit and see what it reports.
I do not remember exactly how to change limits except with ulimit command. I may have modified /etc/security/limits.conf file.
HTH
>
> *Thanks, Keren *
>
> On Wed, Nov 9, 2016 at 4:50 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
>
>> Hi Keren,
>>
>> On 11/09/2016 03:40 PM, Keren Hochman wrote:
>>> On Wed, Nov 9, 2016 at 3:40 PM, Christian Ehrhardt <
>>> christian.ehrhardt@canonical.com> wrote:
>>>
>>>>
>>>> On Wed, Nov 9, 2016 at 1:55 PM, Keren Hochman <
>>>> keren.hochman@lightcyber.com> wrote:
>>>>
>>>>> how can I create mempool without hugepages?My application is running
>> on a
>>>>> pcap file so no huge pages is needed ?
>>>>>
>>>>
>>>> Not sure if that is what you really want (Debug use only), but in
>> general
>>>> no-huge is available as EAL arg
>>>>
>>>> From http://pktgen.readthedocs.io/en/latest/usage_eal.html :
>>>>
>>>> EAL options for DEBUG use only:
>>>> --no-huge : Use malloc instead of hugetlbfs
>>>>
>>> I need this option only for testing. How can I use rte_mempool_create if
>> I
>>> use --no-huge?
>>
>> When using --no-huge, the dpdk libraries (including mempool) allocate
>> its memory in standard memory. Just keep in mind the physical addresses
>> will be wrong, so this memory cannot be given to hw devices.
>>
>> Regards,
>> Olivier
>>
Regards,
Keith
^ permalink raw reply
* Re: disable hugepages
From: Keren Hochman @ 2016-11-10 12:32 UTC (permalink / raw)
To: Olivier Matz; +Cc: Christian Ehrhardt, dev
In-Reply-To: <af2edd56-f900-4317-2d78-f7c6051e8502@6wind.com>
I tried using the following dpdk options:
--no-huge --vdev eth_pcap0 ,rx_pcap=/t1,tx_pcap=/t2
*It's worked but the number of elements is limited, although the machine
has enough free memory. *rte_mempool_create is failed when I'm trying to
allocate more memory. Is there any limitation on the memory beside the
machine?
*Thanks, Keren *
On Wed, Nov 9, 2016 at 4:50 PM, Olivier Matz <olivier.matz@6wind.com> wrote:
> Hi Keren,
>
> On 11/09/2016 03:40 PM, Keren Hochman wrote:
> > On Wed, Nov 9, 2016 at 3:40 PM, Christian Ehrhardt <
> > christian.ehrhardt@canonical.com> wrote:
> >
> >>
> >> On Wed, Nov 9, 2016 at 1:55 PM, Keren Hochman <
> >> keren.hochman@lightcyber.com> wrote:
> >>
> >>> how can I create mempool without hugepages?My application is running
> on a
> >>> pcap file so no huge pages is needed ?
> >>>
> >>
> >> Not sure if that is what you really want (Debug use only), but in
> general
> >> no-huge is available as EAL arg
> >>
> >> From http://pktgen.readthedocs.io/en/latest/usage_eal.html :
> >>
> >> EAL options for DEBUG use only:
> >> --no-huge : Use malloc instead of hugetlbfs
> >>
> > I need this option only for testing. How can I use rte_mempool_create if
> I
> > use --no-huge?
>
> When using --no-huge, the dpdk libraries (including mempool) allocate
> its memory in standard memory. Just keep in mind the physical addresses
> will be wrong, so this memory cannot be given to hw devices.
>
> Regards,
> Olivier
>
^ permalink raw reply
* [PATCH] maintainers: add staging tree for network drivers
From: Ferruh Yigit @ 2016-11-10 12:14 UTC (permalink / raw)
To: dev; +Cc: Bruce Richardson, Thomas Monjalon
In-Reply-To: <20160725162143.GA34436@bricha3-MOBL3>
Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
---
CC: Bruce Richardson <bruce.richardson@intel.com>
CC: Thomas Monjalon <thomas.monjalon@6wind.com>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 065397b..d6bb8f8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -252,6 +252,8 @@ F: examples/l2fwd-crypto/
Networking Drivers
------------------
+M: Ferruh Yigit <ferruh.yigit@intel.com>
+T: git://dpdk.org/next/dpdk-next-net
Link bonding
M: Declan Doherty <declan.doherty@intel.com>
--
2.9.3
^ 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