* Re: [PATCH v2 0/4] provide man pages for binaries provided by DPDK
From: Thomas Monjalon @ 2016-10-26 21:32 UTC (permalink / raw)
To: christian.ehrhardt; +Cc: dev
In-Reply-To: <1473854336.8480.10.camel@brocade.com>
> > Christian Ehrhardt (4):
> > doc: move tool guides in their own subdirectory
> > doc: rendering and installation of man pages
> > doc: add basic invocation info for dpdk-pmdinfo
> > doc: add basic invocation info for dpdk-devbind
>
> Acked-by: Luca Boccassi <lboccass@brocade.com>
Applied with minor comments from John and me fixed, thanks
^ permalink raw reply
* Re: [PATCH v4 18/32] net/qede: add missing 100G link speed capability
From: Harish Patil @ 2016-10-26 21:28 UTC (permalink / raw)
To: Thomas Monjalon, Rasesh Mody, ferruh.yigit@intel.com,
bruce.richardson@intel.com
Cc: dev@dpdk.org, Dept-Eng DPDK Dev
In-Reply-To: <4491648.SeJM0cAZEU@xps13>
>2016-10-18 21:11, Rasesh Mody:
>> From: Harish Patil <harish.patil@qlogic.com>
>>
>> This patch fixes the missing 100G link speed advertisement
>> when the 100G support was initially added.
>>
>> Fixes: 2af14ca79c0a ("net/qede: support 100G")
>>
>> Signed-off-by: Harish Patil <harish.patil@qlogic.com>
>[...]
>> [Features]
>> +Speed capabilities = Y
>
>This feature should be checked only when it is fully implemented,
>i.e. when you return the real capabilities of the device.
>
>> --- a/drivers/net/qede/qede_ethdev.c
>> +++ b/drivers/net/qede/qede_ethdev.c
>> @@ -599,7 +599,8 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
>> DEV_TX_OFFLOAD_UDP_CKSUM |
>> DEV_TX_OFFLOAD_TCP_CKSUM);
>>
>> - dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G;
>> + dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G |
>> + ETH_LINK_SPEED_100G;
>> }
>
>It is only faking the capabilities at driver-level.
>You should check if the underlying device is able to achieve 100G
>before advertising this flag to the application.
>
>I suggest to update this patch to remove the doc update.
>The contract is to fill it only when the code is fixed.
>By the way, we must call every other drivers to properly implement
>this feature.
>
Hi Thomas,
Its not really a faking. The same driver supports all three link speeds.
The required support for 100G was already present in the 16.07 inbox
driver.
We just had missed out advertising 100G link speed via
dev_info->speed_capa.
Hence it is - Fixes: 2af14ca79c0a ("net/qede: support 100G”).
Hope it is okay.
Thanks,
Harish
^ permalink raw reply
* Re: [PATCH v2 2/4] doc: rendering and installation of man pages
From: Thomas Monjalon @ 2016-10-26 21:13 UTC (permalink / raw)
To: Christian Ehrhardt; +Cc: dev
In-Reply-To: <1472629812-4397-3-git-send-email-christian.ehrhardt@canonical.com>
2016-08-31 09:50, Christian Ehrhardt:
> +ifneq ($(wildcard $O/doc/man/*/*.1),)
> + $(Q)$(call rte_mkdir, $(DESTDIR)$(mandir))
This line is useless because implicit in the next one.
> + $(Q)$(call rte_mkdir, $(DESTDIR)$(mandir)/man1)
> + $(Q)cp -a $O/doc/man/*/*.1 $(DESTDIR)$(mandir)/man1
> +endif
There is also a small alignment issue.
^ permalink raw reply
* Re: [PATCH v4 07/32] net/qede: fix 32 bit compilation
From: Mody, Rasesh @ 2016-10-26 21:01 UTC (permalink / raw)
To: Thomas Monjalon, Rasesh Mody
Cc: dev@dpdk.org, Dept-EngDPDKDev@qlogic.com, ferruh.yigit@intel.com
In-Reply-To: <1638805.EFUnSErrGQ@xps13>
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, October 26, 2016 9:54 AM
>
> 2016-10-18 21:11, Rasesh Mody:
> > Fix 32 bit compilation for gcc version 4.3.4.
> >
> > Fixes: ec94dbc57362 ("qede: add base driver")
> >
> > Signed-off-by: Rasesh Mody <rasesh.mody@qlogic.com>
> [...]
> > ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
> > +ifeq ($(shell gcc -Wno-unused-but-set-variable -Werror -E - <
> > +/dev/null > /dev/null 2>&1; echo $$?),0)
> > CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
> > +endif
> > CFLAGS_BASE_DRIVER += -Wno-missing-declarations
> > +ifeq ($(shell gcc -Wno-maybe-uninitialized -Werror -E - < /dev/null >
> > +/dev/null 2>&1; echo $$?),0)
> > CFLAGS_BASE_DRIVER += -Wno-maybe-uninitialized
> > +endif
> > CFLAGS_BASE_DRIVER += -Wno-strict-prototypes ifeq ($(shell test
> > $(GCC_VERSION) -ge 60 && echo 1), 1) CFLAGS_BASE_DRIVER +=
> > -Wno-shift-negative-value
>
> What the hell are you doing here?
In one of our compilation testing on i586, we have gcc version 4.3.4. This version of gcc gives us following errors:
cc1: error: unrecognized command line option "-Wno-unused-but-set-variable"
cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
-Wno-unused-but-set-variable option was added only in gcc version 5.1.0
-Wno-maybe-uninitialized option was added only in gcc version 4.7.0
All that above change does is that it checks if -Wno-unused-but-set-variable and -Wno-maybe-uninitialized options are available with gcc only then include them for compilation.
> 1/ You should better fix "unused-but-set-variable" errors 2/ It won't work
> when cross-compiling because you do not use $(CC)
> in $(shell gcc
We tested on gcc version 6.2.0 on x86_64 without applying this patch. Errors related to "unused-but-set-variable" option were not seen. The only errors we saw are as noted above due to an older version of gcc.
We do use $(shell gcc, however, it is used under ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y), so, I believe it should work when cross-compiling. For example, in one of our compilation testing on clang version 3.8.0, with this patch applied, we did not see any errors. Please let us know if you see otherwise.
However, I do agree it is better to use $(CC). We could change that with a follow on patch.
Thanks!
-Rasesh
>
> I really do not want to look at the qede patches.
> But each time my eyes stop on one of them, I'm struggling.
^ permalink raw reply
* Re: [PATCH v2] doc: arm64: document DPDK application profiling methods
From: Thomas Monjalon @ 2016-10-26 20:07 UTC (permalink / raw)
To: Jerin Jacob, john.mcnamara; +Cc: dev, viktorin
In-Reply-To: <1475657009-11139-1-git-send-email-jerin.jacob@caviumnetworks.com>
2016-10-05 14:13, Jerin Jacob:
> Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> v2:
> -Addressed ARM64 specific review comments(Suggested by Thomas)
I feel more comments could be done, especially about formatting.
You are adding a chapter Introduction without any other section
of the same level.
Some technical terms should be enclosed in backquotes.
Please John, could you guide Jerin or provide an updated version?
Thanks
^ permalink raw reply
* Re: [PATCH] doc: add note on primary process dependency
From: Thomas Monjalon @ 2016-10-26 19:58 UTC (permalink / raw)
To: Reshma Pattan; +Cc: dev
In-Reply-To: <1476371342-8946-1-git-send-email-reshma.pattan@intel.com>
2016-10-13 16:09, Reshma Pattan:
> The note i.e. "The dpdk-pdump tool can only be used in
> conjunction with a primary process which has the packet
> capture framework initialized already" is added to
> doc/guides/sample_app_ug/pdump.rst to facilitate
> easy understanding on the usage of the tool.
>
> Suggested-by: Jianfeng Tan <jianfeng.tan@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH] pdump: revert PCI device name conversion
From: Thomas Monjalon @ 2016-10-26 19:55 UTC (permalink / raw)
To: Pattan, Reshma; +Cc: dev
In-Reply-To: <9F7182E3F746AB4EA17801C148F3C60409E15CB7@IRSMSX101.ger.corp.intel.com>
> > Earlier ethdev library created the device names in the "bus:device.func"
> > format hence pdump library implemented its own conversion method for
> > changing the user passed device name format "domain:bus:device.func" to
> > "bus:device.func"
> > for finding the port id using device name using ethdev library calls. Now after
> > ethdev and eal rework http://dpdk.org/dev/patchwork/patch/15855/,
> > the device names are created in the format "domain:bus:device.func", so
> > pdump library conversion is not needed any more, hence removed the
> > corresponding code.
> >
> > Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
>
> Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Vincent Jardin @ 2016-10-26 18:37 UTC (permalink / raw)
To: Van Haaren, Harry, Jerin Jacob, dev
Cc: Eads, Gage, Vangati, Narender, thomas.monjalon
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA6129AD56F@IRSMSX102.ger.corp.intel.com>
Le 26 octobre 2016 2:11:26 PM "Van Haaren, Harry"
<harry.van.haaren@intel.com> a écrit :
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
>>
>> So far, I have received constructive feedback from Intel, NXP and Linaro folks.
>> Let me know, if anyone else interested in contributing to the definition of
>> eventdev?
>>
>> If there are no major issues in proposed spec, then Cavium would like work on
>> implementing and up-streaming the common code(lib/librte_eventdev/) and
>> an associated HW driver.(Requested minor changes of v2 will be addressed
>> in next version).
>
> Hi All,
>
> I will propose a minor change to the rte_event struct, allowing some bits
> to be implementation specific. Currently the rte_event struct has no space
> to allow an implementation store any metadata about the event. For software
> performance it would be really helpful if there are some bits available for
> the implementation to keep some flags about each event.
>
> I suggest to rework the struct as below which opens 6 bits that were
> otherwise wasted, and define them as implementation specific. By
> implementation specific it is understood that the implementation can
> overwrite any information stored in those bits, and the application must
> not expect the data to remain after the event is scheduled.
>
> OLD:
> struct rte_event {
> uint32_t flow_id:24;
> uint32_t queue_id:8;
> uint8_t sched_type; /* Note only 2 bits of 8 are required */
>
> NEW:
> struct rte_event {
> uint32_t flow_id:24;
> uint32_t sched_type:2; /* reduced size : but 2 bits is enough for the
> enqueue types Ordered,Atomic,Parallel.*/
> uint32_t implementation:6; /* available for implementation specific
> metadata */
> uint8_t queue_id; /* still 8 bits as before */
Bitfileds are efficients on Octeon. What's about other CPUs you have in
mind? x86 is not as efficient.
>
>
> Thoughts? -Harry
^ permalink raw reply
* [PATCH] net/vmxnet3: fix mbuf release on reset/stop
From: Yong Wang @ 2016-10-26 17:45 UTC (permalink / raw)
To: stephen; +Cc: dev
During device reset/stop, vmxnet3 releases all mbufs in tx and
rx cmd ring. For rx, we should go over all ring descriptors and
free using rte_pktmbuf_free_seg() instead of rte_pktmbuf_free()
as the metadata of the mbuf might not be properly initialized
(initialization after mempool creation is done in the rx routine)
and the mbuf should always be a single-segment one when populated.
For tx, we can use the existing way as mbuf, if any, will be a
valid one stashed in the eop.
Fixes: dfaff37fc46d ("vmxnet3: import new vmxnet3 poll mode driver implementation")
Signed-off-by: Yong Wang <yongwang@vmware.com>
---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 34 +++++++++++++++++++++++++++++-----
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index 31f396c..b109168 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -140,10 +140,10 @@ vmxnet3_txq_dump(struct vmxnet3_tx_queue *txq)
#endif
static void
-vmxnet3_cmd_ring_release_mbufs(vmxnet3_cmd_ring_t *ring)
+vmxnet3_tx_cmd_ring_release_mbufs(vmxnet3_cmd_ring_t *ring)
{
while (ring->next2comp != ring->next2fill) {
- /* No need to worry about tx desc ownership, device is quiesced by now. */
+ /* No need to worry about desc ownership, device is quiesced by now. */
vmxnet3_buf_info_t *buf_info = ring->buf_info + ring->next2comp;
if (buf_info->m) {
@@ -157,9 +157,27 @@ vmxnet3_cmd_ring_release_mbufs(vmxnet3_cmd_ring_t *ring)
}
static void
+vmxnet3_rx_cmd_ring_release_mbufs(vmxnet3_cmd_ring_t *ring)
+{
+ uint32_t i;
+
+ for (i = 0; i < ring->size; i++) {
+ /* No need to worry about desc ownership, device is quiesced by now. */
+ vmxnet3_buf_info_t *buf_info = &ring->buf_info[i];
+
+ if (buf_info->m) {
+ rte_pktmbuf_free_seg(buf_info->m);
+ buf_info->m = NULL;
+ buf_info->bufPA = 0;
+ buf_info->len = 0;
+ }
+ vmxnet3_cmd_ring_adv_next2comp(ring);
+ }
+}
+
+static void
vmxnet3_cmd_ring_release(vmxnet3_cmd_ring_t *ring)
{
- vmxnet3_cmd_ring_release_mbufs(ring);
rte_free(ring->buf_info);
ring->buf_info = NULL;
}
@@ -170,6 +188,8 @@ vmxnet3_dev_tx_queue_release(void *txq)
vmxnet3_tx_queue_t *tq = txq;
if (tq != NULL) {
+ /* Release mbufs */
+ vmxnet3_tx_cmd_ring_release_mbufs(&tq->cmd_ring);
/* Release the cmd_ring */
vmxnet3_cmd_ring_release(&tq->cmd_ring);
}
@@ -182,6 +202,10 @@ vmxnet3_dev_rx_queue_release(void *rxq)
vmxnet3_rx_queue_t *rq = rxq;
if (rq != NULL) {
+ /* Release mbufs */
+ for (i = 0; i < VMXNET3_RX_CMDRING_SIZE; i++)
+ vmxnet3_rx_cmd_ring_release_mbufs(&rq->cmd_ring[i]);
+
/* Release both the cmd_rings */
for (i = 0; i < VMXNET3_RX_CMDRING_SIZE; i++)
vmxnet3_cmd_ring_release(&rq->cmd_ring[i]);
@@ -199,7 +223,7 @@ vmxnet3_dev_tx_queue_reset(void *txq)
if (tq != NULL) {
/* Release the cmd_ring mbufs */
- vmxnet3_cmd_ring_release_mbufs(&tq->cmd_ring);
+ vmxnet3_tx_cmd_ring_release_mbufs(&tq->cmd_ring);
}
/* Tx vmxnet rings structure initialization*/
@@ -228,7 +252,7 @@ vmxnet3_dev_rx_queue_reset(void *rxq)
if (rq != NULL) {
/* Release both the cmd_rings mbufs */
for (i = 0; i < VMXNET3_RX_CMDRING_SIZE; i++)
- vmxnet3_cmd_ring_release_mbufs(&rq->cmd_ring[i]);
+ vmxnet3_rx_cmd_ring_release_mbufs(&rq->cmd_ring[i]);
}
ring0 = &rq->cmd_ring[0];
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] doc/guides: add more info re VT-d/iommu settings for QAT
From: Jain, Deepak K @ 2016-10-26 17:38 UTC (permalink / raw)
To: Trahe, Fiona, dev@dpdk.org
In-Reply-To: <1477495224-2235-1-git-send-email-fiona.trahe@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Fiona Trahe
> Sent: Wednesday, October 26, 2016 4:20 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] doc/guides: add more info re VT-d/iommu
> settings for QAT
>
> add more info re VT-d/iommu settings for QAT remove limitation re
> performance tuning
>
> Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
> ---
> doc/guides/cryptodevs/qat.rst | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
> index 70bc2b1..bbe0b12 100644
> --- a/doc/guides/cryptodevs/qat.rst
> +++ b/doc/guides/cryptodevs/qat.rst
>
> --
> 2.5.0
Acked-by: Deepak Kumar Jain<deepak.k.jain@intel.com>
^ permalink raw reply
* rte_eth_dev_config_restore problem
From: Igor Ryzhov @ 2016-10-26 17:33 UTC (permalink / raw)
To: dev@dpdk.org; +Cc: Thomas Monjalon
Hello everyone,
I think there is a bug in rte_eth_dev_config_restore function.
During restoration of MAC address configuration, all MAC addresses are
restored with mac_addr_add function, but as I think MAC address with index
0 shouldn't be restored in such way, because it is a default MAC address.
This problem can be solved in two ways:
1. Just call mac_addr_set instead of mac_addr_add for index 0.
2. Don't restore address with index 0 at all and let driver do it.
I think the second option is the right one, because:
1. Some drivers don't support mac_addr_set at all, it means that we must
not touch it.
2. Some drivers already support restoration of default MAC address. For
example, look at the ixgbe "ixgbe_init_rx_addrs_generic" function. It
restores default MAC address if it was overridden by user. All that we have
to do is to rewrite hw->mac.addr in mac_addr_set function.
Best regards,
Igor
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-10-26 17:30 UTC (permalink / raw)
To: Bruce Richardson; +Cc: dev, gage.eads, narender.vangati, thomas.monjalon
In-Reply-To: <20161026124325.GA33288@bricha3-MOBL3.ger.corp.intel.com>
On Wed, Oct 26, 2016 at 01:43:25PM +0100, Bruce Richardson wrote:
> On Tue, Oct 25, 2016 at 11:19:05PM +0530, Jerin Jacob wrote:
> > On Wed, Oct 12, 2016 at 01:00:16AM +0530, Jerin Jacob wrote:
> > > Thanks to Intel and NXP folks for the positive and constructive feedback
> > > I've received so far. Here is the updated RFC(v2).
> > >
> > > I've attempted to address as many comments as possible.
> > >
> > > This series adds rte_eventdev.h to the DPDK tree with
> > > adequate documentation in doxygen format.
> > >
> > > Updates are also available online:
> > >
> > > Related draft header file (this patch):
> > > https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h
> > >
> > > PDF version(doxgen output):
> > > https://rawgit.com/jerinjacobk/libeventdev/master/librte_eventdev_v2.pdf
> > >
> > > Repo:
> > > https://github.com/jerinjacobk/libeventdev
> > >
> >
> > Hi Community,
> >
> > So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> > Let me know, if anyone else interested in contributing to the definition of eventdev?
> >
> > If there are no major issues in proposed spec, then Cavium would like work on
> > implementing and up-streaming the common code(lib/librte_eventdev/) and
> > an associated HW driver.(Requested minor changes of v2 will be addressed
> > in next version).
> >
> > We are planning to submit the work for 17.02 or 17.05 release(based on
> > how implementation goes).
> >
>
> Hi Jerin,
Hi Bruce,
>
> thanks for driving this. In terms of the common code framework, when
> would you see that you might have something to upstream for that? As you
> know, we've been working on a software implementation which we are now
> looking to move to the eventdev APIs, and which also needs this common
> code to support it.
>
> If it can accelerate this effort, we can perhaps provide as an RFC
> the common code part that we have implemented for our work, or else we
> are happy to migrate to use common code you provide if it can be
> upstreamed fairly soon.
I have already started the common code framework. I will send the common code
as RFC in couple of days with vdev and pci bus interface.
>
> Regards,
> /Bruce
^ permalink raw reply
* [PATCH v2] doc/guides: add more info about VT-d/iommu settings
From: Fiona Trahe @ 2016-10-26 17:23 UTC (permalink / raw)
To: dev
In-Reply-To: <1477495224-2235-1-git-send-email-fiona.trahe@intel.com>
Add more information about VT-d/iommu settings for QAT PMD.
Remove limitation indicating QAT driver is not performance tuned.
Signed-off-by: Fiona Trahe <fiona.trahe@intel.com>
---
v2:
clarified commit message
doc/guides/cryptodevs/qat.rst | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst
index 70bc2b1..bbe0b12 100644
--- a/doc/guides/cryptodevs/qat.rst
+++ b/doc/guides/cryptodevs/qat.rst
@@ -77,7 +77,6 @@ Limitations
* Hash only is not supported except SNOW 3G UIA2 and KASUMI F9.
* Cipher only is not supported except SNOW 3G UEA2, KASUMI F8 and 3DES.
* Only supports the session-oriented API implementation (session-less APIs are not supported).
-* Not performance tuned.
* SNOW 3G (UEA2) and KASUMI (F8) supported only if cipher length, cipher offset fields are byte-aligned.
* SNOW 3G (UIA2) and KASUMI (F9) supported only if hash length, hash offset fields are byte-aligned.
* No BSD support as BSD QAT kernel driver not available.
@@ -201,7 +200,7 @@ The steps below assume you are:
* Running DPDK on a platform with one ``DH895xCC`` device.
* On a kernel at least version 4.4.
-In BIOS ensure that SRIOV is enabled and VT-d is disabled.
+In BIOS ensure that SRIOV is enabled and either a) disable VT-d or b) enable VT-d and set ``"intel_iommu=on iommu=pt"`` in the grub file.
Ensure the QAT driver is loaded on your system, by executing::
@@ -260,7 +259,7 @@ The steps below assume you are:
* Running DPDK on a platform with one ``C62x`` device.
* On a kernel at least version 4.5.
-In BIOS ensure that SRIOV is enabled and VT-d is disabled.
+In BIOS ensure that SRIOV is enabled and either a) disable VT-d or b) enable VT-d and set ``"intel_iommu=on iommu=pt"`` in the grub file.
Ensure the QAT driver is loaded on your system, by executing::
@@ -304,7 +303,7 @@ The steps below assume you are:
* Running DPDK on a platform with one ``C3xxx`` device.
* On a kernel at least version 4.5.
-In BIOS ensure that SRIOV is enabled and VT-d is disabled.
+In BIOS ensure that SRIOV is enabled and either a) disable VT-d or b) enable VT-d and set ``"intel_iommu=on iommu=pt"`` in the grub file.
Ensure the QAT driver is loaded on your system, by executing::
--
2.5.0
^ permalink raw reply related
* Re: [PATCH v4 00/32] net/qede: update qede pmd to 1.2.0.1 and enable by default
From: Mody, Rasesh @ 2016-10-26 17:01 UTC (permalink / raw)
To: Thomas Monjalon, Rasesh Mody
Cc: dev@dpdk.org, Dept-EngDPDKDev@qlogic.com, ferruh.yigit@intel.com
In-Reply-To: <39933081.0D9pxCKPPb@xps13>
Hi Thomas,
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, October 26, 2016 8:20 AM
>
> 2016-10-24 14:41, Bruce Richardson:
> > On Tue, Oct 18, 2016 at 09:11:14PM -0700, Rasesh Mody wrote:
> > > Please apply to DPDK tree for v16.11 release.
> >
> > Patchset applied to dpdk_next_net/rel_16_11
>
> It breaks compilation because it is enabled everywhere and zlib.h is still
> included without checking CONFIG_ECORE_ZIPPED_FW.
> The patch removing zlib dependency was not tested without zlib installed.
> I will fix it while applying with this change:
Sorry, we missed to test the patch removing zlib dependency from latest patch set when zlib headers are unavailable.
The zlib.h include is not needed in bcm_osal.c. It got left out there when zlib.h was included in ecore.h file by patch "[PATCH v4 03/32] net/qede: use FW CONFIG defines as needed". In ecore.h it is protected by ifdef, however, same is not true about bcm_osal.c. Hence compilation complains when zlib.h is not available.
--- a/drivers/net/qede/base/bcm_osal.c
+++ b/drivers/net/qede/base/bcm_osal.c
@@ -6,8 +6,6 @@
* See LICENSE.qede_pmd for copyright and licensing details.
*/
-#include <zlib.h>
-
#include <rte_memzone.h>
#include <rte_errno.h>
> --- a/drivers/net/qede/base/bcm_osal.c
> +++ b/drivers/net/qede/base/bcm_osal.c
> @@ -6,7 +6,9 @@
> * See LICENSE.qede_pmd for copyright and licensing details.
> */
>
> +#ifdef CONFIG_ECORE_ZIPPED_FW
> #include <zlib.h>
> +#endif
>
> #include <rte_memzone.h>
> #include <rte_errno.h>
>
Above change looks fine. Thanks!
> I won't do any quality review of qede patches but from what I've seen
> before, there is some room for improvements.
>
> Another nit, important to help reviews, please use --in-reply-to when
> sending a new revision of a patch to keep them in the same thread and allow
> us to understand the progress.
> I plan to do an automatic nack for patches missing the --in-reply-to.
Sure, will do.
Thanks!
-Rasesh
^ permalink raw reply
* Re: [PATCH] doc/guides: add more info re VT-d/iommu settings for QAT
From: Thomas Monjalon @ 2016-10-26 16:59 UTC (permalink / raw)
To: Trahe, Fiona; +Cc: dev
In-Reply-To: <348A99DA5F5B7549AA880327E580B435891157AC@IRSMSX101.ger.corp.intel.com>
2016-10-26 16:50, Trahe, Fiona:
> Hi Thomas,
>
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2016-10-26 16:20, Fiona Trahe:
> > > add more info re VT-d/iommu settings for QAT remove limitation re
> > > performance tuning
> >
> > Sorry, I do not understand what means "re".
>
> "re" is commonly used in the English language and means "in reference to" or "about"
> but I'm happy to change to "about" which is the more conventional word.
> There's an interesting explanation of the evolution of the term here:
> https://en.oxforddictionaries.com/definition/re
> Usage
> The traditional view is that re should be used in headings and references, as in Re: Ainsworth versus Chambers, but not as a normal word meaning 'about', as in I saw the deputy head re the incident. However, the evidence suggests that re is now widely used in the second context in official and semi-official contexts, and is now generally accepted. It is hard to see any compelling logical argument against using it as an ordinary English word in this way
Thanks for the detailed explanations, and sorry again for my ignorance :)
^ permalink raw reply
* Re: [PATCH v4 07/32] net/qede: fix 32 bit compilation
From: Thomas Monjalon @ 2016-10-26 16:54 UTC (permalink / raw)
To: Rasesh Mody; +Cc: dev, Dept-EngDPDKDev, ferruh.yigit
In-Reply-To: <1476850306-2141-8-git-send-email-rasesh.mody@qlogic.com>
2016-10-18 21:11, Rasesh Mody:
> Fix 32 bit compilation for gcc version 4.3.4.
>
> Fixes: ec94dbc57362 ("qede: add base driver")
>
> Signed-off-by: Rasesh Mody <rasesh.mody@qlogic.com>
[...]
> ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
> +ifeq ($(shell gcc -Wno-unused-but-set-variable -Werror -E - < /dev/null > /dev/null 2>&1; echo $$?),0)
> CFLAGS_BASE_DRIVER += -Wno-unused-but-set-variable
> +endif
> CFLAGS_BASE_DRIVER += -Wno-missing-declarations
> +ifeq ($(shell gcc -Wno-maybe-uninitialized -Werror -E - < /dev/null > /dev/null 2>&1; echo $$?),0)
> CFLAGS_BASE_DRIVER += -Wno-maybe-uninitialized
> +endif
> CFLAGS_BASE_DRIVER += -Wno-strict-prototypes
> ifeq ($(shell test $(GCC_VERSION) -ge 60 && echo 1), 1)
> CFLAGS_BASE_DRIVER += -Wno-shift-negative-value
What the hell are you doing here?
1/ You should better fix "unused-but-set-variable" errors
2/ It won't work when cross-compiling because you do not use $(CC)
in $(shell gcc
I really do not want to look at the qede patches.
But each time my eyes stop on one of them, I'm struggling.
^ permalink raw reply
* Re: [PATCH] doc/guides: add more info re VT-d/iommu settings for QAT
From: Trahe, Fiona @ 2016-10-26 16:50 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev@dpdk.org
In-Reply-To: <1620839.dXv2gATAhT@xps13>
Hi Thomas,
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, October 26, 2016 4:27 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] doc/guides: add more info re VT-d/iommu
> settings for QAT
>
> 2016-10-26 16:20, Fiona Trahe:
> > add more info re VT-d/iommu settings for QAT remove limitation re
> > performance tuning
>
> Sorry, I do not understand what means "re".
"re" is commonly used in the English language and means "in reference to" or "about"
but I'm happy to change to "about" which is the more conventional word.
There's an interesting explanation of the evolution of the term here:
https://en.oxforddictionaries.com/definition/re
Usage
The traditional view is that re should be used in headings and references, as in Re: Ainsworth versus Chambers, but not as a normal word meaning 'about', as in I saw the deputy head re the incident. However, the evidence suggests that re is now widely used in the second context in official and semi-official contexts, and is now generally accepted. It is hard to see any compelling logical argument against using it as an ordinary English word in this way
> Please use an uppercase at the beginning of each sentence and a dot at the
> end. It helps reading.
Ok.
I was confusing this with the style needed for the email subject, which is the opposite!
^ permalink raw reply
* Re: [PATCH v6 1/2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
From: Wu, Jingjing @ 2016-10-26 16:33 UTC (permalink / raw)
To: Iremonger, Bernard, dev@dpdk.org, Shah, Rahul R, Lu, Wenzhuo,
Dumitrescu, Cristian
In-Reply-To: <8CEF83825BEC744B83065625E567D7C21A09E1FF@IRSMSX108.ger.corp.intel.com>
> -----Original Message-----
> From: Iremonger, Bernard
> Sent: Thursday, October 27, 2016 12:10 AM
> To: Wu, Jingjing <jingjing.wu@intel.com>; dev@dpdk.org; Shah, Rahul R
> <rahul.r.shah@intel.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>
> Subject: RE: [PATCH v6 1/2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
>
> Hi Jingling,
>
> <snip>
>
> > > > Subject: [PATCH v6 1/2] net/ixgbe: support multiqueue mode VMDq DCB
> > > > with SRIOV
> > > >
> > > > The folowing changes have been made to allow Data Centre Bridge
> > > > (DCB) configuration when SRIOV is enabled.
> > > >
> > > > Modify ixgbe_check_mq_mode function, when SRIOV is enabled, enable
> > > > mq_mode ETH_MQ_RX_VMDQ_DCB and ETH_MQ_TX_VMDQ_DCB.
> > > >
> > > > Modify ixgbe_dcb_tx_hw_config function, replace the struct ixgbe_hw
> > > > parameter with a struct rte_eth_dev parameter and handle SRIOV
> > > > enabled.
> > > >
> > > > Modify ixgbe_dev_mq_rx_configure function, when SRIOV is enabled,
> > > > enable mq_mode ETH_MQ_RX_VMDQ_DCB.
> > > >
> > > > Modify ixgbe_configure_dcb function, revise check on
> > > > dev->data->nb_rx_queues.
> > > >
> > > > Signed-off-by: Rahul R Shah <rahul.r.shah@intel.com>
> > > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> > > > Acked-by: Wenzhuo Lu <Wenzhuo.lu@intel.com>
> > > > ---
> > > > drivers/net/ixgbe/ixgbe_ethdev.c | 11 ++++++-----
> > > > drivers/net/ixgbe/ixgbe_rxtx.c | 35 ++++++++++++++++++++++--------
> > ---
> > > --
> > > > 2 files changed, 28 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > > index 4ca5747..4d5ce83 100644
> > > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > > @@ -1977,6 +1977,9 @@ ixgbe_check_mq_mode(struct rte_eth_dev
> > > *dev)
> > > > /* check multi-queue mode */
> > > > switch (dev_conf->rxmode.mq_mode) {
> > > > case ETH_MQ_RX_VMDQ_DCB:
> > > > + PMD_INIT_LOG(INFO, "ETH_MQ_RX_VMDQ_DCB
> > > mode supported in SRIOV");
> > > > + dev->data->dev_conf.rxmode.mq_mode =
> > > ETH_MQ_RX_VMDQ_DCB;
> > > This line is duplicated, mq_mode is ETH_MQ_RX_VMDQ_DCB already.
> >
> > The mq_mode is assigned at this point in the other cases. This case is coded
> > in line with the other cases.
> >
> > > and it's better to check if the nb_queue is valid.
> >
> The nb_rx_q and nb_tx_q are checked after the switch statements at line 2027 with the v6
> patch applied.
Thanks, it's fine then. :)
> Regards,
>
> Bernard.
^ permalink raw reply
* Re: [PATCH v6 1/2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
From: Iremonger, Bernard @ 2016-10-26 16:09 UTC (permalink / raw)
To: Wu, Jingjing, dev@dpdk.org, Shah, Rahul R, Lu, Wenzhuo,
Dumitrescu, Cristian
In-Reply-To: <8CEF83825BEC744B83065625E567D7C21A09E16F@IRSMSX108.ger.corp.intel.com>
Hi Jingling,
<snip>
> > > Subject: [PATCH v6 1/2] net/ixgbe: support multiqueue mode VMDq DCB
> > > with SRIOV
> > >
> > > The folowing changes have been made to allow Data Centre Bridge
> > > (DCB) configuration when SRIOV is enabled.
> > >
> > > Modify ixgbe_check_mq_mode function, when SRIOV is enabled, enable
> > > mq_mode ETH_MQ_RX_VMDQ_DCB and ETH_MQ_TX_VMDQ_DCB.
> > >
> > > Modify ixgbe_dcb_tx_hw_config function, replace the struct ixgbe_hw
> > > parameter with a struct rte_eth_dev parameter and handle SRIOV
> > > enabled.
> > >
> > > Modify ixgbe_dev_mq_rx_configure function, when SRIOV is enabled,
> > > enable mq_mode ETH_MQ_RX_VMDQ_DCB.
> > >
> > > Modify ixgbe_configure_dcb function, revise check on
> > > dev->data->nb_rx_queues.
> > >
> > > Signed-off-by: Rahul R Shah <rahul.r.shah@intel.com>
> > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> > > Acked-by: Wenzhuo Lu <Wenzhuo.lu@intel.com>
> > > ---
> > > drivers/net/ixgbe/ixgbe_ethdev.c | 11 ++++++-----
> > > drivers/net/ixgbe/ixgbe_rxtx.c | 35 ++++++++++++++++++++++--------
> ---
> > --
> > > 2 files changed, 28 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > index 4ca5747..4d5ce83 100644
> > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > @@ -1977,6 +1977,9 @@ ixgbe_check_mq_mode(struct rte_eth_dev
> > *dev)
> > > /* check multi-queue mode */
> > > switch (dev_conf->rxmode.mq_mode) {
> > > case ETH_MQ_RX_VMDQ_DCB:
> > > + PMD_INIT_LOG(INFO, "ETH_MQ_RX_VMDQ_DCB
> > mode supported in SRIOV");
> > > + dev->data->dev_conf.rxmode.mq_mode =
> > ETH_MQ_RX_VMDQ_DCB;
> > This line is duplicated, mq_mode is ETH_MQ_RX_VMDQ_DCB already.
>
> The mq_mode is assigned at this point in the other cases. This case is coded
> in line with the other cases.
>
> > and it's better to check if the nb_queue is valid.
>
The nb_rx_q and nb_tx_q are checked after the switch statements at line 2027 with the v6 patch applied.
Regards,
Bernard.
^ permalink raw reply
* Re: [PATCH v4 18/32] net/qede: add missing 100G link speed capability
From: Bruce Richardson @ 2016-10-26 15:54 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev, Dept-EngDPDKDev, ferruh.yigit
In-Reply-To: <4491648.SeJM0cAZEU@xps13>
On Wed, Oct 26, 2016 at 05:41:58PM +0200, Thomas Monjalon wrote:
> 2016-10-18 21:11, Rasesh Mody:
> > From: Harish Patil <harish.patil@qlogic.com>
> >
> > This patch fixes the missing 100G link speed advertisement
> > when the 100G support was initially added.
> >
> > Fixes: 2af14ca79c0a ("net/qede: support 100G")
> >
> > Signed-off-by: Harish Patil <harish.patil@qlogic.com>
> [...]
> > [Features]
> > +Speed capabilities = Y
>
> This feature should be checked only when it is fully implemented,
> i.e. when you return the real capabilities of the device.
>
> > --- a/drivers/net/qede/qede_ethdev.c
> > +++ b/drivers/net/qede/qede_ethdev.c
> > @@ -599,7 +599,8 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
> > DEV_TX_OFFLOAD_UDP_CKSUM |
> > DEV_TX_OFFLOAD_TCP_CKSUM);
> >
> > - dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G;
> > + dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G |
> > + ETH_LINK_SPEED_100G;
> > }
>
> It is only faking the capabilities at driver-level.
> You should check if the underlying device is able to achieve 100G
> before advertising this flag to the application.
>
> I suggest to update this patch to remove the doc update.
> The contract is to fill it only when the code is fixed.
> By the way, we must call every other drivers to properly implement
> this feature.
I agree that devices should only advertise speeds they support and the
doc should reflect this ability (or lack of this ability) in a driver.
Regards,
/Bruce
^ permalink raw reply
* Re: [PATCH v2] net/i40e: fix Rx hang when disable LLDP
From: Bruce Richardson @ 2016-10-26 15:51 UTC (permalink / raw)
To: Wu, Jingjing; +Cc: dev@dpdk.org
In-Reply-To: <9BB6961774997848B5B42BEC655768F80E295A42@SHSMSX103.ccr.corp.intel.com>
On Wed, Oct 26, 2016 at 04:47:31PM +0100, Wu, Jingjing wrote:
>
>
> > -----Original Message-----
> > From: Richardson, Bruce
> > Sent: Wednesday, October 26, 2016 11:44 PM
> > To: Wu, Jingjing <jingjing.wu@intel.com>
> > Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Zhang, Helin <helin.zhang@intel.com>;
> > dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: fix Rx hang when disable LLDP
> >
> > On Wed, Oct 26, 2016 at 03:12:41PM +0000, Wu, Jingjing wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Zhang, Qi Z
> > > > Sent: Thursday, October 20, 2016 4:40 AM
> > > > To: Wu, Jingjing <jingjing.wu@intel.com>; Zhang, Helin
> > > > <helin.zhang@intel.com>
> > > > Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>
> > > > Subject: [PATCH v2] net/i40e: fix Rx hang when disable LLDP
> > > >
> > > > Remove stopping LLDP as a workaround for a known errata which can cause
> > > > Rx hang.
> > > >
> > > > Fixes: 4861cde46116 ("i40e: new poll mode driver")
> > > >
> > > > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> > >
> > > Acked-by: Jingjing Wu <jingjing.wu@intel.com>
> > >
> > I'm hoping to apply this patch to make it in RC2. However, there is an
> > errata mentioned in the commit log, so it would be good to actually
> > include a reference or link to the errata itself, so that the reader can
> > look it up himself. Can you supply such a link to the errata in
> > question?
> >
> errata #70 in the Public Spec Update with link
> http://www.intel.com/content/www/us/en/embedded/products/networking/xl710-10-40-controller-spec-update.html
>
> Thanks
> Jingjing
Applied to dpdk-next-net/rel_16_11 with errata link included in commit
message.
thanks,
/Bruce
^ permalink raw reply
* Re: [PATCH v2] net/i40e: fix Rx hang when disable LLDP
From: Wu, Jingjing @ 2016-10-26 15:47 UTC (permalink / raw)
To: Richardson, Bruce; +Cc: dev@dpdk.org
In-Reply-To: <20161026154419.GB42064@bricha3-MOBL3.ger.corp.intel.com>
> -----Original Message-----
> From: Richardson, Bruce
> Sent: Wednesday, October 26, 2016 11:44 PM
> To: Wu, Jingjing <jingjing.wu@intel.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; Zhang, Helin <helin.zhang@intel.com>;
> dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] net/i40e: fix Rx hang when disable LLDP
>
> On Wed, Oct 26, 2016 at 03:12:41PM +0000, Wu, Jingjing wrote:
> >
> >
> > > -----Original Message-----
> > > From: Zhang, Qi Z
> > > Sent: Thursday, October 20, 2016 4:40 AM
> > > To: Wu, Jingjing <jingjing.wu@intel.com>; Zhang, Helin
> > > <helin.zhang@intel.com>
> > > Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>
> > > Subject: [PATCH v2] net/i40e: fix Rx hang when disable LLDP
> > >
> > > Remove stopping LLDP as a workaround for a known errata which can cause
> > > Rx hang.
> > >
> > > Fixes: 4861cde46116 ("i40e: new poll mode driver")
> > >
> > > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
> >
> > Acked-by: Jingjing Wu <jingjing.wu@intel.com>
> >
> I'm hoping to apply this patch to make it in RC2. However, there is an
> errata mentioned in the commit log, so it would be good to actually
> include a reference or link to the errata itself, so that the reader can
> look it up himself. Can you supply such a link to the errata in
> question?
>
errata #70 in the Public Spec Update with link
http://www.intel.com/content/www/us/en/embedded/products/networking/xl710-10-40-controller-spec-update.html
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH v2] net/i40e: fix Rx hang when disable LLDP
From: Bruce Richardson @ 2016-10-26 15:44 UTC (permalink / raw)
To: Wu, Jingjing; +Cc: dev@dpdk.org
In-Reply-To: <9BB6961774997848B5B42BEC655768F80E295523@SHSMSX103.ccr.corp.intel.com>
On Wed, Oct 26, 2016 at 03:12:41PM +0000, Wu, Jingjing wrote:
>
>
> > -----Original Message-----
> > From: Zhang, Qi Z
> > Sent: Thursday, October 20, 2016 4:40 AM
> > To: Wu, Jingjing <jingjing.wu@intel.com>; Zhang, Helin
> > <helin.zhang@intel.com>
> > Cc: dev@dpdk.org; Zhang, Qi Z <qi.z.zhang@intel.com>
> > Subject: [PATCH v2] net/i40e: fix Rx hang when disable LLDP
> >
> > Remove stopping LLDP as a workaround for a known errata which can cause
> > Rx hang.
> >
> > Fixes: 4861cde46116 ("i40e: new poll mode driver")
> >
> > Signed-off-by: Qi Zhang <qi.z.zhang@intel.com>
>
> Acked-by: Jingjing Wu <jingjing.wu@intel.com>
>
I'm hoping to apply this patch to make it in RC2. However, there is an
errata mentioned in the commit log, so it would be good to actually
include a reference or link to the errata itself, so that the reader can
look it up himself. Can you supply such a link to the errata in
question?
/Bruce
^ permalink raw reply
* Re: [PATCH v4 18/32] net/qede: add missing 100G link speed capability
From: Thomas Monjalon @ 2016-10-26 15:41 UTC (permalink / raw)
To: Rasesh Mody, ferruh.yigit, bruce.richardson, Harish Patil
Cc: dev, Dept-EngDPDKDev
In-Reply-To: <1476850306-2141-19-git-send-email-rasesh.mody@qlogic.com>
2016-10-18 21:11, Rasesh Mody:
> From: Harish Patil <harish.patil@qlogic.com>
>
> This patch fixes the missing 100G link speed advertisement
> when the 100G support was initially added.
>
> Fixes: 2af14ca79c0a ("net/qede: support 100G")
>
> Signed-off-by: Harish Patil <harish.patil@qlogic.com>
[...]
> [Features]
> +Speed capabilities = Y
This feature should be checked only when it is fully implemented,
i.e. when you return the real capabilities of the device.
> --- a/drivers/net/qede/qede_ethdev.c
> +++ b/drivers/net/qede/qede_ethdev.c
> @@ -599,7 +599,8 @@ qede_dev_info_get(struct rte_eth_dev *eth_dev,
> DEV_TX_OFFLOAD_UDP_CKSUM |
> DEV_TX_OFFLOAD_TCP_CKSUM);
>
> - dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G;
> + dev_info->speed_capa = ETH_LINK_SPEED_25G | ETH_LINK_SPEED_40G |
> + ETH_LINK_SPEED_100G;
> }
It is only faking the capabilities at driver-level.
You should check if the underlying device is able to achieve 100G
before advertising this flag to the application.
I suggest to update this patch to remove the doc update.
The contract is to fill it only when the code is fixed.
By the way, we must call every other drivers to properly implement
this feature.
^ permalink raw reply
* Re: [PATCH v7] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
From: Bruce Richardson @ 2016-10-26 15:41 UTC (permalink / raw)
To: Bernard Iremonger; +Cc: dev
In-Reply-To: <1477495720-21590-1-git-send-email-bernard.iremonger@intel.com>
On Wed, Oct 26, 2016 at 04:28:40PM +0100, Bernard Iremonger wrote:
> The folowing changes have been made to allow Data Centre Bridge
> (DCB) configuration when SRIOV is enabled.
>
> Modify ixgbe_check_mq_mode function,
> when SRIOV is enabled, enable mq_mode
> ETH_MQ_RX_VMDQ_DCB and ETH_MQ_TX_VMDQ_DCB.
>
> Modify ixgbe_dcb_tx_hw_config function,
> replace the struct ixgbe_hw parameter with a
> struct rte_eth_dev parameter and handle SRIOV enabled.
>
> Modify ixgbe_dev_mq_rx_configure function,
> when SRIOV is enabled, enable mq_mode ETH_MQ_RX_VMDQ_DCB.
>
> Modify ixgbe_configure_dcb function,
> revise check on dev->data->nb_rx_queues.
>
> Signed-off-by: Rahul R Shah <rahul.r.shah@intel.com>
> Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> Acked-by: Wenzhuo Lu <Wenzhuo.lu@intel.com>
Applied to dpdk-next-net/rel_16_11 with commit message cut down to just
the high-level functional change.
/Bruce
^ 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