[dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len in a bitfield

2014-05-09 Thread Olivier MATZ
Hi Jeff, Thank you for your comment. On 05/09/2014 05:39 PM, Shaw, Jeffrey B wrote: > have you tested this patch to see if there is a negative impact to > performance? Yes, but not with testpmd. I passed our internal non-regression performance tests and it shows no difference (or below the

[dpdk-dev] [PATCH RFC 00/11] ixgbe/mbuf: add TSO support

2014-05-09 Thread Stephen Hemminger
On Fri, 09 May 2014 23:49:45 +0200 Olivier MATZ wrote: > Hi Stephen, > > On 05/09/2014 07:04 PM, Stephen Hemminger wrote: > > I would also like to propose changing the checksum offload flags. > > Many devices can indicate good checksum in some cases but can't test > > for many other types of

[dpdk-dev] [PATCH RFC 11/11] ixgbe/mbuf: add TSO support

2014-05-09 Thread Olivier Matz
Implement TSO (TCP segmentation offload) in ixgbe driver. To delegate the TCP segmentation to the hardware, the user has to: - set the PKT_TX_TCP_SEG flag in mbuf->ol_flags (this flag implies PKT_TX_IP_CKSUM and PKT_TX_TCP_CKSUM) - fill the mbuf->hw_offload information: l2_len, l3_len, l4_len,

[dpdk-dev] [PATCH RFC 10/11] testpmd: modify source address to validate checksum calculation

2014-05-09 Thread Olivier Matz
Always modify the source address of the packet in order to validate the calculation of the checksums (L3 or L4). This was already done for IPv4 software checksum, add it for IPv4 hw checksum and IPv6. Signed-off-by: Olivier Matz --- app/test-pmd/csumonly.c | 2 ++ 1 file changed, 2

[dpdk-dev] [PATCH RFC 09/11] mbuf: rename vlan_macip_len in hw_offload and increase its size

2014-05-09 Thread Olivier Matz
To implement the TCP segmentation offload, we will need to add some more meta information in the mbuf, like the length of the L4 header, the MSS, ... To prepare this modification, this patch renames vlan_macip_len in hw_offload and change its length from 32 bits to 64 bits. Signed-off-by:

[dpdk-dev] [PATCH RFC 08/11] mbuf: change ol_flags to 32 bits

2014-05-09 Thread Olivier Matz
There is no room to add other offload flags in the current 16 bits fields. Since we have more room in the mbuf structure, we can change the ol_flags to 32 bits. A next commit will add the support of TSO (TCP Segmentation Offload) which require a new ol_flags, justifying this commit. Thanks to

[dpdk-dev] [PATCH RFC 07/11] mbuf: add functions to get the name of an ol_flag

2014-05-09 Thread Olivier Matz
In test-pmd (rxonly.c), the code is able to dump the list of ol_flags. The issue is that the list of flags in the application has to be synchronized with the flags defined in rte_mbuf.h. This patch introduces 2 new functions rte_get_rx_ol_flag_name() and rte_get_tx_ol_flag_name() that returns the

[dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an offset

2014-05-09 Thread Olivier Matz
The mbuf structure already contains a pointer to the beginning of the buffer (m->buf_addr). It is not needed to use 8 bytes again to store another pointer to the beginning of the data. Using a 16 bits unsigned integer is enough as we know that a mbuf is never longer than 64KB. We gain 6 bytes in

[dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len in a bitfield

2014-05-09 Thread Olivier Matz
The physical address is never greater than (1 << 48) = 256 TB. We can win 2 bytes in the mbuf structure by merging the physical address and the buffer length in the same bitfield. Signed-off-by: Olivier Matz --- lib/librte_mbuf/rte_mbuf.c | 3 ++- lib/librte_mbuf/rte_mbuf.h | 7 --- 2 files

[dpdk-dev] [PATCH RFC 04/11] mbuf: remove the rte_pktmbuf structure

2014-05-09 Thread 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 doing this: - the access to mbuf fields is

[dpdk-dev] [PATCH RFC 03/11] mbuf: remove rte_ctrlmbuf

2014-05-09 Thread 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 patch removes this feature. Thanks to it, it

[dpdk-dev] [PATCH RFC 02/11] mbuf: rename RTE_MBUF_SCATTER_GATHER into RTE_MBUF_REFCNT

2014-05-09 Thread 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 mbufs. The macro RTE_MBUF_SCATTER_GATHER is

[dpdk-dev] [PATCH RFC 01/11] igb/ixgbe: fix IP checksum calculation

2014-05-09 Thread Olivier Matz
According to Intel? 82599 10 GbE Controller Datasheet (Table 7-38), both L2 and L3 lengths are needed to offload the IP checksum. Note that the e1000 driver does not need to be patched as it already contains the fix. Signed-off-by: Olivier Matz --- lib/librte_pmd_e1000/igb_rxtx.c | 2 +-

[dpdk-dev] [PATCH RFC 00/11] ixgbe/mbuf: add TSO support

2014-05-09 Thread Olivier Matz
This series add TSO support in ixgbe DPDK driver. As discussed previously on the list [1], one problem is that there is not enough room in rte_mbuf today to store the required information to implement this feature: - a new ol_flag - the MSS - the L4 header len A solution would be to

[dpdk-dev] [PATCH] malloc: fix rte_free run time in O(n) free blocks

2014-05-09 Thread Thomas Monjalon
2014-05-09 09:24, Sanford, Robert: > Hi Thomas, > > >Some patches like this one are not yet reviewed because efforts were > >focused > >on release 1.6.0r2. This enhancement must be integrated in 1.7.0. > >I know that patchwork service is desired and I hope it will be available > >soon. > > I

[dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len in a bitfield

2014-05-09 Thread Shaw, Jeffrey B
I agree, we should wait for comments then test the performance when the patches have settled. -Original Message- From: Olivier MATZ [mailto:olivier.m...@6wind.com] Sent: Friday, May 09, 2014 9:06 AM To: Shaw, Jeffrey B; dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH RFC 05/11] mbuf:

[dpdk-dev] [PATCH] mk: add missing scripts directory in install directory

2014-05-09 Thread David Marchand
Trying to install headers for an external library using DPDK exported makefile rte.extshared.mk results in following error : $ cd dpdk $ make install DESTDIR=/home/marchand/myapp/staging/plop T=x86_64-default-linuxapp-gcc $ cd ~/myapp $ make RTE_SDK=/home/marchand/myapp/staging/plop

[dpdk-dev] [PATCH v2] eal: change default per socket memory allocation

2014-05-09 Thread David Marchand
From: Didier Pallard Currently, if there is more memory in hugepages than the amount requested by dpdk application, the memory is allocated by taking as much memory as possible from each socket, starting from first one. For example if a system is configured with 8 GB in

[dpdk-dev] [PATCH v2 7/7] pci: remove deprecated RTE_EAL_UNBIND_PORTS option

2014-05-09 Thread David Marchand
RTE_EAL_UNBIND_PORTS was deprecated in DPDK 1.4.0 and removed in 1.6.0, but the code was not removed. The bind/unbind operations should not be handled by the eal. These operations should be either done outside of dpdk or inside the PMDs themselves as these are their problems. Signed-off-by:

[dpdk-dev] [PATCH v2 6/7] pci: move RTE_PCI_DRV_FORCE_UNBIND handling out of #ifdef

2014-05-09 Thread David Marchand
Move RTE_PCI_DRV_FORCE_UNBIND flag handling out of RTE_EAL_UNBIND_PORTS section. This had nothing to do with RTE_EAL_UNBIND_PORTS anyway. Signed-off-by: David Marchand --- lib/librte_eal/linuxapp/eal/eal_pci.c | 89 - 1 file changed, 44 insertions(+), 45

[dpdk-dev] [PATCH v2 4/7] pci: rework interrupt fd init and fix fd leak

2014-05-09 Thread David Marchand
A fd leak happens in pci_map_resource when multiple bars are mapped. Fix this by closing fd unconditionnally in this function and open the intr_handle fd in pci_uio_map_resource instead. Signed-off-by: David Marchand --- lib/librte_eal/bsdapp/eal/eal_pci.c | 60 +---

[dpdk-dev] [PATCH v2 3/7] pci: remove virtio-uio workaround

2014-05-09 Thread David Marchand
virtio-uio does not need eal to map bars from uio device, so remove flag RTE_PCI_DRV_NEED_IGB_UIO. Then, move virtio-uio workaround out of generic eal_pci.c for linux implementation. Signed-off-by: David Marchand --- lib/librte_eal/bsdapp/eal/eal_pci.c |9 +--

[dpdk-dev] [PATCH v2 2/7] pci: align bsd implementation on linux

2014-05-09 Thread David Marchand
bsd implementation lacks check on driver flags, fix this. Besides, check on BAR0 is not needed and could cause trouble for devices that have no BAR0. Signed-off-by: David Marchand --- lib/librte_eal/bsdapp/eal/eal_pci.c | 42 +++ 1 file changed, 23

[dpdk-dev] [PATCH v2 0/7] pci cleanup

2014-05-09 Thread David Marchand
Hello all, Here is an attempt at having an equal implementation in bsd and linux eal_pci.c. It results in following changes : - checks on driver flag in bsd which were missing - remove virtio-uio workaround in linux eal_pci.c - remove deprecated RTE_EAL_UNBIND_PORTS option Along the way, I

[dpdk-dev] [PATCH v2 6/6] mk: add "make examples" target in root makefile

2014-05-09 Thread Olivier Matz
It is now possible to build all projects from the examples/ directory using one command from root directory. Some illustration of what is possible: - build examples in the DPDK tree for one target # install the x86_64-default-linuxapp-gcc in # ${RTE_SDK}/x86_64-default-linuxapp-gcc

[dpdk-dev] [PATCH v2 5/6] examples: fix netmap_compat example

2014-05-09 Thread Olivier Matz
It is not allowed to reference a an absolute file name in SRCS-y. A VPATH has to be used, else the dependencies won't be checked properly. Signed-off-by: Olivier Matz --- examples/netmap_compat/bridge/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[dpdk-dev] [PATCH v2 4/6] examples: fix qos_sched makefile

2014-05-09 Thread Olivier Matz
The example does not compile as the linker complains about duplicated symbols. Remove -lsched from LDLIBS, it is already present in rte.app.mk and added by the DPDK framework automatically. Signed-off-by: Olivier Matz --- examples/qos_sched/Makefile | 2 -- 1 file changed, 2 deletions(-) diff

[dpdk-dev] [PATCH v2 3/6] examples: add a makefile to build all examples

2014-05-09 Thread Olivier Matz
It is now possible to build all examples by doing the following: user at droids:~/dpdk.org$ make install T=x86_64-default-linuxapp-gcc user at droids:~/dpdk.org$ cd examples user at droids:~/dpdk.org/examples$ make RTE_SDK=${PWD}/.. \ RTE_TARGET=x86_64-default-linuxapp-gcc

[dpdk-dev] [PATCH v2 2/6] examples: use rte.extsubdir.mk to process subdirectories

2014-05-09 Thread Olivier Matz
Signed-off-by: Olivier Matz --- examples/l2fwd-ivshmem/Makefile | 9 + examples/multi_process/Makefile | 16 +++- examples/multi_process/client_server_mp/Makefile | 15 ++- examples/quota_watermark/Makefile| 12

[dpdk-dev] [PATCH v2 1/6] mk: introduce rte.extsubdir.mk

2014-05-09 Thread Olivier Matz
This makefile can be included by a project that needs to build several applications or libraries that are located in different directories. Signed-off-by: Olivier Matz --- mk/rte.extsubdir.mk | 53 + 1 file changed, 53 insertions(+) create

[dpdk-dev] [PATCH v2 0/6] examples: add a new makefile to build all examples

2014-05-09 Thread Olivier Matz
This patch series adds a makefile to build all examples supported by the configuration. It helps to check that all examples compile after a dpdk modification. After applying the patches, it is possible to build all examples for given targets, given the installation directory: # first, install

[dpdk-dev] [PATCH v2 0/2] ring: allow to init a rte_ring outside of an rte_memzone

2014-05-09 Thread Ananyev, Konstantin
-Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz Sent: Friday, May 09, 2014 11:15 AM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH v2 0/2] ring: allow to init a rte_ring outside of an rte_memzone These 2 patches adds 2 new functions that permits to

[dpdk-dev] [PATCH v2 2/2] ring: introduce rte_ring_init()

2014-05-09 Thread Olivier Matz
Allow to initialize a ring in an already allocated memory. The rte_ring_create() function that allocates a ring in a rte_memzone is still available and now uses the new rte_ring_init() function in order to factorize the code. Signed-off-by: Olivier Matz --- lib/librte_ring/rte_ring.c | 63

[dpdk-dev] [PATCH v2 1/2] ring: introduce rte_ring_get_memsize()

2014-05-09 Thread Olivier Matz
Add a function that returns the amount of memory occupied by a rte_ring structure and its object table. This commit prepares the next one that will allow to allocate a ring dynamically. Signed-off-by: Olivier Matz --- lib/librte_ring/rte_ring.c | 30 +++---

[dpdk-dev] Compile failed using g++ 4.8.2

2014-05-09 Thread Bo Chen
When I use Ubuntu 14.04 to compile my program, the g++ 4.8.2 print the following error message, that need to add a space around identifier PRIx64, anyone can help to submit a patch: /home/bodc/workspace/dpdk/build/dpdk-prefix/src/dpdk/x86_64-default-linuxapp-gcc/include/rte_mempool.h:347:6:

[dpdk-dev] [PATCH RFC 00/11] ixgbe/mbuf: add TSO support

2014-05-09 Thread Stephen Hemminger
On Fri, 9 May 2014 16:50:27 +0200 Olivier Matz wrote: > This series add TSO support in ixgbe DPDK driver. As discussed > previously on the list [1], one problem is that there is not enough room > in rte_mbuf today to store the required information to implement this > feature: > - a new

[dpdk-dev] [PATCH] malloc: fix rte_free run time in O(n) free blocks

2014-05-09 Thread Sanford, Robert
Hi Thomas, >Some patches like this one are not yet reviewed because efforts were >focused >on release 1.6.0r2. This enhancement must be integrated in 1.7.0. >I know that patchwork service is desired and I hope it will be available >soon. I realized that you guys had been very busy with 1.6.0r2.

[dpdk-dev] [PATCH] malloc: fix rte_free run time in O(n) free blocks

2014-05-09 Thread Thomas Monjalon
Hi Robert, 2014-05-08 16:17, Sanford, Robert: > I haven't heard anything regarding this patch. > In general, how does your team keep track of outstanding patch requests or > RFCs? If nobody complains, it means that everybody agree on the idea. So it should be accepted after review. Some patches