[dpdk-dev] irq_to_desc undefined when compiling igb_uio

Hi, On Tue, Aug 26, 2014 at 08:55:29PM +, Habibi, Michael wrote: > I have verified in our kernel source, as well as the public > source for 2.6.34, that irq_to_desc is not an exported function. > However the documentation states that the minimum version required is > only 2.6.33. Did I setup

[dpdk-dev] [PATCH v2 0/7] Support flow director programming on fortville

The patch set supports flow director programming on fortville. It includes: - reserve i40e resources for flow director, such as queue and vsi. - support the new ethdev API rx_classification_filter_ctl for all the configuration or queries for receive classification filters. - support

[dpdk-dev] [PATCH v2 4/7] i40e: function implement in i40e for flow director flush and info get

support the API ops defined in ethdev, the behavior according to each command: RTE_CMD_FDIR_FLUSH : clear all FDIR filter rules. RTE_CMD_FDIR_INFO_GET: get FDIR information. Signed-off-by: jingjing.wu Reviewed-by: Helin Zhang Reviewed-by: Jing Chen Reviewed-by: Jijiang Liu ---

[dpdk-dev] [PATCH v2 7/7]app/testpmd: add commands and config functions for i40e flow director support

add structure definition to construct programming packet. add commands to programming 6 flow types for the flow director filters, which is called PCTYPE in fortville: ipv4, tcpv4, udpv4, ipv6, tcpv6, udpv6 add commands to support flushing flow director table and get info Signed-off-by:

[dpdk-dev] [RFC] lib/librte_vhost: qemu vhost-user support into DPDK vhost library

Hi Changchun, (2014/08/27 14:01), Ouyang, Changchun wrote: > Agree with you, the performance should be same as the data path (RX/TX) is > not affected, > The difference between implementation only exists in the virtio device > creation and destroy stage. Yes, I agree. Also There may be the

[dpdk-dev] [RFC] lib/librte_vhost: qemu vhost-user support into DPDK vhost library

> -Original Message- > From: Tetsuya.Mukawa [mailto:mukawa at igel.co.jp] > Sent: Wednesday, August 27, 2014 1:28 PM > To: Ouyang, Changchun; dev at dpdk.org > Cc: Xie, Huawei; Katsuya MATSUBARA; nakajima.yoshihiro at lab.ntt.co.jp; > Hitoshi Masutani > Subject: Re: [dpdk-dev] [RFC]

[dpdk-dev] is there any function like rte_mempool_destroy compare with rte_mempool_create

Hello, folks: I only see the rte_mempool_create but without function like rte_mempool_destroy? If I run an application twice, is there possible that the app has the memory leak? Or it just doesn't have enough memory to execute it again because the first one already get most of the memory but

[dpdk-dev] is there any function like rte_mempool_destroy compare with rte_mempool_create

On Wed, Aug 27, 2014 at 07:46:26AM +, Ni, Xun wrote: > If I run an application twice, is there possible that > the app has the memory leak? Or it just doesn't have enough memory to > execute it again because the first one already get most of the memory but > without release it. User-mapped

[dpdk-dev] [PATCH v2 0/7]]Support VxLAN on Fortville

Tested-by: Liu, Yong < yong.liu at intel.com> This patch set has been verified and ready to integrated into dpdk.org. Please refer to following information: Board: CrownPass OS: Fedora20 Kenrel: 3.15.8-200.fc20.x86_64 GCC: gcc version 4.8.3 NIC: Fortville Spirit Falls VxLAN cases

[dpdk-dev] overcommitting CPUs

IMHO adding "Interrupt Mode" to dpdk is important as this can open DPDK to a larger public of consumers, I can easily imagine someone trying to find user space networking solution (And deciding against verbs - RDMA) for the obvious reasons and not needing deterministic latency. A few thoughts:

[dpdk-dev] [PATCH RFC 0/3] only call iopl when necessary

Hi David: The reason iopl is put in rte_eal_init is that we want all later created DPDK processes/threads inherit the iopl permission. If you only call iopl in pmd_init, RX/TX and other threads which needs io permission will segmentation fault. -huawei > -Original Message- > From: dev

[dpdk-dev] [PATCH RFC 0/3] only call iopl when necessary

