* Re: [PATCH] doc: add limitation for L3fwd-power app
From: Mcnamara, John @ 2016-11-04 13:04 UTC (permalink / raw)
To: De Lara Guarch, Pablo, dev@dpdk.org; +Cc: De Lara Guarch, Pablo
In-Reply-To: <1478263697-57575-1-git-send-email-pablo.de.lara.guarch@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Pablo de Lara
> Sent: Friday, November 4, 2016 12:48 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Subject: [dpdk-dev] [PATCH] doc: add limitation for L3fwd-power app
>
> L3fwd-power app needs vector mode to be disabled in order to work
> properly. The app used to work previously, because it was using Rx scalar
> function, but now it uses vector function.
>
> Vector mode needs to be disabled to make the app works, which has been
> documented in release notes.
>
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* [PATCH] net/i40e: fix dcb configure failure
From: Jingjing Wu @ 2016-11-04 5:42 UTC (permalink / raw)
To: dev; +Cc: jingjing.wu, beilei.xing, helin.zhang
Removing stopping LLDP in firmware is a workaround for a
known errata which can cause Rx hang. But the changing will
cause DCB configuration fails. That is because when LLDP is
enabled, the return value of i40e_init_dcb is success. But
following check just considered the case when LLDP agent
is disabled.
This patch fixes this issue.
Fixes: fcbd40d4327b ("net/i40e: fix Rx hang when disable LLDP")
Signed-off-by: Jingjing Wu <jingjing.wu@intel.com>
---
drivers/net/i40e/i40e_ethdev.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bb81b15..5afca1e 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -9428,12 +9428,12 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool sw_dcb)
*/
if (sw_dcb == TRUE) {
ret = i40e_init_dcb(hw);
- /* if sw_dcb, lldp agent is stopped, the return from
+ /* If lldp agent is stopped, the return value from
* i40e_init_dcb we expect is failure with I40E_AQ_RC_EPERM
- * adminq status.
+ * adminq status. Otherwise, it should return success.
*/
- if (ret != I40E_SUCCESS &&
- hw->aq.asq_last_status == I40E_AQ_RC_EPERM) {
+ if ((ret == I40E_SUCCESS) || (ret != I40E_SUCCESS &&
+ hw->aq.asq_last_status == I40E_AQ_RC_EPERM)) {
memset(&hw->local_dcbx_config, 0,
sizeof(struct i40e_dcbx_config));
/* set dcb default configuration */
@@ -9462,8 +9462,8 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool sw_dcb)
return -ENOSYS;
}
} else {
- PMD_INIT_LOG(ERR, "DCBX configuration failed, err = %d,"
- " aq_err = %d.", ret,
+ PMD_INIT_LOG(ERR, "DCB initialization in FW fails,"
+ " err = %d, aq_err = %d.", ret,
hw->aq.asq_last_status);
return -ENOTSUP;
}
--
2.4.11
^ permalink raw reply related
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Maxime Coquelin @ 2016-11-04 12:54 UTC (permalink / raw)
To: Wang, Zhihong, Yuanhan Liu
Cc: stephen@networkplumber.org, Pierre Pfister (ppfister),
Xie, Huawei, dev@dpdk.org, vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <8F6C2BD409508844A0EFC19955BE09414E7DC66F@SHSMSX103.ccr.corp.intel.com>
On 11/04/2016 01:30 PM, Wang, Zhihong wrote:
>
>
>> -----Original Message-----
>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
>> Sent: Friday, November 4, 2016 7:23 PM
>> To: Wang, Zhihong <zhihong.wang@intel.com>; Yuanhan Liu
>> <yuanhan.liu@linux.intel.com>
>> Cc: stephen@networkplumber.org; Pierre Pfister (ppfister)
>> <ppfister@cisco.com>; Xie, Huawei <huawei.xie@intel.com>; dev@dpdk.org;
>> vkaplans@redhat.com; mst@redhat.com
>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to the
>> TX path
>>
>>
>>
>>>>>> Hi Maxime,
>>>>>>
>>>>>> I did a little more macswap test and found out more stuff here:
>>>>> Thanks for doing more tests.
>>>>>
>>>>>>
>>>>>> 1. I did loopback test on another HSW machine with the same H/W,
>>>>>> and indirect_desc on and off seems have close perf
>>>>>>
>>>>>> 2. So I checked the gcc version:
>>>>>>
>>>>>> * Previous: gcc version 6.2.1 20160916 (Fedora 24)
>>>>>>
>>>>>> * New: gcc version 5.4.0 20160609 (Ubuntu 16.04.1 LTS)
>>>>>
>>>>> On my side, I tested with RHEL7.3:
>>>>> - gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>>>>>
>>>>> It certainly contains some backports from newer GCC versions.
>>>>>
>>>>>>
>>>>>> On previous one indirect_desc has 20% drop
>>>>>>
>>>>>> 3. Then I compiled binary on Ubuntu and scp to Fedora, and as
>>>>>> expected I got the same perf as on Ubuntu, and the perf gap
>>>>>> disappeared, so gcc is definitely one factor here
>>>>>>
>>>>>> 4. Then I use the Ubuntu binary on Fedora for PVP test, then the
>>>>>> perf gap comes back again and the same with the Fedora binary
>>>>>> results, indirect_desc causes about 20% drop
>>>>>
>>>>> Let me know if I understand correctly:
>>>
>>> Yes, and it's hard to breakdown further at this time.
>>>
>>> Also we may need to check whether it's caused by certain NIC
>>> model. Unfortunately I don't have the right setup right now.
>>>
>>>>> Loopback test with macswap:
>>>>> - gcc version 6.2.1 : 20% perf drop
>>>>> - gcc version 5.4.0 : No drop
>>>>>
>>>>> PVP test with macswap:
>>>>> - gcc version 6.2.1 : 20% perf drop
>>>>> - gcc version 5.4.0 : 20% perf drop
>>>>
>>>> I forgot to ask, did you recompile only host, or both host and guest
>>>> testmpd's in your test?
>>
>>> Both.
>>
>> I recompiled testpmd on a Fedora 24 machine using GCC6:
>> gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
>> Testing loopback with macswap on my Haswell RHEL7.3 machine gives me the
>> following results:
>> - indirect on: 7.75Mpps
>> - indirect off: 7.35Mpps
>>
>> Surprisingly, I get better results with indirect on my setup (I
>> reproduced the tests multiple times).
>>
>> Do you have a document explaining the tuning/config you apply to both
>> the host and the guest (isolation, HT, hugepage size, ...) in your
>> setup?
>
>
> The setup where it goes wrong:
> 1. Xeon E5-2699, HT on, turbo off, 1GB hugepage for both host and guest
On the Haswell machine (on which I don't have BIOS access), HT is on,
but I unplug siblings at runtime.
I also have 1G pages on both sides, and I isolate the cores used by both
testpmd and vCPUS.
> 2. Fortville 40G
> 3. Fedora 4.7.5-200.fc24.x86_64
> 4. gcc version 6.2.1
> 5. 16.11 RC2 for both host and guest
> 6. PVP, testpmd macswap for both host and guest
>
> BTW, I do see indirect_desc gives slightly better performance for loopback
> in tests on other platforms, but don't know how PVP performs yet.
Interesting, other platforms are also Haswell/Broadwell?
For PVP benchmarks, are your figures with 0% pkt loss?
Thanks,
Maxime
>
>
>>
>> Regards,
>> Maxime
^ permalink raw reply
* [PATCH] doc: add limitation for L3fwd-power app
From: Pablo de Lara @ 2016-11-04 12:48 UTC (permalink / raw)
To: dev; +Cc: Pablo de Lara
L3fwd-power app needs vector mode to be disabled in order to work
properly. The app used to work previously, because it was using
Rx scalar function, but now it uses vector function.
Vector mode needs to be disabled to make the app works,
which has been documented in release notes.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
doc/guides/rel_notes/release_16_11.rst | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index aa0c09a..cb4ec97 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -178,6 +178,17 @@ Known Issues
This section is a comment. Make sure to start the actual text at the margin.
+* **L3fwd-power app does not work properly when Rx vector is enabled.**
+
+ Using some drivers with vector enabled, makes L3fwd-power app not work
+ properly, since the queue monitoring works differently when using
+ scalar compared to vector, making the frequency scaling not to work correctly.
+ In addition, L3fwd-power requires the mbuf to have correct packet type,
+ but in some drivers, the vector mode must be disabled for this.
+
+ Therefore, in order to use L3fwd-power, vector mode should be disabled
+ from the config file.
+
API Changes
-----------
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Wang, Zhihong @ 2016-11-04 12:30 UTC (permalink / raw)
To: Maxime Coquelin, Yuanhan Liu
Cc: stephen@networkplumber.org, Pierre Pfister (ppfister),
Xie, Huawei, dev@dpdk.org, vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <cf5e40da-0201-8c89-5314-96c87894da12@redhat.com>
> -----Original Message-----
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Friday, November 4, 2016 7:23 PM
> To: Wang, Zhihong <zhihong.wang@intel.com>; Yuanhan Liu
> <yuanhan.liu@linux.intel.com>
> Cc: stephen@networkplumber.org; Pierre Pfister (ppfister)
> <ppfister@cisco.com>; Xie, Huawei <huawei.xie@intel.com>; dev@dpdk.org;
> vkaplans@redhat.com; mst@redhat.com
> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support to the
> TX path
>
>
>
> >>>> Hi Maxime,
> >>>>
> >>>> I did a little more macswap test and found out more stuff here:
> >>> Thanks for doing more tests.
> >>>
> >>>>
> >>>> 1. I did loopback test on another HSW machine with the same H/W,
> >>>> and indirect_desc on and off seems have close perf
> >>>>
> >>>> 2. So I checked the gcc version:
> >>>>
> >>>> * Previous: gcc version 6.2.1 20160916 (Fedora 24)
> >>>>
> >>>> * New: gcc version 5.4.0 20160609 (Ubuntu 16.04.1 LTS)
> >>>
> >>> On my side, I tested with RHEL7.3:
> >>> - gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
> >>>
> >>> It certainly contains some backports from newer GCC versions.
> >>>
> >>>>
> >>>> On previous one indirect_desc has 20% drop
> >>>>
> >>>> 3. Then I compiled binary on Ubuntu and scp to Fedora, and as
> >>>> expected I got the same perf as on Ubuntu, and the perf gap
> >>>> disappeared, so gcc is definitely one factor here
> >>>>
> >>>> 4. Then I use the Ubuntu binary on Fedora for PVP test, then the
> >>>> perf gap comes back again and the same with the Fedora binary
> >>>> results, indirect_desc causes about 20% drop
> >>>
> >>> Let me know if I understand correctly:
> >
> > Yes, and it's hard to breakdown further at this time.
> >
> > Also we may need to check whether it's caused by certain NIC
> > model. Unfortunately I don't have the right setup right now.
> >
> >>> Loopback test with macswap:
> >>> - gcc version 6.2.1 : 20% perf drop
> >>> - gcc version 5.4.0 : No drop
> >>>
> >>> PVP test with macswap:
> >>> - gcc version 6.2.1 : 20% perf drop
> >>> - gcc version 5.4.0 : 20% perf drop
> >>
> >> I forgot to ask, did you recompile only host, or both host and guest
> >> testmpd's in your test?
>
> > Both.
>
> I recompiled testpmd on a Fedora 24 machine using GCC6:
> gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
> Testing loopback with macswap on my Haswell RHEL7.3 machine gives me the
> following results:
> - indirect on: 7.75Mpps
> - indirect off: 7.35Mpps
>
> Surprisingly, I get better results with indirect on my setup (I
> reproduced the tests multiple times).
>
> Do you have a document explaining the tuning/config you apply to both
> the host and the guest (isolation, HT, hugepage size, ...) in your
> setup?
The setup where it goes wrong:
1. Xeon E5-2699, HT on, turbo off, 1GB hugepage for both host and guest
2. Fortville 40G
3. Fedora 4.7.5-200.fc24.x86_64
4. gcc version 6.2.1
5. 16.11 RC2 for both host and guest
6. PVP, testpmd macswap for both host and guest
BTW, I do see indirect_desc gives slightly better performance for loopback
in tests on other platforms, but don't know how PVP performs yet.
>
> Regards,
> Maxime
^ permalink raw reply
* Re: [PATCH] examples/l3fwd-power: fix inappropiate Rx queue count method
From: De Lara Guarch, Pablo @ 2016-11-04 12:23 UTC (permalink / raw)
To: dev@dpdk.org
In-Reply-To: <1478217850-77177-1-git-send-email-pablo.de.lara.guarch@intel.com>
> -----Original Message-----
> From: De Lara Guarch, Pablo
> Sent: Friday, November 04, 2016 12:04 AM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo
> Subject: [PATCH] examples/l3fwd-power: fix inappropiate Rx queue count
> method
>
> Since commit b4f3c136a179 ("net/ixgbe: support checksum flags in SSE vector
> Rx"),
> when HW IP Checksum is enabled, the RX vector function is available to use.
> In case of L3fwd-power, since it is enabled, the RX vector function
> was not used, but after this commit, it is. This has affected the way
> to calculate how full an RX queue is, using rte_eth_rx_descriptor done
> function, making the frequency to be at maximum, even when the frequency
> is very low.
>
> This commit reverts the way to know how full a queue is to the
> previous way, using rte_eth_rx_queue_count(), making it work for both
> vector and scalar RX functions.
>
> Fixes: b451aa39db31 ("examples/l3fwd-power: use DD bit rather than RX
> queue count")
>
> Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
NACK, after doing some more tests with other drivers, this solution does not work.
Will send a documentation patch instead.
^ permalink raw reply
* Re: [PATCH v3] net/kni: add KNI PMD
From: Ferruh Yigit @ 2016-11-04 12:21 UTC (permalink / raw)
To: Yong Wang; +Cc: dev@dpdk.org
In-Reply-To: <BY2PR05MB2359471CAB7D494E39CFEE56AFA30@BY2PR05MB2359.namprd05.prod.outlook.com>
Hi Yong,
Thank you for the review.
On 11/3/2016 1:24 AM, Yong Wang wrote:
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit
>> Sent: Monday, October 10, 2016 6:20 AM
>> To: dev@dpdk.org
>> Cc: Ferruh Yigit <ferruh.yigit@intel.com>
>> Subject: [dpdk-dev] [PATCH v3] net/kni: add KNI PMD
>>
>> Add KNI PMD which wraps librte_kni for ease of use.
>>
>> KNI PMD can be used as any regular PMD to send / receive packets to the
>> Linux networking stack.
>>
>> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
>> ---
>>
>> v3:
>> * rebase on top of latest master
>>
>> v2:
>> * updated driver name eth_kni -> net_kni
>> ---
<...>
>> CONFIG_RTE_LIBRTE_KNI=n
>> +CONFIG_RTE_LIBRTE_PMD_KNI=n
>
> Nit: change this to CONFIG_RTE_LIBRTE_KNI_PMD instead to be consistent with all other pmds.
There is an inconsistency between virtual and physical PMD config options.
Physical ones: xxx_PMD=
*IXGBE_PMD, *I40E_PMD, *ENA_PMD, ...
Virtual ones: PMD_xxx=
*PMD_RING, *PMD_PCAP, *PMD_NULL, ...
So I am consistent with inconsistency J
<...>
>> +#define DRV_NAME net_kni
>
> The name generated this way is not consistent with other vdevs. Why not simply assign "KNI PMD" to drv_name?
Right, it is not consistent but intentionaly.
With macro RTE_PMD_REGISTER_VDEV(net_kni, xxx), rte_driver.name set to
"net_kni"
and if you set drivername to "KNI PMD", pmd will report driver name as
"KNI PMD"
so there will be two different driver names, I tried to unify them to a
single name.
And some physical drivers already does same thing.
<...>
>> +static uint16_t
>> +eth_kni_rx(void *q, struct rte_mbuf **bufs, uint16_t nb_bufs)
>> +{
>> + struct pmd_queue *kni_q = q;
>> + struct rte_kni *kni = kni_q->internals->kni;
>> + uint16_t nb_pkts;
>> +
>> + nb_pkts = rte_kni_rx_burst(kni, bufs, nb_bufs);
>> +
>> + kni_q->rx.pkts += nb_pkts;
>> + kni_q->rx.err_pkts += nb_bufs - nb_pkts;
>> +
>> + return nb_pkts;
>> +}
>> +
>
> I don't think it's safe to do receive from two queues concurrently on two cores sharing the same underlying KNI device due to the current limitation of KNI user-space queues not being multi-thread safe.
You are right, above code is not safe.
It is possible to create a KNI interface per queue, but I don't see any
advantage of this against creating a new virtual KNI port.
So I will limit to single queue.
> Is the proposed plan to have the application layer implement
synchronization logic?
> If that's the case, it needs to be clearly documented and depending on
the implementation, measurable overhead will be incurred.
> Otherwise (only single-queue supported), could you check queue number
if the application tries to configure multi-queue?
>
<...>
>> +static struct rte_eth_dev *
>> +eth_kni_create(const char *name, unsigned int numa_node)
>> +{
>> + struct pmd_internals *internals = NULL;
>> + struct rte_eth_dev_data *data;
>> + struct rte_eth_dev *eth_dev;
>> + uint16_t nb_rx_queues = 1;
>> + uint16_t nb_tx_queues = 1;
>
> Since these two values are always 1 here, I think they could be removed.
I will remove them.
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Maxime Coquelin @ 2016-11-04 11:39 UTC (permalink / raw)
To: Yuanhan Liu
Cc: Wang, Zhihong, stephen@networkplumber.org,
Pierre Pfister (ppfister), Xie, Huawei, dev@dpdk.org,
vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <20161104113628.GC16751@yliu-dev.sh.intel.com>
On 11/04/2016 12:36 PM, Yuanhan Liu wrote:
> On Fri, Nov 04, 2016 at 12:22:47PM +0100, Maxime Coquelin wrote:
>>
>>
>>>>>> Hi Maxime,
>>>>>>
>>>>>> I did a little more macswap test and found out more stuff here:
>>>>> Thanks for doing more tests.
>>>>>
>>>>>>
>>>>>> 1. I did loopback test on another HSW machine with the same H/W,
>>>>>> and indirect_desc on and off seems have close perf
>>>>>>
>>>>>> 2. So I checked the gcc version:
>>>>>>
>>>>>> * Previous: gcc version 6.2.1 20160916 (Fedora 24)
>>>>>>
>>>>>> * New: gcc version 5.4.0 20160609 (Ubuntu 16.04.1 LTS)
>>>>>
>>>>> On my side, I tested with RHEL7.3:
>>>>> - gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>>>>>
>>>>> It certainly contains some backports from newer GCC versions.
>>>>>
>>>>>>
>>>>>> On previous one indirect_desc has 20% drop
>>>>>>
>>>>>> 3. Then I compiled binary on Ubuntu and scp to Fedora, and as
>>>>>> expected I got the same perf as on Ubuntu, and the perf gap
>>>>>> disappeared, so gcc is definitely one factor here
>>>>>>
>>>>>> 4. Then I use the Ubuntu binary on Fedora for PVP test, then the
>>>>>> perf gap comes back again and the same with the Fedora binary
>>>>>> results, indirect_desc causes about 20% drop
>>>>>
>>>>> Let me know if I understand correctly:
>>>
>>> Yes, and it's hard to breakdown further at this time.
>>>
>>> Also we may need to check whether it's caused by certain NIC
>>> model. Unfortunately I don't have the right setup right now.
>>>
>>>>> Loopback test with macswap:
>>>>> - gcc version 6.2.1 : 20% perf drop
>>>>> - gcc version 5.4.0 : No drop
>>>>>
>>>>> PVP test with macswap:
>>>>> - gcc version 6.2.1 : 20% perf drop
>>>>> - gcc version 5.4.0 : 20% perf drop
>>>>
>>>> I forgot to ask, did you recompile only host, or both host and guest
>>>> testmpd's in your test?
>>
>>> Both.
>>
>> I recompiled testpmd on a Fedora 24 machine using GCC6:
>
> Have you built host DPDK with gcc6 as well?
Yes, I use the same build based on GCC6 on both sides.
>
> --yliu
>
>> gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
>> Testing loopback with macswap on my Haswell RHEL7.3 machine gives me the
>> following results:
>> - indirect on: 7.75Mpps
>> - indirect off: 7.35Mpps
>>
>> Surprisingly, I get better results with indirect on my setup (I
>> reproduced the tests multiple times).
>>
>> Do you have a document explaining the tuning/config you apply to both the
>> host and the guest (isolation, HT, hugepage size, ...) in your
>> setup?
>>
>> Regards,
>> Maxime
^ permalink raw reply
* Re: [PATCH v11 1/6] ethdev: add Tx preparation
From: Thomas Monjalon @ 2016-11-04 11:35 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: dev
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0CF990@irsmsx105.ger.corp.intel.com>
2016-11-01 12:57, Ananyev, Konstantin:
> > > > I suggest to integrate it in the beginning of 17.02 cycle, with the hope
> > > > that you can convince other developers to implement it in other drivers,
> > > > so we could finally enable it in the default config.
> > >
> > > Ok, any insights then, how we can convince people to do that?
> >
> > You just have to explain clearly what this new feature is bringing
> > and what will be the future possibilities.
> >
> > > BTW, it means then that tx_prep() should become part of mandatory API
> > > to be implemented by each PMD doing TX offloads, right?
> >
> > Right.
> > The question is "what means mandatory"?
>
> For me "mandatory" here would mean that:
> - if the PMD supports TX offloads AND
> - if to be able use any of these offloads the upper layer SW would have to:
> - modify the contents of the packet OR
> - obey HW specific restrictions
> then it is a PMD developer responsibility to provide tx_prep() that would implement
> expected modifications of the packet contents and restriction checks.
> Otherwise, tx_prep() implementation is not required and can be safely set to NULL.
>
> Does it sounds good enough to everyone?
Yes, good definition, thanks.
> > Should we block some patches for non-compliant drivers?
>
> If we agree that it should be a 'mandatory' one - and patch in question breaks
> that requirement, then probably yes.
>
> > Should we remove offloads capability from non-compliant drivers?
>
> Do you mean existing PMDs?
> Are there any particular right now, that can't work properly with testpmd csumonly mode?
I cannot answer to this question.
Before txprep, there is only one API: the application must prepare the
packets checksum itself (get_psd_sum in testpmd).
With txprep, the application have 2 choices: keep doing the job itself
or call txprep which calls a PMD-specific function.
The question is: does non-Intel drivers need a checksum preparation for TSO?
Will it behave well if txprep does nothing in these drivers?
When looking at the code, most of drivers handle the TSO flags.
But it is hard to know whether they rely on the pseudo checksum or not.
git grep -l 'PKT_TX_UDP_CKSUM\|PKT_TX_TCP_CKSUM\|PKT_TX_TCP_SEG' drivers/net/
drivers/net/bnxt/bnxt_txr.c
drivers/net/cxgbe/sge.c
drivers/net/e1000/em_rxtx.c
drivers/net/e1000/igb_rxtx.c
drivers/net/ena/ena_ethdev.c
drivers/net/enic/enic_rxtx.c
drivers/net/fm10k/fm10k_rxtx.c
drivers/net/i40e/i40e_rxtx.c
drivers/net/ixgbe/ixgbe_rxtx.c
drivers/net/mlx4/mlx4.c
drivers/net/mlx5/mlx5_rxtx.c
drivers/net/nfp/nfp_net.c
drivers/net/qede/qede_rxtx.c
drivers/net/thunderx/nicvf_rxtx.c
drivers/net/virtio/virtio_rxtx.c
drivers/net/vmxnet3/vmxnet3_rxtx.c
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Yuanhan Liu @ 2016-11-04 11:36 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Wang, Zhihong, stephen@networkplumber.org,
Pierre Pfister (ppfister), Xie, Huawei, dev@dpdk.org,
vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <cf5e40da-0201-8c89-5314-96c87894da12@redhat.com>
On Fri, Nov 04, 2016 at 12:22:47PM +0100, Maxime Coquelin wrote:
>
>
> >>>>Hi Maxime,
> >>>>
> >>>>I did a little more macswap test and found out more stuff here:
> >>>Thanks for doing more tests.
> >>>
> >>>>
> >>>> 1. I did loopback test on another HSW machine with the same H/W,
> >>>> and indirect_desc on and off seems have close perf
> >>>>
> >>>> 2. So I checked the gcc version:
> >>>>
> >>>> * Previous: gcc version 6.2.1 20160916 (Fedora 24)
> >>>>
> >>>> * New: gcc version 5.4.0 20160609 (Ubuntu 16.04.1 LTS)
> >>>
> >>>On my side, I tested with RHEL7.3:
> >>> - gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
> >>>
> >>>It certainly contains some backports from newer GCC versions.
> >>>
> >>>>
> >>>> On previous one indirect_desc has 20% drop
> >>>>
> >>>> 3. Then I compiled binary on Ubuntu and scp to Fedora, and as
> >>>> expected I got the same perf as on Ubuntu, and the perf gap
> >>>> disappeared, so gcc is definitely one factor here
> >>>>
> >>>> 4. Then I use the Ubuntu binary on Fedora for PVP test, then the
> >>>> perf gap comes back again and the same with the Fedora binary
> >>>> results, indirect_desc causes about 20% drop
> >>>
> >>>Let me know if I understand correctly:
> >
> >Yes, and it's hard to breakdown further at this time.
> >
> >Also we may need to check whether it's caused by certain NIC
> >model. Unfortunately I don't have the right setup right now.
> >
> >>>Loopback test with macswap:
> >>> - gcc version 6.2.1 : 20% perf drop
> >>> - gcc version 5.4.0 : No drop
> >>>
> >>>PVP test with macswap:
> >>> - gcc version 6.2.1 : 20% perf drop
> >>> - gcc version 5.4.0 : 20% perf drop
> >>
> >>I forgot to ask, did you recompile only host, or both host and guest
> >>testmpd's in your test?
>
> >Both.
>
> I recompiled testpmd on a Fedora 24 machine using GCC6:
Have you built host DPDK with gcc6 as well?
--yliu
> gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
> Testing loopback with macswap on my Haswell RHEL7.3 machine gives me the
> following results:
> - indirect on: 7.75Mpps
> - indirect off: 7.35Mpps
>
> Surprisingly, I get better results with indirect on my setup (I
> reproduced the tests multiple times).
>
> Do you have a document explaining the tuning/config you apply to both the
> host and the guest (isolation, HT, hugepage size, ...) in your
> setup?
>
> Regards,
> Maxime
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Maxime Coquelin @ 2016-11-04 11:22 UTC (permalink / raw)
To: Wang, Zhihong, Yuanhan Liu
Cc: stephen@networkplumber.org, Pierre Pfister (ppfister),
Xie, Huawei, dev@dpdk.org, vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <8F6C2BD409508844A0EFC19955BE09414E7DC5B6@SHSMSX103.ccr.corp.intel.com>
>>>> Hi Maxime,
>>>>
>>>> I did a little more macswap test and found out more stuff here:
>>> Thanks for doing more tests.
>>>
>>>>
>>>> 1. I did loopback test on another HSW machine with the same H/W,
>>>> and indirect_desc on and off seems have close perf
>>>>
>>>> 2. So I checked the gcc version:
>>>>
>>>> * Previous: gcc version 6.2.1 20160916 (Fedora 24)
>>>>
>>>> * New: gcc version 5.4.0 20160609 (Ubuntu 16.04.1 LTS)
>>>
>>> On my side, I tested with RHEL7.3:
>>> - gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
>>>
>>> It certainly contains some backports from newer GCC versions.
>>>
>>>>
>>>> On previous one indirect_desc has 20% drop
>>>>
>>>> 3. Then I compiled binary on Ubuntu and scp to Fedora, and as
>>>> expected I got the same perf as on Ubuntu, and the perf gap
>>>> disappeared, so gcc is definitely one factor here
>>>>
>>>> 4. Then I use the Ubuntu binary on Fedora for PVP test, then the
>>>> perf gap comes back again and the same with the Fedora binary
>>>> results, indirect_desc causes about 20% drop
>>>
>>> Let me know if I understand correctly:
>
> Yes, and it's hard to breakdown further at this time.
>
> Also we may need to check whether it's caused by certain NIC
> model. Unfortunately I don't have the right setup right now.
>
>>> Loopback test with macswap:
>>> - gcc version 6.2.1 : 20% perf drop
>>> - gcc version 5.4.0 : No drop
>>>
>>> PVP test with macswap:
>>> - gcc version 6.2.1 : 20% perf drop
>>> - gcc version 5.4.0 : 20% perf drop
>>
>> I forgot to ask, did you recompile only host, or both host and guest
>> testmpd's in your test?
> Both.
I recompiled testpmd on a Fedora 24 machine using GCC6:
gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
Testing loopback with macswap on my Haswell RHEL7.3 machine gives me the
following results:
- indirect on: 7.75Mpps
- indirect off: 7.35Mpps
Surprisingly, I get better results with indirect on my setup (I
reproduced the tests multiple times).
Do you have a document explaining the tuning/config you apply to both
the host and the guest (isolation, HT, hugepage size, ...) in your
setup?
Regards,
Maxime
^ permalink raw reply
* Re: [PATCH v2 1/2] arch/arm: fix file descriptor leakage when getting CPU features
From: Jan Viktorin @ 2016-11-04 11:19 UTC (permalink / raw)
To: Jianbo Liu; +Cc: dev, chaozhu
In-Reply-To: <1478252803-14672-1-git-send-email-jianbo.liu@linaro.org>
On Fri, 4 Nov 2016 15:16:42 +0530
Jianbo Liu <jianbo.liu@linaro.org> wrote:
> close the file descriptor after finish using it.
s/close/Close/
>
> Fixes: b94e5c94 (eal/arm: add CPU flags for ARMv7)
> Fixes: 97523f82 (eal/arm: add CPU flags for ARMv8)
>
> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
Acked-by: Jan Viktorin <viktorin@rehivetech.com>
^ permalink raw reply
* Re: [PATCH v2 2/2] arch/ppc: fix file descriptor leakage when getting CPU features
From: Jan Viktorin @ 2016-11-04 11:18 UTC (permalink / raw)
To: Jianbo Liu; +Cc: dev, chaozhu
In-Reply-To: <1478252803-14672-2-git-send-email-jianbo.liu@linaro.org>
On Fri, 4 Nov 2016 15:16:43 +0530
Jianbo Liu <jianbo.liu@linaro.org> wrote:
> close the file descriptor after finish using it.
s/close/Close/
Please include my ack (below).
Jan
>
> Fixes: 9ae15538 (eal/ppc: cpu flag checks for IBM Power)
>
> Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
Acked-by: Jan Viktorin <viktorin@rehivetech.com>
^ permalink raw reply
* [PATCH RESEND v2] net/i40e: fix floating VEB issue
From: Yuanhan Liu @ 2016-11-04 11:08 UTC (permalink / raw)
To: dev; +Cc: Jingjing Wu, Yu Liu, Beilei Xing
In-Reply-To: <20161104110129.GZ16751@yliu-dev.sh.intel.com>
From: Beilei Xing <beilei.xing@intel.com>
Turning off S-TAG identification will impact floating VEB,
VFs can't communicate with each other.
This patch fixes this issue by judging whether floating
VEB is enabled, S-TAG identification will be turned off
only when floating VEB is disabled.
Fixes: 4d61120d5ce7 ("net/i40e: fix dropping packets with ethertype 0x88A8")
Signed-off-by: Beilei Xing <beilei.xing@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
---
v2 changes:
* Modify the limitation description in i40e.rst
:: Seems that Beilei failed to send this patches out. While I have sent out few
:: patches out successfully, I'm sending it for her.
doc/guides/nics/i40e.rst | 6 ++++++
drivers/net/i40e/i40e_ethdev.c | 12 +++++++-----
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index c0163fc..5780268 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -453,3 +453,9 @@ To work around this issue, ``ethtool -s <dev> autoneg on`` should be
set first and then the link can be brought up through ``ifconfig <dev> up``.
NOTE: requires Linux kernel i40e driver version >= 1.4.X
+
+Receive packets with Ethertype 0x88A8
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Due to the FW limitation, PF can receive packets with Ethertype 0x88A8
+only when floating VEB is disabled.
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bb81b15..631a93f 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1121,11 +1121,13 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
/* Disable double vlan by default */
i40e_vsi_config_double_vlan(vsi, FALSE);
- /* Disable S-TAG identification by default */
- ret = I40E_READ_REG(hw, I40E_PRT_L2TAGSEN);
- if (ret & I40E_L2_TAGS_S_TAG_MASK) {
- ret &= ~I40E_L2_TAGS_S_TAG_MASK;
- I40E_WRITE_REG(hw, I40E_PRT_L2TAGSEN, ret);
+ /* Disable S-TAG identification when floating_veb is disabled */
+ if (!pf->floating_veb) {
+ ret = I40E_READ_REG(hw, I40E_PRT_L2TAGSEN);
+ if (ret & I40E_L2_TAGS_S_TAG_MASK) {
+ ret &= ~I40E_L2_TAGS_S_TAG_MASK;
+ I40E_WRITE_REG(hw, I40E_PRT_L2TAGSEN, ret);
+ }
}
if (!vsi->max_macaddrs)
--
2.5.0
^ permalink raw reply related
* Re: [PATCH RESEND v2] net/i40e: fix floating VEB issue
From: Yuanhan Liu @ 2016-11-04 11:01 UTC (permalink / raw)
To: dev; +Cc: Beilei Xing
In-Reply-To: <1478252000-11455-1-git-send-email-yuanhan.liu@linux.intel.com>
On Fri, Nov 04, 2016 at 05:33:20PM +0800, Yuanhan Liu wrote:
> Turning off S-TAG identification will impact floating VEB,
> VFs can't communicate with each other.
> This patch fixes this issue by judging whether floating
> VEB is enabled, S-TAG identification will be turned off
> only when floating VEB is disabled.
>
> Fixes: 4d61120d5ce7 ("net/i40e: fix dropping packets with ethertype 0x88A8")
>
> Signed-off-by: Beilei Xing <beilei.xing@intel.com>
> Acked-by: Jingjing Wu <jingjing.wu@intel.com>
> ---
> v2 changes:
> * Modify the limitation description in i40e.rst
>
> Seems that Beilei failed to send this patches out; while I have sent out few
> patches out successfully. I'm sending it for her.
Please ignore this patch. The original patch is with wrong format, that
it turns the authorship to me. I will resend another one soon.
--yliu
^ permalink raw reply
* Re: [PATCH 1/2 v2] bnxt: use appropriate data type in bnxt_alloc_vnic_attributes
From: Ferruh Yigit @ 2016-11-04 10:52 UTC (permalink / raw)
To: Ajit Khaparde, dev; +Cc: John W. Linville
In-Reply-To: <20161103185818.GA88405@C02PT1RBG8WP.wifi.aus.avagotech.net>
On 11/3/2016 6:58 PM, Ajit Khaparde wrote:
> Prevent the arithmetic in bnxt_alloc_vnic_attributes from causing
> any unintentional havoc because of the usage of a signed variable.
>
> Coverity: 137874
>
> Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
>
> --
> v2: Previous attempt did not seem complete.
> ---
> drivers/net/bnxt/bnxt_vnic.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/bnxt/bnxt_vnic.c b/drivers/net/bnxt/bnxt_vnic.c
> index 205a940..23c85af 100644
> --- a/drivers/net/bnxt/bnxt_vnic.c
> +++ b/drivers/net/bnxt/bnxt_vnic.c
> @@ -179,7 +179,7 @@ int bnxt_alloc_vnic_attributes(struct bnxt *bp)
> HW_HASH_INDEX_SIZE * sizeof(*vnic->rss_table) +
> HW_HASH_KEY_SIZE);
> uint16_t max_vnics;
> - int i;
> + uint16_t i;
>
> if (BNXT_PF(bp)) {
> struct bnxt_pf_info *pf = &bp->pf;
> @@ -197,7 +197,7 @@ int bnxt_alloc_vnic_attributes(struct bnxt *bp)
> mz = rte_memzone_lookup(mz_name);
> if (!mz) {
> mz = rte_memzone_reserve(mz_name,
> - entry_length * max_vnics,
> + (uint32_t) entry_length * max_vnics,
> SOCKET_ID_ANY,
> RTE_MEMZONE_2MB |
> RTE_MEMZONE_SIZE_HINT_ONLY);
> @@ -210,10 +210,11 @@ int bnxt_alloc_vnic_attributes(struct bnxt *bp)
>
> /* Allocate rss table and hash key */
> vnic->rss_table =
> - (void *)((char *)mz->addr + (entry_length * i));
> + (void *)((char *)mz->addr + ((uint32_t) entry_length * i));
> memset(vnic->rss_table, -1, entry_length);
>
> - vnic->rss_table_dma_addr = mz->phys_addr + (entry_length * i);
> + vnic->rss_table_dma_addr =
> + mz->phys_addr + ((uint32_t) entry_length * i);
((uint32_t) entry_length * i)
casting entry_length to uint32_t will prevent the integer promotion and
fix the coverity issue, but if this is the case, why not make
entry_length uint32_t at first place?
It seems "entry_length" converted from "int" to "uint16_t" to prevent
integer promotion (e8a197d2aa9a), but
"entry_length * max_vnics" => "uint16_t * uint16_t" or
"entry_length * i" => "uint16_t * int"
still causing the promotion.
I guess converting "entry_length" to uint32_t (instead of uint16_t) will
fix both triaged 127557 and new introduced 137874 coverity issues, and
it is simpler modification, - if I don't miss anything J
Thanks,
ferruh
> vnic->rss_hash_key = (void *)((char *)vnic->rss_table +
> HW_HASH_INDEX_SIZE * sizeof(*vnic->rss_table));
>
>
^ permalink raw reply
* Re: [PATCH v4] vhost: Add indirect descriptors support to the TX path
From: Wang, Zhihong @ 2016-11-04 10:43 UTC (permalink / raw)
To: Maxime Coquelin, Yuanhan Liu
Cc: stephen@networkplumber.org, Pierre Pfister (ppfister),
Xie, Huawei, dev@dpdk.org, vkaplans@redhat.com, mst@redhat.com
In-Reply-To: <7e1c8953-db15-f377-cece-85cb7169bb17@redhat.com>
> -----Original Message-----
> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> Sent: Friday, November 4, 2016 4:00 PM
> To: Wang, Zhihong <zhihong.wang@intel.com>; Yuanhan Liu
> <yuanhan.liu@linux.intel.com>
> Cc: stephen@networkplumber.org; Pierre Pfister (ppfister)
> <ppfister@cisco.com>; Xie, Huawei <huawei.xie@intel.com>; dev@dpdk.org;
> vkaplans@redhat.com; mst@redhat.com
> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors support
> to the TX path
>
>
>
> On 11/04/2016 08:57 AM, Maxime Coquelin wrote:
> > Hi Zhihong,
> >
> > On 11/04/2016 08:20 AM, Wang, Zhihong wrote:
> >>
> >>
> >>> -----Original Message-----
> >>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> >>> Sent: Thursday, November 3, 2016 4:11 PM
> >>> To: Wang, Zhihong <zhihong.wang@intel.com>; Yuanhan Liu
> >>> <yuanhan.liu@linux.intel.com>
> >>> Cc: stephen@networkplumber.org; Pierre Pfister (ppfister)
> >>> <ppfister@cisco.com>; Xie, Huawei <huawei.xie@intel.com>;
> dev@dpdk.org;
> >>> vkaplans@redhat.com; mst@redhat.com
> >>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors
> >>> support
> >>> to the TX path
> >>>
> >>>
> >>>
> >>> On 11/02/2016 11:51 AM, Maxime Coquelin wrote:
> >>>>
> >>>>
> >>>> On 10/31/2016 11:01 AM, Wang, Zhihong wrote:
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com]
> >>>>>> Sent: Friday, October 28, 2016 3:42 PM
> >>>>>> To: Wang, Zhihong <zhihong.wang@intel.com>; Yuanhan Liu
> >>>>>> <yuanhan.liu@linux.intel.com>
> >>>>>> Cc: stephen@networkplumber.org; Pierre Pfister (ppfister)
> >>>>>> <ppfister@cisco.com>; Xie, Huawei <huawei.xie@intel.com>;
> >>> dev@dpdk.org;
> >>>>>> vkaplans@redhat.com; mst@redhat.com
> >>>>>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect descriptors
> >>>>>> support
> >>>>>> to the TX path
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 10/28/2016 02:49 AM, Wang, Zhihong wrote:
> >>>>>>>
> >>>>>>>>> -----Original Message-----
> >>>>>>>>> From: Yuanhan Liu [mailto:yuanhan.liu@linux.intel.com]
> >>>>>>>>> Sent: Thursday, October 27, 2016 6:46 PM
> >>>>>>>>> To: Maxime Coquelin <maxime.coquelin@redhat.com>
> >>>>>>>>> Cc: Wang, Zhihong <zhihong.wang@intel.com>;
> >>>>>>>>> stephen@networkplumber.org; Pierre Pfister (ppfister)
> >>>>>>>>> <ppfister@cisco.com>; Xie, Huawei <huawei.xie@intel.com>;
> >>>>>> dev@dpdk.org;
> >>>>>>>>> vkaplans@redhat.com; mst@redhat.com
> >>>>>>>>> Subject: Re: [dpdk-dev] [PATCH v4] vhost: Add indirect
> descriptors
> >>>>>> support
> >>>>>>>>> to the TX path
> >>>>>>>>>
> >>>>>>>>> On Thu, Oct 27, 2016 at 12:35:11PM +0200, Maxime Coquelin
> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 10/27/2016 12:33 PM, Yuanhan Liu wrote:
> >>>>>>>>>>>>> On Thu, Oct 27, 2016 at 11:10:34AM +0200, Maxime
> Coquelin
> >>>>>> wrote:
> >>>>>>>>>>>>>>> Hi Zhihong,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On 10/27/2016 11:00 AM, Wang, Zhihong wrote:
> >>>>>>>>>>>>>>>>> Hi Maxime,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Seems indirect desc feature is causing serious
> >>> performance
> >>>>>>>>>>>>>>>>> degradation on Haswell platform, about 20% drop for
> both
> >>>>>>>>>>>>>>>>> mrg=on and mrg=off (--txqflags=0xf00, non-vector
> >>> version),
> >>>>>>>>>>>>>>>>> both iofwd and macfwd.
> >>>>>>>>>>>>>>> I tested PVP (with macswap on guest) and Txonly/Rxonly
> on
> >>> an
> >>>>>> Ivy
> >>>>>>>>> Bridge
> >>>>>>>>>>>>>>> platform, and didn't faced such a drop.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I was actually wondering that may be the cause. I tested it
> >>>>>>>>>>>>> with
> >>>>>>>>>>>>> my IvyBridge server as well, I saw no drop.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Maybe you should find a similar platform (Haswell) and
> have a
> >>>>>>>>>>>>> try?
> >>>>>>>>>>> Yes, that's why I asked Zhihong whether he could test Txonly
> in
> >>>>>>>>>>> guest
> >>>>>> to
> >>>>>>>>>>> see if issue is reproducible like this.
> >>>>>>>>>
> >>>>>>>>> I have no Haswell box, otherwise I could do a quick test for you.
> >>>>>>>>> IIRC,
> >>>>>>>>> he tried to disable the indirect_desc feature, then the
> >>>>>>>>> performance
> >>>>>>>>> recovered. So, it's likely the indirect_desc is the culprit here.
> >>>>>>>>>
> >>>>>>>>>>> I will be easier for me to find an Haswell machine if it has not
> >>>>>>>>>>> to be
> >>>>>>>>>>> connected back to back to and HW/SW packet generator.
> >>>>>>> In fact simple loopback test will also do, without pktgen.
> >>>>>>>
> >>>>>>> Start testpmd in both host and guest, and do "start" in one
> >>>>>>> and "start tx_first 32" in another.
> >>>>>>>
> >>>>>>> Perf drop is about 24% in my test.
> >>>>>>>
> >>>>>>
> >>>>>> Thanks, I never tried this test.
> >>>>>> I managed to find an Haswell platform (Intel(R) Xeon(R) CPU
> >>>>>> E5-2699 v3
> >>>>>> @ 2.30GHz), and can reproduce the problem with the loop test you
> >>>>>> mention. I see a performance drop about 10% (8.94Mpps/8.08Mpps).
> >>>>>> Out of curiosity, what are the numbers you get with your setup?
> >>>>>
> >>>>> Hi Maxime,
> >>>>>
> >>>>> Let's align our test case to RC2, mrg=on, loopback, on Haswell.
> >>>>> My results below:
> >>>>> 1. indirect=1: 5.26 Mpps
> >>>>> 2. indirect=0: 6.54 Mpps
> >>>>>
> >>>>> It's about 24% drop.
> >>>> OK, so on my side, same setup on Haswell:
> >>>> 1. indirect=1: 7.44 Mpps
> >>>> 2. indirect=0: 8.18 Mpps
> >>>>
> >>>> Still 10% drop in my case with mrg=on.
> >>>>
> >>>> The strange thing with both of our figures is that this is below from
> >>>> what I obtain with my SandyBridge machine. The SB cpu freq is 4%
> >>>> higher,
> >>>> but that doesn't explain the gap between the measurements.
> >>>>
> >>>> I'm continuing the investigations on my side.
> >>>> Maybe we should fix a deadline, and decide do disable indirect in
> >>>> Virtio PMD if root cause not identified/fixed at some point?
> >>>>
> >>>> Yuanhan, what do you think?
> >>>
> >>> I have done some measurements using perf, and know understand
> better
> >>> what happens.
> >>>
> >>> With indirect descriptors, I can see a cache miss when fetching the
> >>> descriptors in the indirect table. Actually, this is expected, so
> >>> we prefetch the first desc as soon as possible, but still not soon
> >>> enough to make it transparent.
> >>> In direct descriptors case, the desc in the virtqueue seems to be
> >>> remain in the cache from its previous use, so we have a hit.
> >>>
> >>> That said, in realistic use-case, I think we should not have a hit,
> >>> even with direct descriptors.
> >>> Indeed, the test case use testpmd on guest side with the forwarding set
> >>> in IO mode. It means the packet content is never accessed by the guest.
> >>>
> >>> In my experiments, I am used to set the "macswap" forwarding mode,
> which
> >>> swaps src and dest MAC addresses in the packet. I find it more
> >>> realistic, because I don't see the point in sending packets to the guest
> >>> if it is not accessed (not even its header).
> >>>
> >>> I tried again the test case, this time with setting the forwarding mode
> >>> to macswap in the guest. This time, I get same performance with both
> >>> direct and indirect (indirect even a little better with a small
> >>> optimization, consisting in prefetching the 2 first descs
> >>> systematically as we know there are contiguous).
> >>
> >>
> >> Hi Maxime,
> >>
> >> I did a little more macswap test and found out more stuff here:
> > Thanks for doing more tests.
> >
> >>
> >> 1. I did loopback test on another HSW machine with the same H/W,
> >> and indirect_desc on and off seems have close perf
> >>
> >> 2. So I checked the gcc version:
> >>
> >> * Previous: gcc version 6.2.1 20160916 (Fedora 24)
> >>
> >> * New: gcc version 5.4.0 20160609 (Ubuntu 16.04.1 LTS)
> >
> > On my side, I tested with RHEL7.3:
> > - gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
> >
> > It certainly contains some backports from newer GCC versions.
> >
> >>
> >> On previous one indirect_desc has 20% drop
> >>
> >> 3. Then I compiled binary on Ubuntu and scp to Fedora, and as
> >> expected I got the same perf as on Ubuntu, and the perf gap
> >> disappeared, so gcc is definitely one factor here
> >>
> >> 4. Then I use the Ubuntu binary on Fedora for PVP test, then the
> >> perf gap comes back again and the same with the Fedora binary
> >> results, indirect_desc causes about 20% drop
> >
> > Let me know if I understand correctly:
Yes, and it's hard to breakdown further at this time.
Also we may need to check whether it's caused by certain NIC
model. Unfortunately I don't have the right setup right now.
> > Loopback test with macswap:
> > - gcc version 6.2.1 : 20% perf drop
> > - gcc version 5.4.0 : No drop
> >
> > PVP test with macswap:
> > - gcc version 6.2.1 : 20% perf drop
> > - gcc version 5.4.0 : 20% perf drop
>
> I forgot to ask, did you recompile only host, or both host and guest
> testmpd's in your test?
Both.
>
> >
> >>
> >> So in all, could you try PVP traffic on HSW to see how it works?
> > Sadly, the HSW machine I borrowed does not have other device connected
> > back to back on its 10G port. I can only test PVP with SNB machines
> > currently.
> >
> >>
> >>
> >>>
> >>> Do you agree we should assume that the packet (header or/and buf) will
> >>> always be accessed by the guest application?
> >>> If so, do you agree we should keep indirect descs enabled, and maybe
> >>> update the test cases?
> >>
> >>
> >> I agree with you that mac/macswap test is more realistic and makes
> >> more sense for real applications.
> >
> > Thanks,
> > Maxime
^ permalink raw reply
* Re: HOW to forward vlan pkt using DPDK loadbalancer and L2FWD, with intel 82599ES
From: Caianning @ 2016-11-04 10:23 UTC (permalink / raw)
To: Lu, Wenzhuo; +Cc: dev@dpdk.org, users@dpdk.org
In the LB, I do not use any rule.
What I do with LB:
1, use a field of the header to select an application,
2, cut the l2 Head, both with the vlan tag
3, add another L2 head with the L2 Dst MAC set to the VF used by the application, Both rx and tx pkt has the same vlan tag.
4, put it to tx queue, the same as original Loadbalancer.
io thread will send it out.
What I do with L2FWD:
1, set dst mac to pkt's src mac,
2, set src mac to L2fwd port mac
Vlan is not changed.
The VF used by LoadBalancer is configured with ip link set mac xx:xx:xx:xx:xx, and spoofchk off. Port_conf with Vlan filter enabled and vlan strip disabled. Called RTE api add Vlan filter table.
The VF used by L2FWD is configured with ip link set mac xx:xx:xx:xx:xx vlan yyy, and spoofchk off. Port_conf with Vlan filter enabled and vlan strip disabled.
But it seems all pkts are dropped by hardware.
When I use the testpmd mac forward(forward pkt to VF 2), it works fine.
Does anyone have used the LB to process vlan tagged packet(both rx and tx) with intel 82599 VF?
I am not sure what's wrong with LB, and it would be grateful to get some advice from DPDK dev and users groups.
thanks.
-----邮件原件-----
发件人: Lu, Wenzhuo [mailto:wenzhuo.lu@intel.com]
发送时间: 2016年11月4日 13:20
收件人: Caianning; users@dpdk.org; dev@dpdk.org
主题: RE: HOW to forward vlan pkt using DPDK loadbalancer and L2FD, with intel 82599ES
Hi Anning,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Caianning
> Sent: Friday, November 4, 2016 10:51 AM
> To: users@dpdk.org; dev@dpdk.org
> Subject: [dpdk-dev] HOW to forward vlan pkt using DPDK loadbalancer
> and L2FD, with intel 82599ES
>
> HI,
>
> I am using DPDK 16.07 example loadbalancer to as LB to
> forward vlan pkt to applications. LB and applications are using VFs
> bound with DPDK igb_uio driver.
> But I found the packet can not be send from LB to application. Pkt
> input to LB with vlan, after LB processing it is sent out to application using another VF.
>
> As 82599 need vlan filters if we use VF to process vlan pkts, in the
> LB we called rte api to add a vlan filter and enable vlan flilter. And
> set port_conf with vlan strip off.
> And for the application(L2FWD) we use the cmd: ip link set PFxxx VF yy
> vlan VLANID.
>
> In the LB ,we can receive pkts with vlan, after processing(cut the
> head and add another L2 head with same vlan tag, set destination MAC
> to application VF), it is send out to the application VF.
> the result is: LB can still processing ,but all the pkt post.
>
> We also did an experiment using testPMD to forward vlan pkt to
> application on the same VF used by LB, and it is OK.
> We tried kinds of different set of vlan filter, vlan strip, ip link
> set, but found no solution.
>
> Does anyone meet the similar problem? And what factor casued the difference?
>
> Thx.
I saw you mentioned testpmd is fine. Testpmd is a very simple example, normally it forwards packets blindly. It means there's no route rule. It just forwards packets from one port to another.
I guess the difference is the APP you use has some rules for routing/swithing.
^ permalink raw reply
* Re: dpdk16.11 RC2 package ipv4 reassembly example can't work
From: Adrien Mazarguil @ 2016-11-04 10:20 UTC (permalink / raw)
To: Lu, Wenzhuo
Cc: Ananyev, Konstantin, Liu, Yu Y, Chen, WeichunX, Xu, HuilongX,
dev@dpdk.org
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC090939341118@shsmsx102.ccr.corp.intel.com>
On Fri, Nov 04, 2016 at 06:36:30AM +0000, Lu, Wenzhuo wrote:
> Hi Adrien,
>
> > -----Original Message-----
> > From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> > Sent: Wednesday, November 2, 2016 11:21 PM
> > To: Lu, Wenzhuo
> > Cc: Ananyev, Konstantin; Liu, Yu Y; Chen, WeichunX; Xu, HuilongX;
> > dev@dpdk.org
> > Subject: Re: dpdk16.11 RC2 package ipv4 reassembly example can't work
> >
> > Hi all,
> >
> > On Wed, Nov 02, 2016 at 08:39:31AM +0000, Lu, Wenzhuo wrote:
> > > Correct the typo of receiver.
> > >
> > > Hi Adrien,
> > > The change from struct ip_frag_pkt pkt[0] to struct ip_frag_pkt pkt[] will
> > make IP reassembly not working. I think this is not the root cause. Maybe
> > Konstantin can give us some idea.
> > > But I notice one thing, you change some from [0] to [], but others just add
> > '__extension__'. I believe if you add '__extension__' for struct ip_frag_pkt pkt[0],
> > we'll not hit this issue. Just curious why you use 2 ways to resolve the same
> > problem.
> >
> > I've used the __extension__ method whenever the C99 syntax could not work
> > due to invalid usage in the code, e.g. a flexible array cannot be the only member
> > of a struct, you cannot make arrays out of structures that contain such fields,
> > while there is no such constraint with the GNU syntax.
> >
> > For example see __extension__ uint8_t action_data[0] in struct
> > rte_pipeline_table_entry. The C99 could not be used because of
> > test_table_acl.c:
> >
> > struct rte_pipeline_table_entry entries[5];
> >
> > If replacing ip_frag_pkt[] with __extension__ ip_frag_pkt pkt[0] in rte_ip_frag.h
> > solves the issue, either some code is breaking some constraint somewhere or
> > this change broke the ABI (unlikely considering a simple recompilation should
> > have taken care of the issue). I did not notice any change in sizeof(struct
> > rte_ip_frag_tbl) nor offsetof(struct rte_ip_frag_tbl, pkt) on my setup, perhaps
> > the compilation flags used in your test affect them somehow.
> Thanks for your explanation. I also checked sizeof(struct rte_ip_frag_tbl). I don't see any change either.
>
> >
> > Can you confirm whether only reverting this particular field solves the issue?
> Yes. ip_frag_pkt pkt[0] or even ip_frag_pkt pkt[1] can work but ip_frag_pkt pkt[] cannot :(
> Do you like the idea of changing the ip_frag_pkt[] to __extension__ ip_frag_pkt pkt[0]?
Yes, restoring the original code (with __extension__) as a workaround until
we understand what is going on is safer, that's fine by me. The commit log
should explicitly state that weirdness occurs for an unknown reason with the
C99 syntax though (compiler bug is also a possibility).
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH] doc: fix mlx5 features overview
From: Mcnamara, John @ 2016-11-04 10:12 UTC (permalink / raw)
To: Nelio Laranjeiro, dev@dpdk.org
In-Reply-To: <552e8de286bd22017ca773d1ea2eafc1adf08eb4.1477580432.git.nelio.laranjeiro@6wind.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Nelio Laranjeiro
> Sent: Thursday, October 27, 2016 4:04 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] doc: fix mlx5 features overview
>
> Fixes: 75ef62a94301 ("net/mlx5: fix link speed capability information")
> Fixes: 188408719888 ("net/mlx5: fix support for newer link speeds")
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* [PATCH v2 2/2] arch/ppc: fix file descriptor leakage when getting CPU features
From: Jianbo Liu @ 2016-11-04 9:46 UTC (permalink / raw)
To: dev, chaozhu, viktorin; +Cc: Jianbo Liu
In-Reply-To: <1478252803-14672-1-git-send-email-jianbo.liu@linaro.org>
close the file descriptor after finish using it.
Fixes: 9ae15538 (eal/ppc: cpu flag checks for IBM Power)
Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
---
lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
index a8147c8..fcf96e0 100644
--- a/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/ppc_64/rte_cpuflags.c
@@ -116,6 +116,7 @@ rte_cpu_get_features(hwcap_registers_t out)
else if (auxv.a_type == AT_HWCAP2)
out[REG_HWCAP2] = auxv.a_un.a_val;
}
+ close(auxv_fd);
}
/*
--
2.4.11
^ permalink raw reply related
* [PATCH v2 1/2] arch/arm: fix file descriptor leakage when getting CPU features
From: Jianbo Liu @ 2016-11-04 9:46 UTC (permalink / raw)
To: dev, chaozhu, viktorin; +Cc: Jianbo Liu
In-Reply-To: <1478240949-13487-1-git-send-email-jianbo.liu@linaro.org>
close the file descriptor after finish using it.
Fixes: b94e5c94 (eal/arm: add CPU flags for ARMv7)
Fixes: 97523f82 (eal/arm: add CPU flags for ARMv8)
Signed-off-by: Jianbo Liu <jianbo.liu@linaro.org>
---
lib/librte_eal/common/arch/arm/rte_cpuflags.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/common/arch/arm/rte_cpuflags.c b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
index 23240ef..79160a6 100644
--- a/lib/librte_eal/common/arch/arm/rte_cpuflags.c
+++ b/lib/librte_eal/common/arch/arm/rte_cpuflags.c
@@ -148,6 +148,7 @@ rte_cpu_get_features(hwcap_registers_t out)
out[REG_PLATFORM] = 0x0001;
}
}
+ close(auxv_fd);
}
/*
--
2.4.11
^ permalink raw reply related
* [PATCH RESEND v2] net/i40e: fix floating VEB issue
From: Yuanhan Liu @ 2016-11-04 9:33 UTC (permalink / raw)
To: dev; +Cc: Beilei Xing
Turning off S-TAG identification will impact floating VEB,
VFs can't communicate with each other.
This patch fixes this issue by judging whether floating
VEB is enabled, S-TAG identification will be turned off
only when floating VEB is disabled.
Fixes: 4d61120d5ce7 ("net/i40e: fix dropping packets with ethertype 0x88A8")
Signed-off-by: Beilei Xing <beilei.xing@intel.com>
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
---
v2 changes:
* Modify the limitation description in i40e.rst
Seems that Beilei failed to send this patches out; while I have sent out few
patches out successfully. I'm sending it for her.
doc/guides/nics/i40e.rst | 6 ++++++
drivers/net/i40e/i40e_ethdev.c | 12 +++++++-----
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst
index c0163fc..5780268 100644
--- a/doc/guides/nics/i40e.rst
+++ b/doc/guides/nics/i40e.rst
@@ -453,3 +453,9 @@ To work around this issue, ``ethtool -s <dev> autoneg on`` should be
set first and then the link can be brought up through ``ifconfig <dev> up``.
NOTE: requires Linux kernel i40e driver version >= 1.4.X
+
+Receive packets with Ethertype 0x88A8
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Due to the FW limitation, PF can receive packets with Ethertype 0x88A8
+only when floating VEB is disabled.
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bb81b15..631a93f 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1121,11 +1121,13 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
/* Disable double vlan by default */
i40e_vsi_config_double_vlan(vsi, FALSE);
- /* Disable S-TAG identification by default */
- ret = I40E_READ_REG(hw, I40E_PRT_L2TAGSEN);
- if (ret & I40E_L2_TAGS_S_TAG_MASK) {
- ret &= ~I40E_L2_TAGS_S_TAG_MASK;
- I40E_WRITE_REG(hw, I40E_PRT_L2TAGSEN, ret);
+ /* Disable S-TAG identification when floating_veb is disabled */
+ if (!pf->floating_veb) {
+ ret = I40E_READ_REG(hw, I40E_PRT_L2TAGSEN);
+ if (ret & I40E_L2_TAGS_S_TAG_MASK) {
+ ret &= ~I40E_L2_TAGS_S_TAG_MASK;
+ I40E_WRITE_REG(hw, I40E_PRT_L2TAGSEN, ret);
+ }
}
if (!vsi->max_macaddrs)
--
2.5.0
^ permalink raw reply related
* Re: [PATCH] doc: update release notes with enic PMD changes
From: Mcnamara, John @ 2016-11-04 9:29 UTC (permalink / raw)
To: John Daley; +Cc: dev@dpdk.org
In-Reply-To: <20161103180133.20000-1-johndale@cisco.com>
> -----Original Message-----
> From: John Daley [mailto:johndale@cisco.com]
> Sent: Thursday, November 3, 2016 6:02 PM
> To: Mcnamara, John <john.mcnamara@intel.com>
> Cc: dev@dpdk.org; John Daley <johndale@cisco.com>
> Subject: [PATCH] doc: update release notes with enic PMD changes
>
> Signed-off-by: John Daley <johndale@cisco.com>
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
* Re: [PATCH v2] doc: add mlx5 release notes
From: Mcnamara, John @ 2016-11-04 9:28 UTC (permalink / raw)
To: Nelio Laranjeiro, dev@dpdk.org; +Cc: Adrien Mazarguil
In-Reply-To: <b3884e8811837a97492d7820edea3351b5407d8a.1478180639.git.nelio.laranjeiro@6wind.com>
> -----Original Message-----
> From: Nelio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> Sent: Thursday, November 3, 2016 1:46 PM
> To: dev@dpdk.org
> Cc: Mcnamara, John <john.mcnamara@intel.com>; Adrien Mazarguil
> <adrien.mazarguil@6wind.com>
> Subject: [PATCH v2] doc: add mlx5 release notes
>
> Add list of tested and validated NICs too.
>
> Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
Hi Nelio,
Nice to see such an extensive list of tested platforms and NICs.
I don't know if it is generally okay to update only part of a patchset
but apart from that:
Acked-by: John McNamara <john.mcnamara@intel.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox