* Re: 17.02 Roadmap
From: O'Driscoll, Tim @ 2016-10-10 16:13 UTC (permalink / raw)
To: dev@dpdk.org
We published our initial roadmap for 17.02 at the end of August. Since then we've been doing more detailed planning and would like to provide an update on the features that we plan to submit for this release. This is our current plan, which should hopefully remain fairly stable now:
Consistent Filter API: Add support for the Consistent Filter API (see http://dpdk.org/ml/archives/dev/2016-September/047924.html) for IGB, IXGBE and I40E.
Elastic Flow Distributor: The Elastic Flow Distributor (EFD) is a flow-based load balancing library which scales linearly for both lookup and insert with the number of threads or cores. EFD lookup uses a "perfect hashing" scheme where only the information needed to compute a key's value (and not the key itself) is stored in the lookup table, thus reducing CPU cache storage requirements.
Extended Stats (Latency and Bit Rate Statistics): Enhance the Extended NIC Stats (Xstats) implementation to support the collection and reporting of latency and bit rate measurements. Latency statistics will include min, max and average latency, and jitter. Bit rate statistics will include peak and average bit rate aggregated over a user-defined time period. This will be implemented for IXGBE and I40E.
Run-Time Configuration of Packet Type (PTYPE) for I40E: At the moment all packet types in DPDK are statically defined. This makes impossible to add new values without first defining them statically and then recompiling DPDK. The ability to configure packet types at run time will be added for I40E.
Packet Distributor Enhancements: Enhancements will be made to the Packet Distributor library to improve performance:
1. Introduce burst functionality to allow batches of packets to be sent to workers.
2. Improve the performance of the flow/core affinity through the use of SSE/AVX instructions.
Add MACsec for IXGBE: MACsec support will be added for IXGBE. Ethdev API primitives will be added to create/delete/enable/disable SC/SA, Next_PN etc. similar to those used in Linux for the macsec_ops. Sample apps (l3fwd, testpmd, etc.) will be updated to support MACsec for the IXGBE.
Enhance AESNI_GCM PMD: The current AESNI_GCM PMD is limited to AES-128 and does not support other features such as "any AAD length value". It will be updated to use a newer GCM implementation supporting AES128/192/256 and other features.
Create Crypto Performance Test App: A new app, similar to testpmd, will be created to allow crypto performance to be tested using any crypto PMD and any supported crypto algorithm.
Enable Cipher-Only and Hash-Only Support in AESNI_MB PMD: Support will be added for cipher-only and hash-only operations in the AESNI_MB PMD.
Support Chained Mbufs in Cryptodev: Currently, an application using the cryptodev API needs to reserve a continuous block of memory for mbufs. Support will be added for chaining of mbufs in both the QAT and SW PMDs supported by cryptodev.
Optimize Vhost-User Performance for Large Packets: A new memory copy function optimized for core-to-core memory copy which will be added. This will be beneficial for virtualization cases involving large packets, but it can be used for other core-to-core cases as well.
Support New Device Types in Vhost-User: Support will be added to vhost-user for new device types including vhost-scsi and vhost-blk.
Interrupt Mode Support in Virtio PMD: Support for interrupt mode will be added to the virtio PMD.
Virtio-User as an Alternative Exception Path: Investigate the use of virtio-user and vhost-net as an alternative exception path to KNI that does not require out of tree drivers. This work is still at an experimental stage, so it may not be included in 17.02.
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of O'Driscoll, Tim
> Sent: Wednesday, August 31, 2016 11:32 AM
> To: dev@dpdk.org
> Subject: [dpdk-dev] 17.02 Roadmap
>
> Below are the features that we're planning to submit for the 17.02
> release. We'll submit a patch to update the roadmap page with this info.
>
> Some things will obviously change during planning/development, so we'll
> provide a more detailed update in late September/early October. After
> that, things should hopefully be relatively stable.
>
> It would be good if others are also willing to share their plans so that
> we can build up a complete picture of what's planned for 17.02 and make
> sure there's no duplication.
>
>
> Consistent Filter API phase 2: Extend support for the Consistent Filter
> API that will be first implemented in 16.11 to IGB and FM10K.
>
> Elastic Flow Distributor: The Elastic Flow Distributor (EFD) is a flow-
> based load balancing library which scales linearly for both lookup and
> insert with the number of threads or cores. EFD lookup uses a "perfect
> hashing" scheme where only the information needed to compute a key's
> value (and not the key itself) is stored in the lookup table, thus
> reducing CPU cache storage requirements.
>
> Cryptodev: Additional Software Algorithms:
> - Optimize the AES-GCM software PMD.
> - Enhance the Intel(r) AES-NI MB PMD to add support for cipher-only and
> authentication-only operations. Add support for AES_CBC_MAC,
> AES_CMAC_128, AES_GMAC_128.
> - Add software support for: 3DES_ECB_128/192, AES_ECB_128/192/256,
> AES_F8, AES_XTS, ARC4.
>
> Run-Time Configuration of Flow Type (PCTYPE) and Packet Type (PTYPE) for
> I40E: At the moment all flow types and packet types in DPDK are
> statically defined. This makes impossible to add new values without
> first defining them statically and then recompiling DPDK. The ability to
> configure flow types and packet types at run time will be added for
> I40E.
>
> Extended Stats Latency and Bit Rate Statistics: Enhance the Extended NIC
> Stats (Xstats) implementation to support the collection and reporting of
> latency and bit rate measurements. Latency statistics will include min,
> max and average latency, and jitter. Bit rate statistics will include
> peak and average bit rate aggregated over a user-defined time period.
> This will be implemented for IXGBE and I40E.
>
> Hardware QoS for IXGBE and I40E: Implement support for Hardware QoS for
> IXGBE and I40E. This involves using DCB so that a PF or VF can receive
> packets for each of the Traffic Classes (TCs) based on the User Priority
> field (in the VLAN header). Bandwidth on transmit for each TC is
> programmable.
^ permalink raw reply
* Re: [PATCH v2] test_cryptodev_perf: IV and digest should be stored at a DMAeble address
From: De Lara Guarch, Pablo @ 2016-10-10 16:24 UTC (permalink / raw)
To: Akhil Goyal, Kusztal, ArkadiuszX, Doherty, Declan
Cc: Griffin, John, Trahe, Fiona, Jain, Deepak K, dev@dpdk.org
In-Reply-To: <3073c5fc-5896-7cde-2c90-596ee6a564c5@nxp.com>
Hi Akhil,
> -----Original Message-----
[...]
> Hi Pablo,
>
> I have already rebased this patch to dpdk-next-crypto subtree. Please
> let me know if there is any issue.
> Here is my git log
> 779f1301a382b6b9e2877fd0357bba33d1242d65 test_cryptodev_perf: IV and
> digest should be stored at a DMAeble address
> 8c9fdf4568768b7765fc2176e400a860dc758020 app/test: remove hard-coding
> of
> crypto num qps
> c1876c1cb90f0882ada0acd9e430be7cf63bc765 app/test: cleanup
> unnecessary
> ring size setup
> 136592c3a350ded56438b59cc4921a243f08e1d0 app/test: remove pointless
> for loop
> fca4f966b42adc0c8f3e1d43a94ddddd93ea4fcb crypto/aesni_mb: free ring
> memory on qp release in PMD
>
>
> Regards
The problem is that AES_CBC_CIPHER_IV_LENGTH does not exist anymore, so compilation is broken.
Also, you could add this change for another tests, like what Arek suggested (for SNOW3G),
or someone can send a new version of this patch, if you prefer that.
Thanks,
Pablo
^ permalink raw reply
* Re: [PATCH] net/i40e: add additional prefetch instructions for bulk rx
From: Vladyslav Buslov @ 2016-10-10 17:05 UTC (permalink / raw)
To: Wu, Jingjing, Yigit, Ferruh, Zhang, Helin; +Cc: dev@dpdk.org
In-Reply-To: <9BB6961774997848B5B42BEC655768F80E277DFC@SHSMSX103.ccr.corp.intel.com>
> -----Original Message-----
> From: Wu, Jingjing [mailto:jingjing.wu@intel.com]
> Sent: Monday, October 10, 2016 4:26 PM
> To: Yigit, Ferruh; Vladyslav Buslov; Zhang, Helin
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] net/i40e: add additional prefetch
> instructions for bulk rx
>
>
>
> > -----Original Message-----
> > From: Yigit, Ferruh
> > Sent: Wednesday, September 14, 2016 9:25 PM
> > To: Vladyslav Buslov <vladyslav.buslov@harmonicinc.com>; Zhang, Helin
> > <helin.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] net/i40e: add additional prefetch
> > instructions for bulk rx
> >
> > On 7/14/2016 6:27 PM, Vladyslav Buslov wrote:
> > > Added prefetch of first packet payload cacheline in
> > > i40e_rx_scan_hw_ring Added prefetch of second mbuf cacheline in
> > > i40e_rx_alloc_bufs
> > >
> > > Signed-off-by: Vladyslav Buslov <vladyslav.buslov@harmonicinc.com>
> > > ---
> > > drivers/net/i40e/i40e_rxtx.c | 7 +++++--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/i40e/i40e_rxtx.c
> > > b/drivers/net/i40e/i40e_rxtx.c index d3cfb98..e493fb4 100644
> > > --- a/drivers/net/i40e/i40e_rxtx.c
> > > +++ b/drivers/net/i40e/i40e_rxtx.c
> > > @@ -1003,6 +1003,7 @@ i40e_rx_scan_hw_ring(struct i40e_rx_queue
> *rxq)
> > > /* Translate descriptor info to mbuf parameters */
> > > for (j = 0; j < nb_dd; j++) {
> > > mb = rxep[j].mbuf;
> > > + rte_prefetch0(RTE_PTR_ADD(mb->buf_addr,
> > RTE_PKTMBUF_HEADROOM));
>
> Why did prefetch here? I think if application need to deal with packet, it is
> more suitable to put it in application.
>
> > > qword1 = rte_le_to_cpu_64(\
> > > rxdp[j].wb.qword1.status_error_len);
> > > pkt_len = ((qword1 &
> > I40E_RXD_QW1_LENGTH_PBUF_MASK) >>
> > > @@ -1086,9 +1087,11 @@ i40e_rx_alloc_bufs(struct i40e_rx_queue
> *rxq)
> > >
> > > rxdp = &rxq->rx_ring[alloc_idx];
> > > for (i = 0; i < rxq->rx_free_thresh; i++) {
> > > - if (likely(i < (rxq->rx_free_thresh - 1)))
> > > + if (likely(i < (rxq->rx_free_thresh - 1))) {
> > > /* Prefetch next mbuf */
> > > - rte_prefetch0(rxep[i + 1].mbuf);
> > > + rte_prefetch0(&rxep[i + 1].mbuf->cacheline0);
> > > + rte_prefetch0(&rxep[i + 1].mbuf->cacheline1);
> > > + }
> Agree with this change. And when I test it by testpmd with iofwd, no
> performance increase is observed but minor decrease.
> Can you share will us when it will benefit the performance in your scenario ?
>
>
> Thanks
> Jingjing
Hello Jingjing,
Thanks for code review.
My use case: We have simple distributor thread that receives packets from port and distributes them among worker threads according to VLAN and MAC address hash.
While working on performance optimization we determined that most of CPU usage of this thread is in DPDK.
As and optimization we decided to switch to rx burst alloc function, however that caused additional performance degradation compared to scatter rx mode.
In profiler two major culprits were:
1. Access to packet data Eth header in application code. (cache miss)
2. Setting next packet descriptor field to NULL in DPDK i40e_rx_alloc_bufs code. (this field is in second descriptor cache line that was not prefetched)
After applying my fixes performance improved compared to scatter rx mode.
I assumed that prefetch of first cache line of packet data belongs to DPDK because it is done in scatter rx mode. (in i40e_recv_scattered_pkts)
It can be moved to application side but IMO it is better to be consistent across all rx modes.
Regards,
Vladyslav
^ permalink raw reply
* Re: [PATCH v2] mk: gcc -march support for intel processors code names
From: Thomas Monjalon @ 2016-10-10 17:09 UTC (permalink / raw)
To: Pattan, Reshma; +Cc: Liu, Yong, dev
In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F010ADCFC@IRSMSX109.ger.corp.intel.com>
2016-10-10 15:21, Pattan, Reshma:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Why not recommend GCC 4.9 and keep the graceful degradation for older
> > versions, at least for one more year, even if it is not optimal for newer
> > architectures?
>
> I am ok with the idea, so should I send latest patch by keeping the code in
> mk/toolchain/gcc/rte.toolchain-compat.mk untouched/intact?
Yes please.
^ permalink raw reply
* Re: [PATCH v4 4/6] i40e: add Tx preparation
From: Kulasek, TomaszX @ 2016-10-10 17:20 UTC (permalink / raw)
To: Wu, Jingjing, dev@dpdk.org; +Cc: Ananyev, Konstantin
In-Reply-To: <9BB6961774997848B5B42BEC655768F80E277E47@SHSMSX103.ccr.corp.intel.com>
Hi Jingjing,
> -----Original Message-----
> From: Wu, Jingjing
> Sent: Monday, October 10, 2016 16:03
> To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>; dev@dpdk.org
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Kulasek, TomaszX
> <tomaszx.kulasek@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v4 4/6] i40e: add Tx preparation
>
> > #include "i40e_logs.h"
> > #include "base/i40e_prototype.h"
> > @@ -79,6 +81,17 @@
> > PKT_TX_TCP_SEG | \
> > PKT_TX_OUTER_IP_CKSUM)
> >
> > +#define I40E_TX_OFFLOAD_MASK ( \
> > + PKT_TX_IP_CKSUM | \
> > + PKT_TX_L4_MASK | \
> > + PKT_TX_OUTER_IP_CKSUM | \
> > + PKT_TX_TCP_SEG | \
> > + PKT_TX_QINQ_PKT | \
> > + PKT_TX_VLAN_PKT)
> > +
> More TX flags are added for tunneling as below.
> /**
> * Bits 45:48 used for the tunnel type.
> * When doing Tx offload like TSO or checksum, the HW needs to configure
> the
> * tunnel type into the HW descriptors.
> */
> #define PKT_TX_TUNNEL_VXLAN (0x1ULL << 45)
> #define PKT_TX_TUNNEL_GRE (0x2ULL << 45)
> #define PKT_TX_TUNNEL_IPIP (0x3ULL << 45)
> #define PKT_TX_TUNNEL_GENEVE (0x4ULL << 45)
> /* add new TX TUNNEL type here */
> #define PKT_TX_TUNNEL_MASK (0xFULL << 45)
>
> Please check:
> commit 63c0d74daaa9a807fbca8a3e363bbe41d6fb715f
> Author: Jianfeng Tan <jianfeng.tan@intel.com>
> Date: Mon Aug 1 03:56:53 2016 +0000
>
> mbuf: add Tx side tunneling type
>
>
> Thanks
> Jingjing
Thanks for spotting this, I will send updated v5.
Tomasz
^ permalink raw reply
* Re: DPDK patchwork upgrade
From: Stephen Finucane @ 2016-10-10 18:09 UTC (permalink / raw)
To: Thomas Monjalon, De Lara Guarch, Pablo; +Cc: dev@dpdk.org
In-Reply-To: <9398822.xtO6cvAGR1@xps13>
> 2016-09-07 16:40, De Lara Guarch, Pablo:
> > I am looking at it, and I see two issues:
> > - There are some patches that have been acked, but I don't see that in patchwork
> > (e.g. http://dpdk.org/dev/patchwork/patch/15381/)
>
> Yes the new columns are empty.
> I guess they will be filled starting from now.
> Stephen, could we re-parse old emails (from August/September) to fill
> A/R/T without breaking the database?
You sure can - use the 'retag' command [1]:
./manage.py retag
I should probably have included that in the upgrade notes...
Stephen
[1] https://github.com/getpatchwork/patchwork/blob/stable/1.1/patchwork/management/commands/retag.py
^ permalink raw reply
* Re: [PATCH 1/4] testpmd: Add support to configure 25G and 50G speeds
From: Ajit Khaparde @ 2016-10-10 18:40 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, Pablo de Lara
In-Reply-To: <b05860da-876c-c7de-0e9a-0d062f700664@intel.com>
On Mon, Oct 10, 2016 at 10:01 AM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:
> Hi Ajit,
>
> On 9/29/2016 6:03 PM, Ajit Khaparde wrote:
> > Support to configure 25G and 50G speeds is missing from testpmd.
> > This patch also updates the testpmd user guide accordingly.
> >
> > Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
>
> This patch seems not really part of the patchset for bnxt driver, but
> standalone testpmd only modification,
>
> and can be threaded as single patch.
>
OK. Got it.
I had worked on this change in the middle of other things.
So it got bundled along with other bnxt patches.
>
> I am adding testpmd maintainer to cc.
>
Let me know if you want me to send it again as a standalone patch.
Thanks
>
> Thanks,
> ferruh
>
>
^ permalink raw reply
* Re: [PATCH 2/4] bnxt: Fix a segfault encountered during KNI exit
From: Ajit Khaparde @ 2016-10-10 18:41 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <91ebdd13-b556-dc9b-5488-a38483b16733@intel.com>
On Mon, Oct 10, 2016 at 10:24 AM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:
> On 9/29/2016 8:06 PM, Ajit Khaparde wrote:
> > On Thu, Sep 29, 2016 at 12:41 PM, Ferruh Yigit <ferruh.yigit@intel.com
> > <mailto:ferruh.yigit@intel.com>>wrote:
> >
> > On 9/29/2016 6:03 PM, Ajit Khaparde wrote:
> > > The bnxt PMD is running into a segfault when exiting out of KNI
> >
> > KNI?
> >
> > examples/kni
> >
> > On closing the kni app, I am seeing a segfault. because of improper
> > cleanup of resources
> > in the dev_uninit path.
>
> So this is mainly related to driver exit, KNI app is just a way to
> reproduce it.
>
> Are you OK with following update in commit log:
>
> "
> net/bnxt: fix a segfault encountered during PMD exit
>
> This patch fixes segfault encountered during dev_uninit/close routine.
> KNI sample app can be used to reproduce the issue.
> "
>
I am OK with this Ferruh.
Thanks
^ permalink raw reply
* Re: [PATCH v2 4/4] net/bnxt: add ULL suffix to constant 1 for bit shift in bnxt_mac_addr_remove_op
From: Ajit Khaparde @ 2016-10-10 18:41 UTC (permalink / raw)
To: John W. Linville; +Cc: dev, dpdk stable
In-Reply-To: <1475170776-10130-5-git-send-email-linville@tuxdriver.com>
On Thu, Sep 29, 2016 at 12:39 PM, John W. Linville <linville@tuxdriver.com>
wrote:
> Some(?) compilers will treat the unmarked constant 1 as a 32-bit
> integer, but the shift operation is in a loop that could run up to
> 63 times -- undefined behavior!
>
> Coverity issue: 127546
> Fixes: 778b759ba10e ("net/bnxt: add MAC address")
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
Acked
-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> ---
> v2: fix-up changelog entries based-on comments from Ferruh Yigit
>
> drivers/net/bnxt/bnxt_ethdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev
> .c
> index f4eedfd812bb..d7447b15983b 100644
> --- a/drivers/net/bnxt/bnxt_ethdev.c
> +++ b/drivers/net/bnxt/bnxt_ethdev.c
> @@ -463,7 +463,7 @@ static void bnxt_mac_addr_remove_op(struct rte_eth_dev
> *eth_dev,
> * remove the corresponding MAC addr filter
> */
> for (i = 0; i < MAX_FF_POOLS; i++) {
> - if (!(pool_mask & (1 << i)))
> + if (!(pool_mask & (1ULL << i)))
> continue;
>
> STAILQ_FOREACH(vnic, &bp->ff_pool[i], next) {
> --
> 2.7.4
>
>
^ permalink raw reply
* Re: 17.02 Roadmap
From: Thomas Monjalon @ 2016-10-10 20:42 UTC (permalink / raw)
To: O'Driscoll, Tim; +Cc: dev
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA675F11C5@IRSMSX108.ger.corp.intel.com>
Thanks Tim for the interesting inputs.
Some of them may require a dedicated thread to continue the discussion
based on some preliminary specifications or drafts.
2016-10-10 16:13, O'Driscoll, Tim:
> Elastic Flow Distributor: The Elastic Flow Distributor (EFD) is a flow-based load balancing library which scales linearly for both lookup and insert with the number of threads or cores. EFD lookup uses a "perfect hashing" scheme where only the information needed to compute a key's value (and not the key itself) is stored in the lookup table, thus reducing CPU cache storage requirements.
What is the scope of this library? Just apply rte_hash to a flow table?
Or is it also sending the packets in some queues?
Does it depend of librte_distributor?
> Extended Stats (Latency and Bit Rate Statistics): Enhance the Extended NIC Stats (Xstats) implementation to support the collection and reporting of latency and bit rate measurements. Latency statistics will include min, max and average latency, and jitter. Bit rate statistics will include peak and average bit rate aggregated over a user-defined time period. This will be implemented for IXGBE and I40E.
Are they retrieved from hardware or just computed in software?
Could we have some drivers hook to compute them in a generic layer?
> Run-Time Configuration of Packet Type (PTYPE) for I40E: At the moment all packet types in DPDK are statically defined. This makes impossible to add new values without first defining them statically and then recompiling DPDK. The ability to configure packet types at run time will be added for I40E.
The packet types are part of the API.
Although not yet convinced by the packet types, I do not understand how
to benefit from some run-time defined packet types.
> Packet Distributor Enhancements: Enhancements will be made to the Packet Distributor library to improve performance:
> 1. Introduce burst functionality to allow batches of packets to be sent to workers.
> 2. Improve the performance of the flow/core affinity through the use of SSE/AVX instructions.
The packet distributor looks more and more like a DPDK application
at the same level of BESS, VPP, OVS, etc.
> Add MACsec for IXGBE: MACsec support will be added for IXGBE. Ethdev API primitives will be added to create/delete/enable/disable SC/SA, Next_PN etc. similar to those used in Linux for the macsec_ops. Sample apps (l3fwd, testpmd, etc.) will be updated to support MACsec for the IXGBE.
How the ethdev interface and the cryptodev capabilities will be linked for MACsec?
[...]
> Create Crypto Performance Test App: A new app, similar to testpmd, will be created to allow crypto performance to be tested using any crypto PMD and any supported crypto algorithm.
Good idea :)
When I read "testpmd", I tend to think that it could test any PMD,
including crypto. Are you saying that we should read dpdk-netdev-test?
And you would introduce dpdk-cryptodev-test?
[...]
> Optimize Vhost-User Performance for Large Packets: A new memory copy function optimized for core-to-core memory copy which will be added. This will be beneficial for virtualization cases involving large packets, but it can be used for other core-to-core cases as well.
Is it an enhancement of rte_memcpy or something else?
> Support New Device Types in Vhost-User: Support will be added to vhost-user for new device types including vhost-scsi and vhost-blk.
Great!
Is it only related to networking or should we expect some storage-related
code or drivers to come up?
> Interrupt Mode Support in Virtio PMD: Support for interrupt mode will be added to the virtio PMD.
I guess you mean Rx interrupt in virtio PMD to avoid 100% polling in the VM?
> Virtio-User as an Alternative Exception Path: Investigate the use of virtio-user and vhost-net as an alternative exception path to KNI that does not require out of tree drivers. This work is still at an experimental stage, so it may not be included in 17.02.
Interesting. Please share more details of the design you are thinking of.
^ permalink raw reply
* [PATCH v3] mk: gcc -march support for intel processors code names
From: Reshma Pattan @ 2016-10-10 21:33 UTC (permalink / raw)
To: dev; +Cc: Reshma Pattan
In-Reply-To: <1471875574-29807-1-git-send-email-reshma.pattan@intel.com>
The GCC 4.9 -march option supports the intel code names for processors,
for example -march=silvermont, -march=broadwell.
The RTE_MACHINE config flag can be used to pass code name to
the compiler as -march flag.
Release notes is updated.
Linux and FreeBSD getting started guides are updated with recommended
gcc version as 4.9 and above.
Some of the gmake command examples in sample application guide and driver
guides are updated with gcc version as 4.9.
Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
---
doc/guides/freebsd_gsg/build_dpdk.rst | 4 ++--
doc/guides/freebsd_gsg/build_sample_apps.rst | 6 +++---
doc/guides/linux_gsg/sys_reqs.rst | 6 +++---
doc/guides/nics/bnx2x.rst | 4 ++--
doc/guides/nics/qede.rst | 2 +-
doc/guides/rel_notes/release_16_11.rst | 5 +++++
mk/target/generic/rte.vars.mk | 4 ++++
7 files changed, 20 insertions(+), 11 deletions(-)
v3:
Reverted changes of mk/toolchain/gcc/rte.toolchain-compat.mk.
v2:
Updated Linux and FreeBSD gsg guides, sample application guide and other driver doc
with recommended gcc version as 4.9 and above.
diff --git a/doc/guides/freebsd_gsg/build_dpdk.rst b/doc/guides/freebsd_gsg/build_dpdk.rst
index 27f21de..24a9f87 100644
--- a/doc/guides/freebsd_gsg/build_dpdk.rst
+++ b/doc/guides/freebsd_gsg/build_dpdk.rst
@@ -88,7 +88,7 @@ The ports required and their locations are as follows:
For compiling and using the DPDK with gcc, the compiler must be installed
from the ports collection:
-* gcc: version 4.8 is recommended ``/usr/ports/lang/gcc48``.
+* gcc: version 4.9 is recommended ``/usr/ports/lang/gcc49``.
Ensure that ``CPU_OPTS`` is selected (default is OFF).
When running the make config-recursive command, a dialog may be presented to the
@@ -164,7 +164,7 @@ For example to compile for FreeBSD use:
If the compiler binary to be used does not correspond to that given in the
TOOLCHAIN part of the target, the compiler command may need to be explicitly
specified. For example, if compiling for gcc, where the gcc binary is called
- gcc4.8, the command would need to be ``gmake install T=<target> CC=gcc4.8``.
+ gcc4.9, the command would need to be ``gmake install T=<target> CC=gcc4.9``.
Browsing the Installed DPDK Environment Target
----------------------------------------------
diff --git a/doc/guides/freebsd_gsg/build_sample_apps.rst b/doc/guides/freebsd_gsg/build_sample_apps.rst
index 2662303..fffc4c0 100644
--- a/doc/guides/freebsd_gsg/build_sample_apps.rst
+++ b/doc/guides/freebsd_gsg/build_sample_apps.rst
@@ -54,7 +54,7 @@ the following variables must be exported:
The following is an example of creating the ``helloworld`` application, which runs
in the DPDK FreeBSD environment. While the example demonstrates compiling
-using gcc version 4.8, compiling with clang will be similar, except that the ``CC=``
+using gcc version 4.9, compiling with clang will be similar, except that the ``CC=``
parameter can probably be omitted. The ``helloworld`` example may be found in the
``${RTE_SDK}/examples`` directory.
@@ -72,7 +72,7 @@ in the build directory.
setenv RTE_SDK $HOME/DPDK
setenv RTE_TARGET x86_64-native-bsdapp-gcc
- gmake CC=gcc48
+ gmake CC=gcc49
CC main.o
LD helloworld
INSTALL-APP helloworld
@@ -96,7 +96,7 @@ in the build directory.
cd my_rte_app/
setenv RTE_TARGET x86_64-native-bsdapp-gcc
- gmake CC=gcc48
+ gmake CC=gcc49
CC main.o
LD helloworld
INSTALL-APP helloworld
diff --git a/doc/guides/linux_gsg/sys_reqs.rst b/doc/guides/linux_gsg/sys_reqs.rst
index b321544..3d74342 100644
--- a/doc/guides/linux_gsg/sys_reqs.rst
+++ b/doc/guides/linux_gsg/sys_reqs.rst
@@ -61,8 +61,8 @@ Compilation of the DPDK
* coreutils: ``cmp``, ``sed``, ``grep``, ``arch``, etc.
-* gcc: versions 4.5.x or later is recommended for ``i686/x86_64``. Versions 4.8.x or later is recommended
- for ``ppc_64`` and ``x86_x32`` ABI. On some distributions, some specific compiler flags and linker flags are enabled by
+* gcc: versions 4.9 or later is recommended for all platforms.
+ On some distributions, some specific compiler flags and linker flags are enabled by
default and affect performance (``-fstack-protector``, for example). Please refer to the documentation
of your distribution and to ``gcc -dumpspecs``.
@@ -82,7 +82,7 @@ Compilation of the DPDK
.. note::
x86_x32 ABI is currently supported with distribution packages only on Ubuntu
- higher than 13.10 or recent Debian distribution. The only supported compiler is gcc 4.8+.
+ higher than 13.10 or recent Debian distribution. The only supported compiler is gcc 4.9+.
.. note::
diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst
index 6453168..6d1768a 100644
--- a/doc/guides/nics/bnx2x.rst
+++ b/doc/guides/nics/bnx2x.rst
@@ -162,7 +162,7 @@ To compile BNX2X PMD for FreeBSD x86_64 gcc target, run the following "gmake"
command::
cd <DPDK-source-directory>
- gmake config T=x86_64-native-bsdapp-gcc install -Wl,-rpath=/usr/local/lib/gcc48 CC=gcc48
+ gmake config T=x86_64-native-bsdapp-gcc install -Wl,-rpath=/usr/local/lib/gcc49 CC=gcc49
To compile BNX2X PMD for FreeBSD x86_64 gcc target, run the following "gmake"
command:
@@ -170,7 +170,7 @@ command:
.. code-block:: console
cd <DPDK-source-directory>
- gmake config T=x86_64-native-bsdapp-gcc install -Wl,-rpath=/usr/local/lib/gcc48 CC=gcc48
+ gmake config T=x86_64-native-bsdapp-gcc install -Wl,-rpath=/usr/local/lib/gcc49 CC=gcc49
Linux
-----
diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst
index 53d749c..3af755e 100644
--- a/doc/guides/nics/qede.rst
+++ b/doc/guides/nics/qede.rst
@@ -150,7 +150,7 @@ command::
cd <DPDK-source-directory>
gmake config T=x86_64-native-bsdapp-gcc install -Wl,-rpath=\
- /usr/local/lib/gcc48 CC=gcc48
+ /usr/local/lib/gcc49 CC=gcc49
Sample Application Notes
diff --git a/doc/guides/rel_notes/release_16_11.rst b/doc/guides/rel_notes/release_16_11.rst
index 905186a..f55bac4 100644
--- a/doc/guides/rel_notes/release_16_11.rst
+++ b/doc/guides/rel_notes/release_16_11.rst
@@ -89,6 +89,11 @@ New Features
* AES CBC IV generation with cipher forward function
* AES GCM/CTR mode
+* **Added support for new gcc -march option.**
+
+ The GCC 4.9 ``-march`` option supports the Intel processor code names.
+ The config option ``RTE_MACHINE`` can be used to pass code names to the compiler as ``-march`` flag.
+
Resolved Issues
---------------
diff --git a/mk/target/generic/rte.vars.mk b/mk/target/generic/rte.vars.mk
index 75a616a..b31e426 100644
--- a/mk/target/generic/rte.vars.mk
+++ b/mk/target/generic/rte.vars.mk
@@ -50,7 +50,11 @@
# - can define CPU_ASFLAGS variable (overriden by cmdline value) that
# overrides the one defined in arch.
#
+ifneq ($(wildcard $(RTE_SDK)/mk/machine/$(RTE_MACHINE)/rte.vars.mk),)
include $(RTE_SDK)/mk/machine/$(RTE_MACHINE)/rte.vars.mk
+else
+MACHINE_CFLAGS := -march=$(RTE_MACHINE)
+endif
#
# arch:
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] pdump: fix dir permissions value in mkdir call
From: Remy Horton @ 2016-10-10 21:44 UTC (permalink / raw)
To: Reshma Pattan, dev
In-Reply-To: <1476110148-31624-1-git-send-email-reshma.pattan@intel.com>
On 10/10/2016 15:35, Reshma Pattan wrote:
[..]
> Fixes: e4ffa2d3 ("pdump: fix error handlings")
> Fixes: bdd8dcc6 ("pdump: fix default socket path")
>
> Reported-by: Jianfeng Tan <jianfeng.tan@intel.com>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> lib/librte_pdump/rte_pdump.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Remy Horton <remy.horton@intel.com>
^ permalink raw reply
* [PATCH v2] log: respect rte_openlog_stream calls before rte_eal_init
From: John Ousterhout @ 2016-10-10 22:39 UTC (permalink / raw)
To: dev; +Cc: John Ousterhout
In-Reply-To: <20160928204244.8288-1-ouster@cs.stanford.edu>
Before this patch, application-specific loggers could not be
installed before rte_eal_init completed (the initialization process
called rte_openlog_stream, overwriting any previously installed
logger). This made it impossible for an application to capture the
initial log messages generated during rte_eal_init. This patch changes
initialization so that information from a previous call to
rte_openlog_stream is not lost. Specifically:
* The default log stream is now maintained separately from an
application-specific log stream installed with rte_openlog_stream.
* rte_eal_common_log_init has been renamed to rte_eal_log_set_default,
since this is all it does. It no longer invokes rte_openlog_stream; it
just updates the default stream. Also, this method now returns void,
rather than int, since there are no errors.
* The "early log" mechanism (e.g. rte_eal_log_early_init) has been
removed; all of the desired functionality can be achieved by calling
rte_eal_log_set_default.
Signed-off-by: John Ousterhout <ouster@cs.stanford.edu>
----
v2:
* Removed the early log mechanism, renamed rte_eal_common_log_init.
Note: I see from the code that Linux and BSD set different default streams:
Linux uses stdout, while BSD uses stderr. This patch retains the distinction,
though I'm not sure why it is there.
---
lib/librte_eal/bsdapp/eal/eal.c | 3 +--
lib/librte_eal/bsdapp/eal/eal_log.c | 11 +--------
lib/librte_eal/common/eal_common_log.c | 19 +++++++---------
lib/librte_eal/common/eal_private.h | 16 ++++---------
lib/librte_eal/common/include/rte_log.h | 2 +-
lib/librte_eal/linuxapp/eal/eal.c | 3 +--
lib/librte_eal/linuxapp/eal/eal_log.c | 40 +--------------------------------
7 files changed, 17 insertions(+), 77 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index a0c8f8c..a1ef75b 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -501,8 +501,7 @@ rte_eal_init(int argc, char **argv)
thread_id = pthread_self();
- if (rte_eal_log_early_init() < 0)
- rte_panic("Cannot init early logs\n");
+ rte_eal_log_set_default(stderr);
eal_log_level_parse(argc, argv);
diff --git a/lib/librte_eal/bsdapp/eal/eal_log.c b/lib/librte_eal/bsdapp/eal/eal_log.c
index a425f7a..6b2c6da 100644
--- a/lib/librte_eal/bsdapp/eal/eal_log.c
+++ b/lib/librte_eal/bsdapp/eal/eal_log.c
@@ -44,14 +44,5 @@
int
rte_eal_log_init(const char *id __rte_unused, int facility __rte_unused)
{
- if (rte_eal_common_log_init(stderr) < 0)
- return -1;
- return 0;
-}
-
-int
-rte_eal_log_early_init(void)
-{
- rte_openlog_stream(stderr);
- return 0;
+ rte_eal_set_default(stderr);
}
diff --git a/lib/librte_eal/common/eal_common_log.c b/lib/librte_eal/common/eal_common_log.c
index 967991a..2181cfa 100644
--- a/lib/librte_eal/common/eal_common_log.c
+++ b/lib/librte_eal/common/eal_common_log.c
@@ -48,11 +48,12 @@ struct rte_logs rte_logs = {
.file = NULL,
};
+/* Stream to use for logging if rte_logs.file is NULL */
static FILE *default_log_stream;
/**
* This global structure stores some informations about the message
- * that is currently beeing processed by one lcore
+ * that is currently being processed by one lcore
*/
struct log_cur_msg {
uint32_t loglevel; /**< log level - see rte_log.h */
@@ -68,10 +69,7 @@ static RTE_DEFINE_PER_LCORE(struct log_cur_msg, log_cur_msg);
int
rte_openlog_stream(FILE *f)
{
- if (f == NULL)
- rte_logs.file = default_log_stream;
- else
- rte_logs.file = f;
+ rte_logs.file = f;
return 0;
}
@@ -127,6 +125,8 @@ rte_vlog(uint32_t level, uint32_t logtype, const char *format, va_list ap)
{
int ret;
FILE *f = rte_logs.file;
+ if (f == NULL)
+ f = default_log_stream;
if ((level > rte_logs.level) || !(logtype & rte_logs.type))
return 0;
@@ -158,17 +158,14 @@ rte_log(uint32_t level, uint32_t logtype, const char *format, ...)
}
/*
- * called by environment-specific log init function
+ * Called by environment-specific initialization functions.
*/
-int
-rte_eal_common_log_init(FILE *default_log)
+void
+rte_eal_log_set_default(FILE *default_log)
{
default_log_stream = default_log;
- rte_openlog_stream(default_log);
#if RTE_LOG_LEVEL >= RTE_LOG_DEBUG
RTE_LOG(NOTICE, EAL, "Debug logs available - lower performance\n");
#endif
-
- return 0;
}
diff --git a/lib/librte_eal/common/eal_private.h b/lib/librte_eal/common/eal_private.h
index 19f7535..a037994 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -47,7 +47,9 @@
int rte_eal_memzone_init(void);
/**
- * Common log initialization function (private to eal).
+ * Common log initialization function (private to eal). Determines
+ * where log data is written when no call to eal_openlog_stream is
+ * in effect.
*
* @param default_log
* The default log stream to be used.
@@ -55,7 +57,7 @@ int rte_eal_memzone_init(void);
* - 0 on success
* - Negative on error
*/
-int rte_eal_common_log_init(FILE *default_log);
+void rte_eal_log_set_default(FILE *default_log);
/**
* Fill configuration with number of physical and logical processors
@@ -97,16 +99,6 @@ int rte_eal_memory_init(void);
int rte_eal_timer_init(void);
/**
- * Init early logs
- *
- * This function is private to EAL.
- *
- * @return
- * 0 on success, negative on error
- */
-int rte_eal_log_early_init(void);
-
-/**
* Init the default log stream
*
* This function is private to EAL.
diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h
index 919563c..d99baf3 100644
--- a/lib/librte_eal/common/include/rte_log.h
+++ b/lib/librte_eal/common/include/rte_log.h
@@ -54,7 +54,7 @@ extern "C" {
struct rte_logs {
uint32_t type; /**< Bitfield with enabled logs. */
uint32_t level; /**< Log level. */
- FILE *file; /**< Pointer to current FILE* for logs. */
+ FILE *file; /**< Output file set by rte_openlog_stream, or NULL. */
};
/** Global log informations */
diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxapp/eal/eal.c
index d5b81a3..4bd2439 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -748,8 +748,7 @@ rte_eal_init(int argc, char **argv)
thread_id = pthread_self();
- if (rte_eal_log_early_init() < 0)
- rte_panic("Cannot init early logs\n");
+ rte_eal_log_set_default(stdout);
eal_log_level_parse(argc, argv);
diff --git a/lib/librte_eal/linuxapp/eal/eal_log.c b/lib/librte_eal/linuxapp/eal/eal_log.c
index d391100..4a6690a 100644
--- a/lib/librte_eal/linuxapp/eal/eal_log.c
+++ b/lib/librte_eal/linuxapp/eal/eal_log.c
@@ -97,45 +97,7 @@ rte_eal_log_init(const char *id, int facility)
openlog(id, LOG_NDELAY | LOG_PID, facility);
- if (rte_eal_common_log_init(log_stream) < 0)
- return -1;
-
- return 0;
-}
-
-/* early logs */
-
-/*
- * early log function, used before rte_eal_log_init
- */
-static ssize_t
-early_log_write(__attribute__((unused)) void *c, const char *buf, size_t size)
-{
- ssize_t ret;
- ret = fwrite(buf, size, 1, stdout);
- fflush(stdout);
- if (ret == 0)
- return -1;
- return ret;
-}
-
-static cookie_io_functions_t early_log_func = {
- .write = early_log_write,
-};
-static FILE *early_log_stream;
+ rte_eal_log_set_default(log_stream);
-/*
- * init the log library, called by rte_eal_init() to enable early
- * logs
- */
-int
-rte_eal_log_early_init(void)
-{
- early_log_stream = fopencookie(NULL, "w+", early_log_func);
- if (early_log_stream == NULL) {
- printf("Cannot configure early_log_stream\n");
- return -1;
- }
- rte_openlog_stream(early_log_stream);
return 0;
}
--
2.8.3
^ permalink raw reply related
* Re: [PATCH v2 04/22] qede/base: update base driver
From: Mody, Rasesh @ 2016-10-10 23:31 UTC (permalink / raw)
To: Thomas Monjalon
Cc: Ferruh Yigit, Rasesh Mody, dev@dpdk.org,
Dept-EngDPDKDev@qlogic.com, Bruce Richardson
In-Reply-To: <2423952.d1lHHhMD9K@xps13>
Hi Ferruh, Thomas,
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, October 05, 2016 9:29 AM
>
> 2016-09-30 18:40, Mody, Rasesh:
> > > From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] Thank you for the
> > > update, base driver patch update now reduced from
> > > "14653 insertions(+), 8536 deletions(-)" to
> > > "10857 insertions(+), 4853 deletions(-)"
> > >
> > > But this is still to big for reviewing, specially there are some low
> > > hanging fruits for cleanup, like big chunk of comment updates or
> > > whitespace updates or non base driver codes in the patch.
> > >
> > > If the expectation is that somebody non maintainer review the code,
> > > understand it and highlight any possible defects, I believe this
> > > patch is too big and needs to be split more into logical pieces, but
> > > since this is a driver code and a little special, and it may not be
> > > possible to completely understand the code without knowing
> > > underlying hardware, I am not sure how to proceed and adding Bruce and
> Thomas to cc for guidance.
>
> As you said it makes contribution really hard.
> So it is missing the point of sharing its source code in Open Source.
>
> > This 8.10.x.x base driver is a common code shared by multiple drivers. It has
> gone through extensive testing.
> > We have split the base driver patch into smaller logical patches. It would be
> difficult to split this patch further.
>
> Please check how Intel updates its base drivers and try harder.
> We all know it requires some time, but it provides a valuable knowledge
> base.
We are working on the feedback and will be submitting the edited patch set this week as soon as they are ready.
Thanks!
Rasesh
^ permalink raw reply
* Re: [PATCH 1/1] fix the number of operations in libcrypto test
From: De Lara Guarch, Pablo @ 2016-10-11 0:27 UTC (permalink / raw)
To: Kerlin, MarcinX, dev@dpdk.org; +Cc: Jastrzebski, MichalX K
In-Reply-To: <1476086870-10538-1-git-send-email-marcinx.kerlin@intel.com>
> -----Original Message-----
> From: Kerlin, MarcinX
> Sent: Monday, October 10, 2016 1:08 AM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo; Jastrzebski, MichalX K; Kerlin, MarcinX
> Subject: [PATCH 1/1] fix the number of operations in libcrypto test
>
> This patch reduce the number of total operations from 1M to 10K, because
> test is taking too long time now.
>
> Fixes: ffbe3be0d4b5 ("app/test: add libcrypto")
>
> Signed-off-by: Marcin Kerlin <marcinx.kerlin@intel.com>
> ---
> app/test/test_cryptodev_perf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test/test_cryptodev_perf.c b/app/test/test_cryptodev_perf.c
> index 4aee9af..43a7166 100644
> --- a/app/test/test_cryptodev_perf.c
> +++ b/app/test/test_cryptodev_perf.c
> @@ -3420,7 +3420,7 @@ test_perf_snow3G_vary_pkt_size(void)
> static int
> test_perf_libcrypto_vary_pkt_size(void)
> {
> - unsigned int total_operations = 1000000;
> + unsigned int total_operations = 10000;
> unsigned int burst_size = { 64 };
> unsigned int buf_lengths[] = { 64, 128, 256, 512, 768, 1024, 1280,
> 1536,
> 1792, 2048 };
> --
> 1.9.1
Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Will change the title, as it is missing the category (app/test: )
^ permalink raw reply
* Re: [PATCH 1/1] fix the number of operations in libcrypto test
From: De Lara Guarch, Pablo @ 2016-10-11 0:38 UTC (permalink / raw)
To: De Lara Guarch, Pablo, Kerlin, MarcinX, dev@dpdk.org
Cc: Jastrzebski, MichalX K
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8973CA06F43@IRSMSX108.ger.corp.intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of De Lara Guarch,
> Pablo
> Sent: Monday, October 10, 2016 5:27 PM
> To: Kerlin, MarcinX; dev@dpdk.org
> Cc: Jastrzebski, MichalX K
> Subject: Re: [dpdk-dev] [PATCH 1/1] fix the number of operations in libcrypto
> test
>
>
>
> > -----Original Message-----
> > From: Kerlin, MarcinX
> > Sent: Monday, October 10, 2016 1:08 AM
> > To: dev@dpdk.org
> > Cc: De Lara Guarch, Pablo; Jastrzebski, MichalX K; Kerlin, MarcinX
> > Subject: [PATCH 1/1] fix the number of operations in libcrypto test
> >
> > This patch reduce the number of total operations from 1M to 10K, because
> > test is taking too long time now.
> >
> > Fixes: ffbe3be0d4b5 ("app/test: add libcrypto")
> >
> > Signed-off-by: Marcin Kerlin <marcinx.kerlin@intel.com>
> > ---
> > app/test/test_cryptodev_perf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/app/test/test_cryptodev_perf.c
> b/app/test/test_cryptodev_perf.c
> > index 4aee9af..43a7166 100644
> > --- a/app/test/test_cryptodev_perf.c
> > +++ b/app/test/test_cryptodev_perf.c
> > @@ -3420,7 +3420,7 @@ test_perf_snow3G_vary_pkt_size(void)
> > static int
> > test_perf_libcrypto_vary_pkt_size(void)
> > {
> > - unsigned int total_operations = 1000000;
> > + unsigned int total_operations = 10000;
> > unsigned int burst_size = { 64 };
> > unsigned int buf_lengths[] = { 64, 128, 256, 512, 768, 1024, 1280,
> > 1536,
> > 1792, 2048 };
> > --
> > 1.9.1
>
> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
>
> Will change the title, as it is missing the category (app/test: )
Applied to dpdk-next-crypto.
Thanks,
Pablo
^ permalink raw reply
* [PATCH] crypto/zuc: fix init function names
From: Pablo de Lara @ 2016-10-11 1:14 UTC (permalink / raw)
To: dev; +Cc: Pablo de Lara
All init/uninit function names in the virtual devices have been renamed,
so they finish with probe or remove, so to keep consistency,
same thing should be done in this PMD.
Fixes: cf7685d68f00 ("crypto/zuc: add driver for ZUC library")
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
drivers/crypto/zuc/rte_zuc_pmd.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/zuc/rte_zuc_pmd.c b/drivers/crypto/zuc/rte_zuc_pmd.c
index 457f3ca..403dca9 100644
--- a/drivers/crypto/zuc/rte_zuc_pmd.c
+++ b/drivers/crypto/zuc/rte_zuc_pmd.c
@@ -445,7 +445,7 @@ zuc_pmd_dequeue_burst(void *queue_pair,
return nb_dequeued;
}
-static int cryptodev_zuc_uninit(const char *name);
+static int cryptodev_zuc_remove(const char *name);
static int
cryptodev_zuc_create(const char *name,
@@ -499,12 +499,12 @@ cryptodev_zuc_create(const char *name,
init_error:
ZUC_LOG_ERR("driver %s: cryptodev_zuc_create failed", name);
- cryptodev_zuc_uninit(crypto_dev_name);
+ cryptodev_zuc_remove(crypto_dev_name);
return -EFAULT;
}
static int
-cryptodev_zuc_init(const char *name,
+cryptodev_zuc_probe(const char *name,
const char *input_args)
{
struct rte_crypto_vdev_init_params init_params = {
@@ -526,7 +526,7 @@ cryptodev_zuc_init(const char *name,
}
static int
-cryptodev_zuc_uninit(const char *name)
+cryptodev_zuc_remove(const char *name)
{
if (name == NULL)
return -EINVAL;
@@ -539,8 +539,8 @@ cryptodev_zuc_uninit(const char *name)
}
static struct rte_vdev_driver cryptodev_zuc_pmd_drv = {
- .probe = cryptodev_zuc_init,
- .remove = cryptodev_zuc_uninit
+ .probe = cryptodev_zuc_probe,
+ .remove = cryptodev_zuc_remove
};
DRIVER_REGISTER_VDEV(CRYPTODEV_NAME_ZUC_PMD, cryptodev_zuc_pmd_drv);
--
2.7.4
^ permalink raw reply related
* [PATCH] crypto/libcrypto: fix init function names
From: Pablo de Lara @ 2016-10-11 1:15 UTC (permalink / raw)
To: dev; +Cc: Pablo de Lara
All init/uninit function names in the virtual devices have been renamed,
so they finish with probe or remove, so to keep consistency,
same thing should be done in this PMD.
Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for OpenSSL library")
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
---
drivers/crypto/libcrypto/rte_libcrypto_pmd.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/libcrypto/rte_libcrypto_pmd.c b/drivers/crypto/libcrypto/rte_libcrypto_pmd.c
index 535fb57..b2c571d 100644
--- a/drivers/crypto/libcrypto/rte_libcrypto_pmd.c
+++ b/drivers/crypto/libcrypto/rte_libcrypto_pmd.c
@@ -42,7 +42,7 @@
#include "rte_libcrypto_pmd_private.h"
-static int cryptodev_libcrypto_uninit(const char *name);
+static int cryptodev_libcrypto_remove(const char *name);
/*----------------------------------------------------------------------------*/
@@ -1008,13 +1008,13 @@ cryptodev_libcrypto_create(const char *name,
init_error:
LIBCRYPTO_LOG_ERR("driver %s: cryptodev_libcrypto_create failed", name);
- cryptodev_libcrypto_uninit(crypto_dev_name);
+ cryptodev_libcrypto_remove(crypto_dev_name);
return -EFAULT;
}
/** Initialise LIBCRYPTO crypto device */
static int
-cryptodev_libcrypto_init(const char *name,
+cryptodev_libcrypto_probe(const char *name,
const char *input_args)
{
struct rte_crypto_vdev_init_params init_params = {
@@ -1037,7 +1037,7 @@ cryptodev_libcrypto_init(const char *name,
/** Uninitialise LIBCRYPTO crypto device */
static int
-cryptodev_libcrypto_uninit(const char *name)
+cryptodev_libcrypto_remove(const char *name)
{
if (name == NULL)
return -EINVAL;
@@ -1050,8 +1050,8 @@ cryptodev_libcrypto_uninit(const char *name)
}
static struct rte_vdev_driver cryptodev_libcrypto_pmd_drv = {
- .probe = cryptodev_libcrypto_init,
- .remove = cryptodev_libcrypto_uninit
+ .probe = cryptodev_libcrypto_probe,
+ .remove = cryptodev_libcrypto_remove
};
DRIVER_REGISTER_VDEV(CRYPTODEV_NAME_LIBCRYPTO_PMD, cryptodev_libcrypto_pmd_drv);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 3/4] bnxt: Add support for Async Link Notification
From: Ajit Khaparde @ 2016-10-11 1:22 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev
In-Reply-To: <30145fbb-2d02-de2d-e4b4-d1317645e2db@intel.com>
On Mon, Oct 10, 2016 at 10:40 AM, Ferruh Yigit <ferruh.yigit@intel.com>
wrote:
> Hi Ajit,
>
> On 9/29/2016 6:03 PM, Ajit Khaparde wrote:
> > This patch adds support to get Link notification asynchronously.
> > The HW sends Async notifications on default completion ring. The
> > PMD processes these notifications and logs a message appropriately.
> >
> > Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
> > ---
> > drivers/net/bnxt/Makefile | 1 +
> > drivers/net/bnxt/bnxt.h | 6 +-
> > drivers/net/bnxt/bnxt_cpr.c | 21 +++---
> > drivers/net/bnxt/bnxt_ethdev.c | 114 ++++++++++++++++++++++++++----
> > drivers/net/bnxt/bnxt_hwrm.c | 93 ++++++++++++------------
> > drivers/net/bnxt/bnxt_irq.c | 156 ++++++++++++++++++++++++++++++
> +++++++++++
> > drivers/net/bnxt/bnxt_irq.h | 51 ++++++++++++++
> > 7 files changed, 367 insertions(+), 75 deletions(-)
> > create mode 100644 drivers/net/bnxt/bnxt_irq.c
> > create mode 100644 drivers/net/bnxt/bnxt_irq.h
> >
>
> <...>
>
> > +static inline int
> > +rte_bnxt_atomic_read_link_status(struct rte_eth_dev *eth_dev,
> > + struct rte_eth_link *link)
> > +{
> > + struct rte_eth_link *dst = link;
> > + struct rte_eth_link *src = ð_dev->data->dev_link;
> > +
> > + if (rte_atomic64_cmpset((uint64_t *)dst, *(uint64_t *)dst,
> > + *(uint64_t *)src) == 0)
> > + return 1;
> > +
> > + return 0;
> > +}
> > +
>
> This creates a compilation error:
> .../drivers/net/bnxt/bnxt_ethdev.c:444:1:
> error: unused function 'rte_bnxt_atomic_read_link_status'
> [-Werror,-Wunused-function]
> rte_bnxt_atomic_read_link_status(struct rte_eth_dev *eth_dev,
> ^
>
> Since the patches in this patchet really not related, it is OK to send a
>
> new version of just this patch.
>
Sure. Let me respin it. Thanks
>
> Thanks,
> ferruh
>
>
^ permalink raw reply
* Re: [RFC v2] Generic flow director/filtering/classification API
From: Zhao1, Wei @ 2016-10-11 1:47 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: dev@dpdk.org
In-Reply-To: <20161010131927.GK17252@6wind.com>
Hi Adrien Mazarguil,
There is a struct rte_flow_action_rss in rte_flow.txt, the member rss_conf is a pointer type, is there any convenience in using pointer?
Why not using struct rte_eth_rss_conf rss_conf type, as rte_flow_item_ipv4/ rte_flow_item_ipv6 struct member?
Thank you.
struct rte_flow_action_rss {
struct rte_eth_rss_conf *rss_conf; /**< RSS parameters. */
uint16_t queues; /**< Number of entries in queue[]. */
uint16_t queue[]; /**< Queues indices to use. */
};
> -----Original Message-----
> From: Adrien Mazarguil [mailto:adrien.mazarguil@6wind.com]
> Sent: Monday, October 10, 2016 9:19 PM
> To: Zhao1, Wei <wei.zhao1@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [RFC v2] Generic flow director/filtering/classification
> API
>
> Hi Wei,
>
> On Mon, Oct 10, 2016 at 09:42:53AM +0000, Zhao1, Wei wrote:
> > Hi Adrien Mazarguil,
> >
> > In your v2 version of rte_flow.txt , there is an action type
> RTE_FLOW_ACTION_TYPE_MARK, but there is no definition of struct
> rte_flow_action_mark.
> > And there is an definition of struct rte_flow_action_id. Is it a typo or other
> usage?
> >
> > Thank you.
> >
> > struct rte_flow_action_id {
> > uint32_t id; /**< 32 bit value to return with packets. */ };
>
> That is indeed a mistake, this struct should be named
> "rte_flow_action_mark". I'll fix it for the next update, thanks.
>
> --
> Adrien Mazarguil
> 6WIND
^ permalink raw reply
* Re: [PATCH v7] net/virtio: add set_mtu in virtio
From: Yuanhan Liu @ 2016-10-11 4:01 UTC (permalink / raw)
To: Kavanagh, Mark B; +Cc: Dey, stephen@networkplumber.org, dev@dpdk.org
In-Reply-To: <DC5AD7FA266D86499789B1BCAEC715F85C7260DD@irsmsx105.ger.corp.intel.com>
On Mon, Oct 10, 2016 at 10:49:22AM +0000, Kavanagh, Mark B wrote:
> >
> >On Thu, Sep 29, 2016 at 04:31:30PM -0400, Dey wrote:
> >> /*
> >> * dev_ops for virtio, bare necessities for basic operation
> >> */
> >> @@ -677,7 +685,6 @@ static const struct eth_dev_ops virtio_eth_dev_ops = {
> >> .allmulticast_enable = virtio_dev_allmulticast_enable,
> >> .allmulticast_disable = virtio_dev_allmulticast_disable,
> >> + .mtu_set = virtio_mtu_set,
> >> .dev_infos_get = virtio_dev_info_get,
> >> .stats_get = virtio_dev_stats_get,
> >> .xstats_get = virtio_dev_xstats_get,
> >> --
> >> 2.9.3.windows.1
> >
> >Your patch is malformed: I got an error while trying to apply it.
> >
> > patch: **** malformed patch at line 167: * dev_ops for virtio,
> > bare necessities for basic operation
> >
> >Seems like the way you were generating the patch is wrong.
> >
> >Anyway, I applied it manually, with the "- frame_size" fix as well
> >as few more minor coding style fixes.
> >
> >So applied to dpdk-next-virtio.
>
> Hi Yuanhan/Souvik,
>
> Given my contributions to this patch (and in particular since comments from here - http://dpdk.org/ml/archives/dev/2016-September/047208.html - were copied directly into the commit message), I think that I should have been added as co-author of the patch?
Mark,
I appreciate your contributions here. But for this case, I think it
might not be enough for adding you as the co-author: you don't co-write
the code with Souvik after all.
However, I'd suggest you to add your "Reviewed-by" if a patch looks to
you after your review effort. This is another way to recognize your
contributions to a patch.
Thanks.
--yliu
>
> Let me know if you think that I am mistaken.
>
> Thanks in advance,
> Mark
> >
> > --yliu
^ permalink raw reply
* Re: [PATCH V2 1/2] net/virtio: support modern device id
From: Yuanhan Liu @ 2016-10-11 4:14 UTC (permalink / raw)
To: Jason Wang; +Cc: dev, huawei.xie, mst, vkaplans
In-Reply-To: <1475051112-5108-1-git-send-email-jasowang@redhat.com>
On Wed, Sep 28, 2016 at 04:25:11PM +0800, Jason Wang wrote:
> Add modern device id and rename VIRTIO_PCI_DEVICEID_MIN to
> VIRTIO_PCI_LEGACY_DEVICEID_NET. While at it, remove unused macros too.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Series applied to dpdk-next-virtio.
Thanks.
--yliu
^ permalink raw reply
* Re: [PATCH V2 2/2] virtio: support IOMMU platform
From: Yuanhan Liu @ 2016-10-11 4:14 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jason Wang, dev, huawei.xie, vkaplans
In-Reply-To: <20161007042444.jbfoimmbuaxh2ped@redhat.com>
On Fri, Oct 07, 2016 at 07:24:44AM +0300, Michael S. Tsirkin wrote:
> On Wed, Sep 28, 2016 at 04:25:12PM +0800, Jason Wang wrote:
> > Negotiate VIRTIO_F_IOMMU_PLATFORM to have IOMMU support.
> >
> > Signed-off-by: Jason Wang <jasowang@redhat.com>
> > ---
> > Changes from v1:
> > - remove unnecessary NEED_MAPPING flag
>
> One thing we probably should do is enable this flag
> with VFIO but not with UIO or VFIO-noiommu.
Good suggestion. I think we could do that in another patch.
> > ---
> > drivers/net/virtio/virtio_ethdev.h | 3 ++-
> > drivers/net/virtio/virtio_pci.h | 3 ++-
> > 2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/virtio/virtio_ethdev.h b/drivers/net/virtio/virtio_ethdev.h
> > index 2ecec6e..04a06e2 100644
> > --- a/drivers/net/virtio/virtio_ethdev.h
> > +++ b/drivers/net/virtio/virtio_ethdev.h
> > @@ -63,7 +63,8 @@
> > 1u << VIRTIO_NET_F_CTRL_RX | \
> > 1u << VIRTIO_NET_F_CTRL_VLAN | \
> > 1u << VIRTIO_NET_F_MRG_RXBUF | \
> > - 1ULL << VIRTIO_F_VERSION_1)
> > + 1ULL << VIRTIO_F_VERSION_1 | \
> > + 1ULL << VIRTIO_F_IOMMU_PLATFORM )
>
> Space before ) looks kind of ugly.
Yes, a bit. I will remove it while apply.
> > #define VIRTIO_TRANSPORT_F_START 28
> > -#define VIRTIO_TRANSPORT_F_END 32
> > +#define VIRTIO_TRANSPORT_F_END 34
> >
>
> This seems unused. Drop it?
Indeed. I will submit a patch to remove both (_START and _END).
--yliu
^ permalink raw reply
* Re: 17.02 Roadmap
From: Yuanhan Liu @ 2016-10-11 5:32 UTC (permalink / raw)
To: Thomas Monjalon
Cc: O'Driscoll, Tim, dev, Maxime Coquelin, Harris, James R,
Liu, Changpeng
In-Reply-To: <1998191.9HGrB6oKr3@xps13>
On Mon, Oct 10, 2016 at 10:42:58PM +0200, Thomas Monjalon wrote:
> > Support New Device Types in Vhost-User: Support will be added to vhost-user for new device types including vhost-scsi and vhost-blk.
>
> Great!
> Is it only related to networking or should we expect some storage-related
> code or drivers to come up?
It's not only netowrking related. It just introduces few more APIs to
export those buf infos (virt addr, phys addr, len, etc) to applications,
so that they can handle/parse the data in the way they want. For example,
for SPDK (https://01.org/spdk), they can use those APIs to fetch guest
data and parse it following virtio-SCSI spec.
The dequeue path (guest Tx) might look like something below:
rte_vhost_dequeue_vring_desc_burst(vid, queue_id, iov, count)
{
for (i = 0; i < count; i++) {
desc_idx = get_next_desc();
iov[i]->addr = desc_virt_addr(desc[desc_idx]->addr);
iov[i]->phys_addr = desc_phys_addr(desc[desc_idx]->addr);
iov[i]->len = desc[desc_idx]->len;
iov[i]->desc = desc_idx;
}
return i;
}
rte_vhost_update_used_ring(vid, queue_id, descs, count)
{
for (i = 0; i < count; i++) {
used_idx = get_next_used_idx();
vq->used->ring[used_idx] = descs[i];
}
vq->used->idx += i;
}
And we introduce similar APIs to the enqueue path.
--yliu
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 1/2] vhost: enable any layout feature
From: Yuanhan Liu @ 2016-10-11 6:04 UTC (permalink / raw)
To: Maxime Coquelin; +Cc: Michael S. Tsirkin, Stephen Hemminger, dev, qemu-devel
In-Reply-To: <18372cc2-19d3-f455-728d-2f2ed405d800@redhat.com>
On Mon, Oct 10, 2016 at 04:54:39PM +0200, Maxime Coquelin wrote:
>
>
> On 10/10/2016 04:42 PM, Yuanhan Liu wrote:
> >On Mon, Oct 10, 2016 at 02:40:44PM +0200, Maxime Coquelin wrote:
> >>>>>At that time, a packet always use 2 descs. Since indirect desc is
> >>>>>enabled (by default) now, the assumption is not true then. What's
> >>>>>worse, it might even slow things a bit down. That should also be
> >>>>>part of the reason why performance is slightly worse than before.
> >>>>>
> >>>>> --yliu
> >>>>
> >>>>I'm not sure I get what you are saying
> >>>>
> >>>>>commit 1d41d77cf81c448c1b09e1e859bfd300e2054a98
> >>>>>Author: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> >>>>>Date: Mon May 2 17:46:17 2016 -0700
> >>>>>
> >>>>> vhost: optimize dequeue for small packets
> >>>>>
> >>>>> A virtio driver normally uses at least 2 desc buffers for Tx: the
> >>>>> first for storing the header, and the others for storing the data.
> >>>>>
> >>>>> Therefore, we could fetch the first data desc buf before the main
> >>>>> loop, and do the copy first before the check of "are we done yet?".
> >>>>> This could save one check for small packets that just have one data
> >>>>> desc buffer and need one mbuf to store it.
> >>>>>
> >>>>> Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> >>>>> Acked-by: Huawei Xie <huawei.xie@intel.com>
> >>>>> Tested-by: Rich Lane <rich.lane@bigswitch.com>
> >>>>
> >>>>This fast-paths the 2-descriptors format but it's not active
> >>>>for indirect descriptors. Is this what you mean?
> >>>
> >>>Yes. It's also not active when ANY_LAYOUT is actually turned on.
> >>>>Should be a simple matter to apply this optimization for indirect.
> >>>
> >>>Might be.
> >>
> >>If I understand the code correctly, indirect descs also benefit from this
> >>optimization, or am I missing something?
> >
> >Aha..., you are right!
>
> The interesting thing is that the patch I send on Thursday that removes
> header access when no offload has been negotiated[0] seems to reduce
> almost to zero the performance seen with indirect descriptors enabled.
Didn't follow that.
> I see this with 64 bytes packets using testpmd on both ends.
>
> When I did the patch, I would have expected the same gain with both
> modes, whereas I measured +1% for direct and +4% for indirect.
IIRC, I did a test before (remove those offload code piece), and the
performance was basically the same before and after that. Well, there
might be some small difference, say 1% as you said. But the result has
never been steady.
Anyway, I think your patch is good to have: I just didn't see v2.
--yliu
^ 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