[dpdk-dev] [PATCH v2]:rte_timer:timer lag issue correction
Thanks !! So as next steps I will push the patch .
-Original Message-
From: Sanford, Robert [mailto:rsanf...@akamai.com]
Sent: Tuesday, October 4, 2016 5:40 PM
To: Karmarkar Suyash ; dev at dpdk.org;
thomas.monjalon at 6wind.com; reshma.pattan at intel.com
Subject: Re: [PATCH v2]:rte_timer:timer lag issue correction
Yes, this change makes sense. I ran timer tests and they passed.
Acked-by: Robert Sanford
Thanks,
Robert
On 9/29/16, 10:27 AM, "Karmarkar Suyash" wrote:
Hello,
Can you please review the changes and suggest next steps? Thanks
Regards
Suyash Karmarkar
-Original Message-----
From: Karmarkar Suyash
Sent: Wednesday, September 21, 2016 4:54 PM
To: dev at dpdk.org; thomas.monjalon at 6wind.com; rsanford at akamai.com;
reshma.pattan at intel.com
Cc: Karmarkar Suyash
Subject: [PATCH v2]:rte_timer:timer lag issue correction
For Periodic timers ,if the lag gets introduced, the current code added
additional delay when the next peridoc timer was initialized by not taking into
account the delay added, with this fix the code would start the next occurrence
of timer keeping in account the lag added.Corrected the behavior.
Fixes: 9b15ba89 ("timer: use a skip list")
Karmarkar Suyash (1):
Signed-off-by: Karmarkar Suyash
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c index
43da836..18782fa 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -613,7 +613,7 @@ void rte_timer_manage(void)
status.owner = (int16_t)lcore_id;
rte_wmb();
tim->status.u32 = status.u32;
- __rte_timer_reset(tim, cur_time + tim->period,
+ __rte_timer_reset(tim, tim->expire + tim->period,
tim->period, lcore_id, tim->f, tim->arg, 1);
rte_spinlock_unlock(_timer[lcore_id].list_lock);
}
--
2.9.3.windows.1
[dpdk-dev] [PATCH v2]:rte_timer:timer lag issue correction
Hello Robert/Thomas,
Can you please review the changes in V2 of the Patch and suggest next steps?
Thanks
Regards
Suyash Karmarkar
-Original Message-
From: Karmarkar Suyash
Sent: Thursday, September 29, 2016 10:27 AM
To: dev at dpdk.org; thomas.monjalon at 6wind.com; rsanford at akamai.com;
reshma.pattan at intel.com
Subject: RE: [PATCH v2]:rte_timer:timer lag issue correction
Hello,
Can you please review the changes and suggest next steps? Thanks
Regards
Suyash Karmarkar
-Original Message-
From: Karmarkar Suyash
Sent: Wednesday, September 21, 2016 4:54 PM
To: dev at dpdk.org; thomas.monjalon at 6wind.com; rsanford at akamai.com;
reshma.pattan at intel.com
Cc: Karmarkar Suyash
Subject: [PATCH v2]:rte_timer:timer lag issue correction
For Periodic timers ,if the lag gets introduced, the current code added
additional delay when the next peridoc timer was initialized by not taking into
account the delay added, with this fix the code would start the next occurrence
of timer keeping in account the lag added.Corrected the behavior.
Fixes: 9b15ba89 ("timer: use a skip list")
Karmarkar Suyash (1):
Signed-off-by: Karmarkar Suyash
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c index
43da836..18782fa 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -613,7 +613,7 @@ void rte_timer_manage(void)
status.owner = (int16_t)lcore_id;
rte_wmb();
tim->status.u32 = status.u32;
- __rte_timer_reset(tim, cur_time + tim->period,
+ __rte_timer_reset(tim, tim->expire + tim->period,
tim->period, lcore_id, tim->f, tim->arg, 1);
rte_spinlock_unlock(_timer[lcore_id].list_lock);
}
--
2.9.3.windows.1
[dpdk-dev] [PATCH v1]:rte_timer:timer lag issue correction
Thanks Reshma for the comments, the issue is a day one bug. I will correct the
fixes line and submit v2 of the patch.
-Original Message-
From: Pattan, Reshma [mailto:reshma.pat...@intel.com]
Sent: Thursday, September 15, 2016 5:28 AM
To: Karmarkar Suyash
Cc: dev at dpdk.org; thomas.monjalon at 6wind.com; rsanford at akamai.com
Subject: RE: [PATCH v1]:rte_timer:timer lag issue correction
Hi,
>
> For Periodic timers ,if the lag gets introduced, the current code
> added additional delay when the next peridoc timer was initialized by
> not taking into account the delay added, with this fix the code would
> start the next occurrence of timer keeping in account the lag added.Corrected
> the behavior.
>
> Fixes:rte_timer: timer lag issue
Fixes line format is not corerct. Fixes line should contain commit hash that
introduced the bug and its subject line. For your case below should be added.
Fixes: 9b15ba89 ("timer: use a skip list")
Thanks,
Reshma
[dpdk-dev] [PATCH v2]:rte_timer:timer lag issue correction
For Periodic timers ,if the lag gets introduced, the current code
added additional delay when the next peridoc timer was initialized
by not taking into account the delay added, with this fix the code
would start the next occurrence of timer keeping in account the
lag added.Corrected the behavior.
Fixes:ba885531ac26 ("rte_timer: timer lag issue")
Karmarkar Suyash (1):
Signed-off-by: Karmarkar Suyash
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 43da836..18782fa 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -613,7 +613,7 @@ void rte_timer_manage(void)
status.owner = (int16_t)lcore_id;
rte_wmb();
tim->status.u32 = status.u32;
- __rte_timer_reset(tim, cur_time + tim->period,
+ __rte_timer_reset(tim, tim->expire + tim->period,
tim->period, lcore_id, tim->f, tim->arg, 1);
rte_spinlock_unlock(_timer[lcore_id].list_lock);
}
--
2.9.3.windows.1
[dpdk-dev] [PATCH v2]:rte_timer:timer lag issue correction
For Periodic timers ,if the lag gets introduced, the current code
added additional delay when the next peridoc timer was initialized
by not taking into account the delay added, with this fix the code
would start the next occurrence of timer keeping in account the
lag added.Corrected the behavior.
Fixes:ba885531ac26 ("rte_timer: timer lag issue")
Karmarkar Suyash (1):
Signed-off-by: Karmarkar Suyash
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 43da836..18782fa 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -613,7 +613,7 @@ void rte_timer_manage(void)
status.owner = (int16_t)lcore_id;
rte_wmb();
tim->status.u32 = status.u32;
- __rte_timer_reset(tim, cur_time + tim->period,
+ __rte_timer_reset(tim, tim->expire + tim->period,
tim->period, lcore_id, tim->f, tim->arg, 1);
rte_spinlock_unlock(_timer[lcore_id].list_lock);
}
--
2.9.3.windows.1
[dpdk-dev] [PATCH v1]:rte_timer:timer lag issue correction
Hello, Can you please review the change and let me know if any comments. I would like to push this patch to 16.11 release. Thanks. Please note this fix is tested as well. Regards Suyash Karmarkar _ From: Karmarkar Suyash Sent: Monday, August 29, 2016 6:28 PM To: dev at dpdk.org Subject: RE: [PATCH v1]:rte_timer:timer lag issue correction Hello All, Can you please review the change and let me know if any comments. I would like to push this patch to 16.07 release. Thanks Regards Suyash Karmarkar -Original Message- From: Karmarkar Suyash Sent: Friday, August 26, 2016 9:27 AM To: rsanford at akamai.com<mailto:rsanford at akamai.com> Cc: dev at dpdk.org<mailto:dev at dpdk.org>; Karmarkar Suyash mailto:skarmarkar at sonusnet.com>> Subject: [PATCH v1]:rte_timer:timer lag issue correction For Periodic timers ,if the lag gets introduced, the current code added additional delay when the next peridoc timer was initialized by not taking into account the delay added, with this fix the code would start the next occurrence of timer keeping in account the lag added.Corrected the behavior. Fixes:rte_timer: timer lag issue Karmarkar Suyash (1): Signed-off-by: Karmarkar Suyash mailto:skarmarkar at sonusnet.com>> lib/librte_timer/rte_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) From ba885531ac26af1aabc6bd0f58d7ce744b04acf7 Mon Sep 17 00:00:00 2001 From: Karmarkar Suyash mailto:skarmar...@sonusnet.com>> Date: Fri, 26 Aug 2016 09:20:37 -0400 Subject: [PATCH v1] Signed-off-by: Karmarkar Suyash mailto:skarmarkar at sonusnet.com>> --- lib/librte_timer/rte_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c index 43da836..18782fa 100644 --- a/lib/librte_timer/rte_timer.c +++ b/lib/librte_timer/rte_timer.c @@ -613,7 +613,7 @@ void rte_timer_manage(void) status.owner = (int16_t)lcore_id; rte_wmb(); tim->status.u32 = status.u32; - __rte_timer_reset(tim, cur_time + tim->period, + __rte_timer_reset(tim, tim->expire + tim->period, tim->period, lcore_id, tim->f, tim->arg, 1); rte_spinlock_unlock(_timer[lcore_id].list_lock); } -- 2.9.3.windows.1
[dpdk-dev] [PATCH v1]:rte_timer:timer lag issue correction
Hello All, Can you please review the change and let me know if any comments. I would like to push this patch to 16.07 release. Thanks Regards Suyash Karmarkar -Original Message- From: Karmarkar Suyash Sent: Friday, August 26, 2016 9:27 AM To: rsanford at akamai.com Cc: dev at dpdk.org; Karmarkar Suyash Subject: [PATCH v1]:rte_timer:timer lag issue correction For Periodic timers ,if the lag gets introduced, the current code added additional delay when the next peridoc timer was initialized by not taking into account the delay added, with this fix the code would start the next occurrence of timer keeping in account the lag added.Corrected the behavior. Fixes:rte_timer: timer lag issue Karmarkar Suyash (1): Signed-off-by: Karmarkar Suyash mailto:skarmarkar at sonusnet.com>> lib/librte_timer/rte_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) From ba885531ac26af1aabc6bd0f58d7ce744b04acf7 Mon Sep 17 00:00:00 2001 From: Karmarkar Suyash mailto:skarmar...@sonusnet.com>> Date: Fri, 26 Aug 2016 09:20:37 -0400 Subject: [PATCH v1] Signed-off-by: Karmarkar Suyash mailto:skarmarkar at sonusnet.com>> --- lib/librte_timer/rte_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c index 43da836..18782fa 100644 --- a/lib/librte_timer/rte_timer.c +++ b/lib/librte_timer/rte_timer.c @@ -613,7 +613,7 @@ void rte_timer_manage(void) status.owner = (int16_t)lcore_id; rte_wmb(); tim->status.u32 = status.u32; - __rte_timer_reset(tim, cur_time + tim->period, + __rte_timer_reset(tim, tim->expire + tim->period, tim->period, lcore_id, tim->f, tim->arg, 1); rte_spinlock_unlock(_timer[lcore_id].list_lock); } -- 2.9.3.windows.1
[dpdk-dev] [PATCH v1]:rte_timer:timer lag issue correction
For Periodic timers ,if the lag gets introduced, the current code added additional delay when the next peridoc timer was initialized by not taking into account the delay added, with this fix the code would start the next occurrence of timer keeping in account the lag added.Corrected the behavior. Fixes:rte_timer: timer lag issue Karmarkar Suyash (1): Signed-off-by: Karmarkar Suyash lib/librte_timer/rte_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) From ba885531ac26af1aabc6bd0f58d7ce744b04acf7 Mon Sep 17 00:00:00 2001 From: Karmarkar Suyash <skarmar...@sonusnet.com> Date: Fri, 26 Aug 2016 09:20:37 -0400 Subject: [PATCH v1] Signed-off-by: Karmarkar Suyash --- lib/librte_timer/rte_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c index 43da836..18782fa 100644 --- a/lib/librte_timer/rte_timer.c +++ b/lib/librte_timer/rte_timer.c @@ -613,7 +613,7 @@ void rte_timer_manage(void) status.owner = (int16_t)lcore_id; rte_wmb(); tim->status.u32 = status.u32; - __rte_timer_reset(tim, cur_time + tim->period, + __rte_timer_reset(tim, tim->expire + tim->period, tim->period, lcore_id, tim->f, tim->arg, 1); rte_spinlock_unlock(_timer[lcore_id].list_lock); } -- 2.9.3.windows.1
[dpdk-dev] [PATCH v1] rte_timer:timer lag issue correction
For Periodic timers ,if the lag gets introduced, the current code added
additional
delay when the next peridoc timer was initialized by not taking into account
the delay added, with this fix
the code would start the next occurrence of timer keeping in account the lag
added.Corrected the behavior.
Fixes:rte_timer: timer lag issue
---
lib/librte_timer/rte_timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c
index 43da836..18782fa 100644
--- a/lib/librte_timer/rte_timer.c
+++ b/lib/librte_timer/rte_timer.c
@@ -613,7 +613,7 @@ void rte_timer_manage(void)
status.owner = (int16_t)lcore_id;
rte_wmb();
tim->status.u32 = status.u32;
- __rte_timer_reset(tim, cur_time + tim->period,
+ __rte_timer_reset(tim, tim->expire + tim->period,
tim->period, lcore_id, tim->f, tim->arg, 1);
rte_spinlock_unlock(_timer[lcore_id].list_lock);
}
--
Karmarkar Suyash (1):
Signed-off-by: Karmarkar Suyash
--
2.9.3.windows.1
[dpdk-dev] [PATCH v1] Signed-off-by: Karmarkar Suyash <skarmar...@sonusnet.com> For Recurring/Periodic timers , if the lag gets introduced and it was keeping the lag consistently. Corrected the behavi
--- lib/librte_timer/rte_timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_timer/rte_timer.c b/lib/librte_timer/rte_timer.c index 43da836..18782fa 100644 --- a/lib/librte_timer/rte_timer.c +++ b/lib/librte_timer/rte_timer.c @@ -613,7 +613,7 @@ void rte_timer_manage(void) status.owner = (int16_t)lcore_id; rte_wmb(); tim->status.u32 = status.u32; - __rte_timer_reset(tim, cur_time + tim->period, + __rte_timer_reset(tim, tim->expire + tim->period, tim->period, lcore_id, tim->f, tim->arg, 1); rte_spinlock_unlock(_timer[lcore_id].list_lock); } -- 2.9.3.windows.1
[dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5
Thanks Rashmin for the response. The error code is -1 and the box I am doing my experiments is Cisco B200-M3 which would support CISCO VNIC 1240 or 1340 NIC. The NIC is in hypervisor but what puzzles me is if there is no dependency with ESX the NIC initialization should have passed in both ESX versions 5.5 and 6.0. Error is rte_eth_dev_start error = -1 Regards Suyash -Original Message- From: Patel, Rashmin N [mailto:rashmin.n.pa...@intel.com] Sent: Thursday, November 19, 2015 11:50 PM To: Karmarkar Suyash ; dev at dpdk.org Subject: RE: DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5 What is the error code it failed with? There is no dependency between ESXi and DPDK versions as such. But depending your VM settings, it may pop up some issues related to memory assigned to VM. When you use NIC in Hypervisor and feed packets to VM via Vmxnet3, the guest OS can use Vmxnet3-pmd and that's the sole requirement. Guest OS or DPDK API in VM are unaware and independent of the physical NIC beneath. When you use NIC in VM via Passthrough (or device direct assignment,) the guest OS can use ixgbe-pmd/igb-pmd/xyz-pmd to control them for Rx/Tx operations. ESXi can't look into such device operations like it can't see packets coming in or going out. When you enable SRIOV on a NIC, you get a PF and multiple VFs and if you use a NIC-Virtual Function via passthrough, the guest OS can use respective pmd (ixgbevf/igbvf/xyzvf) in DPDK API to control it for Rx/Tx ops. ESXi control the Physical Function through a respective driver (ixgbe/igb/xyz provided with ESXi) DPDK API doesn't have support to run in ESXi to control that PF. Thanks, Rashmin -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Karmarkar Suyash Sent: Wednesday, November 18, 2015 8:34 PM To: dev at dpdk.org Subject: [dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5 Hello All, I am trying some experiments with DPDK 1.6 and Cisco NIC - (:06:00.0 Network controller: Cisco Systems Inc. Cisco VIC Ethernet NIC [vmnic0]), on the guest I am using VMXNET3 as interface/pmd and one weird behavior that is see is with VMWare ESX 5.5 DPDK is not able to initialize the NIC and I get the error rte_eth_dev_start failed with error code as, but same NIC and with DPDK 1.6 version works fine with VMWare ESX 6.0 and with VMXNET3 PMD. Two questions: 1. Is there any dependency with VMWare version ESX (5.0/5.1/6.0) with DPDK Release version (1.6/1.7/2.x)? If yes can you please let me know? 2. If we are not using the NIC in pass-through mode and we are using it via Hypervisor - vmxnet3 or virtio pmd is there still a dependency for the list of NIC's supported by DPDK? Regards Suyash
[dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5
I was looking at older thread here it mentions the kernel vmxnet3 pmd dependency with Vmware tsc map, Is this the reason why the CISCO NIC is coming up fine on ESX 6.0 which will have higher version/updated driver and ESX 5.5 has older version of the driver and because of incompatability the NIC is not coming up and initialization fails? Thanks. http://dpdk.org/ml/archives/dev/2013-July/000302.html From: Karmarkar Suyash Sent: Thursday, November 19, 2015 9:03 AM To: 'dev at dpdk.org' Subject: DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5 Hello All, I am trying some experiments with DPDK 1.6 and Cisco NIC - (:06:00.0 Network controller: Cisco Systems Inc. Cisco VIC Ethernet NIC [vmnic0]), on the guest I am using VMXNET3 as interface/pmd and one weird behavior that is see is with VMWare ESX 5.5 DPDK is not able to initialize the NIC and I get the error rte_eth_dev_start failed with error code as, but same NIC and with DPDK 1.6 version works fine with VMWare ESX 6.0 and with VMXNET3 PMD. Two questions: 1. Is there any dependency with VMWare version ESX (5.0/5.1/6.0) with DPDK Release version (1.6/1.7/2.x)? If yes can you please let me know? 2. If we are not using the NIC in pass-through mode and we are using it via Hypervisor - vmxnet3 or virtio pmd is there still a dependency for the list of NIC's supported by DPDK? Regards Suyash
[dpdk-dev] DPDK 1.6 and Cisco VIC-NIC pmd fails to initialize with VMWare ESX 5.5
Hello All, I am trying some experiments with DPDK 1.6 and Cisco NIC - (:06:00.0 Network controller: Cisco Systems Inc. Cisco VIC Ethernet NIC [vmnic0]), on the guest I am using VMXNET3 as interface/pmd and one weird behavior that is see is with VMWare ESX 5.5 DPDK is not able to initialize the NIC and I get the error rte_eth_dev_start failed with error code as, but same NIC and with DPDK 1.6 version works fine with VMWare ESX 6.0 and with VMXNET3 PMD. Two questions: 1. Is there any dependency with VMWare version ESX (5.0/5.1/6.0) with DPDK Release version (1.6/1.7/2.x)? If yes can you please let me know? 2. If we are not using the NIC in pass-through mode and we are using it via Hypervisor - vmxnet3 or virtio pmd is there still a dependency for the list of NIC's supported by DPDK? Regards Suyash
[dpdk-dev] Running DPDK with Docker
<< igb_uio and rte_kni are unlikely to be accepted upstream since they have intrinsic security problems. Can you use VFIO?>> Hi Stephen, Thanks for the reply. Can you please elaborate on the security issue?Thanks. Regards Suyash -Original Message- From: Stephen Hemminger [mailto:step...@networkplumber.org] Sent: Thursday, April 02, 2015 12:12 AM To: Karmarkar Suyash Cc: dev at dpdk.org Subject: Re: [dpdk-dev] Running DPDK with Docker On Wed, 1 Apr 2015 17:56:56 +0000 Karmarkar Suyash wrote: > Hi, > > Given the popularity of Docker it would be nice if we can run DPDK inside a > Docker container but the challenge is the igb_uio.ko and rte_kni.ko kernel > modules which need to be compiled with the exact kernel source running on the > host. Are there ways to seamlessly run DPDK with Docker? I came across an > articles about running DPDK with Linux container but still the requirement is > to insert igb_uio. Any plans to make the igb_uio and rte_kni modules as > default modules of Linux source code or any other better > approaches/suggestions ? Thanks. > > http://dpdk.org/ml/archives/dev/2014-October/006373.html > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/6479 igb_uio and rte_kni are unlikely to be accepted upstream since they have intrinsic security problems. Can you use VFIO?
[dpdk-dev] Running DPDK with Docker
Hi, Given the popularity of Docker it would be nice if we can run DPDK inside a Docker container but the challenge is the igb_uio.ko and rte_kni.ko kernel modules which need to be compiled with the exact kernel source running on the host. Are there ways to seamlessly run DPDK with Docker? I came across an articles about running DPDK with Linux container but still the requirement is to insert igb_uio. Any plans to make the igb_uio and rte_kni modules as default modules of Linux source code or any other better approaches/suggestions ? Thanks. http://dpdk.org/ml/archives/dev/2014-October/006373.html http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/6479 Regards Suyash Karmarkar
[dpdk-dev] DDPK use of MAP_FIXED in mmap
Hello, In DPDK when we use mmap why are we passing the MAP_FIXED flag when Linux man page itself says that the option is discouraged? Any specific reason for passing the MAP_FIXED flag? http://linux.die.net/man/2/mmap MAP_FIXED Don't interpret addr as a hint: place the mapping at exactly that address. addr must be a multiple of the page size. If the memory region specified by addr and len overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap() will fail. Because requiring a fixed address for a mapping is less portable, the use of this option is discouraged. Regards Suyash Karmarkar
[dpdk-dev] Bug in IPACL library of DPDK-1.6.0
Hi Konstantin,
We did even tried with DPDK-1.7.0 version still we faced the same issue.
Regards
Suyash Karmarkar
-Original Message-
From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
Sent: Tuesday, October 14, 2014 8:15 PM
To: Karmarkar Suyash; dev at dpdk.org
Cc: Dey, Souvik; Patil, PraveenKumar
Subject: RE: Bug in IPACL library of DPDK-1.6.0
> From: Karmarkar Suyash [mailto:skarmarkar at sonusnet.com]
> Sent: Tuesday, October 14, 2014 1:36 PM
> To: Ananyev, Konstantin; dev at dpdk.org
> Cc: Dey, Souvik; Patil, PraveenKumar
> Subject: RE: Bug in IPACL library of DPDK-1.6.0
>
> There are two user defined ACL rules and they are added with just
> different priority -
>
> 1. And all other fields are wild card:
> * SOURCE IP and DEST IP = wild card (*)
> * LIF_GRP_INFO_FIELD_IPV6 = wild card (*)
> * PORTS = wild card (*)
> 2. Only next header protocol is specified = ICMPv6 (58) 3. Priority is
> different. But the one with lower priority is returned during lookup.
>
Hm, I tried what your described - works ok for me.
Are you saying you are still using DPDK 1.6 IPL?
If so, can you upgrade to 1.7 and give it another try?
There was one bug fixed in 1.7 very similar to what you describing:
http://dpdk.org/ml/archives/dev/2014-June/003198.html
Konstantin
> The structure is -
>
> enum
> {
>NEXT_HDR_FIELD_IPV4, //8
>IPSRC_FIELD_IPV4, //src ip (32)
>IPDST_FIELD_IPV4, //dst ip (32)
>PORTS_FIELD_IPV4, // src port (16) + dest port (16) => 32
>LIF_GRP_INFO_FIELD_IPV4, //lif group (16) + lif Id (16) => 32
>ADDR_CTX_FIELD_IPV4, //addr context (32)
>NUM_FIELDS_IPV4
> };
>
>
>
> struct rte_acl_field_def ipv6_defs[NUM_FIELDS_IPV6] = {
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint8_t),
> .field_index = NEXT_HDR_FIELD_IPV6,
> .input_index = NEXT_HDR_FIELD_IPV6,
> .offset = offsetof(struct ipv6_hdr, proto),
>},
>
> ///source ip
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPSRC_FIELD0_IPV6,
> .input_index = IPSRC_FIELD0_IPV6,
> .offset = offsetof(struct ipv6_hdr, src_addr),
>},
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPSRC_FIELD1_IPV6,
> .input_index = IPSRC_FIELD1_IPV6,
> .offset = offsetof(struct ipv6_hdr, src_addr) + 1*sizeof (uint32_t),
>},
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPSRC_FIELD2_IPV6,
> .input_index = IPSRC_FIELD2_IPV6,
> .offset = offsetof(struct ipv6_hdr, src_addr) + 2*sizeof (uint32_t),
>},
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPSRC_FIELD3_IPV6,
> .input_index = IPSRC_FIELD3_IPV6,
> .offset = offsetof(struct ipv6_hdr, src_addr) + 3*sizeof (uint32_t),
>},
>
> ///destination ip
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPDST_FIELD0_IPV6,
> .input_index = IPDST_FIELD0_IPV6,
> .offset = offsetof(struct ipv6_hdr, dst_addr),
>},
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPDST_FIELD1_IPV6,
> .input_index = IPDST_FIELD1_IPV6,
> .offset = offsetof(struct ipv6_hdr, dst_addr) + 1*sizeof (uint32_t),
>},
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPDST_FIELD2_IPV6,
> .input_index = IPDST_FIELD2_IPV6,
> .offset = offsetof(struct ipv6_hdr, dst_addr) + 2*sizeof (uint32_t),
>},
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = IPDST_FIELD3_IPV6,
> .input_index = IPDST_FIELD3_IPV6,
> .offset = offsetof(struct ipv6_hdr, dst_addr) + 3*sizeof (uint32_t),
>},
>
>///ports
> {
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = PORTS_FIELD_IPV6,
> .input_index = PORTS_FIELD_IPV6,
> .offset = sizeof(struct ipv6_hdr) ,
>},
> //LIF grp and addr ctx
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = LIF_GRP_INFO_FIELD_IPV6,
> .input_index = LIF_GRP_INFO_FIELD_IPV6,
> .offset = sizeof(struct ipv6_hdr) + sizeof (uint32_t),
>},
>{
> .type = RTE_ACL_FIELD_TYPE_BITMASK,
> .size = sizeof (uint32_t),
> .field_index = ADDR_CTX_FIELD_IPV
[dpdk-dev] Bug in IPACL library of DPDK-1.6.0
There are two user defined ACL rules and they are added with just different
priority -
1. And all other fields are wild card:
> SOURCE IP and DEST IP = wild card (*)
> LIF_GRP_INFO_FIELD_IPV6 = wild card (*)
> PORTS = wild card (*)
2. Only next header protocol is specified = ICMPv6 (58)
3. Priority is different. But the one with lower priority is returned
during lookup.
The structure is -
enum
{
NEXT_HDR_FIELD_IPV4, //8
IPSRC_FIELD_IPV4, //src ip (32)
IPDST_FIELD_IPV4, //dst ip (32)
PORTS_FIELD_IPV4, // src port (16) + dest port (16) => 32
LIF_GRP_INFO_FIELD_IPV4, //lif group (16) + lif Id (16) => 32
ADDR_CTX_FIELD_IPV4, //addr context (32)
NUM_FIELDS_IPV4
};
struct rte_acl_field_def ipv6_defs[NUM_FIELDS_IPV6] = {
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint8_t),
.field_index = NEXT_HDR_FIELD_IPV6,
.input_index = NEXT_HDR_FIELD_IPV6,
.offset = offsetof(struct ipv6_hdr, proto),
},
///source ip
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = IPSRC_FIELD0_IPV6,
.input_index = IPSRC_FIELD0_IPV6,
.offset = offsetof(struct ipv6_hdr, src_addr),
},
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = IPSRC_FIELD1_IPV6,
.input_index = IPSRC_FIELD1_IPV6,
.offset = offsetof(struct ipv6_hdr, src_addr) + 1*sizeof (uint32_t),
},
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = IPSRC_FIELD2_IPV6,
.input_index = IPSRC_FIELD2_IPV6,
.offset = offsetof(struct ipv6_hdr, src_addr) + 2*sizeof (uint32_t),
},
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = IPSRC_FIELD3_IPV6,
.input_index = IPSRC_FIELD3_IPV6,
.offset = offsetof(struct ipv6_hdr, src_addr) + 3*sizeof (uint32_t),
},
///destination ip
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = IPDST_FIELD0_IPV6,
.input_index = IPDST_FIELD0_IPV6,
.offset = offsetof(struct ipv6_hdr, dst_addr),
},
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = IPDST_FIELD1_IPV6,
.input_index = IPDST_FIELD1_IPV6,
.offset = offsetof(struct ipv6_hdr, dst_addr) + 1*sizeof (uint32_t),
},
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = IPDST_FIELD2_IPV6,
.input_index = IPDST_FIELD2_IPV6,
.offset = offsetof(struct ipv6_hdr, dst_addr) + 2*sizeof (uint32_t),
},
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = IPDST_FIELD3_IPV6,
.input_index = IPDST_FIELD3_IPV6,
.offset = offsetof(struct ipv6_hdr, dst_addr) + 3*sizeof (uint32_t),
},
///ports
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = PORTS_FIELD_IPV6,
.input_index = PORTS_FIELD_IPV6,
.offset = sizeof(struct ipv6_hdr) ,
},
//LIF grp and addr ctx
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = LIF_GRP_INFO_FIELD_IPV6,
.input_index = LIF_GRP_INFO_FIELD_IPV6,
.offset = sizeof(struct ipv6_hdr) + sizeof (uint32_t),
},
{
.type = RTE_ACL_FIELD_TYPE_BITMASK,
.size = sizeof (uint32_t),
.field_index = ADDR_CTX_FIELD_IPV6,
.input_index = ADDR_CTX_FIELD_IPV6,
.offset = sizeof(struct ipv6_hdr) + 2*sizeof (uint32_t),
}
} ;
-Original Message-
From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
Sent: Tuesday, October 14, 2014 4:16 PM
To: Karmarkar Suyash; dev at dpdk.org
Cc: Dey, Souvik; Patil, PraveenKumar
Subject: RE: Bug in IPACL library of DPDK-1.6.0
Hi,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Karmarkar Suyash
> Sent: Tuesday, October 14, 2014 10:55 AM
> To: dev at dpdk.org<mailto:dev at dpdk.org>
> Cc: Dey, Souvik; Patil, PraveenKumar
> Subject: [dpdk-dev] Bug in IPACL library of DPDK-1.6.0
>
> Hello All,
>
> If there are two identical IPv6 rules with source and destination IP
> addresses as wild card but with different priority, then during lookup
> always the rule that is added first in TRIE is returned even though the
> second rule that has highest priority.
>
Could you provide a bit more details how to reproduce the problem:
- either a rule and trace file to reproduce the problem in testacl
(classsbench) format -or some simple code snippet.
Thanks
Konstantin
> Regards
> Suyash Karmarkar
[dpdk-dev] Bug in IPACL library of DPDK-1.6.0
Hello All, If there are two identical IPv6 rules with source and destination IP addresses as wild card but with different priority, then during lookup always the rule that is added first in TRIE is returned even though the second rule that has highest priority. Regards Suyash Karmarkar
[dpdk-dev] Bug in outgoing packet with vmxnet3 with VLAN tagging
I meant in the below code snippet the function must be corrected to -
<<< file 1: /DPDK/DPDK-1.6.0/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c/1
>>> file 2: /DPDK/DPDK-1.6.0/lib/librte_pmd_vmxnet3/vmxnet3_rxtx.c
-[289 changed to 289-290]-
< if(txm->pkt.data_len >
(hw->cur_mtu + ETHER_HDR_LEN)) {
---
> //if(txm->pkt.data_len >
> (hw->cur_mtu + ETHER_HDR_LEN)) {
> if(txm->pkt.data_len >
> (hw->cur_mtu + ETHER_HDR_LEN + 4 /* 4 bytes for VLAN */)) {
From: Karmarkar Suyash
Sent: Friday, October 10, 2014 6:17 PM
To: 'dev at dpdk.org'
Subject: Bug in outgoing packet with vmxnet3 with VLAN tagging
Hello All,
When a outgoing packet is sent with data Len more than 1514 which will be a
case in VLAN (Max 1518 ) the packet is getting dropped because of the below
code snippet. This looks incorrect as in case of VLAN .
FUNCTION NAME: vmxnet3_xmit_pkts
/* Needs to minus ether header len */
if(txm->pkt.data_len >
(hw->cur_mtu + ETHER_HDR_LEN)) {
PMD_TX_LOG(DEBUG, "Packet data_len higher than MTU\n");
rte_pktmbuf_free(tx_pkts[nb_tx]);
txq->stats.drop_total++;
nb_tx++;
continue;
}
#define ETHER_ADDR_LEN 6 /**< Length of Ethernet address. */
#define ETHER_TYPE_LEN 2 /**< Length of Ethernet type field. */
#define ETHER_CRC_LEN 4 /**< Length of Ethernet CRC. */
#define ETHER_HDR_LEN \
(ETHER_ADDR_LEN * 2 + ETHER_TYPE_LEN) /**< Length of Ethernet
header. */
But in case of VLAN the Ethernet header is 18 bytes. Does this mean we do not
support VLAN for VMXNET3 PMD? Thanks.
Regards
Suyash Karmarkar
[dpdk-dev] Bug in outgoing packet with vmxnet3 with VLAN tagging
Hello All,
When a outgoing packet is sent with data Len more than 1514 which will be a
case in VLAN (Max 1518 ) the packet is getting dropped because of the below
code snippet. This looks incorrect as in case of VLAN .
FUNCTION NAME: vmxnet3_xmit_pkts
/* Needs to minus ether header len */
if(txm->pkt.data_len >
(hw->cur_mtu + ETHER_HDR_LEN)) {
PMD_TX_LOG(DEBUG, "Packet data_len higher than MTU\n");
rte_pktmbuf_free(tx_pkts[nb_tx]);
txq->stats.drop_total++;
nb_tx++;
continue;
}
#define ETHER_ADDR_LEN 6 /**< Length of Ethernet address. */
#define ETHER_TYPE_LEN 2 /**< Length of Ethernet type field. */
#define ETHER_CRC_LEN 4 /**< Length of Ethernet CRC. */
#define ETHER_HDR_LEN \
(ETHER_ADDR_LEN * 2 + ETHER_TYPE_LEN) /**< Length of Ethernet
header. */
But in case of VLAN the Ethernet header is 18 bytes. Does this mean we do not
support VLAN for VMXNET3 PMD? Thanks.
Regards
Suyash Karmarkar