Hello, On Wed, Aug 27, 2014 at 11:22 AM, Xie, Huawei wrote: > Hi David: > The reason iopl is put in rte_eal_init is that we want all later created > DPDK processes/threads inherit the iopl permission. > If you only call iopl in pmd_init, RX/TX and other threads which needs io > permission will

[dpdk-dev] [dpdk-announce] SPEED MATTERS contest by 6WIND

Hi all, Yesterday, during Hot Interconnects in Google?s Mountain View Headquarters, has been announced the winners of the DPDK SPEED MATTERS contest, sponsored by 6WIND. We get three winners: AEPONYX, TrustInSoft and Srivats P. They won nice RC cars running at more than 50 km/h (not for

[dpdk-dev] [PATCH RFC 0/3] only call iopl when necessary

That is ok. If virtio PMD is a dynamic linked library, is it possible that virtio PMD is loaded later? From: David Marchand [mailto:david.march...@6wind.com] Sent: Wednesday, August 27, 2014 5:34 PM To: Xie, Huawei Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH RFC 0/3] only call iopl when

[dpdk-dev] [PATCH] fix unix permissions for source files

On Tue, Aug 26, 2014 at 04:10:41PM +0200, David Marchand wrote: > No need for that 'x bit' on source files. > > Signed-off-by: David Marchand Acked-by: Bruce Richardson > --- > 0 files changed > mode change 100755 => 100644 examples/l3fwd/main.c > mode change 100755 => 100644

[dpdk-dev] Error in compiling Intel DPDK in FreeBSD with IVSHMEM

On Wed, Aug 27, 2014 at 08:13:59AM +, Abdul Rasheed Shaik wrote: > > Hello, > > DPDK doesnt compile with MACHINE---> ivshmem. > > I tried to compile DPDK on FreeBSD Guest machine. > gmake install T=x86_64-ivshmem-bsdapp-gcc CC=gcc48 > I get the following error > ,,, > ,,, > Build app >

[dpdk-dev] [PATCH RFC 0/3] only call iopl when necessary

Hi Huawei, 2014-08-27 10:09, Xie, Huawei: > ok, as long as we ensure with virtio PMD, the parent DPDK process has the > iopl permission so that all child threads inherits the permission. If you think the patch serie is ok, a "Reviewed-by" would be appreciated. Also, please could you check your

[dpdk-dev] [RFC] PCI config access for drivers

Hi Stephen, > Some drivers need ability to access PCI config (for example for power > management). This > adds an abstraction to do this; only implemented on Linux, but should be > possible on BSD. Since VFIO has to go to PCI config space too for some things, could you please amend your patch

[dpdk-dev] [PATCHv3] librte_acl make it build/work for 'default' target

> From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Tuesday, August 26, 2014 6:45 PM > To: Ananyev, Konstantin > Cc: dev at dpdk.org; thomas.monjalon at 6wind.com > Subject: Re: [PATCHv3] librte_acl make it build/work for 'default' target > > On Mon, Aug 25, 2014 at 04:30:05PM +,

[dpdk-dev] [PATCH 01/11] ixgbe: clean log messages

Hi David, The updated output is definitely an improvement, but if you'll go with the first solution you described (adding \n in the log macro), it works much better for products using DPDK. For developer use, I think it ends up being a wash either way. At least for my product (embedded network

[dpdk-dev] [PATCH v2 2/7] ethdev: define new ethdev API rx_classification_filter_ctl

Hi Jingjing, 2014-08-27 10:13, Jingjing Wu: > support a new ethdev API rx_classification_filter_ctl for all > the configuration or queries for receive classification filters. > this patch supports commands the API used below: > RTE_CMD_FDIR_RULE_ADD > RTE_CMD_FDIR_RULE_DEL >

[dpdk-dev] [PATCH v2 3/7] i40e: function implement in i40e for flow director filter programming

2014-08-27 10:13, Jingjing Wu: > support the API ops defined in ethdev, the behavior according to each command: > RTE_CMD_FDIR_RULE_ADD: add a new FDIR filter rule. > RTE_CMD_FDIR_RULE_DEL: delete a FDIR filter rule. Here title is really too complicated. Be concise. I'd change it to:

