RE: [PATCH] net/ixgbe: Retry SFP ID read field to handle misbehaving SFPs
> -Original Message-
> From: je...@silicom-usa.com
> Sent: Tuesday, March 8, 2022 06:34
> To: dev@dpdk.org
> Cc: Stephen Douthit ; Daly, Jeff
> ; Wang, Haiyue
>
> Subject: [PATCH] net/ixgbe: Retry SFP ID read field to handle misbehaving SFPs
>
> From: Stephen Douthit
>
> Some XGS-PON SFPs have been observed ACKing I2C reads and returning
> uninitialized garbage while their uC boots. This can lead to the SFP ID
> code marking an otherwise working SFP module as unsupported if a bogus
> ID value is read while its internal PHY/microcontroller is still
> booting.
>
> Retry the ID read several times looking not just for NAK, but also for a
> valid ID field.
>
> Since the device isn't NAKing the trasanction the existing longer retry
> code in ixgbe_read_i2c_byte_generic_int() doesn't apply here.
>
> Signed-off-by: Stephen Douthit
> Signed-off-by: Jeff Daly
> ---
> drivers/net/ixgbe/base/ixgbe_phy.c | 31 ++
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ixgbe/base/ixgbe_phy.c
> b/drivers/net/ixgbe/base/ixgbe_phy.c
> index d8d51d2c3f..27bce066a1 100644
> --- a/drivers/net/ixgbe/base/ixgbe_phy.c
> +++ b/drivers/net/ixgbe/base/ixgbe_phy.c
> @@ -1275,6 +1275,7 @@ s32 ixgbe_identify_sfp_module_generic(struct ixgbe_hw
> *hw)
> + for (id_reads = 0; id_reads < 5; id_reads++) {
> + status = hw->phy.ops.read_i2c_eeprom(hw,
> + IXGBE_SFF_IDENTIFIER,
> + &identifier);
>
> - if (status != IXGBE_SUCCESS)
> + DEBUGOUT("status %d, id %d\n", status, identifier);
DEBUGOUT("status %d, SFF identifier 0x%x\n", status, identifier);
Since "#define IXGBE_SFF_IDENTIFIER_SFP 0x3" is hex value, and the ID is too
simple.
> + if (!status &&
> + identifier == IXGBE_SFF_IDENTIFIER_SFP)
> + break;
> + }
> +
> + if (status != IXGBE_SUCCESS) {
> + DEBUGOUT("Failed SFF ID read (%d attempts)\n", id_reads);
> goto err_read_i2c_eeprom;
> + }
This DEBUGOUT can be removed, it's redundant, every call for
hw->phy.ops.read_i2c_eeprom
has added the DEBUOUT.
>
> if (identifier != IXGBE_SFF_IDENTIFIER_SFP) {
> hw->phy.type = ixgbe_phy_sfp_unsupported;
> --
> 2.25.1
[PATCH 1/1] ethdev: add packet expiry event subtype
Patch adds a new event subtype for notifying expiry
event upon soft packet limit expiry.
Signed-off-by: Vamsi Attunuru
---
lib/ethdev/rte_ethdev.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/ethdev/rte_ethdev.h b/lib/ethdev/rte_ethdev.h
index 04cff8ee10..07d1f02bae 100644
--- a/lib/ethdev/rte_ethdev.h
+++ b/lib/ethdev/rte_ethdev.h
@@ -3828,6 +3828,8 @@ enum rte_eth_event_ipsec_subtype {
RTE_ETH_EVENT_IPSEC_SA_TIME_EXPIRY,
/** Soft byte expiry of SA */
RTE_ETH_EVENT_IPSEC_SA_BYTE_EXPIRY,
+ /** Soft packet expiry of SA */
+ RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY,
/** Max value of this enum */
RTE_ETH_EVENT_IPSEC_MAX
};
@@ -3849,6 +3851,7 @@ struct rte_eth_event_ipsec_desc {
* - @ref RTE_ETH_EVENT_IPSEC_ESN_OVERFLOW
* - @ref RTE_ETH_EVENT_IPSEC_SA_TIME_EXPIRY
* - @ref RTE_ETH_EVENT_IPSEC_SA_BYTE_EXPIRY
+* - @ref RTE_ETH_EVENT_IPSEC_SA_PKT_EXPIRY
*
* @see struct rte_security_session_conf
*
--
2.25.1
Re: [PATCH v1] doc: update release notes for 22.03
16/03/2022 18:33, John McNamara: > Fix grammar, spelling and formatting of DPDK 22.03 release notes. > > Signed-off-by: John McNamara > --- > > Note: I haven't removed the boilerplate RST comments from > this file/patch in order to make it easier to merge > apply. If you want me to do that I can submit a v2. Removed the comments while merging. Applied, thanks.
[PATCH 1/2] common/dpaax: remove dead code
This patch remove structural and logical dead code from
caamflib.
coverity issues: 375251 375258 375261 375267 375269 375285 373161
375249 375257
Fixes: 6127fff842a7 ("common/dpaax: remove outdated caamflib code")
Fixes: 81eb760d2207 ("common/dpaax/caamflib: remove some inline keys")
Cc: sta...@dpdk.org
Signed-off-by: Gagandeep Singh
---
drivers/common/dpaax/caamflib/desc/pdcp.h | 196 +-
drivers/common/dpaax/caamflib/desc/sdap.h | 44 +
2 files changed, 45 insertions(+), 195 deletions(-)
diff --git a/drivers/common/dpaax/caamflib/desc/pdcp.h
b/drivers/common/dpaax/caamflib/desc/pdcp.h
index 2fe56c53c6..46153b9c29 100644
--- a/drivers/common/dpaax/caamflib/desc/pdcp.h
+++ b/drivers/common/dpaax/caamflib/desc/pdcp.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause or GPL-2.0+
* Copyright 2008-2013 Freescale Semiconductor, Inc.
- * Copyright 2019-2021 NXP
+ * Copyright 2019-2022 NXP
*/
#ifndef __DESC_PDCP_H__
@@ -776,21 +776,11 @@ pdcp_insert_uplane_snow_snow_op(struct program *p,
return 0;
}
- /* Non-proto is supported only for 5bit cplane and 18bit uplane */
- switch (sn_size) {
- case PDCP_SN_SIZE_18:
- offset = 5;
- length = 3;
- sn_mask = (swap == false) ? PDCP_U_PLANE_18BIT_SN_MASK :
- PDCP_U_PLANE_18BIT_SN_MASK_BE;
- break;
- case PDCP_SN_SIZE_5:
- case PDCP_SN_SIZE_7:
- case PDCP_SN_SIZE_12:
- case PDCP_SN_SIZE_15:
- pr_err("Invalid sn_size for %s\n", __func__);
- return -ENOTSUP;
- }
+ /* sn_size is 18 */
+ offset = 5;
+ length = 3;
+ sn_mask = (swap == false) ? PDCP_U_PLANE_18BIT_SN_MASK :
+ PDCP_U_PLANE_18BIT_SN_MASK_BE;
if (dir == OP_TYPE_ENCAP_PROTOCOL)
MATHB(p, SEQINSZ, SUB, length, VSEQINSZ, 4, IMMED2);
@@ -901,21 +891,11 @@ pdcp_insert_uplane_zuc_zuc_op(struct program *p,
return 0;
}
- /* Non-proto is supported only for 5bit cplane and 18bit uplane */
- switch (sn_size) {
- case PDCP_SN_SIZE_18:
- offset = 5;
- length = 3;
- sn_mask = (swap == false) ? PDCP_U_PLANE_18BIT_SN_MASK :
- PDCP_U_PLANE_18BIT_SN_MASK_BE;
- break;
- case PDCP_SN_SIZE_5:
- case PDCP_SN_SIZE_7:
- case PDCP_SN_SIZE_12:
- case PDCP_SN_SIZE_15:
- pr_err("Invalid sn_size for %s\n", __func__);
- return -ENOTSUP;
- }
+ /* sn_size is 18 */
+ offset = 5;
+ length = 3;
+ sn_mask = (swap == false) ? PDCP_U_PLANE_18BIT_SN_MASK :
+ PDCP_U_PLANE_18BIT_SN_MASK_BE;
SEQLOAD(p, MATH0, offset, length, 0);
JUMP(p, 1, LOCAL_JUMP, ALL_TRUE, CALM);
@@ -1190,27 +1170,11 @@ pdcp_insert_cplane_snow_aes_op(struct program *p,
return 0;
}
- /* Non-proto is supported only for 5bit cplane and 18bit uplane */
- switch (sn_size) {
- case PDCP_SN_SIZE_5:
- offset = 7;
- length = 1;
- sn_mask = (swap == false) ? PDCP_C_PLANE_SN_MASK :
- PDCP_C_PLANE_SN_MASK_BE;
- break;
- case PDCP_SN_SIZE_18:
- offset = 5;
- length = 3;
- sn_mask = (swap == false) ? PDCP_U_PLANE_18BIT_SN_MASK :
- PDCP_U_PLANE_18BIT_SN_MASK_BE;
- break;
- case PDCP_SN_SIZE_7:
- case PDCP_SN_SIZE_12:
- case PDCP_SN_SIZE_15:
- pr_err("Invalid sn_size for %s\n", __func__);
- return -ENOTSUP;
-
- }
+ /* sn_size is 18 */
+ offset = 5;
+ length = 3;
+ sn_mask = (swap == false) ? PDCP_U_PLANE_18BIT_SN_MASK :
+ PDCP_U_PLANE_18BIT_SN_MASK_BE;
SEQLOAD(p, MATH0, offset, length, 0);
JUMP(p, 1, LOCAL_JUMP, ALL_TRUE, CALM);
@@ -1421,27 +1385,11 @@ pdcp_insert_cplane_aes_snow_op(struct program *p,
return 0;
}
- /* Non-proto is supported only for 5bit cplane and 18bit uplane */
- switch (sn_size) {
- case PDCP_SN_SIZE_5:
- offset = 7;
- length = 1;
- sn_mask = (swap == false) ? PDCP_C_PLANE_SN_MASK :
- PDCP_C_PLANE_SN_MASK_BE;
- break;
- case PDCP_SN_SIZE_18:
- offset = 5;
- length = 3;
- sn_mask = (swap == false) ? PDCP_U_PLANE_18BIT_SN_MASK :
- PDCP_U_PLANE_18BIT_SN_MASK_BE;
- break;
- case PDCP_SN_SIZE_7:
- case PDCP_SN_SIZE_12:
- case PDCP_SN_SIZE_15:
- pr_err("Invalid sn_size for
[PATCH 2/2] crypto/dpaa_sec: fix digest size
DPAA crypto driver can support 64 bytes size digest size
for SHA512-HMAC.
This patch changes the value of macro max supported digest size to
64.
Fixes: c3e85bdcc6e6 ("crypto/dpaa_sec: add crypto driver for NXP DPAA platform")
Cc: sta...@dpdk.org
Signed-off-by: Gagandeep Singh
---
drivers/crypto/dpaa_sec/dpaa_sec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/dpaa_sec/dpaa_sec.h
b/drivers/crypto/dpaa_sec/dpaa_sec.h
index 7890687828..b3f2258ead 100644
--- a/drivers/crypto/dpaa_sec/dpaa_sec.h
+++ b/drivers/crypto/dpaa_sec/dpaa_sec.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: BSD-3-Clause
*
- * Copyright 2016-2021 NXP
+ * Copyright 2016-2022 NXP
*
*/
@@ -231,7 +231,7 @@ struct dpaa_sec_job {
struct qm_sg_entry sg[MAX_JOB_SG_ENTRIES];
};
-#define DPAA_MAX_NB_MAX_DIGEST 32
+#define DPAA_MAX_NB_MAX_DIGEST 64
struct dpaa_sec_op_ctx {
struct dpaa_sec_job job;
union {
--
2.25.1
DPDK 22.03 released
A new release is available: https://fast.dpdk.org/rel/dpdk-22.03.tar.xz Winter release numbers are quite small as usual: 956 commits from 181 authors 2289 files changed, 83849 insertions(+), 97801 deletions(-) It is not planned to start a maintenance branch for 22.03. This version is ABI-compatible with 21.11. Below are some new features: - fast restart by reusing hugepages - UDP/TCP checksum on multi-segments - IP reassembly offload - queue-based priority flow control - flow API for templates and async operations - private ethdev driver info dump - private user data in asymmetric crypto session More details in the release notes: https://doc.dpdk.org/guides/rel_notes/release_22_03.html There are 51 new contributors (including authors, reviewers and testers). Welcome to Abhimanyu Saini, Adham Masarwah, Asaf Ravid, Bin Zheng, Brian Dooley, Brick Yang, Bruce Merry, Christophe Fontaine, Chuanshe Zhang, Dawid Gorecki, Daxue Gao, Geoffrey Le Gourriérec, Gerry Gribbon, Harold Huang, Harshad Narayane, Igor Chauskin, Jakub Poczatek, Jeff Daly, Jie Hai, Josh Soref, Kamalakannan R, Karl Bonde Torp, Kevin Liu, Kumara Parameshwaran, Madhuker Mythri, Markus Theil, Martijn Bakker, Maxime Gouin, Megha Ajmera, Michael Barker, Michal Wilczynski, Nan Zhou, Nobuhiro Miki, Padraig Connolly, Peng Yu, Peng Zhang, Qiao Liu, Rahul Bhansali, Stephen Douthit, Tianli Lai, Tudor Brindus, Usama Arif, Wang Yunjian, Weiguo Li, Wenxiang Qian, Wenxuan Wu, Yajun Wu, Yiding Zhou, Yingya Han, Yu Wenjun and Yuan Wang. Below is the number of commits per employer (with authors count): 242 Intel (53) 209 Marvell (26) 184 NVIDIA (27) 61 Huawei (7) 29 Microsoft (2) 27 Broadcom (5) 26 Red Hat (4) 24 NXP (8) 23 Semihalf (4) 21 Weiguo Li (1) 16 OKTET Labs (1) 12 Trustnet (1) 10 Arm (5) A big thank to all courageous people who took on the non rewarding task of reviewing other's job. Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are: 41 Akhil Goyal 29 Bruce Richardson 26 Ferruh Yigit 20 Ori Kam 19 David Marchand 16 Tyler Retzlaff 15 Viacheslav Ovsiienko 15 Morten Brørup 15 Chenbo Xia 14 Stephen Hemminger 14 Jerin Jacob 12 Dmitry Kozlyuk 11 Ruifeng Wang 11 Maxime Coquelin Next version will be 22.07 in July. The new features for 22.07 can be submitted during the next 3 weeks: http://core.dpdk.org/roadmap#dates Please share your roadmap. Thanks everyone
Re: [dpdk-dev] [PATCH 2/3] net/bnxt: fix ver get HWRM command
Kalesh, Ajit,
On Tue, Mar 1, 2022 at 1:53 PM David Marchand wrote:
> On Thu, Mar 4, 2021 at 9:45 AM Kalesh A P
> wrote:
> >
> > From: Kalesh AP
> >
> > Fix HWRM_VER_GET command to handle DEV_NOT_RDY state.
> >
> > Driver should fail probe if the device is not ready.
> > Conversely, the HWRM_VER_GET poll after reset can safely
> > retry until the existing timeout is exceeded.
> >
> > Fixes: 804e746c7b73 ("net/bnxt: add hardware resource manager init code")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Kalesh AP
> > Reviewed-by: Somnath Kotur
> > Reviewed-by: Randy Schacher
> > Reviewed-by: Ajit Kumar Khaparde
>
> This patch makes probing fail on a RHEL9 kernel with firmwares:
> firmware-version: 20.6.143.0/pkg 20.06.04.06
> and
> firmware-version: 20.6.112.0
>
> Simply reverting the patch fixes probing in my env.
>
> This was reported by our QE team which is doing sanity checks on ovs
> 2.17 which uses dpdk v21.11.
> https://bugzilla.redhat.com/show_bug.cgi?id=2055531
QE confirmed reverting this patch fixed initialisation in their setup.
I reproduced the issue on another system with RHEL 8.5, and confirmed
that reverting the patch or upgrading the firmware fix the issue.
I can understand new features in a PMD might require newer firmwares.
But breaking compatibility with older firmwares is a big no.
If there is no other option, I will send a revert for this patch.
Thanks.
--
David Marchand
[PATCH] net/nfp: add the restrict of setting the mtu
1.When the setting mtu is higher than flbufsz, the mtu doesn't work.
But it doesn't have any notice about this restrict.
2.when the setting mtu isn't in the range, it doesn't have any notice.
This patch will add the notice about these restrict.
Signed-off-by: Peng Zhang
Signed-off-by: Chaoyong He
Signed-off-by: Louis Peens
---
drivers/net/nfp/nfp_common.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/nfp/nfp_common.c b/drivers/net/nfp/nfp_common.c
index f8978e803a..2ea9853548 100644
--- a/drivers/net/nfp/nfp_common.c
+++ b/drivers/net/nfp/nfp_common.c
@@ -956,6 +956,20 @@ nfp_net_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
return -EBUSY;
}
+ /* the setting mtu is in the range */
+ if (mtu < 68 || mtu > hw->max_mtu) {
+ PMD_DRV_LOG(ERR, "the setting mtu cannot be less than 68 or
more than %d",
+ hw->max_mtu);
+ return -ERANGE;
+ }
+
+ /* the setting mtu is lower than flbufsz */
+ if (mtu > hw->flbufsz) {
+ PMD_DRV_LOG(ERR, "the setting mtu must be lower than current
mbufsize of %d",
+ hw->flbufsz);
+ return -ERANGE;
+ }
+
/* writing to configuration space */
nn_cfg_writel(hw, NFP_NET_CFG_MTU, mtu);
--
2.27.0
Re: [dpdk-dev] [PATCH 2/3] net/bnxt: fix ver get HWRM command
On Thu, Mar 17, 2022 at 3:11 AM David Marchand
wrote:
>
> Kalesh, Ajit,
>
> On Tue, Mar 1, 2022 at 1:53 PM David Marchand
> wrote:
> > On Thu, Mar 4, 2021 at 9:45 AM Kalesh A P
> > wrote:
> > >
> > > From: Kalesh AP
> > >
> > > Fix HWRM_VER_GET command to handle DEV_NOT_RDY state.
> > >
> > > Driver should fail probe if the device is not ready.
> > > Conversely, the HWRM_VER_GET poll after reset can safely
> > > retry until the existing timeout is exceeded.
> > >
> > > Fixes: 804e746c7b73 ("net/bnxt: add hardware resource manager init code")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Kalesh AP
> > > Reviewed-by: Somnath Kotur
> > > Reviewed-by: Randy Schacher
> > > Reviewed-by: Ajit Kumar Khaparde
> >
> > This patch makes probing fail on a RHEL9 kernel with firmwares:
> > firmware-version: 20.6.143.0/pkg 20.06.04.06
> > and
> > firmware-version: 20.6.112.0
Oh wow! That's really old FW.
> >
> > Simply reverting the patch fixes probing in my env.
> >
> > This was reported by our QE team which is doing sanity checks on ovs
> > 2.17 which uses dpdk v21.11.
> > https://bugzilla.redhat.com/show_bug.cgi?id=2055531
>
> QE confirmed reverting this patch fixed initialisation in their setup.
> I reproduced the issue on another system with RHEL 8.5, and confirmed
> that reverting the patch or upgrading the firmware fix the issue.
>
> I can understand new features in a PMD might require newer firmwares.
> But breaking compatibility with older firmwares is a big no.
I agree.
Ideally this should not have been sent as a fix targeting the super-old commit
804e746c7b73.
>
> If there is no other option, I will send a revert for this patch.
A version check may help avoid a complete revert.
But that will require some testing, which means we are looking at
mid-next week for the fix.
Submit the revert patch, just in case it takes longer than that.
Thanks
Ajit
>
>
> Thanks.
>
> --
> David Marchand
>
smime.p7s
Description: S/MIME Cryptographic Signature
[PATCH] net/pcap: support MTU set
Support rte_eth_dev_set_mtu by pcap vdevs
Enforce mtu on rx/tx
For more details see https://bugs.dpdk.org/show_bug.cgi?id=961
Signed-off-by: ido g
---
drivers/net/pcap/pcap_ethdev.c | 34 +++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pcap/pcap_ethdev.c b/drivers/net/pcap/pcap_ethdev.c
index ec29fd6bc5..476d03c6b1 100644
--- a/drivers/net/pcap/pcap_ethdev.c
+++ b/drivers/net/pcap/pcap_ethdev.c
@@ -278,11 +278,12 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t
nb_pkts)
const u_char *packet;
struct rte_mbuf *mbuf;
struct pcap_rx_queue *pcap_q = queue;
+ struct rte_eth_dev *dev = &rte_eth_devices[pcap_q->port_id];
uint16_t num_rx = 0;
uint32_t rx_bytes = 0;
pcap_t *pcap;
- pp = rte_eth_devices[pcap_q->port_id].process_private;
+ pp = dev->process_private;
pcap = pp->rx_pcap[pcap_q->queue_id];
if (unlikely(pcap == NULL || nb_pkts == 0))
@@ -303,6 +304,12 @@ eth_pcap_rx(void *queue, struct rte_mbuf **bufs, uint16_t
nb_pkts)
break;
}
+ if (unlikely(header.caplen > dev->data->mtu)) {
+ pcap_q->rx_stat.err_pkts++;
+ rte_pktmbuf_free(mbuf);
+ break;
+ }
+
if (header.caplen <= rte_pktmbuf_tailroom(mbuf)) {
/* pcap packet will fit in the mbuf, can copy it */
rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
@@ -378,6 +385,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *dumper_q = queue;
+ struct rte_eth_dev *dev = &rte_eth_devices[dumper_q->port_id];
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
struct pcap_pkthdr header;
@@ -385,7 +393,7 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
size_t len, caplen;
- pp = rte_eth_devices[dumper_q->port_id].process_private;
+ pp = dev->process_private;
dumper = pp->tx_dumper[dumper_q->queue_id];
if (dumper == NULL || nb_pkts == 0)
@@ -396,6 +404,12 @@ eth_pcap_tx_dumper(void *queue, struct rte_mbuf **bufs,
uint16_t nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = caplen = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > dev->data->mtu)) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
caplen = sizeof(temp_data);
@@ -464,13 +478,14 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t
nb_pkts)
struct rte_mbuf *mbuf;
struct pmd_process_private *pp;
struct pcap_tx_queue *tx_queue = queue;
+ struct rte_eth_dev *dev = &rte_eth_devices[tx_queue->port_id];
uint16_t num_tx = 0;
uint32_t tx_bytes = 0;
pcap_t *pcap;
unsigned char temp_data[RTE_ETH_PCAP_SNAPLEN];
size_t len;
- pp = rte_eth_devices[tx_queue->port_id].process_private;
+ pp = dev->process_private;
pcap = pp->tx_pcap[tx_queue->queue_id];
if (unlikely(nb_pkts == 0 || pcap == NULL))
@@ -479,6 +494,12 @@ eth_pcap_tx(void *queue, struct rte_mbuf **bufs, uint16_t
nb_pkts)
for (i = 0; i < nb_pkts; i++) {
mbuf = bufs[i];
len = rte_pktmbuf_pkt_len(mbuf);
+
+ if (unlikely(len > dev->data->mtu)) {
+ rte_pktmbuf_free(mbuf);
+ continue;
+ }
+
if (unlikely(!rte_pktmbuf_is_contiguous(mbuf) &&
len > sizeof(temp_data))) {
PMD_LOG(ERR,
@@ -807,6 +828,12 @@ eth_stats_reset(struct rte_eth_dev *dev)
return 0;
}
+static int eth_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
+{
+ PMD_LOG(INFO, "mtu set %s %u\n", dev->device->name, mtu);
+ return 0;
+}
+
static inline void
infinite_rx_ring_free(struct rte_ring *pkts)
{
@@ -1004,6 +1031,7 @@ static const struct eth_dev_ops ops = {
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
+ .mtu_set = eth_mtu_set,
};
static int
--
2.17.1
Re: [PATCH] net/pcap: support MTU set
On Thu, 17 Mar 2022 19:43:47 +0200
ido g wrote:
> + if (unlikely(header.caplen > dev->data->mtu)) {
> + pcap_q->rx_stat.err_pkts++;
> + rte_pktmbuf_free(mbuf);
> + break;
> + }
MTU should only be enforced on transmit.
Other real network devices allow oversized packets.
Since the pcap file is something user provides, if you don't want that then use
something
to filter the file.
Re: [PATCH] net/nfp: add the restrict of setting the mtu
On Thu, 17 Mar 2022 16:39:17 +0200
Peng Zhang wrote:
> + /* the setting mtu is in the range */
> + if (mtu < 68 || mtu > hw->max_mtu) {
> + PMD_DRV_LOG(ERR, "the setting mtu cannot be less than 68 or
> more than %d",
> + hw->max_mtu);
> + return -ERANGE;
> + }
> +
> + /* the setting mtu is lower than flbufsz */
> + if (mtu > hw->flbufsz) {
> + PMD_DRV_LOG(ERR, "the setting mtu must be lower than current
> mbufsize of %d",
> + hw->flbufsz);
> + return -ERANGE;
The ethdev layer already has min/max mtu checks, why is it needed inside common
code?
It looks like nfp_net_infos_get() does not set these values.
Please fix it there instead.
PS: 68 is RTE_ETHER_MIN_MTU so please use that.
[PATCH v2] doc: announce changes in bbdev related to enum extension
v2: indentation fix Realizing when submitting new bbdev operation in this patch (https://patchwork.dpdk.org/project/dpdk/list/?series=22111) that this is not workable in practice to extend this API into 22.07 without fundamental ABI breakage even by using existing versionning framework. Some existing learnings to be applied here to prevent extension being blocked, hence accouncing changes in bbdev intended for 22.11 to make this more future-proof, including dropping max value from enum, as well as deferring extension of the API for FFT operation into DPDK 22.11. Let me know if any comments or in case this should be captured differently. Thanks Nic Nicolas Chautru (1): doc: announce changes in bbdev related to enum extension doc/guides/rel_notes/deprecation.rst | 8 1 file changed, 8 insertions(+) -- 1.8.3.1
[PATCH v2] doc: announce changes in bbdev related to enum extension
Intent to resolve in DPDK 22.11 historical usage which prevents graceful extension of enum and API without troublesome ABI breakage as well as extending API RTE_BBDEV_OP_FFT for new operation type in bbdev. Signed-off-by: Nicolas Chautru --- doc/guides/rel_notes/deprecation.rst | 8 1 file changed, 8 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 4e5b23c..ff161c5 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -112,6 +112,14 @@ Deprecation Notices session and the private data of session. An opaque pointer can be exposed directly to application which can be attached to the ``rte_crypto_op``. +* bbdev: Will fix extending some enum breaking the ABI. Notably + deprecating ``RTE_BBDEV_OP_TYPE_COUNT`` terminating the ``rte_bbdev_op_type`` + and use fixed array size when required to allow for future enum extension. + Will also remove some of the inlining when causing ABI future-proof concerns. + Will extend API to support new operation type ``RTE_BBDEV_OP_FFT`` as per this + RFC https://patchwork.dpdk.org/project/dpdk/list/?series=22111 + This should be updated in DPDK 22.11. + * security: Hide structure ``rte_security_session`` and expose an opaque pointer for the private data to the application which can be attached to the packet while enqueuing. -- 1.8.3.1
RE: [PATCH v1] bbdev: add new operation for FFT processing
Hi Stephen,
Yes I am deferring thispatch to 22.11 due to ABI breakage that cannot be
resolved using versioning in a few places.
Still that patch can be used in anticipation of 22.11 to get early comments on
the API extension. I have marked it as deferred in patchwork.
For 22.07 I have pushed this notice to highlight change in 22.11 so that to
clean some of this to be more future proof and extend the API. Ie. no actual
change of API in 22.07.
=>
https://patches.dpdk.org/project/dpdk/patch/1647542252-35727-2-git-send-email-nicolas.chau...@intel.com/
Thanks
Nic
> -Original Message-
> From: Stephen Hemminger
> Sent: Thursday, March 10, 2022 5:13 PM
> To: Chautru, Nicolas
> Cc: dev@dpdk.org; gak...@marvell.com; t...@redhat.com;
> tho...@monjalon.net; hemant.agra...@nxp.com; Zhang, Mingshan
> ; david.march...@redhat.com
> Subject: Re: [PATCH v1] bbdev: add new operation for FFT processing
>
> On Thu, 10 Mar 2022 15:49:17 -0800
> Nicolas Chautru wrote:
>
> > diff --git a/lib/bbdev/rte_bbdev.c b/lib/bbdev/rte_bbdev.c index
> > aaee7b7..a72ecba 100644
> > --- a/lib/bbdev/rte_bbdev.c
> > +++ b/lib/bbdev/rte_bbdev.c
> > @@ -850,6 +850,9 @@ struct rte_bbdev *
> > case RTE_BBDEV_OP_LDPC_ENC:
> > result = sizeof(struct rte_bbdev_enc_op);
> > break;
> > + case RTE_BBDEV_OP_FFT:
> > + result = sizeof(struct rte_bbdev_fft_op);
> > + break;
> > default:
> > break;
> > }
> > @@ -873,6 +876,10 @@ struct rte_bbdev *
> > struct rte_bbdev_enc_op *op = element;
> > memset(op, 0, mempool->elt_size);
> > op->mempool = mempool;
> > + } else if (type == RTE_BBDEV_OP_FFT) {
> > + struct rte_bbdev_fft_op *op = element;
> > + memset(op, 0, mempool->elt_size);
> > + op->mempool = mempool;
> > }
> > }
> >
> > @@ -1123,6 +1130,7 @@ struct rte_mempool *
> > "RTE_BBDEV_OP_TURBO_ENC",
> > "RTE_BBDEV_OP_LDPC_DEC",
> > "RTE_BBDEV_OP_LDPC_ENC",
> > + "RTE_BBDEV_OP_FFT",
> > };
> >
> > if (op_type < RTE_BBDEV_OP_TYPE_COUNT) diff --git
> > a/lib/bbdev/rte_bbdev.h b/lib/bbdev/rte_bbdev.h index b88c881..e9ca673
> > 100644
> > --- a/lib/bbdev/rte_bbdev.h
> > +++ b/lib/bbdev/rte_bbdev.h
> > @@ -380,6 +380,12 @@ typedef uint16_t
> (*rte_bbdev_enqueue_dec_ops_t)(
> > struct rte_bbdev_dec_op **ops,
> > uint16_t num);
> >
> > +/** @internal Enqueue fft operations for processing on queue of a
> > +device. */ typedef uint16_t (*rte_bbdev_enqueue_fft_ops_t)(
> > + struct rte_bbdev_queue_data *q_data,
> > + struct rte_bbdev_fft_op **ops,
> > + uint16_t num);
> > +
> > /** @internal Dequeue encode operations from a queue of a device. */
> > typedef uint16_t (*rte_bbdev_dequeue_enc_ops_t)(
> > struct rte_bbdev_queue_data *q_data, @@ -390,6 +396,11
> @@ typedef
> > uint16_t (*rte_bbdev_dequeue_dec_ops_t)(
> > struct rte_bbdev_queue_data *q_data,
> > struct rte_bbdev_dec_op **ops, uint16_t num);
> >
> > +/** @internal Dequeue fft operations from a queue of a device. */
> > +typedef uint16_t (*rte_bbdev_dequeue_fft_ops_t)(
> > + struct rte_bbdev_queue_data *q_data,
> > + struct rte_bbdev_fft_op **ops, uint16_t num);
> > +
> > #define RTE_BBDEV_NAME_MAX_LEN 64 /**< Max length of device name
> */
> >
> > /**
> > @@ -438,6 +449,10 @@ struct __rte_cache_aligned rte_bbdev {
> > rte_bbdev_dequeue_enc_ops_t dequeue_ldpc_enc_ops;
> > /** Dequeue decode function */
> > rte_bbdev_dequeue_dec_ops_t dequeue_ldpc_dec_ops;
> > + /** Enqueue FFT function */
> > + rte_bbdev_enqueue_fft_ops_t enqueue_fft_ops;
> > + /** Dequeue FFT function */
> > + rte_bbdev_dequeue_fft_ops_t dequeue_fft_ops;
> > const struct rte_bbdev_ops *dev_ops; /**< Functions exported by
> PMD */
> > struct rte_bbdev_data *data; /**< Pointer to device data */
> > enum rte_bbdev_state state; /**< If device is currently used or not
> > */
>
>
> Since rte_bbdev is exposed in rte_bbdev.h it can not be changed without
> breaking ABI. It would have been better if data structure was better hidden
> (hint).
> But you can't change it now until 22.11
RE: [PATCH] net/pcap: support MTU set
As far as I can see the initial device MTU is derived from port *RX*
configuration in struct rte_eth_rxmode
https://doc.dpdk.org/api-21.11/structrte__eth__rxmode.html
Couple of real NICs I've tested (ixgbe, i40e based) don't allow oversized,
tests details can be seen in https://bugs.dpdk.org/show_bug.cgi?id=961
> -Original Message-
> From: Stephen Hemminger
> Sent: Thursday, 17 March 2022 20:21
> To: Ido Goshen
> Cc: Ferruh Yigit ; dev@dpdk.org
> Subject: Re: [PATCH] net/pcap: support MTU set
>
> On Thu, 17 Mar 2022 19:43:47 +0200
> ido g wrote:
>
> > + if (unlikely(header.caplen > dev->data->mtu)) {
> > + pcap_q->rx_stat.err_pkts++;
> > + rte_pktmbuf_free(mbuf);
> > + break;
> > + }
>
> MTU should only be enforced on transmit.
> Other real network devices allow oversized packets.
>
> Since the pcap file is something user provides, if you don't want that then
> use
> something to filter the file.
[PATCH v2] maintainers: add explicit maintainer for some bbdev PMDs
v2: adding suggested updates from Thomas and David to split and fix maintainers list, let me know. -- Suggested by Bruce to add explicit maintainer for some of the existing bbdev PMDs even it is already implicit currently. Intent is to be easier for user to get a hit when looking for a specific PMD. Nicolas Chautru (1): maintainers: add explicit maintainer for some bbdev PMDs MAINTAINERS | 32 ++-- 1 file changed, 26 insertions(+), 6 deletions(-) -- 1.8.3.1
[PATCH v2] maintainers: add explicit maintainer for some bbdev PMDs
These were implicit from DPDK script but adding separate reference to make it explicit. Separate sections for API and PMDs Signed-off-by: Nicolas Chautru --- MAINTAINERS | 32 ++-- 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index a3b4f5a..45b30e5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -421,12 +421,7 @@ M: Nicolas Chautru T: git://dpdk.org/next/dpdk-next-crypto F: lib/bbdev/ F: doc/guides/prog_guide/bbdev.rst -F: drivers/baseband/ -F: drivers/baseband/turbo_sw/ -F: drivers/baseband/fpga_lte_fec/ -F: drivers/baseband/fpga_5gnr_fec/ -F: drivers/baseband/acc100/ -F: doc/guides/bbdevs/ +F: doc/guides/bbdevs/features/default.ini F: app/test-bbdev/ F: doc/guides/tools/testbbdev.rst F: examples/bbdev_app/ @@ -1303,11 +1298,36 @@ F: doc/guides/eventdevs/opdl.rst Baseband Drivers +Intel PMDs +M: Nicolas Chautru +T: git://dpdk.org/next/dpdk-next-crypto +F: drivers/baseband/turbo_sw/ +F: drivers/baseband/fpga_lte_fec/ +F: drivers/baseband/fpga_5gnr_fec/ +F: drivers/baseband/acc100/ +F: doc/guides/bbdevs/turbo_sw.rst +F: doc/guides/bbdevs/fpga_lte_fec.rst +F: doc/guides/bbdevs/fpga_5gnr_fec.rst +F: doc/guides/bbdevs/acc100.rst +F: doc/guides/bbdevs/features/turbo_sw.ini +F: doc/guides/bbdevs/features/fpga_lte_fec.ini +F: doc/guides/bbdevs/features/fpga_5gnr_fec.ini +F: doc/guides/bbdevs/features/acc100.ini + +Null bbdev PMD +M: Nicolas Chautru +T: git://dpdk.org/next/dpdk-next-crypto +F: drivers/baseband/null/ +F: doc/guides/bbdevs/null.rst +F: doc/guides/bbdevs/features/null.ini + NXP LA12xx M: Nipun Gupta M: Hemant Agrawal +T: git://dpdk.org/next/dpdk-next-crypto F: drivers/baseband/la12xx/ F: doc/guides/bbdevs/la12xx.rst +F: doc/guides/bbdevs/features/la12xx.ini GPU Drivers -- 1.8.3.1
[PATCH v2] maintainers: add explicit maintainer for some bbdev PMDs
v3: squash issue in v2 v2: adding suggested updates from Thomas and David to split and fix maintainers list, let me know. -- Suggested by Bruce to add explicit maintainer for some of the existing bbdev PMDs even it is already implicit currently. Intent is to be easier for user to get a hit when looking for a specific PMD. Nicolas Chautru (1): maintainers: add explicit maintainer for some bbdev PMDs MAINTAINERS | 28 ++-- 1 file changed, 26 insertions(+), 2 deletions(-) -- 1.8.3.1
[PATCH v2] maintainers: add explicit maintainer for some bbdev PMDs
These were implicit from DPDK script but adding separate reference to make it explicit. Separate sections for API and PMDs Signed-off-by: Nicolas Chautru --- MAINTAINERS | 28 ++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index fdea1c6..45b30e5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -421,8 +421,7 @@ M: Nicolas Chautru T: git://dpdk.org/next/dpdk-next-crypto F: lib/bbdev/ F: doc/guides/prog_guide/bbdev.rst -F: drivers/baseband/ -F: doc/guides/bbdevs/ +F: doc/guides/bbdevs/features/default.ini F: app/test-bbdev/ F: doc/guides/tools/testbbdev.rst F: examples/bbdev_app/ @@ -1299,11 +1298,36 @@ F: doc/guides/eventdevs/opdl.rst Baseband Drivers +Intel PMDs +M: Nicolas Chautru +T: git://dpdk.org/next/dpdk-next-crypto +F: drivers/baseband/turbo_sw/ +F: drivers/baseband/fpga_lte_fec/ +F: drivers/baseband/fpga_5gnr_fec/ +F: drivers/baseband/acc100/ +F: doc/guides/bbdevs/turbo_sw.rst +F: doc/guides/bbdevs/fpga_lte_fec.rst +F: doc/guides/bbdevs/fpga_5gnr_fec.rst +F: doc/guides/bbdevs/acc100.rst +F: doc/guides/bbdevs/features/turbo_sw.ini +F: doc/guides/bbdevs/features/fpga_lte_fec.ini +F: doc/guides/bbdevs/features/fpga_5gnr_fec.ini +F: doc/guides/bbdevs/features/acc100.ini + +Null bbdev PMD +M: Nicolas Chautru +T: git://dpdk.org/next/dpdk-next-crypto +F: drivers/baseband/null/ +F: doc/guides/bbdevs/null.rst +F: doc/guides/bbdevs/features/null.ini + NXP LA12xx M: Nipun Gupta M: Hemant Agrawal +T: git://dpdk.org/next/dpdk-next-crypto F: drivers/baseband/la12xx/ F: doc/guides/bbdevs/la12xx.rst +F: doc/guides/bbdevs/features/la12xx.ini GPU Drivers -- 1.8.3.1
Re: [PATCH v2 1/2] eal_debug: do not use malloc in rte_dump_stack
On Sun, 13 Feb 2022 12:41:59 +0100 Thomas Monjalon wrote: > 12/02/2022 19:44, Stephen Hemminger: > > The glibc backtrace_symbols() calls malloc which makes it > > dangerous to use rte_dump_stack() in a signal handler that > > is handling errors that maybe due to memory corruption. > > > > Instead, use dladdr() to lookup up symbols incrementally. > > > > The format of the messages is based on what X org server > > has been doing for many years. It changes from bottom up > > to top down order. > > > > Signed-off-by: Stephen Hemminger > > Morten acked the RFC. > Is there any significant change? > > > The change was making it not RFC. Lets make a common code for this FreeBSD should have same code.
[PATCH] net/ice: fix raw flow input pattern value change in FDIR
When parsing raw flow pattern in FDIR, the input parameter spec and
mask are used directly and the original value will be changed. It
will cause error if these values are used in other functions. In this
patch, temporary variables are created to store the spec and mask.
Fixes: 25be39cc1760 ("net/ice: enable protocol agnostic flow offloading in
FDIR")
Cc: sta...@dpdk.org
Signed-off-by: Ting Xu
---
drivers/net/ice/ice_fdir_filter.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ice/ice_fdir_filter.c
b/drivers/net/ice/ice_fdir_filter.c
index 7954c6d8ea..6e3851a71b 100644
--- a/drivers/net/ice/ice_fdir_filter.c
+++ b/drivers/net/ice/ice_fdir_filter.c
@@ -1868,14 +1868,15 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
*ad,
break;
/* convert raw spec & mask from byte string to int */
- unsigned char *tmp_spec =
+ unsigned char *spec_pattern =
(uint8_t *)(uintptr_t)raw_spec->pattern;
- unsigned char *tmp_mask =
+ unsigned char *mask_pattern =
(uint8_t *)(uintptr_t)raw_mask->pattern;
uint16_t udp_port = 0;
uint16_t tmp_val = 0;
uint8_t pkt_len = 0;
uint8_t tmp = 0;
+ uint8_t *tmp_spec, *tmp_mask;
int i, j;
pkt_len = strlen((char *)(uintptr_t)raw_spec->pattern);
@@ -1883,8 +1884,18 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
*ad,
pkt_len)
return -rte_errno;
+ tmp_spec = rte_zmalloc(NULL, pkt_len / 2, 0);
+ if (!tmp_spec)
+ return -rte_errno;
+
+ tmp_mask = rte_zmalloc(NULL, pkt_len / 2, 0);
+ if (!tmp_mask) {
+ rte_free(tmp_spec);
+ return -rte_errno;
+ }
+
for (i = 0, j = 0; i < pkt_len; i += 2, j++) {
- tmp = tmp_spec[i];
+ tmp = spec_pattern[i];
if (tmp >= 'a' && tmp <= 'f')
tmp_val = tmp - 'a' + 10;
if (tmp >= 'A' && tmp <= 'F')
@@ -1893,7 +1904,7 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
*ad,
tmp_val = tmp - '0';
tmp_val *= 16;
- tmp = tmp_spec[i + 1];
+ tmp = spec_pattern[i + 1];
if (tmp >= 'a' && tmp <= 'f')
tmp_spec[j] = tmp_val + tmp - 'a' + 10;
if (tmp >= 'A' && tmp <= 'F')
@@ -1901,7 +1912,7 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
*ad,
if (tmp >= '0' && tmp <= '9')
tmp_spec[j] = tmp_val + tmp - '0';
- tmp = tmp_mask[i];
+ tmp = mask_pattern[i];
if (tmp >= 'a' && tmp <= 'f')
tmp_val = tmp - 'a' + 10;
if (tmp >= 'A' && tmp <= 'F')
@@ -1910,7 +1921,7 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
*ad,
tmp_val = tmp - '0';
tmp_val *= 16;
- tmp = tmp_mask[i + 1];
+ tmp = mask_pattern[i + 1];
if (tmp >= 'a' && tmp <= 'f')
tmp_mask[j] = tmp_val + tmp - 'a' + 10;
if (tmp >= 'A' && tmp <= 'F')
@@ -1953,6 +1964,8 @@ ice_fdir_parse_pattern(__rte_unused struct ice_adapter
*ad,
filter->parser_ena = true;
+ rte_free(tmp_spec);
+ rte_free(tmp_mask);
break;
}
--
2.17.1
