Get up to speed with the latest DPDK Newsletter ⚡

2023-11-07 Thread DPDK 
The latest developments, news, releases, events and highlights from the global 
DPDK community.

View in browser 
(https://email.linuxfoundation.org/e3t/Ctc/RI+113/cZw--04/VWBP8Z97SzMnW23V82h3Cy0kzW50jS-p55xNdSN2x86ys5m_5PW7lCGcx6lZ3mQW5NtFDQ12zWhSW4Yf_Pc10597pW4CJdFn8y2njPW1Lmwkl8Qg8cmW2QS34x7R8yFTVN9pT_1JVm4mW9gnMm63x9JhSV31bT-8yqlY3N1K0ZZCJcws0N1jG0zxSRYjHW61m2jK4r82ZFW5TKgM56KR8KmW47yNKz6BVwqNW7Vd4DV596jMQW1rkFRW4sxNNSW1h8Rkh5H9swDW4Tshl479ZX7jN8Z1vGl3vqtNW1kRmBT53slc8VrvjbM2vqD2CW57ZKpr6_lNJ0W8Z9PKl1r00rlW4CVM8w95LDz1VygJyy8--7D0VqQmh85TX10TW2CG8r-7SkW7NVPbl0b1213s5Vk_JS36rCML6W5ykrkG2dyB2BW5TL3-w574t4HW70Yf1j9jYTqtN8nNRF7Xg7f5W3QkvS71Z8yw9W22QJcp8hk8xgW2FpZXf2qClBGM-Tw0CNbTj0W2LYM046n5X7FN1crpdZ_dgXXW2XtYyj1qGtfrW6nV8_r1T8wdcf69bdvn04
 )

DPDK June Newsletter (600 × 200 px) 
(https://email.linuxfoundation.org/e3t/Ctc/RI+113/cZw--04/VWBP8Z97SzMnW23V82h3Cy0kzW50jS-p55xNdSN2x86y83prCCW6N1vHY6lZ3pzW5N6DxL2bNh9vV7Rt0M85w_07W3jc02x7FjXwNW673mwl8qW6_fW8TN_JY4sJHypW2Z0hgM7vd2q-W1PCYlt6y8sMdW3XP0K62_Gz78W5QYgNG61Zt42W6PGj5N2Vf3SLW13FGPJ6r7L83W3M7tzD3hvxdQN8zMgnvzWy7mW3SkM1T8_JMlDV7nlhg6tV14PW5TkQnY1T81xkW7dLTHJ1rpSldW8w9V2L6SXpRZW2qM50l4fYPzdW3JQ8k01ZRCGcW9b7lCm9lKSJ0W4sBq_91rvrM7f4NzVNz04
 )

Here’s five things this month we think you should know from the DPDK community.

1. Main Announcements

- New DPDK release candidate 
(https://email.linuxfoundation.org/e3t/Ctc/RI+113/cZw--04/VWBP8Z97SzMnW23V82h3Cy0kzW50jS-p55xNdSN2x86ys3prCCW7lCdLW6lZ3mKV65Ry32GS81NW5wq6-P8ZzlMNW6cKQ558tYRSDN4zrrrh4YkHpW7L3STJ2ltkDzW7B8M2k7kKFlCW2QwqrH762ZmWW4KQM_q4-X102W1knX-S7LVjCfW1w7HCP7Ljf_TW1wfyZ58vWVGnW7l_LY648PxB4W4LJ1F98dnyS7W7JQrP44_7C-RN8Xmr8s9MQ6xW620mL248L9J8W3KcY982wX_K-N650_GnNxsxBW6PJjlC6GbrwZW44cm5d8BmXCRW42Z7mq4K2jwTMtM6kvjXTMTN36GVK_zJ05GW1VtZ6960rDlpf4-Jyp604
 ) is ready for testing

2. Events

