[dpdk-dev] ethtool not supported intel 82574 chip, has any plan?
Hi, ethtool not supported intel 82574 chip has any plan? Thanks. fandunqiu
[dpdk-dev] [PATCH v2] timer: add lfence before TSC read
According to Intel Developer's Manual:
"The RDTSC instruction is not a serializing instruction. It does not
necessarily wait
until all previous instructions have been executed before reading the counter.
Simi-
larly, subsequent instructions may begin execution before the read operation is
performed. If software requires RDTSC to be executed only after all previous
instruc-
tions have completed locally, it can either use RDTSCP (if the processor
supports that
instruction) or execute the sequence LFENCE;RDTSC."
So add a rte_rdtsc_precise function that do a lfence instruction before rdtsc to
synchronize read operations and ensure that the TSC read is done at the expected
place.
Signed-off-by: Didier Pallard
---
Introduce a rte_rdtsc_precise function that adds lfence before reading tsc
counter.
lib/librte_eal/common/include/rte_cycles.h | 37
1 file changed, 37 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_cycles.h
b/lib/librte_eal/common/include/rte_cycles.h
index cc6fe71..662f62d 100644
--- a/lib/librte_eal/common/include/rte_cycles.h
+++ b/lib/librte_eal/common/include/rte_cycles.h
@@ -128,6 +128,43 @@ rte_rdtsc(void)
}
/**
+ * Read the TSC register precisely where function is called.
+ *
+ * @return
+ * The TSC for this lcore.
+ */
+static inline uint64_t
+rte_rdtsc_precise(void)
+{
+ union {
+ uint64_t tsc_64;
+ struct {
+ uint32_t lo_32;
+ uint32_t hi_32;
+ };
+ } tsc;
+
+ /* serialize previous load instructions in pipe */
+ asm volatile("lfence");
+
+#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
+ if (unlikely(rte_cycles_vmware_tsc_map)) {
+ /* ecx = 0x1 corresponds to the physical TSC for VMware */
+ asm volatile("rdpmc" :
+"=a" (tsc.lo_32),
+"=d" (tsc.hi_32) :
+"c"(0x1));
+ return tsc.tsc_64;
+ }
+#endif
+
+ asm volatile("rdtsc" :
+"=a" (tsc.lo_32),
+"=d" (tsc.hi_32));
+ return tsc.tsc_64;
+}
+
+/**
* Get the measured frequency of the RDTSC counter
*
* @return
--
1.7.10.4
[dpdk-dev] [RFC PATCH 1/2] e1000: release software locked semaphores on initialization
It may happen that DPDK application gets killed while having
acquired locks on the ethernet hardware, causing these locks to
be never released. On next restart of the application, DPDK
skip those ports because it can not acquire the lock,
this may cause some ports (or even complete board if SMBI is locked)
to be inaccessible from DPDK application until reboot of the
hardware.
This patch release locks that are supposed to be locked due to
an improper exit of the application.
8254x series do not have SWFW sempahores.
82571 implementation already has some kind of lock reset at the end of
e1000_init_mac_params_82571 function. Since I have no mean to test this
implementation, code is not modified for this hardware.
Signed-off-by: Didier Pallard
---
lib/librte_pmd_e1000/e1000/e1000_80003es2lan.c | 29 +
lib/librte_pmd_e1000/e1000/e1000_82575.c | 33
lib/librte_pmd_e1000/e1000/e1000_i210.c|3 +--
lib/librte_pmd_e1000/e1000/e1000_i210.h|1 +
4 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/lib/librte_pmd_e1000/e1000/e1000_80003es2lan.c
b/lib/librte_pmd_e1000/e1000/e1000_80003es2lan.c
index 60d7c2a..952e8de 100644
--- a/lib/librte_pmd_e1000/e1000/e1000_80003es2lan.c
+++ b/lib/librte_pmd_e1000/e1000/e1000_80003es2lan.c
@@ -195,6 +195,7 @@ STATIC s32 e1000_init_nvm_params_80003es2lan(struct
e1000_hw *hw)
STATIC s32 e1000_init_mac_params_80003es2lan(struct e1000_hw *hw)
{
struct e1000_mac_info *mac = &hw->mac;
+ u16 mask;
DEBUGFUNC("e1000_init_mac_params_80003es2lan");
@@ -267,6 +268,34 @@ STATIC s32 e1000_init_mac_params_80003es2lan(struct
e1000_hw *hw)
/* set lan id for port to determine which phy lock to use */
hw->mac.ops.set_lan_id(hw);
+ /* Ensure that all locks are released before first NVM or PHY access */
+
+ /*
+* Phy lock should not fail in this early stage. If this is the case,
+* it is due to an improper exit of the application.
+* So force the release of the faulty lock.
+*/
+ if (e1000_acquire_phy_80003es2lan(hw) < 0) {
+ if (e1000_get_hw_semaphore_generic(hw) < 0) {
+ DEBUGOUT("SMBI lock released");
+ }
+ e1000_put_hw_semaphore_generic(hw);
+ DEBUGOUT1("SWFW phy%d lock released", hw->bus.func);
+ }
+ e1000_release_phy_80003es2lan(hw);
+
+ /*
+* Those one are more tricky since they are common to all ports; but
+* swfw_sync retries last long enough (250ms) to be almost sure that if
+* lock can not be taken it is due to an improper lock of the
+* semaphore.
+*/
+ mask = E1000_SWFW_EEP_SM | E1000_SWFW_CSR_SM;
+ if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
+ DEBUGOUT("SWFW common locks released");
+ }
+ hw->mac.ops.release_swfw_sync(hw, mask);
+
return E1000_SUCCESS;
}
diff --git a/lib/librte_pmd_e1000/e1000/e1000_82575.c
b/lib/librte_pmd_e1000/e1000/e1000_82575.c
index fd15b7b..99c4a1f 100644
--- a/lib/librte_pmd_e1000/e1000/e1000_82575.c
+++ b/lib/librte_pmd_e1000/e1000/e1000_82575.c
@@ -507,6 +507,39 @@ STATIC s32 e1000_init_mac_params_82575(struct e1000_hw *hw)
/* set lan id for port to determine which phy lock to use */
hw->mac.ops.set_lan_id(hw);
+ /* Ensure that all locks are released before first NVM or PHY access */
+
+ /*
+* Phy lock should not fail in this early stage. If this is the case,
+* it is due to an improper exit of the application.
+* So force the release of the faulty lock.
+*/
+ if (e1000_acquire_phy_82575(hw) < 0) {
+ if (mac->type >= e1000_i210) {
+ if (e1000_get_hw_semaphore_i210(hw) < 0) {
+ DEBUGOUT("SMBI lock released");
+ }
+ } else {
+ if (e1000_get_hw_semaphore_generic(hw) < 0) {
+ DEBUGOUT("SMBI lock released");
+ }
+ }
+ e1000_put_hw_semaphore_generic(hw);
+ DEBUGOUT1("SWFW phy%d lock released", hw->bus.func);
+ }
+ e1000_release_phy_82575(hw);
+
+ /*
+* This one is more tricky since it is common to all ports; but
+* swfw_sync retries last long enough (1s) to be almost sure that if
+* lock can not be taken it is due to an improper lock of the
+* semaphore.
+*/
+ if (hw->mac.ops.acquire_swfw_sync(hw, E1000_SWFW_EEP_SM) < 0) {
+ DEBUGOUT("SWFW common locks released");
+ }
+ hw->mac.ops.release_swfw_sync(hw, E1000_SWFW_EEP_SM);
+
return E1000_SUCCESS;
}
diff --git a/lib/librte_pmd_e1000/e1000/e1000_i210.c
b/lib/librte_pmd_e1000/e1000/e1000_i210.c
index 722877a..122fe70 100644
--- a/lib/librte_pmd_e1000/e1000/e1000_i210.
[dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked semaphores on initialization
It may happen that DPDK application gets killed while having
acquired locks on the ethernet hardware, causing these locks to
be never released. On next restart of the application, DPDK
skip those ports because it can not acquire the lock,
this may cause some ports (or even complete board if SMBI is locked)
to be inaccessible from DPDK application until reboot of the
hardware.
This patch release locks that are supposed to be locked due to
an improper exit of the application.
Signed-off-by: Didier Pallard
---
lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c | 30 +++
lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c | 29 ++
lib/librte_pmd_ixgbe/ixgbe/ixgbe_x540.c | 33 ++
3 files changed, 92 insertions(+)
diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c
b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c
index a9d1b9d..8e2ca1c 100644
--- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c
+++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c
@@ -115,6 +115,7 @@ s32 ixgbe_init_ops_82598(struct ixgbe_hw *hw)
struct ixgbe_mac_info *mac = &hw->mac;
struct ixgbe_phy_info *phy = &hw->phy;
s32 ret_val;
+ u16 mask;
DEBUGFUNC("ixgbe_init_ops_82598");
@@ -166,6 +167,35 @@ s32 ixgbe_init_ops_82598(struct ixgbe_hw *hw)
/* Manageability interface */
mac->ops.set_fw_drv_ver = NULL;
+ /* Get bus info */
+ mac->ops.get_bus_info(hw);
+
+ /* Ensure that all locks are released before first NVM or PHY access */
+
+ /*
+* Phy lock should not fail in this early stage. If this is the case,
+* it is due to an improper exit of the application.
+* So force the release of the faulty lock. Release of common lock
+* is done automatically by swfw_sync function.
+*/
+ mask = IXGBE_GSSR_PHY0_SM << hw->bus.func;
+ if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
+ DEBUGOUT1("SWFW phy%d lock released", hw->bus.func);
+ }
+ hw->mac.ops.release_swfw_sync(hw, mask);
+
+ /*
+* Those one are more tricky since they are common to all ports; but
+* swfw_sync retries last long enough (1s) to be almost sure that if
+* lock can not be taken it is due to an improper lock of the
+* semaphore.
+*/
+ mask = IXGBE_GSSR_EEP_SM | IXGBE_GSSR_MAC_CSR_SM | IXGBE_GSSR_SW_MNG_SM;
+ if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
+ DEBUGOUT("SWFW common locks released");
+ }
+ hw->mac.ops.release_swfw_sync(hw, mask);
+
return ret_val;
}
diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c
b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c
index db07789..ca91967 100644
--- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c
+++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c
@@ -223,6 +223,7 @@ s32 ixgbe_init_ops_82599(struct ixgbe_hw *hw)
struct ixgbe_phy_info *phy = &hw->phy;
struct ixgbe_eeprom_info *eeprom = &hw->eeprom;
s32 ret_val;
+ u16 mask;
DEBUGFUNC("ixgbe_init_ops_82599");
@@ -291,6 +292,34 @@ s32 ixgbe_init_ops_82599(struct ixgbe_hw *hw)
/* Manageability interface */
mac->ops.set_fw_drv_ver = &ixgbe_set_fw_drv_ver_generic;
+ /* Get bus info */
+ mac->ops.get_bus_info(hw);
+
+ /* Ensure that all locks are released before first NVM or PHY access */
+
+ /*
+* Phy lock should not fail in this early stage. If this is the case,
+* it is due to an improper exit of the application.
+* So force the release of the faulty lock. Release of common lock
+* is done automatically by swfw_sync function.
+*/
+ mask = IXGBE_GSSR_PHY0_SM << hw->bus.func;
+ if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
+ DEBUGOUT1("SWFW phy%d lock released", hw->bus.func);
+ }
+ hw->mac.ops.release_swfw_sync(hw, mask);
+
+ /*
+* Those one are more tricky since they are common to all ports; but
+* swfw_sync retries last long enough (1s) to be almost sure that if
+* lock can not be taken it is due to an improper lock of the
+* semaphore.
+*/
+ mask = IXGBE_GSSR_EEP_SM | IXGBE_GSSR_MAC_CSR_SM | IXGBE_GSSR_SW_MNG_SM;
+ if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
+ DEBUGOUT("SWFW common locks released");
+ }
+ hw->mac.ops.release_swfw_sync(hw, mask);
return ret_val;
}
diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_x540.c
b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_x540.c
index d3e1730..607c9c7 100644
--- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_x540.c
+++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_x540.c
@@ -55,6 +55,7 @@ s32 ixgbe_init_ops_X540(struct ixgbe_hw *hw)
struct ixgbe_phy_info *phy = &hw->phy;
struct ixgbe_eeprom_info *eeprom = &hw->eeprom;
s32 ret_val;
+ u16 mask;
DEBUGFUNC("ixgbe_init_ops_X540");
@@ -141,6 +142,38 @@ s32
[dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked semaphores on initialization
Hi,
Can the patch be reworked to keep changes under librte_pmd_ixgbe/ixgbe
directory untouched?
Those files are derived directly from the BSD driver baseline, and any changes
will make future merges of newer code more challenging.
The changes should be limited to files in the librte_pmd_ixgbe directory (and
ethdev).
Thanks
Konstantin
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Didier Pallard
Sent: Wednesday, February 19, 2014 11:59 AM
To: thomas.monjalon at 6wind.com
Subject: [dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked semaphores
on initialization
It may happen that DPDK application gets killed while having acquired locks on
the ethernet hardware, causing these locks to be never released. On next
restart of the application, DPDK skip those ports because it can not acquire
the lock, this may cause some ports (or even complete board if SMBI is locked)
to be inaccessible from DPDK application until reboot of the hardware.
This patch release locks that are supposed to be locked due to an improper exit
of the application.
Signed-off-by: Didier Pallard
---
lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c | 30 +++
lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c | 29 ++
lib/librte_pmd_ixgbe/ixgbe/ixgbe_x540.c | 33 ++
3 files changed, 92 insertions(+)
diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c
b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c
index a9d1b9d..8e2ca1c 100644
--- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c
+++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82598.c
@@ -115,6 +115,7 @@ s32 ixgbe_init_ops_82598(struct ixgbe_hw *hw)
struct ixgbe_mac_info *mac = &hw->mac;
struct ixgbe_phy_info *phy = &hw->phy;
s32 ret_val;
+ u16 mask;
DEBUGFUNC("ixgbe_init_ops_82598");
@@ -166,6 +167,35 @@ s32 ixgbe_init_ops_82598(struct ixgbe_hw *hw)
/* Manageability interface */
mac->ops.set_fw_drv_ver = NULL;
+ /* Get bus info */
+ mac->ops.get_bus_info(hw);
+
+ /* Ensure that all locks are released before first NVM or PHY access
+*/
+
+ /*
+* Phy lock should not fail in this early stage. If this is the case,
+* it is due to an improper exit of the application.
+* So force the release of the faulty lock. Release of common lock
+* is done automatically by swfw_sync function.
+*/
+ mask = IXGBE_GSSR_PHY0_SM << hw->bus.func;
+ if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
+ DEBUGOUT1("SWFW phy%d lock released", hw->bus.func);
+ }
+ hw->mac.ops.release_swfw_sync(hw, mask);
+
+ /*
+* Those one are more tricky since they are common to all ports; but
+* swfw_sync retries last long enough (1s) to be almost sure that if
+* lock can not be taken it is due to an improper lock of the
+* semaphore.
+*/
+ mask = IXGBE_GSSR_EEP_SM | IXGBE_GSSR_MAC_CSR_SM | IXGBE_GSSR_SW_MNG_SM;
+ if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
+ DEBUGOUT("SWFW common locks released");
+ }
+ hw->mac.ops.release_swfw_sync(hw, mask);
+
return ret_val;
}
diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c
b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c
index db07789..ca91967 100644
--- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c
+++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c
@@ -223,6 +223,7 @@ s32 ixgbe_init_ops_82599(struct ixgbe_hw *hw)
struct ixgbe_phy_info *phy = &hw->phy;
struct ixgbe_eeprom_info *eeprom = &hw->eeprom;
s32 ret_val;
+ u16 mask;
DEBUGFUNC("ixgbe_init_ops_82599");
@@ -291,6 +292,34 @@ s32 ixgbe_init_ops_82599(struct ixgbe_hw *hw)
/* Manageability interface */
mac->ops.set_fw_drv_ver = &ixgbe_set_fw_drv_ver_generic;
+ /* Get bus info */
+ mac->ops.get_bus_info(hw);
+
+ /* Ensure that all locks are released before first NVM or PHY access
+*/
+
+ /*
+* Phy lock should not fail in this early stage. If this is the case,
+* it is due to an improper exit of the application.
+* So force the release of the faulty lock. Release of common lock
+* is done automatically by swfw_sync function.
+*/
+ mask = IXGBE_GSSR_PHY0_SM << hw->bus.func;
+ if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
+ DEBUGOUT1("SWFW phy%d lock released", hw->bus.func);
+ }
+ hw->mac.ops.release_swfw_sync(hw, mask);
+
+ /*
+* Those one are more tricky since they are common to all ports; but
+* swfw_sync retries last long enough (1s) to be almost sure that if
+* lock can not be taken it is due to an improper lock of the
+* semaphore.
+*/
+ mask = IXGBE_GSSR_EEP_SM | IXGBE_GSSR_MAC_CSR_SM | IXGBE_GSSR_SW_MNG_SM;
+ if (hw->mac.ops.acquire_swfw_sync(hw, mask) < 0) {
+
[dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?)
This is my init function: pktmbuf_pool[socketid] = rte_mempool_create( name, APP_DEFAULT_MEMPOOL_BUFFERS, APP_DEFAULT_MBUF_SIZE, APP_DEFAULT_MEMPOOL_CACHE_SIZE, sizeof(struct rte_pktmbuf_pool_private), rte_pktmbuf_pool_init, NULL, rte_pktmbuf_init, NULL, socketid, 0); I copied it from a sample code. Anyway it seems to me that mbuf_free does not reset the *data pointer, actually I have partially resolved by prepending manually the data without moving the * data pointer at all albeit it's not a very clean solution. Could this be a bug in the DPDK mbuf_free() function? - Original Message - From: Benson, Bryan Sent: 02/18/14 06:16 PM To: Periklis Akritidis, Mario Gianni Subject: RE: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?) Whoa, be careful, we used a custom init function and had a nasty bug because we assumed it was called on mbuf_free as well. The rte_pktmbuf_init function pointer passed into mempool create is only used at pool initialization time, not when an mbuf is freed - A reference to the obj_initi function is not stored anywhere for future use during mbuf_free. Some of the fields are reset when the NIC has completed the send of the mbufs, but it does not use a custom function ptr. Thanks, Bryan Benson From: dev [dev-bounces at dpdk.org] on behalf of Periklis Akritidis [akritid at niometrics.com] Sent: Tuesday, February 18, 2014 6:19 AM To: Mario Gianni Cc: dev at dpdk.org Subject: Re: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?) Hi Mario, Are you passing rte_pktmbuf_init as the obj_init argument to rte_mempool_create? It is called when the mbuf if freed and it will reset the fields. I vaguely remember I had the same issue at some point and resolved it somehow. This comes to mind. Cheers, Periklis On 18 Feb, 2014, at 6:27 pm, Mario Gianni wrote: > Hi all, I'm experimenting some code with DPDK v1.5.0 and I have the following problem: > > I have a thread that receives packets from NIC, once I received a packet I want to prepend some data to it and I try to do so through the function rte_pktmbuf_prepend() > then the packet is enqueued in a ring buffer where it will be used by a client thread before being dropped through the function rte_pktmbuf_free() called by the client thread. > > Now, if I try to send packets to this program I have the following behaviour: > In a first time it seems to work correctly, then after a certain number of received packets (approximately the same number as the number of mbufs present in the mempool) if I call the rte_pktmbuf_headroom it returns that the headroom is shrinking more than the expected, until after a certain number of packets the headroom goes to zero. > > It seems like that when I call the rte_pktmbuf_free() function it doesn't reset the data position inside the mbuf, so when I call for a second time the mbuf the headroom continues to shrink until it finishes. > > > Do you have any idea of this strange behaviour?Could it be a bug in the prepend/free function? > > > Thank you, > > Mario
[dpdk-dev] [PATCH v3] timer: add new rte_rdtsc_precise function
According to Intel Developer's Manual:
"The RDTSC instruction is not a serializing instruction. It does not
necessarily wait
until all previous instructions have been executed before reading the counter.
Simi-
larly, subsequent instructions may begin execution before the read operation is
performed. If software requires RDTSC to be executed only after all previous
instruc-
tions have completed locally, it can either use RDTSCP (if the processor
supports that
instruction) or execute the sequence LFENCE;RDTSC."
So add a rte_rdtsc_precise function that do a memory barrier before rdtsc to
synchronize operations and ensure that the TSC read is done at the expected
place.
Signed-off-by: Didier Pallard
---
Call rte_mb() and rte_rdtsc() rather than duplicating rte_rdtsc function.
Use r/w memory barrier instead of lfence to serialize both load and stores.
lib/librte_eal/common/include/rte_cycles.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/lib/librte_eal/common/include/rte_cycles.h
b/lib/librte_eal/common/include/rte_cycles.h
index cc6fe71..e91edf8 100644
--- a/lib/librte_eal/common/include/rte_cycles.h
+++ b/lib/librte_eal/common/include/rte_cycles.h
@@ -76,6 +76,7 @@ extern "C" {
#include
#include
+#include
#ifdef RTE_LIBRTE_EAL_VMWARE_TSC_MAP_SUPPORT
/** Global switch to use VMWARE mapping of TSC instead of RDTSC */
@@ -128,6 +129,19 @@ rte_rdtsc(void)
}
/**
+ * Read the TSC register precisely where function is called.
+ *
+ * @return
+ * The TSC for this lcore.
+ */
+static inline uint64_t
+rte_rdtsc_precise(void)
+{
+ rte_mb();
+ return(rte_rdtsc());
+}
+
+/**
* Get the measured frequency of the RDTSC counter
*
* @return
--
1.7.10.4
[dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked semaphores on initialization
19/02/2014 13:41, Ananyev, Konstantin: > Can the patch be reworked to keep changes under librte_pmd_ixgbe/ixgbe > directory untouched? Those files are derived directly from the BSD driver > baseline, and any changes will make future merges of newer code more > challenging. The changes should be limited to files in the > librte_pmd_ixgbe directory (and ethdev). Thanks Please, could you send an url to the BSD driver baseline ? By the way, git is very good at rebasing such patches. And if the fix is good, it should be applied on the baseline. Refusing a fix without alternative is not an option. -- Thomas
[dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?)
Hi Mario, Yes rte_pktmbuf_free doesn't touch data/data_len fields. In fact for 'normal' mbuf it would only update refcnt. It is responsibility of alloc path to reset all mbuf fields to some initial values. Usually it is done by: rte_pktmbuf_alloc()->rte_pktmbuf_reset(). If the code path doesn't use rte_pktmbuf_alloc() to allocate mbufs, then it its own responsibility to reset mbuf fields properly. ixgbe and e1000 PMDs work that way - they use their own alloc routinies (for example to alloc a bulk of mbufs at once) and then reset mbuf fields manually. Thanks Konstantin -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Mario Gianni Sent: Wednesday, February 19, 2014 2:05 PM To: Benson, Bryan; Periklis Akritidis Cc: dev at dpdk.org Subject: Re: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?) This is my init function: pktmbuf_pool[socketid] = rte_mempool_create( name, APP_DEFAULT_MEMPOOL_BUFFERS, APP_DEFAULT_MBUF_SIZE, APP_DEFAULT_MEMPOOL_CACHE_SIZE, sizeof(struct rte_pktmbuf_pool_private), rte_pktmbuf_pool_init, NULL, rte_pktmbuf_init, NULL, socketid, 0); I copied it from a sample code. Anyway it seems to me that mbuf_free does not reset the *data pointer, actually I have partially resolved by prepending manually the data without moving the * data pointer at all albeit it's not a very clean solution. Could this be a bug in the DPDK mbuf_free() function? - Original Message - From: Benson, Bryan Sent: 02/18/14 06:16 PM To: Periklis Akritidis, Mario Gianni Subject: RE: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?) Whoa, be careful, we used a custom init function and had a nasty bug because we assumed it was called on mbuf_free as well. The rte_pktmbuf_init function pointer passed into mempool create is only used at pool initialization time, not when an mbuf is freed - A reference to the obj_initi function is not stored anywhere for future use during mbuf_free. Some of the fields are reset when the NIC has completed the send of the mbufs, but it does not use a custom function ptr. Thanks, Bryan Benson From: dev [dev-bounces at dpdk.org] on behalf of Periklis Akritidis [akritid at niometrics.com] Sent: Tuesday, February 18, 2014 6:19 AM To: Mario Gianni Cc: dev at dpdk.org Subject: Re: [dpdk-dev] problem with rte_pktmbuf_prepend (possible bug?) Hi Mario, Are you passing rte_pktmbuf_init as the obj_init argument to rte_mempool_create? It is called when the mbuf if freed and it will reset the fields. I vaguely remember I had the same issue at some point and resolved it somehow. This comes to mind. Cheers, Periklis On 18 Feb, 2014, at 6:27 pm, Mario Gianni wrote: > Hi all, I'm experimenting some code with DPDK v1.5.0 and I have the following problem: > > I have a thread that receives packets from NIC, once I received a packet I want to prepend some data to it and I try to do so through the function rte_pktmbuf_prepend() > then the packet is enqueued in a ring buffer where it will be used by a client thread before being dropped through the function rte_pktmbuf_free() called by the client thread. > > Now, if I try to send packets to this program I have the following behaviour: > In a first time it seems to work correctly, then after a certain number of received packets (approximately the same number as the number of mbufs present in the mempool) if I call the rte_pktmbuf_headroom it returns that the headroom is shrinking more than the expected, until after a certain number of packets the headroom goes to zero. > > It seems like that when I call the rte_pktmbuf_free() function it doesn't reset the data position inside the mbuf, so when I call for a second time the mbuf the headroom continues to shrink until it finishes. > > > Do you have any idea of this strange behaviour?Could it be a bug in the prepend/free function? > > > Thank you, > > Mario -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked semaphores on initialization
Hi Thomas, I am afraid I couldn't send you an url we are using. We take it from internal Intel ND repository. Though I think, that latest available to download from Intel ixgbe driver for FreeBSD should have pretty close codebase. As a rule of thumb in our internal policy: we take shared code from ND and treat it as read-only (the only exception: ixgbe/ixgbe_osdep.h). Otherwise it might become quite messy pretty quickly. To overcome some problems or shortcomings in ND code people usually use wrappers at the upper layer - that way was implemented bypass support, loopback support, plus some other fixes (reported number of queues per VF, etc). I wonder couldn't your fix also be pushed to the upper layer (in ixgbe_ethdev.c or something)? Thanks Konstantin -Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Wednesday, February 19, 2014 4:52 PM To: Ananyev, Konstantin Cc: Didier Pallard; dev at dpdk.org Subject: Re: [dpdk-dev] [RFC PATCH 2/2] ixgbe: release software locked semaphores on initialization 19/02/2014 13:41, Ananyev, Konstantin: > Can the patch be reworked to keep changes under librte_pmd_ixgbe/ixgbe > directory untouched? Those files are derived directly from the BSD > driver baseline, and any changes will make future merges of newer code > more challenging. The changes should be limited to files in the > librte_pmd_ixgbe directory (and ethdev). Thanks Please, could you send an url to the BSD driver baseline ? By the way, git is very good at rebasing such patches. And if the fix is good, it should be applied on the baseline. Refusing a fix without alternative is not an option. -- Thomas -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
