Re: [dpdk-dev] [PATCH] eal/hotplug: suppress one error log on primary process
19/05/2021 08:45, Changpeng Liu: > This is a normal case that the primary process already > owned one PCI device while the secondary process try to > attach it, so suppress the error log here to exclude > this case. > > Signed-off-by: Changpeng Liu Applied, thanks.
Re: [dpdk-dev] [PATCH v3] ethdev: add IPv4 and L4 checksum RSS offload types
08/07/2021 09:45, Andrew Rybchenko:
> @Thomas, @Ferruh, @Ori I need your opinion on the discussion.
>
> On 7/8/21 4:07 AM, Zhang, Qi Z wrote:
> > From: Andrew Rybchenko
> >>> From: Andrew Rybchenko
> On 7/7/21 6:23 AM, Zhang, Qi Z wrote:
> > From: Andrew Rybchenko
> >> On 7/6/21 10:18 AM, Zhang, Qi Z wrote:
> >>> From: Zhang, AlvinX
>
> >> @@ -537,6 +537,8 @@ struct rte_eth_rss_conf {
> >> #define ETH_RSS_PPPOE(1ULL << 31)
> >> #define ETH_RSS_ECPRI(1ULL << 32)
> >> #define ETH_RSS_MPLS (1ULL << 33)
> >> +#define ETH_RSS_IPV4_CHKSUM (1ULL << 34)
> >> +#define ETH_RSS_L4_CHKSUM(1ULL << 35)
> >
> > What does efine which L4 protocols are supported? How user will
> >> know?
>
> I think if we want to support L4 checksum RSS by using below
> command port config all rss (all|default|eth|vlan|...)
>
> We must define TCP/UDP/SCTP checksum RSS separately:
> #define ETH_RSS_TCP_CHKSUM (1ULL << 35)
> #define ETH_RSS_UDP_CHKSUM (1ULL << 36)
> #deifne ETH_RSS_SCTP_CHKSUM (1ULL << 37)
>
> Here 3 bits are occupied, this is not good for there are not many
> bits
> >> available.
>
> If we only want to using it in flows, we only need to define
> ETH_RSS_L4_CHKSUM, because the flow pattern pointed out the L4
> protocol type.
> flow create 0 ingress pattern eth / ipv4 / tcp / end actions rss
> types l4-chksum end queues end / end
> >>>
> >>> +1, the pattern already give the hint to avoid the ambiguity and I
> >>> +think we
> >> already have ETH_RSS_LEVEL to figure out inner or outer.
> >>
> >> The problem that it may be used in generic RSS flags which has no
> >> the
> context.
> >> Also even in the case of flow API context could have no L4 protocol at
> >> all.
> >
> > For generic case, it can simply assume it cover all L4 checksum
> > cases and I'm
> not sure if any user intend to use it as generic RSS, pmd can simply
> reject it if it's not necessary to support.
>
> Try to look at it from an application point of view which does not
> know any specifics of the driver.
>
> * Get dev_info and see ETH_RSS_L4_CHKSUM, good!, would like to
> use it.
> >>>
> >>>
> >>> The PMD should not expose it if it don't want to (or not able to)
> >>> support all l4 checksum from generic RSS configure
That's restrictive to allow only full-support,
but I'm fine with the trade-off to avoid wasting bits.
> >>
> >> Document what is "all L4".
List of L4 protocols should be explicit.
> >>> And we should assume this is only apply for generic RSS configure but not
> >>> for
> >> flow API.
> >>
> >> I don't think so. IMHO, it should report all RSS capabilities regardless
> >> generic vs
> >> flow API RSS action.
> >
> >
> > The RSS action in flow API could cover lots of possibility.
> > for example an ETH_RSS_IPV4 can be applied on a GTPU flow for inner but may
> > not work for a VxLan flow's inner l3 at the same time.
> > it's difficult to accurately describe all of these by a 64 bits capability,
> > it's more practice to just rely on rte_flow_validation.
> > Otherwise it will always leading the confusing you mentioned in previous
> > mail.
> >
> > It is more reasonable for me, the driver just expose some basic RSS bit
> > that everybody can easiely understand,(e.g.: 5 tuple.), and left all the
> > complexity capability probe to flow API.
>
> May be it is OK to report subset in
> dev_info->flow_type_rss_offloads, but I'm very
> uncomfortable with the approach. Superset sounds
> more logical to me, but has drawbacks as well.
Yes superset should be reported, this is the meaning of capabilities:
the driver is capable but there are some limitations
which cannot be advertised, so rte_flow_validate checks the limitations
in the dynamic context.
> >> It is just RSS capabilities reporting w/o any context.
> >
> >>>
> >>> Because the rte_flow_validate is the recommended method to check if a RSS
> >> action is supported in flow API or not.
> >>
> >> It could restrict the subset. But superset should be reported in caps.
> >>
> >>>
>
> * If I try to use it in default RSS config, but the request
> fail, it could be very confusing.
>
> * Will it distribute TCP packets? UDP packets? SCTP packets?
> Or should I care about RSS for some of them based on other
> supported fields? E.g. if SCTP is not supported by the NIC,
> I need to install RSS flow rule for the IP protocol to do
> RSS based on IPv4/IPv6 addresses. But if SCTP is supported,
> I'm happy to use ETH_RSS_L4_CHKSUM for it as well.
>
> > In flow API, if no l4 protocol in pattern , the PMD should return
Re: [dpdk-dev] [PATCH V4 3/5] pipeline: add support for selector tables
> -Original Message- > From: Thomas Monjalon > Sent: Saturday, July 10, 2021 7:28 AM > To: Dumitrescu, Cristian > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH V4 3/5] pipeline: add support for selector > tables > > 10/07/2021 02:20, Cristian Dumitrescu: > > Add pipeline-level support for selector tables, > > > > Signed-off-by: Cristian Dumitrescu > > --- > > Change log: > > > > V3 -> V4: Fixed proper name of allocated structure > > (rte_swx_table_selector_params instead of > rte_swx_pipeline_selector_params). > > Applied (with next patches), thanks. > > Thanks very much, Thomas, really appreciate your help! Regards, Cristian
Re: [dpdk-dev] [PATCH v2] ethdev: keep count of allocated and used representor ranges
05/07/2021 13:07, Xueming(Steven) Li:
> From: Andrew Rybchenko
> > From: Viacheslav Galaktionov
> >
> > In its current state, the API can overflow the user-passed buffer if a new
> > representor range appears between function calls.
> >
> > In order to solve this problem, augment the representor info structure with
> > the numbers of allocated and initialized ranges. This way
> > the users of this structure can be sure they will not overrun the buffer.
> >
> > Fixes: 85e1588ca72f ("ethdev: add API to get representor info")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Viacheslav Galaktionov
> > Signed-off-by: Andrew Rybchenko
>
> Reviewed-by: Xueming Li
Applied, thanks.
[dpdk-dev] [dpdk-announce] release candidate 21.08-rc1
A new DPDK release candidate is ready for testing: https://git.dpdk.org/dpdk/tag/?id=v21.08-rc1 There are 517 new patches in this snapshot. This release cycle is short and should be small. Release notes: https://doc.dpdk.org/guides/rel_notes/release_21_08.html Highlights of 21.08-rc1: - Linux auxiliary bus - Aarch32 cross-compilation - Arm CPPC power management - Rx multi-queue monitoring for power management - XZ compressed firmware read - Marvell CNXK drivers for ethernet, crypto and baseband PHY Please test and report issues on bugs.dpdk.org. DPDK 21.08-rc2 is expected in less than two weeks. Thank you everyone
[dpdk-dev] [PATCH] net/mlx5: fix use after free in mlx5_dma_unmap
From: Yunjian Wang
This patch fixes the use-after-free bug which was reported by Coverity
Scan in the mlx5_dma_unmap function.
Coverity issue: 371679
Fixes: 992e6df3dafe ("common/mlx5: free MR resource on device DMA unmap")
Cc: sta...@dpdk.org
Signed-off-by: Yunjian Wang
---
drivers/net/mlx5/mlx5_mr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_mr.c b/drivers/net/mlx5/mlx5_mr.c
index 89c43fc9e9..e87f138564 100644
--- a/drivers/net/mlx5/mlx5_mr.c
+++ b/drivers/net/mlx5/mlx5_mr.c
@@ -315,9 +315,9 @@ mlx5_dma_unmap(struct rte_pci_device *pdev, void *addr,
return -1;
}
LIST_REMOVE(mr, mr);
- mlx5_mr_free(mr, sh->share_cache.dereg_mr_cb);
DRV_LOG(DEBUG, "port %u remove MR(%p) from list", dev->data->port_id,
(void *)mr);
+ mlx5_mr_free(mr, sh->share_cache.dereg_mr_cb);
mlx5_mr_rebuild_cache(&sh->share_cache);
/*
* No explicit wmb is needed after updating dev_gen due to
--
2.23.0
Re: [dpdk-dev] [PATCH 1/2] security: enforce semantics for Tx inline processing
> > > > > > > > > For Tx inline processing, when > > > > > > > > > RTE_SECURITY_TX_OLOAD_NEED_MDATA is > > > > > > > > > set, rte_security_set_pkt_metadata() needs to be called for > > > > > > > > > pkts > > > > > > > > > to associate a Security session with a mbuf before submitting > > > > > > > > > to Ethdev Tx. This is apart from setting PKT_TX_SEC_OFFLOAD in > > > > > > > > > mbuf.ol_flags. rte_security_set_pkt_metadata() is also used to > > > > > > > > > set some opaque metadata in mbuf for PMD's use. > > > > > > > > > This patch updates documentation that > > > > > > > > > rte_security_set_pkt_metadata() > > > > > > > > > should be called only with mbuf containing Layer 3 and above > > > > > > > > > data. > > > > > > > > > This behaviour is consistent with existing PMD's such as > > > > > > > > > ixgbe. > > > > > > > > > > > > > > > > > > On Tx, not all net PMD's/HW can parse packet and identify > > > > > > > > > L2 header and L3 header locations on Tx. This is inline with > > > > > > > > > other > > > > > > > > > Tx offloads requirements such as L3 checksum, L4 checksum > > > > > > > > > offload, > > > > > > > > > etc, where mbuf.l2_len, mbuf.l3_len etc, needs to be set for > > > > > > > > > HW to be able to generate checksum. Since Inline IPSec is also > > > > > > > > > such a Tx offload, some PMD's at least need mbuf.l2_len to be > > > > > > > > > valid to find L3 header and perform Outbound IPSec processing. > > > > > > > > > Hence, this patch updates documentation to enforce setting > > > > > > > > > mbuf.l2_len while setting PKT_TX_SEC_OFFLOAD in mbuf.ol_flags > > > > > > > > > for Inline IPSec Crypto / Protocol offload processing to > > > > > > > > > work on Tx. > > > > > > > > > > > > > > > > > > Signed-off-by: Nithin Dabilpuram > > > > > > > > > Reviewed-by: Akhil Goyal > > > > > > > > > --- > > > > > > > > > doc/guides/nics/features.rst | 2 ++ > > > > > > > > > doc/guides/prog_guide/rte_security.rst | 6 +- > > > > > > > > > lib/mbuf/rte_mbuf_core.h | 2 ++ > > > > > > > > > 3 files changed, 9 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > > > diff --git a/doc/guides/nics/features.rst > > > > > > > > > b/doc/guides/nics/features.rst > > > > > > > > > index 403c2b03a..414baf14f 100644 > > > > > > > > > --- a/doc/guides/nics/features.rst > > > > > > > > > +++ b/doc/guides/nics/features.rst > > > > > > > > > @@ -430,6 +430,7 @@ of protocol operations. See Security > > > > > > > > > library and PMD documentation for more deta > > > > > > > > > > > > > > > > > > * **[uses] rte_eth_rxconf,rte_eth_rxmode**: > > > > > > > > > ``offloads:DEV_RX_OFFLOAD_SECURITY``, > > > > > > > > > * **[uses] rte_eth_txconf,rte_eth_txmode**: > > > > > > > > > ``offloads:DEV_TX_OFFLOAD_SECURITY``. > > > > > > > > > +* **[uses] mbuf**: ``mbuf.l2_len``. > > > > > > > > > * **[implements] rte_security_ops**: ``session_create``, > > > > > > > > > ``session_update``, > > > > > > > > >``session_stats_get``, ``session_destroy``, > > > > > > > > > ``set_pkt_metadata``, ``capabilities_get``. > > > > > > > > > * **[provides] rte_eth_dev_info**: > > > > > > > > > ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_SECURITY``, > > > > > > > > > @@ -451,6 +452,7 @@ protocol operations. See security library > > > > > > > > > and PMD documentation for more details > > > > > > > > > > > > > > > > > > * **[uses] rte_eth_rxconf,rte_eth_rxmode**: > > > > > > > > > ``offloads:DEV_RX_OFFLOAD_SECURITY``, > > > > > > > > > * **[uses] rte_eth_txconf,rte_eth_txmode**: > > > > > > > > > ``offloads:DEV_TX_OFFLOAD_SECURITY``. > > > > > > > > > +* **[uses] mbuf**: ``mbuf.l2_len``. > > > > > > > > > * **[implements] rte_security_ops**: ``session_create``, > > > > > > > > > ``session_update``, > > > > > > > > >``session_stats_get``, ``session_destroy``, > > > > > > > > > ``set_pkt_metadata``, ``get_userdata``, > > > > > > > > >``capabilities_get``. > > > > > > > > > diff --git a/doc/guides/prog_guide/rte_security.rst > > > > > > > > > b/doc/guides/prog_guide/rte_security.rst > > > > > > > > > index f72bc8a78..7b68c698d 100644 > > > > > > > > > --- a/doc/guides/prog_guide/rte_security.rst > > > > > > > > > +++ b/doc/guides/prog_guide/rte_security.rst > > > > > > > > > @@ -560,7 +560,11 @@ created by the application is attached > > > > > > > > > to the security session by the API > > > > > > > > > > > > > > > > > > For Inline Crypto and Inline protocol offload, device > > > > > > > > > specific defined metadata is > > > > > > > > > updated in the mbuf using > > > > > > > > > ``rte_security_set_pkt_metadata()`` if > > > > > > > > > -``DEV_TX_OFFLOAD_SEC_NEED_MDATA`` is set. > > > > > > > > > +``RTE_SECURITY_TX_OLOAD_NEED_MDATA`` is set. > > > > > > > > > ``rte_security_set_pkt_metadata()`` > > > > > > > > > +should be called on mbuf only with Layer 3 and above data > > > > > > > > > present and > > > > > > > > > +``mbuf
[dpdk-dev] [PATCH v2] crypto/mvsam: IPSec full offload support
From: Michael Shamis
This patch provides the support for IPSec protocol
offload to the hardware.
Following security operations are added:
- session_create
- session_destroy
- capabilities_get
Signed-off-by: Michael Shamis
Reviewed-by: Liron Himi
Tested-by: Liron Himi
---
drivers/crypto/mvsam/meson.build| 2 +-
drivers/crypto/mvsam/mrvl_pmd_private.h | 8 +-
drivers/crypto/mvsam/rte_mrvl_pmd.c | 333 +---
drivers/crypto/mvsam/rte_mrvl_pmd_ops.c | 176 +
4 files changed, 484 insertions(+), 35 deletions(-)
diff --git a/drivers/crypto/mvsam/meson.build b/drivers/crypto/mvsam/meson.build
index c0c828fbf..fec167bf2 100644
--- a/drivers/crypto/mvsam/meson.build
+++ b/drivers/crypto/mvsam/meson.build
@@ -14,4 +14,4 @@ ext_deps += dep
sources = files('rte_mrvl_pmd.c', 'rte_mrvl_pmd_ops.c')
-deps += ['bus_vdev', 'common_mvep']
+deps += ['bus_vdev', 'common_mvep', 'security']
diff --git a/drivers/crypto/mvsam/mrvl_pmd_private.h
b/drivers/crypto/mvsam/mrvl_pmd_private.h
index e575330ef..719d73d82 100644
--- a/drivers/crypto/mvsam/mrvl_pmd_private.h
+++ b/drivers/crypto/mvsam/mrvl_pmd_private.h
@@ -82,11 +82,17 @@ struct mrvl_crypto_src_table {
} __rte_cache_aligned;
/** Set and validate MRVL crypto session parameters */
-extern int
+int
mrvl_crypto_set_session_parameters(struct mrvl_crypto_session *sess,
const struct rte_crypto_sym_xform *xform);
+int
+mrvl_ipsec_set_session_parameters(struct mrvl_crypto_session *sess,
+ struct rte_security_ipsec_xform *ipsec_xform,
+ struct rte_crypto_sym_xform *crypto_xform);
+
/** device specific operations function pointer structure */
extern struct rte_cryptodev_ops *rte_mrvl_crypto_pmd_ops;
+extern struct rte_security_ops *rte_mrvl_security_pmd_ops;
#endif /* _MRVL_PMD_PRIVATE_H_ */
diff --git a/drivers/crypto/mvsam/rte_mrvl_pmd.c
b/drivers/crypto/mvsam/rte_mrvl_pmd.c
index b2cfa710f..c1ccd95fc 100644
--- a/drivers/crypto/mvsam/rte_mrvl_pmd.c
+++ b/drivers/crypto/mvsam/rte_mrvl_pmd.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -398,7 +399,7 @@ mrvl_crypto_set_aead_session_parameters(struct
mrvl_crypto_session *sess,
* Parse crypto transform chain and setup session parameters.
*
* @param dev Pointer to crypto device
- * @param sess Poiner to crypto session
+ * @param sess Pointer to crypto session
* @param xform Pointer to configuration structure chain for crypto operations.
* @returns 0 in case of success, negative value otherwise.
*/
@@ -461,6 +462,96 @@ mrvl_crypto_set_session_parameters(struct
mrvl_crypto_session *sess,
return 0;
}
+static int
+replay_wsz_to_mask(uint32_t replay_win_sz)
+{
+ int mask = 0;
+
+ switch (replay_win_sz) {
+ case 0:
+ mask = SAM_ANTI_REPLY_MASK_NONE;
+ break;
+ case 32:
+ mask = SAM_ANTI_REPLY_MASK_32B;
+ break;
+ case 64:
+ mask = SAM_ANTI_REPLY_MASK_64B;
+ break;
+ case 128:
+ mask = SAM_ANTI_REPLY_MASK_128B;
+ break;
+ default:
+ MRVL_LOG(ERR, "Invalid antireplay window size");
+ return -EINVAL;
+ }
+
+ return mask;
+}
+
+/**
+ * Parse IPSEC session parameters.
+ *
+ * @param sess Pointer to security session
+ * @param ipsec_xform Pointer to configuration structure IPSEC operations.
+ * @param crypto_xform Pointer to chain for crypto operations.
+ * @returns 0 in case of success, negative value otherwise.
+ */
+int
+mrvl_ipsec_set_session_parameters(struct mrvl_crypto_session *sess,
+ struct rte_security_ipsec_xform *ipsec_xform,
+ struct rte_crypto_sym_xform *crypto_xform)
+{
+ int seq_mask_size;
+
+ /* Filter out spurious/broken requests */
+ if (ipsec_xform == NULL || crypto_xform == NULL)
+ return -EINVAL;
+
+ /* Crypto parameters handling */
+ if (mrvl_crypto_set_session_parameters(sess, crypto_xform))
+ return -EINVAL;
+
+ seq_mask_size = replay_wsz_to_mask(ipsec_xform->replay_win_sz);
+ if (seq_mask_size < 0)
+ return -EINVAL;
+
+ /* IPSEC protocol parameters handling */
+ sess->sam_sess_params.proto = SAM_PROTO_IPSEC;
+ sess->sam_sess_params.u.ipsec.is_esp =
+ (ipsec_xform->proto == RTE_SECURITY_IPSEC_SA_PROTO_ESP) ?
+ 1 : 0;
+ sess->sam_sess_params.u.ipsec.is_ip6 = 0;
+ sess->sam_sess_params.u.ipsec.is_tunnel =
+ (ipsec_xform->mode == RTE_SECURITY_IPSEC_SA_MODE_TUNNEL) ?
+ 1 : 0;
+ sess->sam_sess_params.u.ipsec.is_esn = ipsec_xform->options.esn;
+ sess->sam_sess_params.u.ipsec.seq_mask_size = seq_mask_size;
+
+ sess->sam_sess_params.u.ipsec.tunnel.u.ipv4.sip =
+ (uint8_t *)(&ipsec_xform->tunnel.ipv4.src_ip.s_addr);
+ sess-