- Check out the 2023 DPDK Summit videos here 
(https://email.linuxfoundation.org/e3t/Ctc/RI+113/cZw--04/VWBP8Z97SzMnW23V82h3Cy0kzW50jS-p55xNdSN2x86zl3prCCW95jsWP6lZ3lZW8-xvXj1Y_9sDW1pCFt581_rG-W2lCqv81whTYxW5Mht0b2ftb-zW7Nmnzj4pjT6RW6HZByc50zr-cW1tBCMX3ybp6pW7ZBW4Q7qZ44mN1cv3fVqg8wFW4Fwzpc6Vh45kW2J5j825P-8VsVK-cWz9chcfBVNW3-V7RZXqWW7tR3gL8mvL4rW6CCxwj5tjRM_W4WH7qb7MWGmpW2NdTJd8r7cy8W2hPNrX4_LCmZW67fj241wft9mW8c9QXg7_0530W9lMRm41tg6qyW6dFWhy4PwwsLW7rCj3j1BvDq-W1XpCkr6dNW02W7Qy15j1KC4h9W4P0k1Q1xwYwXW5WWkd03PlQlgW3xHV8_2-vHGHW4fCnjt4nD-fVW4kW0jJ7zd315f4-8hM-04
 )

3. Blogs, User Stories and Developer Spotlights

- DPDK Summit 2023: A Technical Synthesis of Networking Evolution 
(https://email.linuxfoundation.org/e3t/Ctc/RI+113/cZw--04/VWBP8Z97SzMnW23V82h3Cy0kzW50jS-p55xNdSN2x86zl3prCCW95jsWP6lZ3ltW6S_0Xr5ctTdqW7fkkS_7Yw9MZN54Y5GfGrc2vT7PTd4zVnZhW38JRgV6WCfJTN82rWCYtGXl6W8Gn6s43JKsQzN73rgYsD3LzXW3vhSH02mN7DKW1-HlC82xtSD-W2WGvfd2MjgxCN5jzSJCPVPkyW3fhlK14TrJtVW6Ds1YD240VS3W3X1wft8Tv-H-W4sHWw43Dz43GW3CdK_s3Ks06-W7GpSyW8cn7TsW71C9sS3ZNtZtW4x6TnS733Z2GW8-dP1f45dLJ1W28mYcX8Jqp8sW7FK7l28XSC_1W7rkMj28Rw6FpW4YLcRl10mp3yW2DWLZt24Wy__My0sQ8FvNlwM3NWzMMlSD6W7zWTzV7Dbj4cW2VqK5K4bf9s1f1JJcpz04
 )

- Submit a blog here 
(https://email.linuxfoundation.org/e3t/Ctc/RI+113/cZw--04/VWBP8Z97SzMnW23V82h3Cy0kzW50jS-p55xNdSN2x86xg5fkwKW50kH_H6lZ3m4W33J17g4c6NpyW94vZnj2dkNGcV1BlnR3SCbNsW1Jnx8k1mtsf1W4F34wb6s9RDvW41KWy81-fXwBW8Vpz7N3Vxgt6W5rF_sW4SCdGKW3Gxbtk7GpXW9W2dzR221TgddkW8Znqjb485g8NW4W_8Qk757S_BW7v3vls4bLN7mW6H-kpW3wz8flN6NbG9MDTl85W92dNmH73fZgzW6LTV9q1bVLsYW2BqgdX5ZMSj1W2zy1QH8DCNBkW6xHmkD1PKFNrW3gTJrS5prbzHW9bWQ1L5pgpC0W35c6gz6hy9wTW5j1l0j1G09P1W9cbdYT4hcdmJW1TmsvF2MrQX6W4fKkLs7rYHplW2ZZwqk4BhztgN3Ty2n21HHLRW2gZBw79gYbWHW53WX2d4b5G8jW7P9MXl1ld7CBf7WvbDl04
 )

