Thank you. And one more thing, does Fortville (or Niantic) support
various L2 headers when calculating RSS hash? I mean MPLS, QinQ, etc.?
14.11.2014 22:57, Chilikin, Andrey ?:
> Fortville supports symmetrical hashing on HW level, a patch for i40e PMD was
> submitted a couple of weeks ago.
14.11.2014 22:50, Ananyev, Konstantin ?:
>> -Original Message-
>> From: Yerden Zhumabekov [mailto:e_zhumabekov at sts.kz]
>> Sent: Friday, November 14, 2014 4:23 PM
>> To: Ananyev, Konstantin; Kamraan Nasim; dev at dpdk.org
>> Cc: Yuanzhang Hu
>> Subject: Re: [dpdk-dev] Load-balancing
14.11.2014 19:53, Neil Horman ?:
> On Fri, Nov 14, 2014 at 05:57:51PM +0600, Yerden Zhumabekov wrote:
>> 14.11.2014 17:33, Neil Horman ?:
>>> Not really. That covers the case of applications selecting the hash
>>> function
>>> using the DEFUALT_HASH_FUNC macro, but doesn't nothing for
I'd like to interject a question here.
In case of flow classification, one might possibly prefer for packets
from the same flow to fall on the same logical core. With this '%' load
balancing, it would require to get the same RSS hash value for packets
with direct (src to dst) and swapped (dst to
Sorry for the noise, but is anyone else having trouble reaching intel addresses
lately? The last 3 emails I've sent to the list that cc'ed intel addresses had
bounces with 554 errors from the intel MTA's.
Neil
If the user specifies 'set verbose 1' in testpmd command line,
the csum forward engine will dump some informations about received
and transmitted packets, especially which flags are set and what
values are assigned to l2_len, l3_len, l4_len and tso_segsz.
This can help someone implementing TSO or
Add two new commands in testpmd:
- tso set
- tso show
These commands can be used enable TSO when transmitting TCP packets in
the csum forward engine. Ex:
set fwd csum
tx_checksum set ip hw 0
tso set 800 0
start
Signed-off-by: Olivier Matz
---
app/test-pmd/cmdline.c | 92
Implement TSO (TCP segmentation offload) in ixgbe driver. The driver is
now able to use PKT_TX_TCP_SEG mbuf flag and mbuf hardware offload infos
(l2_len, l3_len, l4_len, tso_segsz) to configure the hardware support of
TCP segmentation.
In ixgbe, when doing TSO, the IP length must not be included
Some of the NICs supported by DPDK have a possibility to accelerate TCP
traffic by using segmentation offload. The application prepares a packet
with valid TCP header with size up to 64K and deleguates the
segmentation to the NIC.
Implement the generic part of TCP segmentation offload in
Introduce new functions to calculate checksums. These new functions
are derivated from the ones provided csumonly.c but slightly reworked.
There is still some room for future optimization of these functions
(maybe SSE/AVX, ...).
This API will be modified in tbe next commits by the introduction of
The csum forward engine was becoming too complex to be used and
extended (the next commits want to add the support of TSO):
- no explaination about what the code does
- code is not factorized, lots of code duplicated, especially between
ipv4/ipv6
- user command line api: use of bitmasks that
In testpmd the rte_port->tx_ol_flags flag was used in 2 incompatible
manners:
- sometimes used with testpmd specific flags (0xff for checksums, and
bit 11 for vlan)
- sometimes assigned to m->ol_flags directly, which is wrong in case
of checksum flags
This commit replaces the hardcoded values
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
This definition is specific to Intel PMD drivers and its definition
"indicate what bits required for building TX context" shows that it
should not be in the generic rte_mbuf.h but in the PMD driver.
Signed-off-by: Olivier Matz
---
lib/librte_mbuf/rte_mbuf.h| 5 -
Describe how to use hardware checksum API.
Signed-off-by: Olivier Matz
Acked-by: Bruce Richardson
---
lib/librte_mbuf/rte_mbuf.h | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index
The tx mbuf flags are ordered from the highest value to the
the lowest. Move the PKT_TX_VXLAN_CKSUM at the right place.
Signed-off-by: Olivier Matz
Acked-by: Bruce Richardson
---
lib/librte_mbuf/rte_mbuf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Since commit 4332beee9 "mbuf: expand ol_flags field to 64-bits", the
packet flags are now 64 bits wide. Some occurences were forgotten in
the ixgbe driver.
Signed-off-by: Olivier Matz
Acked-by: Bruce Richardson
---
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 12 ++--
1 file changed, 6
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
Acked-by: Konstantin Ananyev
---
This series add TSO support in ixgbe DPDK driver. This is a rework
of the series sent earlier this week [1]. This work is based on
another version [2] that was posted several months ago and
which included a mbuf rework that is now in mainline.
Changes in v2:
- move rte_get_rx_ol_flag_name() and
14.11.2014 17:33, Neil Horman ?:
> On Fri, Nov 14, 2014 at 01:15:12PM +0600, Yerden Zhumabekov wrote:
>>
>> Hello,
>>
>> A quick grep on dpdk source shows that rte_hash_crc() is used in
>> librte_hash in following context:
>>
>> In rte_hash.c:
>> /* Hash function used if none is specified */
2014-11-04 17:49, Yong Wang:
> This patch series include various fixes and improvement to the
> vmxnet3 pmd driver.
>
> V2:
> - Add more commit descriptions
> - Add a new patch that improve tx performance for small packet
>
> Yong Wang (6):
> vmxnet3: Fix VLAN Rx stripping
> vmxnet3: Add
Fortville supports symmetrical hashing on HW level, a patch for i40e PMD was
submitted a couple of weeks ago. For Niantic you can use symmetrical rss key
recommended by Konstantin.
Regards,
Andrey
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev,
> -Original Message-
> From: Yerden Zhumabekov [mailto:e_zhumabekov at sts.kz]
> Sent: Friday, November 14, 2014 4:23 PM
> To: Ananyev, Konstantin; Kamraan Nasim; dev at dpdk.org
> Cc: Yuanzhang Hu
> Subject: Re: [dpdk-dev] Load-balancing position field in DPDK load_balancer
> sample
Hi Lin,
(2014/11/14 14:30), Linhaifeng wrote:
>
> On 2014/11/14 13:12, Tetsuya Mukawa wrote:
>> ease try another value like 6000MB
> i have try this value 6000MB.I can munmap success.
>
> you mmap with size "memory_size + memory_offset" should also munmap with this
> size.
>
I appreciate for your
2014-11-14 08:53, Neil Horman:
> On Fri, Nov 14, 2014 at 05:57:51PM +0600, Yerden Zhumabekov wrote:
> > 14.11.2014 17:33, Neil Horman ?:
> > > On Fri, Nov 14, 2014 at 01:15:12PM +0600, Yerden Zhumabekov wrote:
> > >> A quick grep on dpdk source shows that rte_hash_crc() is used in
> > >>
Hello Thomas,
I want to discuss a small enhancement to KNI that we developed. We wanted
to send/receive mbufs between one KNI device and multiple cores, but we
wanted to keep the changes simple. So, here were our requirements:
1. Don't use heavy synchronization when reading/writing the FIFOs in
Thank you.
That?s not a really big problem that we need it?s own structure for every
command, but the lack of optional parameters is a problem.
For example:
object add IP [port]
it?s just one command, but we need two different structures - with and
without ?port?
Maybe I?ll
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Kamraan Nasim
> Sent: Thursday, November 13, 2014 6:30 PM
> To: dev at dpdk.org
> Cc: Yuanzhang Hu
> Subject: [dpdk-dev] Load-balancing position field in DPDK load_balancer
> sample app vs. Hash table
>
>
This is a very simple example app for doing packet forwarding with the
Intel DPDK. It's designed to serve as a start point for people new to
the Intel DPDK and who want to develop a new app.
Therefore it's meant to:
* have as good a performance out-of-the-box as possible, using the
best-known
Hi Lin,
(2014/11/14 13:42), Linhaifeng wrote:
>
> On 2014/11/14 11:40, Tetsuya Mukawa wrote:
>> Hi Lin,
>>
>> (2014/11/14 12:13), Linhaifeng wrote:
>>> size should be same as mmap and
>>> guest_mem -= (memory.regions[i].mmap_offset / sizeof(*guest_mem));
>>>
>> Thanks. It should be.
>> How about
On Fri, Nov 14, 2014 at 10:43:39PM +0600, Yerden Zhumabekov wrote:
>
> 14.11.2014 19:53, Neil Horman ?:
> > On Fri, Nov 14, 2014 at 05:57:51PM +0600, Yerden Zhumabekov wrote:
> >> 14.11.2014 17:33, Neil Horman ?:
> >>> Not really. That covers the case of applications selecting the hash
(2014/11/14 9:07), Xie, Huawei wrote:
>> +struct vhost_device_user_ctx {
>> +int *fds;
>> +int fd_num;
>> +struct vhost_driver *drv;
>> +};
>> +
>> /*
>> * Structure used to identify device context.
>> */
>> @@ -83,6 +89,7 @@ struct
On 2014/11/14 13:12, Tetsuya Mukawa wrote:
> ease try another value like 6000MB
i have try this value 6000MB.I can munmap success.
you mmap with size "memory_size + memory_offset" should also munmap with this
size.
--
Regards,
Haifeng
14.11.2014 6:52, Neil Horman ?:
> On Thu, Nov 13, 2014 at 06:33:14PM +0100, Thomas Monjalon wrote:
>> Any comment on these patches?
>>
>> 2014-09-03 12:05, Yerden Zhumabekov:
>>> As SSE4.2 provides CRC32 instructions with either 32 and 64 bit operands,
>>> new rte_hash_crc_8byte() call
(2014/11/14 12:40), Tetsuya Mukawa wrote:
> I am using 1GB hugepage size.
>
> $ sudo QTEST_HUGETLBFS_PATH=/mnt/huge make check
> region=0, mmap=0x2aaac000, size=6291456000
> region=0, munmap=0x2aaac000, size=6291456000, ret=-1 << failed
>
> 6291456000 is not aligned by 1GB.
> When I
Hey Folks,
This thread has been tremendously helpful, as I'm looking at adding
RSS-based load balancing to my application in the not too distant future.
Many thanks to all who have contributed, especially regarding symmetric RSS.
Not to derail the conversation too badly, but could one of you
On 2014/11/14 11:40, Tetsuya Mukawa wrote:
> Hi Lin,
>
> (2014/11/14 12:13), Linhaifeng wrote:
>>
>> size should be same as mmap and
>> guest_mem -= (memory.regions[i].mmap_offset / sizeof(*guest_mem));
>>
>
> Thanks. It should be.
> How about following patch?
>
>
Hi Lin,
(2014/11/14 12:13), Linhaifeng wrote:
>
> size should be same as mmap and
> guest_mem -= (memory.regions[i].mmap_offset / sizeof(*guest_mem));
>
Thanks. It should be.
How about following patch?
---
diff --git a/tests/vhost-user-test.c
Hi Igor,
Adding-back the list to the discussion, I removed it by mistake in my
first answer.
>> 14 . 2014 ?., ? 12:20, Olivier MATZ
>> ???(?):
>>
>> Hi Igor,
>>
>> On 11/14/2014 09:52 AM, Igor Ryzhov wrote:
>>> Are there any docs with detailed description of cmdline library?
>>> I
Hi Xie,
(2014/11/14 9:22), Xie, Huawei wrote:
>> I think so. I guess we need to consider 2 types of restarting. One is
>> virtio-net driver restarting, the other is vhost-user backend
>> restarting. But, so far, it's nice to start to think about virtio-net
>> driver restarting first. Probably we
Hello.
Are there any docs with detailed description of cmdline library?
I found only some information in ?DPDK Sample Apps? document, but it describes
only a couple of features.
Best regards,
Igor Ryzhov
(2014/11/14 11:24), Linhaifeng wrote:
> On 2014/11/14 9:28, Xie, Huawei wrote:
> actually there may be two hugepage files created by qemu. one day i
> create a 4G VM found qemu create 2 hugepage file and send them to
> vhost-user. you can try to test it.
That's the case.
Bcasue I didn't think
On 2014/11/14 10:30, Tetsuya Mukawa wrote:
> Hi Lin,
>
> (2014/11/13 15:30), Linhaifeng wrote:
>> On 2014/11/12 12:12, Tetsuya Mukawa wrote:
>>> Hi Xie,
>>>
>>> (2014/11/12 6:37), Xie, Huawei wrote:
Hi Tetsuya:
There are two major technical issues in my mind for vhost-user
I tested with latest qemu(with offset fix) in vhost app(not with test case),
unmap succeeds only when the size is aligned to 1GB(hugepage size).
Another important thing is could we do mmap(0, region[i].memory_size, PROT_XX,
mmap_offset) rather than with offset 0? With the region above 4GB, we
Firstly, due to some conflicts, we're going to move next Tuesday's meeting to 1
hour later. Apologies for the short notice on the change. Here's the new
meeting time in a variety of timezones:
Dublin (Ireland)Tuesday, November 18, 2014 at
5:00:00 PMGMT UTC
On Wed, Nov 12, 2014 at 03:22:37AM +, Chi, Xiaobo (NSN - CN/Hangzhou) wrote:
> Hi,
> Background:
> What we are doing now is port make telecom network element to be cloud based.
> For one of our product, DPDK is applied not only for fastpath/dataplane
> processing, but also for Distributed
On 14/11/14 10:03, Morten Jagd Christensen wrote:
> Hi Marc,
>
> It turns out that I could successively comment out the setting of cpu flags
> in mk/rte.cpuflags,
> rebuild dpdk and my application, and then run valgrid until no further error
> messages occured.
>
> But it turns out to be too slow
On 2014/11/14 9:28, Xie, Huawei wrote:
>
>
>> -Original Message-
>> From: Linhaifeng [mailto:haifeng.lin at huawei.com]
>> Sent: Wednesday, November 12, 2014 11:28 PM
>> To: Xie, Huawei; 'Tetsuya Mukawa'; dev at dpdk.org
>> Subject: Re: [dpdk-dev] vhost-user technical isssues
>>
>>
>>
Hi Jijiang,
On 11/14/2014 09:15 AM, Liu, Jijiang wrote:
>
> Thomas Monjalon wrote:
>>
>> You mean that PKT_TX_VXLAN_CKSUM request hardware checksumming of outer
>> L3, outer L4, inner L3 and inner L4?
>> So maybe the name and comments are not enough clear.
>
> Yes, PKT_TX_VXLAN_CKSUM request
On Thu, Nov 13, 2014 at 07:42:08PM -0500, Neil Horman wrote:
> On Thu, Nov 13, 2014 at 12:57:25PM +0100, Thomas Monjalon wrote:
> > 2014-11-13 06:14, Neil Horman:
> > > On Thu, Nov 13, 2014 at 02:03:18AM -0800, Thomas Monjalon wrote:
> > > > 2014-10-08 15:14, Neil Horman:
> > > > > On Wed, Oct 08,
Hi all,
I'd like to propose an update on DPDK memcpy optimization.
Please see RFC below for details.
Thanks
John
---
DPDK Memcpy Optimization
1. Introduction
2. Terminology
3. Mechanism
3.1 Architectural Insights
3.2 DPDK memcpy optimization
3.3 Code change
4. Glibc memcpy
On Fri, Nov 14, 2014 at 10:48:21AM +, Bruce Richardson wrote:
> On Wed, Nov 12, 2014 at 03:22:37AM +, Chi, Xiaobo (NSN - CN/Hangzhou)
> wrote:
> > Hi,
> > Background:
> > What we are doing now is port make telecom network element to be cloud
> > based. For one of our product, DPDK is
On Fri, Nov 14, 2014 at 05:57:51PM +0600, Yerden Zhumabekov wrote:
>
> 14.11.2014 17:33, Neil Horman ?:
> > On Fri, Nov 14, 2014 at 01:15:12PM +0600, Yerden Zhumabekov wrote:
> >>
> >> Hello,
> >>
> >> A quick grep on dpdk source shows that rte_hash_crc() is used in
> >> librte_hash in
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, November 13, 2014 9:30 PM
> To: Pattan, Reshma
> Cc: dev at dpdk.org; De Lara Guarch, Pablo
> Subject: Re: [dpdk-dev] [PATCH v7] distributor_app: new sample app
>
> Hi Reshma,
>
> > >
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, November 13, 2014 5:10 PM
> To: Liu, Jijiang
> Cc: dev at dpdk.org; Olivier MATZ
> Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum
> offload
>
> 2014-11-13
> -Original Message-
> From: Xie, Huawei
> Sent: Friday, November 14, 2014 2:31 PM
> To: Chen, Jing D; dev at dpdk.org
> Subject: RE: [PATCH 1/2] examples/vhost: support new VMDQ API and new
> nic i40e
>
>
>
> > -Original Message-
> > From: Chen, Jing D
> > Sent: Wednesday,
On Fri, Nov 14, 2014 at 01:15:12PM +0600, Yerden Zhumabekov wrote:
> 14.11.2014 6:52, Neil Horman ?:
> > On Thu, Nov 13, 2014 at 06:33:14PM +0100, Thomas Monjalon wrote:
> >> Any comment on these patches?
> >>
> >> 2014-09-03 12:05, Yerden Zhumabekov:
> >>> As SSE4.2 provides CRC32
> -Original Message-
> From: Chen, Jing D
> Sent: Wednesday, November 12, 2014 10:58 PM
> To: Xie, Huawei; dev at dpdk.org
> Subject: RE: [PATCH 1/2] examples/vhost: support new VMDQ API and new nic
> i40e
>
> Hi,
>
> > -Original Message-
> > From: Xie, Huawei
> > Sent:
> -Original Message-
> From: Linhaifeng [mailto:haifeng.lin at huawei.com]
> Sent: Thursday, November 13, 2014 7:24 PM
> To: Xie, Huawei; 'Tetsuya Mukawa'; dev at dpdk.org; lilijun; zhangkun
> Subject: Re: [dpdk-dev] vhost-user technical isssues
>
>
>
> On 2014/11/14 9:28, Xie, Huawei
> -Original Message-
> From: Chen, Jing D
> Sent: Wednesday, November 12, 2014 11:02 PM
> To: Xie, Huawei; dev at dpdk.org
> Subject: RE: [PATCH 2/2] examples/vhost: use factorized default Rx/Tx
> configuration
>
> Hi,
>
> > -Original Message-
> > From: Xie, Huawei
> > Sent:
> -Original Message-
> From: Linhaifeng [mailto:haifeng.lin at huawei.com]
> Sent: Wednesday, November 12, 2014 11:28 PM
> To: Xie, Huawei; 'Tetsuya Mukawa'; dev at dpdk.org
> Subject: Re: [dpdk-dev] vhost-user technical isssues
>
>
>
> On 2014/11/12 5:37, Xie, Huawei wrote:
> > Hi
> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Tuesday, November 11, 2014 9:13 PM
> To: Xie, Huawei; dev at dpdk.org
> Cc: Long, Thomas
> Subject: Re: vhost-user technical isssues
>
> Hi Xie,
>
> (2014/11/12 6:37), Xie, Huawei wrote:
> > Hi Tetsuya:
>
> +struct vhost_device_user_ctx {
> + int *fds;
> + int fd_num;
> + struct vhost_driver *drv;
> +};
> +
> /*
> * Structure used to identify device context.
> */
> @@ -83,6 +89,7 @@ struct vhost_device_ctx {
> vhost_driver_type_t
63 matches
Mail list logo