[dpdk-dev] [PATCH v2 5/7] fix the Marco conflict

2014-08-27 10:13, Jingjing Wu: > fix the Marco conflict between rte_ip.h and netinet/in.h Who is Marco? > +#ifndef _NETINET_IN_H > +#ifndef _NETINET_IN_H_ > /* IPv4 protocols */ > #define IPPROTO_IP 0 /**< dummy for IP */ > #define IPPROTO_HOPOPTS0 /**< IP6 hop-by-hop options */

[dpdk-dev] [PATCH v2 7/7]app/testpmd: add commands and config functions for i40e flow director support

Hi Jingjing, 2014-08-27 10:13, Jingjing Wu: > add structure definition to construct programming packet. What is a "programming packet"? > +#ifdef RTE_LIBRTE_I40E_PMD > + "i40e_flow_director_filter (port_id) (add|del)" > + " flow (ip4|ip6) src

[dpdk-dev] [PATCH v2 1/7]i40e:support VxLAN packet identification

Hi Jijiang, 2014-08-26 15:31, Jijiang Liu: > VxLAN UDP port configuration on i40e, which include > - VxLAN UDP port initialization > - add APIs to configure VxLAN UDP port Actually you should explain that you introduce tunnels and first one is VxLAN. > lib/librte_ether/rte_ethdev.c |

[dpdk-dev] Clang Scan build results

Hi Everyone, I built dpdk with Clang and used the scan-build analyzer to produce a report. The report is about 13M in size so not very nice to send to the list. I decided to place the report on github.com if you want to see the results. While running scan-build the build would fail, but I

[dpdk-dev] Clang Scan build results

*> We could run something like PC-Lint or Coverity, but they cost money :-)* Pretty sure Coverity is free for open source projects... Jay On Wed, Aug 27, 2014 at 10:13 AM, Wiles, Roger Keith < keith.wiles at windriver.com> wrote: > Hi Everyone, > > I built dpdk with Clang and used the

[dpdk-dev] [PATCH 2/3] app/testpmd: enable RSS support for i40e

2014-07-18 10:45, Helin Zhang: > i40e can support RSS no matter if SR-IOV is enabled or not, while > ixgbe/igb can not support RSS if it is SR-IOV. Code changes are > needed to support i40e RSS if SR-IOV is enabled. [...] > - /* In SR-IOV mode, RSS mode is not available */ > -

[dpdk-dev] [PATCH 3/3] ethdev: improvements for some macro definition in head file

2014-07-18 10:45, Helin Zhang: > improvements for some macro definition about RSS packet > classification types in rte_ethdev.h. [...] > -#define ETH_RSS_IPV4((uint16_t)1 << ETH_RSS_IPV4_SHIFT) [...] > +#define ETH_RSS_IPV4(1 << ETH_RSS_IPV4_SHIFT) Please

[dpdk-dev] [PATCH 1/6] ixgbe: put only non-zero initializer in definition

Since all unspecified fields in an initializer are assumed to be zero we can simplify the empty mbuf definition in the vector driver to only use the fields that are non-zero, i.e. just nb_segs = 1. This makes things shorter and means that the structure doesn't need as many updates for other fields

[dpdk-dev] [PATCH 5/6] mbuf: rename in_port to just port

In some cases we may want to tag a packet for a particular destination or output port, so rename the "in_port" field in the mbuf to just "port" so that it can be re-used for this purpose if an application needs it. Signed-off-by: Bruce Richardson --- examples/dpdk_qat/main.c

[dpdk-dev] [PATCH 2/6] mbuf: rename RTE_MBUF_SCATTER_GATHER into RTE_MBUF_REFCNT

From: Olivier Matz It seems that RTE_MBUF_SCATTER_GATHER is not the proper name for the feature it provides. "Scatter gather" means that data is stored using several buffers. RTE_MBUF_REFCNT seems to be a better name for that feature as it provides a reference counter for

[dpdk-dev] [PATCH 4/6] mbuf: remove the rte_pktmbuf structure

From: Olivier Matz The rte_pktmbuf structure was initially included in the rte_mbuf structure. This was needed when there was 2 types of mbuf (ctrl and packet). As the control mbuf has been removed, we can merge the rte_pktmbuf into the rte_mbuf structure. Advantages of