- Submit a developer spotlight here 
(https://email.linuxfoundation.org/e3t/Ctc/RI+113/cZw--04/VWBP8Z97SzMnW23V82h3Cy0kzW50jS-p55xNdSN2x86xg5fkwKW50kH_H6lZ3nZN1RWcCQcxL9YW61yRm-8qwx9mW4ZbwNf8SHlNtW2g9ClK3GZsh-W6mW0Sg8JKWGmW6fMtCm7HQkQqN3Bj5SDp6LrBW7hwGYF3mwTDnW4d0P3B7-XXDNW72KpxS2KNNwLW384J804cDGM5W53GYFp5m_wFdVP6Ysy1pGV48W63FWcj8ycLqzW5vKzbq80lR4tW3SkD4v4Wy9J0W22ZGsN6YNFwxW8kZPsF2VcYKMW6GMNb445_wKKW6TQcpC1Xkh1WN8RjnnZVrBDXW6fZlXZ1W0b0HW1d7-_-900bXZVPBNr33dNHpKW5tHRPl6_MWP4N7DhZMk6KtNwW28lmS_1T80B5W72zn738L8_vfW8T0K-723n8YyW5ghCf57mwpR6W7LJXJ05vFvdTW4j32v-4ZMqXbf8KjF8M04
 )

4. DPDK & Technologies in the news:

- Portwell Announces the Market’s First OCP NIC 3.0 “Bypass” Network Card APTNC 
Series 
(https://email.linuxfoundation.org/e3t/Ctc/RI+113/cZw--04/VWBP8Z97SzMnW23V82h3Cy0kzW50jS-p55xNdSN2x86y85m_5PW6N1X8z6lZ3mmW7zc6fk3gcnMlVVgwb-24-QfsW7t7_QP2LDhtgW4rm-fZ8vCGgNW4Ncvjp5kyffVVTnVd_3Hsd42W3V_zLy3R_KWkVHlkHp5fNJ2cW32Wyhb8FMsCgW6_nqLF1379rhMzFg1-6XLP-W2FBYjv5W31jwW48TDBX5mknvzW41-XN03wXWYHW3fFfnh2cLTxVN3Fl4QKqRjbcW6jSMQG46gPxrW2_2mlT7_dfXcW51LpGY75dFSlW1nvByG8CqrtVW5q_RF52qwm7lW5G5XGC5lXn6rW8X7wq957KB2wW7xrQz18f1097W1nz7y77-F-4yMkcwp25WFV5VsTPc54PFTZ_W6rvlhd2bMkCrW4Nshcv1hj9-6W7qrb2j508Kg_W496y9v7Znc5kW9hkzJS7RjG5tW2t1F-G86jn6ZVZ_JFp19p9xWW2vP9Pt3V2wHwW5dq8Sn2W1Rt8W4qXLYw2QpcR6W3QhX161d04R4f3dgXYC04
 )

- Data Plane Development Kit (DPDK) latency in Red Hat OpenShift - Part I 
(h

[dpdk-dev] zerocopy between userspace vhost virqueue and vmdq eth nic queu

2014-03-02 Thread dpdk

When tap PMD is used, memory loss occurs in secondary block

2021-12-16 Thread Learn DPDK 
Hello.
Thanks a lot in advance for your help and nice support.

We use tap PMD to send exception packet to kernel by DPDK primary block.
If the secondary block is driven in this state, vdev probe is
performed inside rte_eal_init
func
and memory is allocated using the rte_zmalloc_socket function if it is
a secondary block in the rte_pmd_tap_probe
(dpdk-20.11/drivers/net/tap/rte_eth_tap.c) function.
The secondary block mentioned is used to debug the primary
block and is terminated immediately after executing the command so
the memory allocated above is not free and is lost.
The secondary block does not access the tap interface,
is there any way to prevent memory allocation for tap vdev?
I am inquiring this because rte_eth_tap.c file copyrighted

Does DPDK provide RX timestamps?

2024-09-08 Thread Dpdk Newbie 
Hi. I am using Intel (i210) and AWS ENA network interface cards.

I would like to measure the following RX latencies:

1) NIC to DPDK packet ring buffer
2) DPDK packet ring buffer to application via rte_eth_rx_burst.

