When adding a RSS rule with GTPU_DWN/UP, it will write from top to
bottom for profile due to firmware limitation. If a RSS rule with
GTPU_EH already exists, then GTPU_DWN/UP packet will match GTPU_EH
profile. This patch solves this issue by remembering a gtpu_eh RSS
configure and removing it before
Hello Manish,
I have just a few nits below,
On 24/07/20 03:38 -0700, Manish Chopra wrote:
> By adding generic API, this patch removes individual
> functions/defines implemented by drivers to find PCI
> extended capability.
"to find extended PCI capabilities" sounds better.
>
> Signed-off-by: M
Hi,
We finally get it worked out! It was due to our misconfiguration in the
dpdk vdpa sample application. We continue measuring the performance
using a dpdk traffic gen (64B UDP) and measure at VM's rx queue.
We wonder if the number below (around 1.8Mpps per core) is expected?
At hypervisor:
qemu
We don't support SCTP in PPPoE RSS, remove it.
Fixes: d117de460035 ("net/ice: fix GTPU/PPPoE packets with no hash value")
Fixes: 0b952714e9c1 ("net/ice: refactor PF hash flow")
Signed-off-by: Qi Zhang
---
drivers/net/ice/ice_ethdev.c | 12
drivers/net/ice/ice_hash.c | 14
A new symmetric RSS rule may force another asymmetric rule to be
symmetric, vise versa. The reason is due to the flow engine will
try to reuse the existing profile if the input set matches with the
new rule. The fix is to disable this optimization for RSS since we
are not at the situation as profil
On Sat, 25 Jul 2020 10:35:48 +0200
Tom Barbette wrote:
> Nice patch!
>
> However I would use a multiply and shift approach instead of a division
> in the fast path. When we did that it was really hurting the performance.
See rte_reciprocal
> -Original Message-
> From: Burakov, Anatoly [mailto:anatoly.bura...@intel.com]
> Sent: Friday, July 24, 2020 9:25 PM
> To: wangyunjian ; dev@dpdk.org;
> david.march...@redhat.com
> Cc: Lilijun (Jerry) ; xudingke
> ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] eal/linux: do not cr
Nice patch!
However I would use a multiply and shift approach instead of a division
in the fast path. When we did that it was really hurting the performance.
Cheers,
Tom
Le 24/07/2020 à 22:23, Patrick Keroulas a écrit :
From: Vivien Didelot
When hardware timestamping is enabled on Rx path
For ovs offload scenario, when fw processes the virtio header,
there is no need to offset; and for standard card scenarios,
fw does not care about the vhd_type parameter, so in order to
be compatible with these two scenarios, use 0 offset instead.
Signed-off-by: Xiaoyun wang
---
drivers/net/hini
For x86 platform, the rq cqe without cache aligned, which can
improve performance for some gateway scenarios.
Fixes: 361a9ccf81d6 ("net/hinic: optimize Rx performance")
Cc: sta...@dpdk.org
Signed-off-by: Xiaoyun wang
---
drivers/net/hinic/hinic_pmd_rx.h | 4
1 file changed, 4 insertions(+)
Encapsulate different types of packet checksum preprocessing
into functions.
Signed-off-by: Xiaoyun wang
---
drivers/net/hinic/hinic_pmd_tx.c | 371 +--
1 file changed, 202 insertions(+), 169 deletions(-)
diff --git a/drivers/net/hinic/hinic_pmd_tx.c b/driver
Replace gettimeofday() with clock_gettime(CLOCK_MONOTONIC_RAW, &now),
the reason is same with this patch "make alarm not affected by
system time jump".
Fixes: 81d53291a466 ("net/hinic/base: add various headers")
Cc: sta...@dpdk.org
Signed-off-by: Xiaoyun wang
---
drivers/net/hinic/base/hinic_co
These patches modify csum offload process, optimize Rx
performance for x86, set vhd type with 2 for no offset
in ovs offload scenario, make timeout not affected by
system time jump.
--
v1->v2:
- fix typo spelling
v1:
- modify csum offload process
- optimize Rx performance for x86
- modi
13 matches
Mail list logo
