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 packets. By changing the flags to be:
> PKT_RX_L4_CKSUM_GOOD and PKT_RX
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 error
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 pac
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, m
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 insertions(+)
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: Olivier
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 th
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
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 t
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
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 e
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 is
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
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 +-
lib/
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 increase
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 real
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: mer
Hello Olivier, have you tested this patch to see if there is a negative impact
to performance?
Wouldn't the processor have to mask the high bytes of the physical address when
it is used, for example, to populate descriptors with buffer addresses? When
compute bound, this could steal CPU cycles
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
RTE_TARGET=x
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 2 sockets (4 GB per
socket
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: Anato
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 deletio
The pci_switch_module() function should only do what its name tells: unbind pci
devices and rebind them on the specified kernel driver.
Hence, it can not call pci_uio_map_resource().
Call to pci_uio_map_resource() should be moved to rte_eal_pci_probe_one_driver()
so that we can factorize code.
Si
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 +---
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 +--
lib/librte_eal/linuxapp/eal/e
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 insertions(+)
Looking at bsd implementation, we can see that there are some potential mem
leaks in linux implementation. Fix them.
Signed-off-by: David Marchand
---
lib/librte_eal/linuxapp/eal/eal_pci.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/linuxapp/e
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 disco
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 directory
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 a/examples/netma
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
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
Signed-off-
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 +++
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 mod
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 t
-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 ini
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 ++
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 +++---
lib/librte_rin
These 2 patches adds 2 new functions that permits to initialize and use
a rte_ring anywhere in memory.
Before this patches, only rte_ring_create() was available. This function
allocates a rte_memzone (that cannot be freed) and initializes a ring
inside.
This series allows to do the following:
s
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:
error:
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 ol_flag
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.
42 matches
Mail list logo