I don't mind measuring in nanoseconds or CPU cycles.

Unfortunately I cannot find any mention of hardware timestamps.

I found brief references to mbuf containing a timestamp in the dynamic
fields, but nothing definitive.

Could someone please clarify what the situation is?

Thanks,

Re: Does DPDK provide RX timestamps?

2024-09-09 Thread Dpdk Newbie 
I was looking at the source code but I'm more OOP C++ than C. I found
eth_ena_recv_pkts but is it possible for me to add a software
timestamp before the mbuf is added to the ring buffer? This would be
incredibly useful.

On Mon, 9 Sept 2024 at 09:31, Brandes, Shai  wrote:
>
>
> > מאת: Dpdk Newbie  > <mailto:dpdkuse...@gmail.com> >
> > תאריך: 9 בספט׳ 2024 01:32
> > נושא: [EXTERNAL] Does DPDK provide RX timestamps?
> > אל: dev@dpdk.org <mailto:dev@dpdk.org>
> > ‏עותק:
> >
> >
> >
> > Hi. I am using Intel (i210) and AWS ENA network interface cards.
> >
> >
> >
> > I would like to measure the following RX latencies:
> >
> > 1) NIC to DPDK packet ring buffer
> >
> > 2) DPDK packet ring buffer to application via rte_eth_rx_burst.
> >
> [Brandes, Shai] Hi, currently AWS doesn’t support HW timestamping.
> In order to get the full Rx latency you need to measure rte_eth_rx_burst as 
> it is mapped to ENA driver routine eth_ena_recv_pkts which covers the entire 
> flow including NIC to DPDK packet ring buffer flow (ena_com_rx_pkt)
>
> All the best
> Shai
>
> > I don't mind measuring in nanoseconds or CPU cycles.
> >
> >
> > Unfortunately I cannot find any mention of hardware timestamps.
> >
> >
> > I found brief references to mbuf containing a timestamp in the dynamic
> > fields, but nothing definitive.
> >
> > Could someone please clarify what the situation is?
> >
> > Thanks,
>

[PATCH] IGC: Remove I225_I_PHY_ID checking

2022-08-29 Thread iotg . dpdk . ref . app 
From: NSWE SWS DPDK Dev 

i225 devices have only one PHY vendor. There is unnecessary to check _I_PHY_ID 
during the link establishment
and auto-negotiation process, the checking also caused devices like i225-IT 
failed. This patch is to remove the
mentioned unnecessary checking.

Cc: sta...@dpdk.org
Signed-off-by: NSWE SWS DPDK Dev 
---
 drivers/net/igc/base/igc_api.c  |  1 +
 drivers/net/igc/base/igc_hw.h   |  1 +
 drivers/net/igc/base/igc_i225.c | 15 ++-
 drivers/net/igc/base/igc_phy.c  |  6 ++
 drivers/net/igc/igc_ethdev.c|  1 +
 5 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/net/igc/base/igc_api.c b/drivers/net/igc/base/igc_api.c
index 9b791dc082..c9fc9ed4b0 100644
--- a/drivers/net/igc/base/igc_api.c
+++ b/drivers/net/igc/base/igc_api.c
@@ -886,6 +886,7 @@ s32 igc_set_mac_type(struct igc_hw *hw)
case IGC_DEV_ID_I225_V:
case IGC_DEV_ID_I225_K:
case IGC_DEV_ID_I225_I:
+   case IGC_DEV_ID_I225_IT:
case IGC_DEV_ID_I220_V:
case IGC_DEV_ID_I225_BLANK_NVM:
case IGC_DEV_ID_I226_K:
diff --git a/drivers/net/igc/base/igc_hw.h b/drivers/net/igc/base/igc_hw.h
index 707a1883b4..e919a11c02 100644
--- a/drivers/net/igc/base/igc_hw.h
+++ b/drivers/net/igc/base/igc_hw.h
@@ -164,6 +164,7 @@ struct igc_hw;
 #define IGC_DEV_ID_I225_V  0x15F3
 #define IGC_DEV_ID_I225_K  0x3100
 #define IGC_DEV_ID_I225_I  0x15F8