[dpdk-dev] [PATCH 0/6] Mbuf structure Rework, part 1

This patch set does some initial pre-work to prepare the mbuf data structure (and ixgbe vector driver to a lesser extent) for more major changes which will follow on in a subsequent patch set. [See previous RFC patch set for more indications of the future coming changes]. The main changes here

[dpdk-dev] [PATCH 6/6] mbuf: flatten struct vlan_macip into mbuf struct

The vlan_macip structure combined a vlan tag id with l2 and l3 headers lengths for tracking offloads. However, this structure was only used as a unit by the e1000 and ixgbe drivers, not generally. This patch removes the structure from the mbuf header and places the fields into the mbuf structure

[dpdk-dev] [PATCH 3/6] mbuf: remove rte_ctrlmbuf

From: Olivier Matz The initial role of rte_ctrlmbuf is to carry generic messages (data pointer + data length) but it's not used by the DPDK or it applications. Keeping it implies: - loosing 1 byte in the rte_mbuf structure - having some dead code rte_mbuf.[ch] This

[dpdk-dev] Clang Scan build results

Nice, we had to buy one and that was not cheap :-) I groped around on the Coverity site and did not find any statement about being free to open source, but I may have just missed it. I did find that PC-Lint, Coverity, scan-build, ? all seem to test different parts of your code and some are

[dpdk-dev] Clang Scan build results

Here's the link you want: https://scan.coverity.com/ Check the FAQ for terms and you'll need to register the product, but I didn't see anything obvious that should get in the way from being able to use it for DPDK. Agree with Coverity not being cheap. I bought it for my last company. Really

[dpdk-dev] overcommitting CPUs

When I have time maybe next month, will submit my initial RFC patch to enable interrupt and polling mode switching for 10G NIC with sample. Welcome anybody in the community to further optimize it. I think it will be very hard to have a generic DPDK-NAPI API to fit all the use cases, at least

[dpdk-dev] Clang Scan build results

2014-08-27 15:52, Wiles, Roger Keith: > I groped around on the Coverity site and did not find any statement about > being free to open source, but I may have just missed it. It's here: https://scan.coverity.com Some checks have been done with TrustInSoft Analyzer:

[dpdk-dev] Clang Scan build results

Not sure why cite marks are missing again :-( I hope they come back some day. I still must not have Mac Mail configure correctly, but I only really see a couple of options. If someone has a solution let me know. On Aug 27, 2014, at 11:09 AM, Thomas Monjalon wrote: > 2014-08-27 15:52, Wiles,

[dpdk-dev] [PATCH v2 1/6] ethdev: rename macros of packet classification type

Hi Helin, 2014-07-28 16:25, Helin Zhang: > For better understanding, 'PCTYPE' which represents > 'Packet Classification Type' is used to replace 'RSS' > in the name of shift macros. I have the same comments as for VF RSS serie, since it's almost the same patch ;) -- Thomas

[dpdk-dev] [PATCHv3] librte_acl make it build/work for 'default' target

> -Original Message- > From: Neil Horman [mailto:nhorman at tuxdriver.com] > Sent: Wednesday, August 27, 2014 7:57 PM > To: Ananyev, Konstantin > Cc: dev at dpdk.org; thomas.monjalon at 6wind.com > Subject: Re: [PATCHv3] librte_acl make it build/work for 'default' target > > On Wed, Aug

[dpdk-dev] [PATCH RFC 0/3] only call iopl when necessary

I think iopl() was added to have permission to do Port I/O for Virtio device handling. -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Xie, Huawei Sent: Wednesday, August 27, 2014 2:22 AM To: David Marchand; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH RFC 0/3]

[dpdk-dev] [PATCH RFC 0/3] only call iopl when necessary

Yes. Iopl is to allow out from user space. I played with ioperm instead but that is per thread and was a nuisance.

[dpdk-dev] Clang Scan build results

On Wed, Aug 27, 2014 at 03:13:43PM +, Wiles, Roger Keith wrote: > Hi Everyone, Hi Keith, For me the build failed with clang but I made a series of awful patches to get it to compile... not sure if the clang failures could be related to your scan-build failures. If it will help you I can