+#define IGC_DEV_ID_I225_IT 0x0D9F
 #define IGC_DEV_ID_I220_V  0x15F7
 #define IGC_DEV_ID_I225_BLANK_NVM  0x15FD
 #define IGC_DEV_ID_I226_K   0x3102
diff --git a/drivers/net/igc/base/igc_i225.c b/drivers/net/igc/base/igc_i225.c
index 5f3d535490..bdc6f74976 100644
--- a/drivers/net/igc/base/igc_i225.c
+++ b/drivers/net/igc/base/igc_i225.c
@@ -173,19 +173,8 @@ static s32 igc_init_phy_params_i225(struct igc_hw *hw)
phy->ops.write_reg = igc_write_phy_reg_gpy;
 
ret_val = igc_get_phy_id(hw);
-   /* Verify phy id and set remaining function pointers */
-   switch (phy->id) {
-   case I225_I_PHY_ID:
-   case I226_LM_PHY_ID:
-   phy->type   = igc_phy_i225;
-   phy->ops.set_d0_lplu_state = igc_set_d0_lplu_state_i225;
-   phy->ops.set_d3_lplu_state = igc_set_d3_lplu_state_i225;
-   /* TODO - complete with GPY PHY information */
-   break;
-   default:
-   ret_val = -IGC_ERR_PHY;
-   goto out;
-   }
+
+   phy->type   = igc_phy_i225;
 
 out:
return ret_val;
diff --git a/drivers/net/igc/base/igc_phy.c b/drivers/net/igc/base/igc_phy.c
index 43bbe69bca..2906bae21a 100644
--- a/drivers/net/igc/base/igc_phy.c
+++ b/drivers/net/igc/base/igc_phy.c
@@ -1474,8 +1474,7 @@ s32 igc_phy_setup_autoneg(struct igc_hw *hw)
return ret_val;
}
 
-   if ((phy->autoneg_mask & ADVERTISE_2500_FULL) &&
-   hw->phy.id == I225_I_PHY_ID) {
+   if (phy->autoneg_mask & ADVERTISE_2500_FULL) {
/* Read the MULTI GBT AN Control Register - reg 7.32 */
ret_val = phy->ops.read_reg(hw, (STANDARD_AN_REG_MASK <<
MMD_DEVADDR_SHIFT) |
@@ -1615,8 +1614,7 @@ s32 igc_phy_setup_autoneg(struct igc_hw *hw)
ret_val = phy->ops.write_reg(hw, PHY_1000T_CTRL,
 mii_1000t_ctrl_reg);
 
-   if ((phy->autoneg_mask & ADVERTISE_2500_FULL) &&
-   hw->phy.id == I225_I_PHY_ID)
+   if (phy->autoneg_mask & ADVERTISE_2500_FULL)
ret_val = phy->ops.write_reg(hw,
 (STANDARD_AN_REG_MASK <<
 MMD_DEVADDR_SHIFT) |
diff --git a/drivers/net/igc/igc_ethdev.c b/drivers/net/igc/igc_ethdev.c
index 7f221a5d34..2989b8d488 100644
--- a/drivers/net/igc/igc_ethdev.c
+++ b/drivers/net/igc/igc_ethdev.c
@@ -97,6 +97,7 @@ static const struct rte_pci_id pci_id_igc_map[] = {
{ RTE_PCI_DEVICE(IGC_INTEL_VENDOR_ID, IGC_DEV_ID_I225_V)  },
{ RTE_PCI_DEVICE(IGC_INTEL_VENDOR_ID, IGC_DEV_ID_I225_I)  },
{ RTE_PCI_DEVICE(IGC_INTEL_VENDOR_ID, IGC_DEV_ID_I225_K)  },
+   { RTE_PCI_DEVICE(IGC_INTEL_VENDOR_ID, IGC_DEV_ID_I225_IT)  },
{ RTE_PCI_DEVICE(IGC_INTEL_VENDOR_ID, IGC_DEV_ID_I226_K)  },
{ RTE_PCI_DEVICE(IGC_INTEL_VENDOR_ID, IGC_DEV_ID_I226_LMVP)  },
{ RTE_PCI_DEVICE(IGC_INTEL_VENDOR_ID, IGC_DEV_ID_I226_LM)  },
-- 
2.36.1

[PATCH v2] IGC: Remove I225_I_PHY_ID checking

2022-09-01 Thread iotg . dpdk . ref . app 
From: NSWE SWS DPDK Dev 

i225 devices have only one PHY vendor. There is unnecessary to check
_I_PHY_ID during the link establishment and auto-negotiation process,
the checking also caused devices like i225-IT failed. This patch is to
remove the mentioned unnecessary checking.

Cc: sta...@dpdk.org
Signed-off-by: NSWE SWS DPDK Dev 
---
 drivers/net/igc/base/igc_i225.c | 15 ++-
 drivers/net/igc/base/igc_phy.c  |  6 ++
 2 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/net/igc/base/igc_i225.c b/drivers/net/igc/base/igc_i225.c
index 5f3d535490..af26602afb 100644
--- a/drivers/net/igc/base/igc_i225.c
+++ b/drivers/net/igc/base/igc_i225.c
@@ -173,19 +173,8 @@ static s32 igc_init_phy_params_i225(struct igc_hw *hw)
phy->ops.write_reg = igc_write_phy_reg_gpy;
 
ret_val = igc_get_phy_id(hw);
-   /* Verify phy id and set remaining function pointers */
-   switch (phy->id) {
-   case I225_I_PHY_ID:
-   case I226_LM_PHY_ID:
-   phy->type   = igc_phy_i225;
-   phy->ops.set_d0_lplu_state = igc_set_d0_lplu_state_i225;
-   phy->ops.set_d3_lplu_state = igc_set_d3_lplu_state_i225;
-   /* TODO - complete with GPY PHY information */
-   break;
-   default:
-   ret_val = -IGC_ERR_PHY;
-   goto out;
-   }
+phy->type = igc_phy_i225;
+
 
 out:
return ret_val;
diff --git a/drivers/net/igc/base/igc_phy.c b/drivers/net/igc/base/igc_phy.c
index 43bbe69bca..2906bae21a 100644
--- a/drivers/net/igc/base/igc_phy.c
+++ b/drivers/net/igc/base/igc_phy.c
@@ -1474,8 +1474,7 @@ s32 igc_phy_setup_autoneg(struct igc_hw *hw)
return ret_val;
}
 
-   if ((phy->autoneg_mask & ADVERTISE_2500_FULL) &&
-   hw->phy.id == I225_I_PHY_ID) {
+   if (phy->autoneg_mask & ADVERTISE_2500_FULL) {
/* Read the MULTI GBT AN Control Register - reg 7.32 */
ret_val = phy->ops.read_reg(hw, (STANDARD_AN_REG_MASK <<
MMD_DEVADDR_SHIFT) |
@@ -1615,8 +1614,7 @@ s32 igc_phy_setup_autoneg(struct igc_hw *hw)
ret_val = phy->ops.write_reg(hw, PHY_1000T_CTRL,
 mii_1000t_ctrl_reg);
 
-   if ((phy->autoneg_mask & ADVERTISE_2500_FULL) &&
-   hw->phy.id == I225_I_PHY_ID)
+   if (phy->autoneg_mask & ADVERTISE_2500_FULL)
ret_val = phy->ops.write_reg(hw,
 (STANDARD_AN_REG_MASK <<
 MMD_DEVADDR_SHIFT) |
-- 
2.36.1