Re: [dpdk-dev] [PATCH v8 1/7] ethdev: add set ptype function
On 10/3/19 12:36 AM, pbhagavat...@marvell.com wrote:
From: Pavan Nikhilesh
Add `rte_eth_dev_set_supported_ptypes` function that will allow the
application to inform the PMD the packet types it is interested in.
Based on the ptypes set PMDs can optimize their Rx path.
-If application doesn’t want any ptype information it can call
`rte_eth_dev_set_supported_ptypes(ethdev_id, RTE_PTYPE_UNKNOWN, NULL, 0)`
and PMD may skip packet type processing and set rte_mbuf::packet_type to
RTE_PTYPE_UNKNOWN.
-If application doesn’t call `rte_eth_dev_set_supported_ptypes` PMD can
return `rte_mbuf::packet_type` with `rte_eth_dev_get_supported_ptypes`.
-If application is interested only in L2/L3 layer, it can inform the PMD
to update `rte_mbuf::packet_type` with L2/L3 ptype by calling
`rte_eth_dev_set_supported_ptypes(ethdev_id,
RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK, NULL, 0)`.
Suggested-by: Konstantin Ananyev
Signed-off-by: Pavan Nikhilesh
With few fixes below:
Reviewed-by: Andrew Rybchenko
[snip]
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 17d183e1f..57bc12b56 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -2602,6 +2602,65 @@ rte_eth_dev_get_supported_ptypes(uint16_t port_id,
uint32_t ptype_mask,
return j;
}
+int
+rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t ptype_mask,
+uint32_t *set_ptypes, unsigned int num)
+{
+ unsigned int i, j;
+ struct rte_eth_dev *dev;
+ const uint32_t *all_ptypes;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ dev = &rte_eth_devices[port_id];
+
+ if (num > 0 && set_ptypes == NULL)
+ return -EINVAL;
+
+ if (*dev->dev_ops->dev_supported_ptypes_get == NULL ||
+ *dev->dev_ops->dev_supported_ptypes_set == NULL) {
+ if (num > 0)
+ set_ptypes[0] = RTE_PTYPE_UNKNOWN;
+ return 0;
+ }
+
+ if (ptype_mask == 0) {
+ if (num > 0)
+ set_ptypes[0] = RTE_PTYPE_UNKNOWN;
+
+ return (*dev->dev_ops->dev_supported_ptypes_set)(dev,
+ ptype_mask);
+ }
+
+ all_ptypes = (*dev->dev_ops->dev_supported_ptypes_get)(dev);
+ if (all_ptypes == NULL) {
+ if (num > 0)
+ set_ptypes[0] = RTE_PTYPE_UNKNOWN;
+
+ return 0;
+ }
+
+ /*
+* Accodommodate as many set_ptypes as possible. If the supplied
+* set_ptypes array is insufficient fill it partially.
+*/
+ for (i = 0, j = 0; set_ptypes != NULL &&
+ (all_ptypes[i] != RTE_PTYPE_UNKNOWN); ++i) {
+ if (ptype_mask & all_ptypes[i]) {
+ if (j < num - 1) {
+ set_ptypes[j] = all_ptypes[i];
+ j++;
+ continue;
+ }
+ break;
+ }
+ }
+
+ if (set_ptypes != NULL)
+ set_ptypes[j] = RTE_PTYPE_UNKNOWN;
Initially I thought that we are safe here, but now realized that we
can write more than num here, e.g. if set_ptypes is not NULL, but num is 0.
I think the right condition here is (j < num) since it guarantees that
set_ptype is not NULL as well (since num is greater than 0 if unsigned j
is less than num).
+
+ return (*dev->dev_ops->dev_supported_ptypes_set)(dev, ptype_mask);
+}
+
void
rte_eth_macaddr_get(uint16_t port_id, struct rte_ether_addr *mac_addr)
{
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index d9871782e..c577a9172 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -2431,6 +2431,42 @@ int rte_eth_dev_fw_version_get(uint16_t port_id,
*/
int rte_eth_dev_get_supported_ptypes(uint16_t port_id, uint32_t ptype_mask,
uint32_t *ptypes, int num);
+/**
+ * @warning
+ * @b EXPERIMENTAL: this API may change without prior notice.
+ *
+ * Inform Ethernet device of the packet types classification in which
+ * the recipient is interested.
+ *
+ * Application can use this function to set only specific ptypes that it's
+ * interested. This information can be used by the PMD to optimize Rx path.
+ *
+ * The function accepts an array `set_ptypes` allocated by the caller to
+ * store the packet types set by the driver, the last element of the array
+ * is set to RTE_PTYPE_UNKNOWN. The size of the `set_ptype` array should be
+ * `rte_eth_dev_get_supported_ptypes() + 1` else it might only be filled
+ * partially.
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param ptype_mask
+ * The ptype family that application is interested in.
I think it is better to highlight here that it should be bitwise OR of
RTE_PTYPE_*_MASK or 0.
BTW, I
Re: [dpdk-dev] [PATCH v2 04/30] bus/dpaa: decouple fq portal alloc and init
On 8/29/2019 11:27 AM, Sachin Saxena wrote:
> From: Nipun Gupta
>
> The decoupling of FQ portal allocation is required as a
> pre-requisite to support Rx interrupts as we need to have
> event FD's at portal allocation i.e. before the
> initialization of the Frame Queues.
> This change will help us get the event fd once the portals
> have been allocated for static FQ's.
>
> Signed-off-by: Nipun Gupta
<...>
> @@ -123,3 +123,10 @@ DPDK_19.05 {
>
> local: *;
> } DPDK_18.11;
> +
> +DPDK_19.11 {
> + global:
> + fsl_qman_fq_portal_create;
> +
> + local: *;
> +} DPDK_19.05;
"local:" tag doesn't need to be in each block, having only in the first one is
enough, I can fix while merging.
[dpdk-dev] [PATCH v2] eal: add manual probing option
Add a new EAL option enabling manual probing in the EAL.
This command line option will configure the EAL so that buses
will not trigger their probe step on their own.
Applications are then expected to hotplug devices as they see fit.
Devices declared on the command line by the user (using -w and --vdev),
will be probed using the hotplug API, in the order they are declared.
This has the effect of offering a way for users to control probe order
of their devices, for drivers requiring it.
Signed-off-by: Gaetan Rivet
---
I haven't heard many opinions on the matter, please shout if you see an issue
with this approach.
@Slava: I have tested rather quickly that it does not break anything,
and that it works as intended for basic cases.
Can you test it further for your use-case and tell me if it works fine?
Beyond the obvious difference between both probe mode, something to keep in
mind:
while using -w on invalid devices would not block (PCI) bus probing, it will
stop manual
probing in its track. All devices need to exist and be valid device IDs.
v2: fixed a few typos, map file (and used Travis to validate).
Slava, are you able to test this patch?
doc/guides/rel_notes/release_19_11.rst | 9 +++
lib/librte_eal/common/eal_common_bus.c | 6 +
lib/librte_eal/common/eal_common_dev.c | 41 ++
lib/librte_eal/common/eal_common_options.c | 8 ++
lib/librte_eal/common/eal_internal_cfg.h | 1 +
lib/librte_eal/common/eal_options.h| 2 ++
lib/librte_eal/common/eal_private.h| 9 +++
lib/librte_eal/common/include/rte_eal.h| 17 +
lib/librte_eal/freebsd/eal/eal.c | 5
lib/librte_eal/linux/eal/eal.c | 5
lib/librte_eal/rte_eal_version.map | 7 +
11 files changed, 110 insertions(+)
diff --git a/doc/guides/rel_notes/release_19_11.rst
b/doc/guides/rel_notes/release_19_11.rst
index 27cfbd9e3..88d06e82e 100644
--- a/doc/guides/rel_notes/release_19_11.rst
+++ b/doc/guides/rel_notes/release_19_11.rst
@@ -56,6 +56,15 @@ New Features
Also, make sure to start the actual text at the margin.
=
+* **EAL will now propose to enforce manual probing of devices.**
+
+ Previously, a user could not force an order when probing declared devices.
+ This could cause issues for drivers depending on another device being
present.
+ A new option ``--manual-probe`` is now available to do just that.
+ This new option relies on the device bus supporting hotplug. It can
+ also be used to disable automatic probing from the ``PCI`` bus without
+ having to disable the whole bus.
+
Removed Items
-
diff --git a/lib/librte_eal/common/eal_common_bus.c
b/lib/librte_eal/common/eal_common_bus.c
index baa5b532a..145a96812 100644
--- a/lib/librte_eal/common/eal_common_bus.c
+++ b/lib/librte_eal/common/eal_common_bus.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -63,6 +64,11 @@ rte_bus_probe(void)
int ret;
struct rte_bus *bus, *vbus = NULL;
+ if (rte_eal_manual_probe()) {
+ RTE_LOG(DEBUG, EAL, "Manual probing enabled.\n");
+ return rte_dev_probe_devargs_list();
+ }
+
TAILQ_FOREACH(bus, &rte_bus_list, next) {
if (!strcmp(bus->name, "vdev")) {
vbus = bus;
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common/eal_common_dev.c
index 9e4f09d83..f4ce1c56c 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -109,6 +109,47 @@ build_devargs(const char *busname, const char *devname,
}
int
+rte_dev_probe_devargs_list(void)
+{
+ struct rte_device *dev;
+ struct rte_devargs *da;
+ int ret;
+
+ RTE_EAL_DEVARGS_FOREACH(NULL, da) {
+ dev = da->bus->find_device(NULL, cmp_dev_name, da->name);
+ if (dev == NULL) {
+ RTE_LOG(ERR, EAL, "Unable to find device %s on bus
%s\n",
+ da->name, da->bus->name);
+ continue;
+ }
+
+ if (rte_dev_is_probed(dev))
+ continue;
+
+ if (dev->bus->plug == NULL) {
+ RTE_LOG(ERR, EAL, "Manual probing (hotplug) not
supported by bus %s, "
+ "required by device %s\n",
+ dev->bus->name, dev->name);
+ continue;
+ }
+
+ ret = dev->bus->plug(dev);
+ /* Ignore positive return values, they are possibly
+* triggered by blacklisted devices on the PCI bus. Probing
+* should then continue.
+*/
+ if (ret < 0) {
+ RTE_LOG(ERR, EAL, "Driver cannot attach device %s\n",
+
Re: [dpdk-dev] [PATCH 8/8] doc: update octeontx asymmetric features
> > > > Hi Anoob, > > > > > > > > From: Sunila Sahu > > > > > > Update documentation with supported asymmetric features for octeontx > > > > > > Signed-off-by: Anoob Joseph > > > Signed-off-by: Kanaka Durga Kotamarthy > > > Signed-off-by: Sunila Sahu > > > --- > > > doc/guides/cryptodevs/features/octeontx.ini | 6 +- > > > doc/guides/cryptodevs/octeontx.rst | 25 > + > > > 2 files changed, 30 insertions(+), 1 deletion(-) > > > > > > diff --git a/doc/guides/cryptodevs/features/octeontx.ini > > > b/doc/guides/cryptodevs/features/octeontx.ini > > > index 1735b8f..1c036c5 100644 > > > --- a/doc/guides/cryptodevs/features/octeontx.ini > > > +++ b/doc/guides/cryptodevs/features/octeontx.ini > > > @@ -5,11 +5,13 @@ > > > ; > > > [Features] > > > Symmetric crypto = Y > > > +Asymmetric crypto = Y > > > Sym operation chaining = Y > > > HW Accelerated = Y > > > In Place SGL = Y > > > OOP SGL In LB Out = Y > > > OOP SGL In SGL Out = Y > > > +RSA PRIV OP KEY QT = Y > > > > > > ; > > > ; Supported crypto algorithms of 'octeontx' crypto driver. > > > @@ -64,4 +66,6 @@ AES GCM (256) = Y > > > ; > > > ; Supported Asymmetric algorithms of the 'octeontx' crypto driver. > > > ; > > > -[Asymmetric] > > > \ No newline at end of file > > > +[Asymmetric] > > > +RSA= Y > > > +Modular Exponentiation = Y > > > diff --git a/doc/guides/cryptodevs/octeontx.rst > > > b/doc/guides/cryptodevs/octeontx.rst > > > index 1600a56..a26882b 100644 > > > --- a/doc/guides/cryptodevs/octeontx.rst > > > +++ b/doc/guides/cryptodevs/octeontx.rst > > > @@ -53,6 +53,12 @@ AEAD Algorithms > > > > > > * ``RTE_CRYPTO_AEAD_AES_GCM`` > > > > > > +Asymmetric Crypto Algorithms > > > + > > > > Probably you should have some heading to specify Symmetric crypto > Algorithms > > also. > > [Anoob] Do you recommend adding that change also in this patch or should I > submit a separate patch for redesigning that. FYI. For crypto_octeontx2, > following is the list we are adding. Do you suggest a similar change there > also? You can refer to qat.rst. I believe it will not be a big change and is totally relevant in this patchset, so you can have That in this patchset. Yes you should do this in octeontx2 as well. > > The OCTEON TX2 crypto PMD has support for: > > Cipher algorithms: > > * ``RTE_CRYPTO_CIPHER_NULL`` > * ``RTE_CRYPTO_CIPHER_3DES_CBC`` > * ``RTE_CRYPTO_CIPHER_3DES_ECB`` > * ``RTE_CRYPTO_CIPHER_AES_CBC`` > * ``RTE_CRYPTO_CIPHER_AES_CTR`` > * ``RTE_CRYPTO_CIPHER_AES_XTS`` > * ``RTE_CRYPTO_CIPHER_DES_CBC`` > * ``RTE_CRYPTO_CIPHER_KASUMI_F8`` > * ``RTE_CRYPTO_CIPHER_SNOW3G_UEA2`` > * ``RTE_CRYPTO_CIPHER_ZUC_EEA3`` > > Hash algorithms: > > * ``RTE_CRYPTO_AUTH_NULL`` > * ``RTE_CRYPTO_AUTH_AES_GMAC`` > * ``RTE_CRYPTO_AUTH_KASUMI_F9`` > * ``RTE_CRYPTO_AUTH_MD5`` > * ``RTE_CRYPTO_AUTH_MD5_HMAC`` > * ``RTE_CRYPTO_AUTH_SHA1`` > * ``RTE_CRYPTO_AUTH_SHA1_HMAC`` > * ``RTE_CRYPTO_AUTH_SHA224`` > * ``RTE_CRYPTO_AUTH_SHA224_HMAC`` > * ``RTE_CRYPTO_AUTH_SHA256`` > * ``RTE_CRYPTO_AUTH_SHA256_HMAC`` > * ``RTE_CRYPTO_AUTH_SHA384`` > * ``RTE_CRYPTO_AUTH_SHA384_HMAC`` > * ``RTE_CRYPTO_AUTH_SHA512`` > * ``RTE_CRYPTO_AUTH_SHA512_HMAC`` > * ``RTE_CRYPTO_AUTH_SNOW3G_UIA2`` > * ``RTE_CRYPTO_AUTH_ZUC_EIA3`` > > AEAD algorithms: > > * ``RTE_CRYPTO_AEAD_AES_GCM`` > > Asymmetric algorithms: > > * ``RTE_CRYPTO_ASYM_XFORM_RSA`` > * ``RTE_CRYPTO_ASYM_XFORM_MODEX`` > > > > > > + > > > +* ``RTE_CRYPTO_ASYM_XFORM_RSA`` > > > +* ``RTE_CRYPTO_ASYM_XFORM_MODEX`` > > > + > > > Config flags > > > > > > > > > @@ -120,3 +126,22 @@ OCTEON TX crypto PMD. > > > > > > ./build/ipsec-secgw --log-level=8 -c 0xff -- -P -p 0x3 -u 0x2 > > > --config > > > "(1,0,0),(0,0,0)" -f ep1.cfg > > > + > > > +Testing > > > +--- > > > + > > > +The symmetric crypto operations on OCTEON TX crypto PMD may be > verified > > > by running the test > > > +application: > > > + > > > +.. code-block:: console > > > + > > > +./test > > > +RTE>>cryptodev_octeontx_autotest > > > + > > > +The asymmetric crypto operations on OCTEON TX crypto PMD may be > > verified > > > by running the test > > > +application: > > > + > > > +.. code-block:: console > > > + > > > +./test > > > +RTE>>cryptodev_octeontx_asym_autotest > > > -- > > > 2.7.4
Re: [dpdk-dev] [PATCH 2/8] crypto/octeontx: add RSA and modexp asym capabilities
> >
> > Hi Anoob,
> >
> > > const struct rte_cryptodev_capabilities *
> > > -otx_get_capabilities(void)
> > > +otx_get_capabilities(uint64_t flags)
> > > {
> > > - return otx_capabilities;
> > > + if (flags & RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO)
> > > + return otx_asym_capabilities;
> > > + else
> > > + return otx_sym_capabilities;
> > > +
> > > }
> >
> > I believe this will give Asym capabilities always. As the feature flag
> > RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO will always be set, as the flags
> are
> > set in init.
> >
> > It will never go in else.
>
> [Anoob] The flags is set based on the type of underlying device. The crypto
> module on OCTEONTX exposes two kinds of VFs. One which does only
> symmetric and one which does only asymmetric. Both are never supported
> together for a VF, and hence the if...else.
OK probably a comment should be added to avoid this confusion while calling
infos_get.
And add this info in doc as well if not already there.
>
> From the first patch, crypto/octeontx: add device type mailbox routine
>
> switch (cptvf->vftype) {
> case OTX_CPT_VF_TYPE_AE:
> /* Set asymmetric cpt feature flags */
> c_dev->feature_flags =
> RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO |
> RTE_CRYPTODEV_FF_HW_ACCELERATED;
> break;
> case OTX_CPT_VF_TYPE_SE:
> /* Set symmetric cpt feature flags */
> c_dev->feature_flags =
> RTE_CRYPTODEV_FF_SYMMETRIC_CRYPTO |
> RTE_CRYPTODEV_FF_HW_ACCELERATED |
>
> RTE_CRYPTODEV_FF_SYM_OPERATION_CHAINING |
> RTE_CRYPTODEV_FF_IN_PLACE_SGL |
> RTE_CRYPTODEV_FF_OOP_SGL_IN_LB_OUT |
> RTE_CRYPTODEV_FF_OOP_SGL_IN_SGL_OUT;
> break;
>
> Hope this clarifies.
>
> >
> > > diff --git a/drivers/crypto/octeontx/otx_cryptodev_capabilities.h
> > > b/drivers/crypto/octeontx/otx_cryptodev_capabilities.h
> > > index fc62821..439b50e 100644
> > > --- a/drivers/crypto/octeontx/otx_cryptodev_capabilities.h
> > > +++ b/drivers/crypto/octeontx/otx_cryptodev_capabilities.h
> > > @@ -8,10 +8,9 @@
> > > #include
> > >
> > > /*
> > > - * Get capabilities list for the device
> > > - *
> > > + * Get capabilities list for the device, based on device type
> > > */
> > > const struct rte_cryptodev_capabilities *
> > > -otx_get_capabilities(void);
> > > +otx_get_capabilities(uint64_t flags);
> > >
> > > #endif /* _OTX_CRYPTODEV_CAPABILITIES_H_ */ diff --git
> > > a/drivers/crypto/octeontx/otx_cryptodev_ops.c
> > > b/drivers/crypto/octeontx/otx_cryptodev_ops.c
> > > index 88efed3..b59a001 100644
> > > --- a/drivers/crypto/octeontx/otx_cryptodev_ops.c
> > > +++ b/drivers/crypto/octeontx/otx_cryptodev_ops.c
> > > @@ -105,7 +105,7 @@ otx_cpt_dev_info_get(struct rte_cryptodev *dev,
> > > struct rte_cryptodev_info *info)
> > > if (info != NULL) {
> > > info->max_nb_queue_pairs = CPT_NUM_QS_PER_VF;
> > > info->feature_flags = dev->feature_flags;
> > > - info->capabilities = otx_get_capabilities();
> > > + info->capabilities = otx_get_capabilities(info->feature_flags);
> > > info->sym.max_nb_sessions = 0;
> > > info->driver_id = otx_cryptodev_driver_id;
> > > info->min_mbuf_headroom_req =
> > > OTX_CPT_MIN_HEADROOM_REQ;
> > > @@ -635,7 +635,8 @@ otx_cpt_dev_create(struct rte_cryptodev *c_dev)
> > > case OTX_CPT_VF_TYPE_AE:
> > > /* Set asymmetric cpt feature flags */
> > > c_dev->feature_flags =
> > > RTE_CRYPTODEV_FF_ASYMMETRIC_CRYPTO |
> > > - RTE_CRYPTODEV_FF_HW_ACCELERATED;
> > > + RTE_CRYPTODEV_FF_HW_ACCELERATED |
> > > + RTE_CRYPTODEV_FF_RSA_PRIV_OP_KEY_QT;
> > > break;
> > > case OTX_CPT_VF_TYPE_SE:
> > > /* Set symmetric cpt feature flags */
> > > --
> > > 2.7.4
Re: [dpdk-dev] [PATCH] maintainers: add David for main branch
26/09/2019 12:57, David Marchand: > On Thu, Sep 26, 2019 at 12:24 PM Thomas Monjalon wrote: > > > > 26/09/2019 12:12, Ferruh Yigit: > > > David will be co-maintaining the top level tree with Thomas, > > > Welcome and best luck J > > Thanks Ferruh. > > > > > > > Signed-off-by: Ferruh Yigit > > > --- > > > Main Branch > > > M: Thomas Monjalon > > > -M: Ferruh Yigit > > > +M: David Marchand > > > T: git://dpdk.org/dpdk > > > > Acked-by: Thomas Monjalon > > > > Thanks a lot to both of you! > > You should wait before thanking me (expect some phone calls :-)). It seems everybody is OK Applied, thanks
Re: [dpdk-dev] [PATCH] net/null: fix multi-process rx and tx
On 2019/10/02 1:00, Ferruh Yigit wrote:
On 9/29/2019 3:41 AM, Yasufumi Ogawa wrote:
Packet processing in secondary process cannot work because rx_pkt_burst
and tx_pkt_burst in eth_dev are not initialized while probing device.
This patch is to the initialization.
Signed-off-by: Yasufumi Ogawa
---
drivers/net/null/rte_eth_null.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 0c60d241a..5a2010e3e 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -586,6 +586,13 @@ rte_pmd_null_probe(struct rte_vdev_device *dev)
/* TODO: request info from primary to set up Rx and Tx */
eth_dev->dev_ops = &ops;
eth_dev->device = &dev->device;
+ if (packet_copy) {
+ eth_dev->rx_pkt_burst = eth_null_copy_rx;
+ eth_dev->tx_pkt_burst = eth_null_copy_tx;
+ } else {
+ eth_dev->rx_pkt_burst = eth_null_rx;
+ eth_dev->tx_pkt_burst = eth_null_tx;
+ }
rte_eth_dev_probing_finish(eth_dev);
return 0;
}
Reviewed-by: Ferruh Yigit
But this seems the issue for other virtual PMDs too, @Yasufumi, can you please
check others too if you have any bandwidth for it?
Yes. I have also tried to fix other PMDs, and would like to make some
updates for vhost and virtio next if possible.
Yasufumi
I assume this is missing for a long time because there is not easy way to test
them in secondary process, testpmd doesn't support the multi process. cc'ed
testpmd and multi process maintainers, what do you think about adding multi
process support to testpmd?
I tested with "examples/multi_process/symmetric_mp" sample app, it required
fixing with null pmd:
1- Requested offload config was not supported by null pmd
2- promics_enable dev_ops was not implemented in null pmd
We should fix sample app / virtual pmds too so they can work together...
[dpdk-dev] [PATCH] net: re-add qede to meson
qede has been dropped from the drivers/net meson.
Add it again.
Fixes: 9a8864c8b5da ("net/octeontx2: add build and doc infrastructure")
Signed-off-by: David Marchand
---
drivers/net/meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/meson.build b/drivers/net/meson.build
index 513f19b..0170f01 100644
--- a/drivers/net/meson.build
+++ b/drivers/net/meson.build
@@ -37,6 +37,7 @@ drivers = ['af_packet',
'octeontx',
'octeontx2',
'pcap',
+ 'qede',
'ring',
'sfc',
'softnic',
--
1.8.3.1
Re: [dpdk-dev] [PATCH v2 15/30] net/dpaa2: add optional non-prefetch Rx mode
Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH v2 24/30] net/dpaa2: add ptp driver
Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH v2 23/30] net/dpaa2: add dprtc sub-module
Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH v2 30/30] net/dpaa2: add soft parser driver
Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH v2 07/30] net/dpaa: add SG support in Tx for non DPAA buffer
Acked-by: Hemant Agrawal
Re: [dpdk-dev] [PATCH v2 0/5] fix 32-bit meson builds
On Wed, Oct 02, 2019 at 04:11:56PM +0100, Kevin Traynor wrote:
> On 28/05/2019 12:07, Bruce Richardson wrote:
> > This set fixes some issues seen on the automated CI system with building
> > on 32-bit Linux distro's using meson and ninja. The fixes are to disable
> > unsupported parts of the build, and switch the 32-bit builds to always
> > having large file support, so that make and meson are consistent in that
> > regard.
> >
> > V2: add two additional patches to fix clang builds. This allows the
> > test-meson-builds.sh script to run successfully on 32-bit Ubuntu
> > 16.04 systems.
> >
> > Bruce Richardson (5):
> > net/nfp: disable nfp for 32-bit meson builds
> > build: enable large file support on 32-bit
> > build: remove unnecessary large file support defines
> > eal: mark unused function in 32-bit builds
> > build: add libatomic dependency for 32-bit clang compile
> >
>
> Hi Bruce, Intel validation team reported failures with some 32-bit
> builds with meson on 18.11.3-rc1. I've tested with these patches and it
> fixes the problems.
>
> I also took d23e141ffa52 ("build: set RTE_ARCH_64 based on pointer
> size"), to avoid rebasing the other patches to check 'void *' size
> multiple times.
>
> Any objection to applying for 18.11 branch?
>
> Kevin.
>
Nope, no objections.
Thanks.
Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: update pkttest requirements
> > > > Update Scapy version requirement from 2.4.3rc1 to 2.4.3, which has been > > used because 2.4.2 had a bug which made this version unable to install. Is this 2.4.2 or 2.4.3?? > > Accept future versions of Scapy too. > > > > Signed-off-by: Marcin Smoczynski > > Acked-by: Konstantin Ananyev >
Re: [dpdk-dev] [PATCH] net: re-add qede to meson
On Thu, Oct 3, 2019 at 1:48 PM David Marchand wrote:
>
> qede has been dropped from the drivers/net meson.
> Add it again.
>
> Fixes: 9a8864c8b5da ("net/octeontx2: add build and doc infrastructure")
>
> Signed-off-by: David Marchand
Reviewed-by: Jerin Jacob
> ---
> drivers/net/meson.build | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/meson.build b/drivers/net/meson.build
> index 513f19b..0170f01 100644
> --- a/drivers/net/meson.build
> +++ b/drivers/net/meson.build
> @@ -37,6 +37,7 @@ drivers = ['af_packet',
> 'octeontx',
> 'octeontx2',
> 'pcap',
> + 'qede',
> 'ring',
> 'sfc',
> 'softnic',
> --
> 1.8.3.1
>
Re: [dpdk-dev] [PATCH] bus/fslmc: fix for resource leak coverity issue
Acked-by: Sachin Saxena
regards,
Sachin Saxena
> -Original Message-
> From: Agalya Babu RadhaKrishnan
> Sent: Tuesday, September 10, 2019 1:01 PM
> To: dev@dpdk.org
> Cc: reshma.pat...@intel.com; Hemant Agrawal
> ; Sachin Saxena ;
> jananeex.m.parthasara...@intel.com; Agalya Babu RadhaKrishnan
> ; sta...@dpdk.org
> Subject: [PATCH] bus/fslmc: fix for resource leak coverity issue
> Importance: High
>
> From: Agalya Babu RadhaKrishnan
>
> 1 issue caught by 344967
> Leaked_storage: Variable sep going out of scope leaks the storage it points
> to.
>
> When 'sep' is not null and sep_exist is 0, 'sep' is freed before going out of
> scope of the function irrespective of 'addr' exists or not.
>
> Coverity Issue: 344967
> Fixes: e67a61614d0b ("bus/fslmc: support device iteration")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Agalya Babu RadhaKrishnan
>
> ---
> drivers/bus/fslmc/fslmc_bus.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bus/fslmc/fslmc_bus.c b/drivers/bus/fslmc/fslmc_bus.c
> index a2f482516..60c34098c 100644
> --- a/drivers/bus/fslmc/fslmc_bus.c
> +++ b/drivers/bus/fslmc/fslmc_bus.c
> @@ -291,10 +291,13 @@ rte_fslmc_parse(const char *name, void *addr)
> goto err_out;
> }
>
> - if (addr)
> + if (addr) {
> strcpy(addr, sep);
> + if (!sep_exists && sep)
> + free(sep);
> + return 0;
> + }
>
> - return 0;
> err_out:
> if (!sep_exists && sep)
> free(sep);
> --
> 2.14.1
Re: [dpdk-dev] [PATCH] bus/fslmc: fix for resource leak coverity issue
> -Original Message-
> From: Babu Radhakrishnan, AgalyaX
>
> Sent: Tuesday, September 10, 2019 1:11 PM
> To: dev@dpdk.org
> Cc: Pattan, Reshma ; Hemant Agrawal
> ; Sachin Saxena ;
> Parthasarathy, JananeeX M ;
> sta...@dpdk.org
> Subject: RE: [PATCH] bus/fslmc: fix for resource leak coverity issue
> Importance: High
>
> Hi,
>
> > -Original Message-
> > From: Babu Radhakrishnan, AgalyaX
> > Sent: Tuesday, September 10, 2019 1:01 PM
> > To: dev@dpdk.org
> > Cc: Pattan, Reshma ;
> hemant.agra...@nxp.com;
> > sachin.sax...@nxp.com; Parthasarathy, JananeeX M
> > ; Babu Radhakrishnan, AgalyaX
> > ; sta...@dpdk.org
> > Subject: [PATCH] bus/fslmc: fix for resource leak coverity issue
> >
> > From: Agalya Babu RadhaKrishnan
>
> >
> > 1 issue caught by 344967
> > Leaked_storage: Variable sep going out of scope leaks the storage it
> > points to.
> >
> > When 'sep' is not null and sep_exist is 0, 'sep' is freed before going
> > out of scope of the function irrespective of 'addr' exists or not.
> >
> > Coverity Issue: 344967
> > Fixes: e67a61614d0b ("bus/fslmc: support device iteration")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Agalya Babu RadhaKrishnan
> >
> > ---
>
> if (strncmp("dpni", sep, 4) &&
> strncmp("dpseci", sep, 6) &&
> strncmp("dpcon", sep, 5) &
> .
>
> We think validation of device name is done using AND operator instead it
> should be done by OR operator.
> Please confirm
[Sachin Saxena] The purpose of this logic to confirm that one of the device
name should match to supported list and as soon as one strncmp() matches the
string it will return 0 and the control comes out of IF condition.
So, existing logic is correct.
Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: update pkttest requirements
I've used 2.4.3rc1 in the first place because 2.4.2 which was the latest version at that time had a bug which made it unable to install. 2.4.3rc1 worked fine. 2.4.3 has been released recently so we are moving from pre-release RC to stable version. Thanks to ">=" in the requirement we won't need to update it in the future. > -Original Message- > From: Akhil Goyal [mailto:akhil.go...@nxp.com] > Sent: Thursday, October 3, 2019 10:30 AM > To: Ananyev, Konstantin ; Smoczynski, > MarcinX ; Iremonger, Bernard > > Cc: dev@dpdk.org > Subject: RE: [PATCH] examples/ipsec-secgw: update pkttest requirements > > > > > > > Update Scapy version requirement from 2.4.3rc1 to 2.4.3, which has > > > been used because 2.4.2 had a bug which made this version unable to > install. > > Is this 2.4.2 or 2.4.3?? > > > > Accept future versions of Scapy too. > > > > > > Signed-off-by: Marcin Smoczynski > > > > Acked-by: Konstantin Ananyev > >
Re: [dpdk-dev] [PATCH v3 3/3] test/lpm: add RCU integration performance tests
On Wed, Oct 02, 2019 at 09:02:03AM -0400, Aaron Conole wrote: > Honnappa Nagarahalli writes: > > > Add performance tests for RCU integration. The performance > > difference with and without RCU integration is very small > > (~1% to ~2%) on both Arm and x86 platforms. > > > > Signed-off-by: Honnappa Nagarahalli > > Reviewed-by: Gavin Hu > > Reviewed-by: Ruifeng Wang > > --- > > I see the following: > > lib/meson.build:89:5: ERROR: Problem encountered: Missing dependency rcu > for library rte_lpm > > Maybe there's something wrong with the environment? This isn't the > first time I've seen a dependency detection problem with meson. > It probably not a detection problem, more likely the rcu library is not being built for some reason. If you apply patch [1] the meson run will print out each library and the dependency object generated for it as each is processed. That should help debug issues like this. /Bruce [1] http://patches.dpdk.org/patch/59470/
Re: [dpdk-dev] [PATCH] devtools: reset compilation flags for each target
On Wed, Oct 02, 2019 at 06:55:47PM +0200, David Marchand wrote:
> Same idea than overriding PATH and PKG_CONFIG_PATH, it can be quite
> useful to override compilation flags like CFLAGS, CPPFLAGS and LDFLAGS
> for cross compilation or libraries that won't provide a pkg-config file.
>
> Fixes: 272236741258 ("devtools: load target-specific compilation environment")
>
> Signed-off-by: David Marchand
> ---
No strong objection to this change, but for meson the better way to handle
this may be to put these flags into the cross-file used for the build. By
explicitly passing CFLAGS etc. to the build, I'm not sure what the
behaviour is with regards to passing those flags to cross-built vs
native-built components. For a cross-compile, not all CFLAGS should be
passed to the build of pmdinfogen, for instance.
/Bruce
Re: [dpdk-dev] [PATCH v2 04/30] bus/dpaa: decouple fq portal alloc and init
> -Original Message-
> From: Ferruh Yigit
> Sent: Thursday, October 3, 2019 1:23 PM
> To: Sachin Saxena ; dev@dpdk.org
> Cc: tho...@monjalon.net; Nipun Gupta
> Subject: Re: [dpdk-dev] [PATCH v2 04/30] bus/dpaa: decouple fq portal alloc
> and
> init
>
> On 8/29/2019 11:27 AM, Sachin Saxena wrote:
> > From: Nipun Gupta
> >
> > The decoupling of FQ portal allocation is required as a
> > pre-requisite to support Rx interrupts as we need to have
> > event FD's at portal allocation i.e. before the
> > initialization of the Frame Queues.
> > This change will help us get the event fd once the portals
> > have been allocated for static FQ's.
> >
> > Signed-off-by: Nipun Gupta
>
> <...>
>
> > @@ -123,3 +123,10 @@ DPDK_19.05 {
> >
> > local: *;
> > } DPDK_18.11;
> > +
> > +DPDK_19.11 {
> > + global:
> > + fsl_qman_fq_portal_create;
> > +
> > + local: *;
> > +} DPDK_19.05;
>
> "local:" tag doesn't need to be in each block, having only in the first one is
> enough, I can fix while merging.
Thank you !!
Re: [dpdk-dev] [PATCH v6 0/6] examples/ioat: sample app on ioat driver usage
On Mon, Sep 30, 2019 at 09:50:28AM +0200, Marcin Baran wrote: > A new sample app demonstrating use of driver for CBDMA. > The app receives packets, performs software or hardware > copy, changes packets' MAC addresses (if enabled) and > forwards them. The patch includes sample application as > well as it's guide. > > v6: > - rearrange 'ioat_tx_port()' to remove unnecessary code > - improve documentation > - format patches for better readability > > v5: > - change dependency name from 'pmd_ioat' to 'rawdev_ioat' >fixing build errors (branch diverged from master) > > v4: > - fix meson build support check > > v3: > - add check for meson build whether IOAT is supported > > v2: > - change printing total stats to be deltas > - update documentation > - fix 1 thread/sw copy/multiple Rx queues packet dropping > - divide patch into several presenting functional change > > > Marcin Baran (4): > examples/ioat: add software copy support > examples/ioat: add rawdev copy mode support > examples/ioat: add stats printing for each port > doc/guides/: provide IOAT sample app guide > > Pawel Modrak (2): > examples/ioat: create sample app on ioat driver usage > examples/ioat: add two threads configuration > Series-acked-by: Bruce Richardson
Re: [dpdk-dev] [PATCH] devtools: reset compilation flags for each target
On Thu, Oct 3, 2019 at 11:21 AM Bruce Richardson
wrote:
>
> On Wed, Oct 02, 2019 at 06:55:47PM +0200, David Marchand wrote:
> > Same idea than overriding PATH and PKG_CONFIG_PATH, it can be quite
> > useful to override compilation flags like CFLAGS, CPPFLAGS and LDFLAGS
> > for cross compilation or libraries that won't provide a pkg-config file.
> >
> > Fixes: 272236741258 ("devtools: load target-specific compilation
> > environment")
> >
> > Signed-off-by: David Marchand
> > ---
>
> No strong objection to this change, but for meson the better way to handle
> this may be to put these flags into the cross-file used for the build. By
> explicitly passing CFLAGS etc. to the build, I'm not sure what the
> behaviour is with regards to passing those flags to cross-built vs
> native-built components. For a cross-compile, not all CFLAGS should be
> passed to the build of pmdinfogen, for instance.
Ok, I see.
Then the only usecase would be for locally built libraries that meson
can't find by itself.
A bit hackish too.
Mm, is there a way to tell meson "library X (CFLAGS, LDFLAGS) is (xx, yy)" ?
I could write some local .pc files and override PKG_CONFIG_PATH...
Any better idea ?
--
David Marchand
Re: [dpdk-dev] [PATCH] eventdev: flag to identify same destined packets enqueue
On Thu, Oct 3, 2019 at 12:15 PM Hemant Agrawal wrote: > > Hi Nikhil, > > > -Original Message- > > From: Rao, Nikhil > > Sent: Thursday, October 3, 2019 11:43 AM > > > > > > On Wed, Oct 2, 2019 at 8:38 AM Hemant Agrawal > > > > > wrote: > > > > > > > > Hi Jerin, > > > > > > Hi Hemant, > > > > > > > > > > > > I understand your concern that this shall not be valid on a general > > cases. > > > > > > > > > > > > There are certain use-case (NXP internal) of DPDK event which > > > > > > have separate event ports/cores dedicated for certain tasks - > > > > > > and can use the burst functionality for performance according to > > > > > > the event ports which are used. Not having this at runtime will > > > > > > limit the flexibility for such > > > > > applications. > > > > > > > > > > If it is specific to NXP internal use case then no more comments > > > > > on dynamic vs static. > > > > > > > > > > @ Nikhil Rao any comments. > > Hi Jerin, Hemant, > > > > Looks like we are trying to give a generic wrapper for the NXP internal use > > case, do we really need to solve that problem ? > > [Hemant] no, that is not the case. > > On the argument sake, eth TX adapter is also Marvel/Cavium specific - the > idea was to reach consensus and come with generic APIs. NXP does not need > ethTX adapter. > However, here, we are trying to avoid too many code paths for the > applications, so that it becomes easy for the application writer. > > - We do support RX burst, so TX burst should be supported. I remember Marvel > do not support RX burst, but we added it as NXP HW support it. Intel SW can > also support it. > - See existing L3 fwd application, how the burst accumulation is being done > on per queue basis. > - Why the application is not sending all the packets and letting driver do > the buffering on per queue basis? > - The reason is that applications knows which packets can be buffered, which > need to be sent immediately. Only application can control the time out and > different setting for burst mode. The burst segregation logic can not be > pushed into the driver for all these various reasons. > > I am not in favor of new APIs and more code paths for the applications. It > will not be favorable for the adaptability of the eventdev widely. > We are only asking for one additional argument to indicate whether > application has sent the current burst targeted for single FQ or it has mixed > data. It can be set as 0 for the application like l2fwd, who are not doing > buffering. However application like l3fwd, who do buffering, will definitely > use it. > > Note that it is always costly for the driver to internally sort/buffer the > packets from the buffer. After going through l3fwd code, I understand, you want to reuse segregation logic of send_packets_multi(). So, this makes sense to me. > > > > > > > > > > > > > > > > One option could be to incorporate NXP internal use case will be > > > > > introducing a new API, parallel to > > > > > rte_event_eth_tx_adapter_enqueue as > > > > > rte_event_eth_tx_adapter_enqueue_same_dest() > > > > > or something. > > > > > > > > > > Two advantage: > > > > > # Not a major ABI breakage. Only need to add new fast-path > > > > > function in rte_eventdev. > > > > > # Even though we add 'zero' in API all the time, the Compiler > > > > > prologue needs to push to stack or move the value to argument > > > > > register as there is function pointer indirection. so new API will > > > > > have zero performance impact for normal cases. > > > > > > > > > > Not sure about minor ABI breakage in rte_eventdev(adding a new > > > > > fastpath function). If everyone is OK as the exception for 19.11 > > > > > then we can introduce a new API. > > > > > > > > [Hemant] There are already too many APIs and mode in eventdev. My > > > suggestion is to minimize the new APIs. Else writing generic > > > applications will be really difficult and it will not be easy to adapt by > > > the > > application developers. > > > > In this particular case, it is better for NXP to go with direct eth > > > > enque mode > > > rather than TX adapter. Note that crypto adapter already provide that > > mode. > > > However we are trying to adjust so that applications do not become > > complex. > > > > > > Why? If you think direct queue model as use case if you might as well > > > write "ethdev" driver and internally use atomic schedule type. > > > > > > > > > > In the existing code also we have two modes in the application to > > > > send the > > > packets out - one is 'rte_event_enqueue_burst' and other is > > > 'rte_event_eth_tx_adapter_enqueue'. > > > > It is still cumbersome for the application to maintain separate > > > > modes. This > > > increases when crypto/timer is also being used in event mode. > > > > > > I think, we have two things here > > > a) specialized API for specific work like > > > rte_event_enqueue_new_burst() or > > rte_event_enqueue_forward_burst() vs > > > generic rte_event_en
Re: [dpdk-dev] [PATCH v5 00/10] example/l2fwd-event: introduce l2fwd-event example
On Thu, Oct 3, 2019 at 2:28 AM wrote: > > From: Pavan Nikhilesh > > This patchset adds a new application to demonstrate the usage of event > mode. The poll mode is also available to help with the transition. > > The following new command line parameters are added: > --mode: Dictates the mode of operation either poll or event. > --eventq_sync: Dictates event synchronization mode either atomic or > ordered. > > Based on event device capability the configuration is done as follows: > - A single event device is enabled. > - The number of event ports is equal to the number of worker > cores enabled in the core mask. Additional event ports might > be configured based on Rx/Tx adapter capability. > - The number of event queues is equal to the number of ethernet > ports. If Tx adapter doesn't have internal port capability then > an additional single link event queue is used to enqueue events > to Tx adapter. > - Each event port is linked to all existing event queues. > - Dedicated Rx/Tx adapters for each Ethernet port. > > v5 Changes: > - Redo poll mode datapath by removing all the static globals. > - Fix event queue configuration when required queues are not available. > - Fix Rx/Tx adapter creation based on portmask. > - Update release notes. > - Unroll macro used to generate event mode functions. Adding all eventdev maintainers. I have some minor comments on Documentation. Other than that, The series looks good to me in general. Anyone else planning to review this code. If yes, We will wait for merging this patch after RC1. If no, then we can merge in RC1 if no objection.
Re: [dpdk-dev] [PATCH] devtools: reset compilation flags for each target
On Thu, Oct 03, 2019 at 12:08:30PM +0200, David Marchand wrote:
> On Thu, Oct 3, 2019 at 11:21 AM Bruce Richardson
> wrote:
> >
> > On Wed, Oct 02, 2019 at 06:55:47PM +0200, David Marchand wrote:
> > > Same idea than overriding PATH and PKG_CONFIG_PATH, it can be quite
> > > useful to override compilation flags like CFLAGS, CPPFLAGS and LDFLAGS
> > > for cross compilation or libraries that won't provide a pkg-config file.
> > >
> > > Fixes: 272236741258 ("devtools: load target-specific compilation
> > > environment")
> > >
> > > Signed-off-by: David Marchand
> > > ---
> >
> > No strong objection to this change, but for meson the better way to handle
> > this may be to put these flags into the cross-file used for the build. By
> > explicitly passing CFLAGS etc. to the build, I'm not sure what the
> > behaviour is with regards to passing those flags to cross-built vs
> > native-built components. For a cross-compile, not all CFLAGS should be
> > passed to the build of pmdinfogen, for instance.
>
> Ok, I see.
>
> Then the only usecase would be for locally built libraries that meson
> can't find by itself.
> A bit hackish too.
>
> Mm, is there a way to tell meson "library X (CFLAGS, LDFLAGS) is (xx, yy)" ?
> I could write some local .pc files and override PKG_CONFIG_PATH...
> Any better idea ?
>
If the scheme here using CFLAGS/LDFLAGS works just go with it for now.
Ideally for cross compiles, we could consider taking the stored
cross-compile files and copying them to /tmp and then adding the additional
flags there. However, for just passing flags to help find library X or Y,
its probably not worth doing, so let's keep it simple until we need
something more powerful. I was just pointing out that this could cause
issues in the future if we do start using it for something more fancy...
Re: [dpdk-dev] [PATCH 8/9] event/opdl: remove commented out code
On 01 Oct 14:04, Kevin Traynor wrote:
> Some variables are commented out. Remove them.
>
> Fixes: d548ef513cd7 ("event/opdl: add unit tests")
> Cc: liang.j...@intel.com
> Cc: sta...@dpdk.org
>
> Signed-off-by: Kevin Traynor
> ---
> drivers/event/opdl/opdl_test.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/event/opdl/opdl_test.c b/drivers/event/opdl/opdl_test.c
> index 5868ec1be..e7a32fbd3 100644
> --- a/drivers/event/opdl/opdl_test.c
> +++ b/drivers/event/opdl/opdl_test.c
> @@ -696,7 +696,4 @@ static int
> single_link(struct test *t)
> {
> - /* const uint8_t rx_port = 0; */
> - /* const uint8_t w1_port = 1; */
> - /* const uint8_t w3_port = 3; */
> const uint8_t tx_port = 2;
> int err;
> --
> 2.21.0
>
Acked-by: Liang Ma
[dpdk-dev] DPDK Release Status Meeting 3/10/2019
Minutes 3 October 2019 -- Agenda: * Release Dates * Subtrees * OvS * Opens Participants: * Debian/Microsoft * Intel * Marvell * Mellanox * NXP * Red Hat Release Dates - * v19.11 dates: * Integration/Merge/RC1 date pushed to *Wednesday 23 October* * Sub-trees needs to be ready on *Monday 21 October* * Release pushed to *Friday 22 November* * There is a PRC holiday on October 1-7 * Proposed dates for 20.02 release on the mail list, please comment https://mails.dpdk.org/archives/dev/2019-September/143311.html These dates may affected from the 19.11 delays, please review again. Subtrees * main * David will be co-maintaining the main branch * Thomas start merging today, need 2-3 weeks * next-net * ~150 patches in backlog, some may be pushed to rc2 * It will be good if we can do an early merge to master branch this week * next-net-crypto * Two new PMDs, nitrox one is almost ready * changes requested for 'octeontx2' * Some Intel patches, 'qat' ones requires review * ipsec patches review today/tomorrow, planning to merge next week * There are some crypto change proposal not ready yet * next-net-virtio * Pulled to next-net previous week * Reviews going on, some will be merged tomorrow * Maxime's patch requires new revision * Flavio's vhost patch will be reviewed by Maxime, it is required by OvS * next-net-intel * More patches to merge, PRC team is on holiday * LTS * v18.11.3-rc1 is under test * Intel reported errors all fixed locally by Kevin * Will create an -rc2 * More test from more companies is welcome * Microsoft investigation performance issue * Target release date is pushed to 14 October * v17.11.7 released * http://mails.dpdk.org/archives/announce/2019-September/000278.html * A last release 17.11.8 will be done with best effort * https://mails.dpdk.org/archives/web/2019-September/001205.html OvS --- * Started to test 18.11.3-rc1 * For TSO support, DPDK patch has been sent, review going on * https://patches.dpdk.org/patch/60373/ * 'dpdk_latest' rebased on 'master' Open * The time of the meeting is not good for the US timezone, we talked about changing the time of the meeting but not had enough time to discuss it. If you have any preferences, please comment. DPDK Release Status Meetings The DPDK Release Status Meeting is intended for DPDK Committers to discuss the status of the master tree and sub-trees, and for project managers to track progress or milestone dates. The meeting occurs on Thursdays at 8:30 UTC. If you wish to attend just send an email to "John McNamara " for the invite.
Re: [dpdk-dev] [PATCH v2 00/30] Enhancements and fixes in NXP dpaax drivers and fsl-mc bus
On 8/29/2019 11:27 AM, Sachin Saxena wrote: > This patch set adds following enhancements: > 1. IEEE1588 support in net/dpaa2 > 2. Interrupt support in net/dpaa > 3. Support multi vfio group in fsl-mc bus > 4. Taildrop support on frame count basis > 5. Soft parser driver in net/dpaa2 > 6. Enhanced debug information > > --- > v2 Change-log: > * Fixed compilation break with gcc-4.8 on x86 platform > > Hemant Agrawal (14): > bus/dpaa: fix DPAA SEC blacklist case > net/dpaa: improve the Rx offload debug message > net/dpaa: reduce debug messages > net/dpaa2: improve the Rx offload debug message > common/dpaax: reduce debug mesages > mempool/dpaa: reduce debug messages > net/dpaa2: realign Rx offload support types > net/dpaa2: enable Rx offload for timestamp > net/dpaa2: support L2 payload based RSS distribution > net/dpaa2: add taildrop support on frame count basis > net/dpaa2: add cgr counters in xtra stats > net/dpaa2: add support for config max Rx length in HW > net/dpaa2: support dpdmux classification on eth type > bus/fslmc: support multi vfio group > > Nipun Gupta (6): > bus/dpaa: remove un-necessary thread affinity > bus/dpaa: decouple fq portal alloc and init > net/dpaa: support Rx interrupt handler > net/dpaa: support for Rx interrupt enable and disable > net/dpaa: add SG support in Tx for non DPAA buffer > net/dpaa2: add optional non-prefetch Rx mode > > Priyanka Jain (4): > net/dpaa2: add Tx confirmation mode support > net/dpaa2: add timestamp support > net/dpaa2: add dprtc sub-module > net/dpaa2: add ptp driver > > Sachin Saxena (1): > net/dpaa2: use LFQIDs in Tx instead of qdid > > Shreyansh Jain (3): > bus/fslmc: update PA-VA dpaax library only in PA mode > bus/fslmc: check for Dma map in primary process only > net/dpaa2: support separate MC portal per process > > Sunil Kumar Kori (2): > net/dpaa2: add support for soft parser in MC > net/dpaa2: add soft parser driver Series applied to dpdk-next-net/master, thanks.
[dpdk-dev] [PATCH v9 2/3] ethdev: extend RSS offload types
This patch reserves several bits as input set selection from the
high end of the 64 bits. It is combined with exisiting ETH_RSS_*
to represent RSS types.
Signed-off-by: Simei Su
Reviewed-by: Qi Zhang
Acked-by: Ori Kam
---
lib/librte_ethdev/rte_ethdev.c | 11 +++
lib/librte_ethdev/rte_ethdev.h | 14 ++
2 files changed, 25 insertions(+)
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index af82360..e483098 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -3112,6 +3112,17 @@ struct rte_eth_dev *
if (ret != 0)
return ret;
+ /* simplified the SRC/DST_ONLY RSS offload modificaiton */
+ if ((rss_conf->rss_hf & ETH_RSS_L3_SRC_ONLY) &&
+ (rss_conf->rss_hf & ETH_RSS_L3_DST_ONLY))
+ rss_conf->rss_hf &=
+ ~(ETH_RSS_L3_SRC_ONLY | ETH_RSS_L3_DST_ONLY);
+
+ if ((rss_conf->rss_hf & ETH_RSS_L4_SRC_ONLY) &&
+ (rss_conf->rss_hf & ETH_RSS_L4_DST_ONLY))
+ rss_conf->rss_hf &=
+ ~(ETH_RSS_L4_SRC_ONLY | ETH_RSS_L4_DST_ONLY);
+
dev = &rte_eth_devices[port_id];
if ((dev_info.flow_type_rss_offloads | rss_conf->rss_hf) !=
dev_info.flow_type_rss_offloads) {
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index 7722f70..6d61b84 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -505,6 +505,20 @@ struct rte_eth_rss_conf {
#define ETH_RSS_GENEVE (1ULL << 20)
#define ETH_RSS_NVGRE (1ULL << 21)
+/*
+ * We use the following macros to combine with above ETH_RSS_* for
+ * more specific input set selection. These bits are defined starting
+ * from the high end of the 64 bits.
+ * Note: If we use above ETH_RSS_* without SRC/DST_ONLY, it represents
+ * both SRC and DST are taken into account. If SRC_ONLY and DST_ONLY of
+ * the same level be used simultaneously, it is the same case as none of
+ * them are added.
+ */
+#define ETH_RSS_L3_SRC_ONLY(1ULL << 63)
+#define ETH_RSS_L3_DST_ONLY(1ULL << 62)
+#define ETH_RSS_L4_SRC_ONLY(1ULL << 61)
+#define ETH_RSS_L4_DST_ONLY(1ULL << 60)
+
#define ETH_RSS_IP ( \
ETH_RSS_IPV4 | \
ETH_RSS_FRAG_IPV4 | \
--
1.8.3.1
[dpdk-dev] [PATCH v9 3/3] app/testpmd: add RSS offload types extending support
This patch adds cmdline support for extended rss types configuration.
Signed-off-by: Simei Su
Reviewed-by: Qi Zhang
---
app/test-pmd/cmdline.c | 18 +++---
app/test-pmd/config.c | 4
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index def471d..f5c0cde 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -2189,7 +2189,9 @@ struct cmd_config_rss {
if (!strcmp(res->value, "all"))
rss_conf.rss_hf = ETH_RSS_IP | ETH_RSS_TCP |
ETH_RSS_UDP | ETH_RSS_SCTP |
- ETH_RSS_L2_PAYLOAD;
+ ETH_RSS_L2_PAYLOAD |
+ ETH_RSS_L3_SRC_ONLY | ETH_RSS_L3_DST_ONLY |
+ ETH_RSS_L4_SRC_ONLY | ETH_RSS_L4_DST_ONLY;
else if (!strcmp(res->value, "ip"))
rss_conf.rss_hf = ETH_RSS_IP;
else if (!strcmp(res->value, "udp"))
@@ -2208,6 +2210,14 @@ struct cmd_config_rss {
rss_conf.rss_hf = ETH_RSS_GENEVE;
else if (!strcmp(res->value, "nvgre"))
rss_conf.rss_hf = ETH_RSS_NVGRE;
+ else if (!strcmp(res->value, "l3-src-only"))
+ rss_conf.rss_hf = ETH_RSS_L3_SRC_ONLY;
+ else if (!strcmp(res->value, "l3-dst-only"))
+ rss_conf.rss_hf = ETH_RSS_L3_DST_ONLY;
+ else if (!strcmp(res->value, "l4-src-only"))
+ rss_conf.rss_hf = ETH_RSS_L4_SRC_ONLY;
+ else if (!strcmp(res->value, "l4-dst-only"))
+ rss_conf.rss_hf = ETH_RSS_L4_DST_ONLY;
else if (!strcmp(res->value, "none"))
rss_conf.rss_hf = 0;
else if (!strcmp(res->value, "default"))
@@ -2375,7 +2385,8 @@ struct cmd_config_rss_hash_key {
"ipv4#ipv4-frag#ipv4-tcp#ipv4-udp#ipv4-sctp#"
"ipv4-other#ipv6#ipv6-frag#ipv6-tcp#ipv6-udp#"
"ipv6-sctp#ipv6-other#l2-payload#ipv6-ex#"
-"ipv6-tcp-ex#ipv6-udp-ex");
+"ipv6-tcp-ex#ipv6-udp-ex#"
+
"l3-src-only#l3-dst-only#l4-src-only#l4-dst-only");
cmdline_parse_token_string_t cmd_config_rss_hash_key_value =
TOKEN_STRING_INITIALIZER(struct cmd_config_rss_hash_key, key, NULL);
@@ -2385,7 +2396,8 @@ struct cmd_config_rss_hash_key {
.help_str = "port config rss-hash-key "
"ipv4|ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|"
"ipv6|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|"
- "l2-payload|ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex "
+ "l2-payload|ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex|"
+ "l3-src-only|l3-dst-only|l4-src-only|l4-dst-only "
"",
.tokens = {
(void *)&cmd_config_rss_hash_key_port,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index a3b6cbd..5022d42 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -103,6 +103,10 @@
{ "tcp", ETH_RSS_TCP },
{ "sctp", ETH_RSS_SCTP },
{ "tunnel", ETH_RSS_TUNNEL },
+ { "l3-src-only", ETH_RSS_L3_SRC_ONLY },
+ { "l3-dst-only", ETH_RSS_L3_DST_ONLY },
+ { "l4-src-only", ETH_RSS_L4_SRC_ONLY },
+ { "l4-dst-only", ETH_RSS_L4_DST_ONLY },
{ NULL, 0 },
};
--
1.8.3.1
[dpdk-dev] [PATCH v9 0/3] extend RSS offload types
[PATCH v9 1/3] ethdev: decouple flow types and RSS offload types. [PATCH v9 2/3] ethdev: add several bits for extending rss offload types. [PATCH v9 3/3] app/testpmd: add cmdline support for extending rss types. v9: * Fix code style. * Delete duplicate logic in rte_eth_dev_configure(). v8: * Add to check the simultaneous use of SRC/DST_ONLY of the same level in rte_eth_dev_rss_hash_update() and rte_eth_dev_configure(). * Update code comments. v7: * Supplement related configuration for new flag in app/test-pmd/cmdline.c. v6: * Add the new flag in app/test-pmd/cmdline.c. v5: * Update code comments. v4: * Divide one patch into two patches. * Delete ETH_RSS_L2_SRC/DST_ONLY. v3: * Update code comments and code style. v2: * Update code comments. Simei Su (3): ethdev: decouple flow types and RSS offload types ethdev: extend RSS offload types app/testpmd: add RSS offload types extending support app/test-pmd/cmdline.c | 18 ++-- app/test-pmd/config.c | 4 +++ lib/librte_ethdev/rte_ethdev.c | 11 lib/librte_ethdev/rte_ethdev.h | 63 +- 4 files changed, 67 insertions(+), 29 deletions(-) -- 1.8.3.1
[dpdk-dev] [PATCH v9 1/3] ethdev: decouple flow types and RSS offload types
This patch decouples RTE_ETH_FLOW_* and ETH_RSS_*. The former defines
flow types and the latter defines RSS offload types.
Signed-off-by: Simei Su
Reviewed-by: Qi Zhang
Acked-by: Ori Kam
Acked-by: Andrew Rybchenko
---
lib/librte_ethdev/rte_ethdev.h | 49 --
1 file changed, 23 insertions(+), 26 deletions(-)
diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h
index d937fb4..7722f70 100644
--- a/lib/librte_ethdev/rte_ethdev.h
+++ b/lib/librte_ethdev/rte_ethdev.h
@@ -453,7 +453,6 @@ struct rte_eth_rss_conf {
* possible, and exclusively. For example, if a packet is identified as
* 'RTE_ETH_FLOW_NONFRAG_IPV4_TCP', it will not be any of other flow types,
* though it is an actual IPV4 packet.
- * Note that the flow types are used to define RSS offload types.
*/
#define RTE_ETH_FLOW_UNKNOWN 0
#define RTE_ETH_FLOW_RAW 1
@@ -482,31 +481,29 @@ struct rte_eth_rss_conf {
#define RTE_ETH_FLOW_MAX23
/*
- * The RSS offload types are defined based on flow types.
- * Different NIC hardware may support different RSS offload
- * types. The supported flow types or RSS offload types can be queried by
- * rte_eth_dev_info_get().
- */
-#define ETH_RSS_IPV4 (1ULL << RTE_ETH_FLOW_IPV4)
-#define ETH_RSS_FRAG_IPV4 (1ULL << RTE_ETH_FLOW_FRAG_IPV4)
-#define ETH_RSS_NONFRAG_IPV4_TCP (1ULL << RTE_ETH_FLOW_NONFRAG_IPV4_TCP)
-#define ETH_RSS_NONFRAG_IPV4_UDP (1ULL << RTE_ETH_FLOW_NONFRAG_IPV4_UDP)
-#define ETH_RSS_NONFRAG_IPV4_SCTP (1ULL << RTE_ETH_FLOW_NONFRAG_IPV4_SCTP)
-#define ETH_RSS_NONFRAG_IPV4_OTHER (1ULL << RTE_ETH_FLOW_NONFRAG_IPV4_OTHER)
-#define ETH_RSS_IPV6 (1ULL << RTE_ETH_FLOW_IPV6)
-#define ETH_RSS_FRAG_IPV6 (1ULL << RTE_ETH_FLOW_FRAG_IPV6)
-#define ETH_RSS_NONFRAG_IPV6_TCP (1ULL << RTE_ETH_FLOW_NONFRAG_IPV6_TCP)
-#define ETH_RSS_NONFRAG_IPV6_UDP (1ULL << RTE_ETH_FLOW_NONFRAG_IPV6_UDP)
-#define ETH_RSS_NONFRAG_IPV6_SCTP (1ULL << RTE_ETH_FLOW_NONFRAG_IPV6_SCTP)
-#define ETH_RSS_NONFRAG_IPV6_OTHER (1ULL << RTE_ETH_FLOW_NONFRAG_IPV6_OTHER)
-#define ETH_RSS_L2_PAYLOAD (1ULL << RTE_ETH_FLOW_L2_PAYLOAD)
-#define ETH_RSS_IPV6_EX(1ULL << RTE_ETH_FLOW_IPV6_EX)
-#define ETH_RSS_IPV6_TCP_EX(1ULL << RTE_ETH_FLOW_IPV6_TCP_EX)
-#define ETH_RSS_IPV6_UDP_EX(1ULL << RTE_ETH_FLOW_IPV6_UDP_EX)
-#define ETH_RSS_PORT (1ULL << RTE_ETH_FLOW_PORT)
-#define ETH_RSS_VXLAN (1ULL << RTE_ETH_FLOW_VXLAN)
-#define ETH_RSS_GENEVE (1ULL << RTE_ETH_FLOW_GENEVE)
-#define ETH_RSS_NVGRE (1ULL << RTE_ETH_FLOW_NVGRE)
+ * Below macros are defined for RSS offload types, they can be used to
+ * fill rte_eth_rss_conf.rss_hf or rte_flow_action_rss.types.
+ */
+#define ETH_RSS_IPV4 (1ULL << 2)
+#define ETH_RSS_FRAG_IPV4 (1ULL << 3)
+#define ETH_RSS_NONFRAG_IPV4_TCP (1ULL << 4)
+#define ETH_RSS_NONFRAG_IPV4_UDP (1ULL << 5)
+#define ETH_RSS_NONFRAG_IPV4_SCTP (1ULL << 6)
+#define ETH_RSS_NONFRAG_IPV4_OTHER (1ULL << 7)
+#define ETH_RSS_IPV6 (1ULL << 8)
+#define ETH_RSS_FRAG_IPV6 (1ULL << 9)
+#define ETH_RSS_NONFRAG_IPV6_TCP (1ULL << 10)
+#define ETH_RSS_NONFRAG_IPV6_UDP (1ULL << 11)
+#define ETH_RSS_NONFRAG_IPV6_SCTP (1ULL << 12)
+#define ETH_RSS_NONFRAG_IPV6_OTHER (1ULL << 13)
+#define ETH_RSS_L2_PAYLOAD (1ULL << 14)
+#define ETH_RSS_IPV6_EX(1ULL << 15)
+#define ETH_RSS_IPV6_TCP_EX(1ULL << 16)
+#define ETH_RSS_IPV6_UDP_EX(1ULL << 17)
+#define ETH_RSS_PORT (1ULL << 18)
+#define ETH_RSS_VXLAN (1ULL << 19)
+#define ETH_RSS_GENEVE (1ULL << 20)
+#define ETH_RSS_NVGRE (1ULL << 21)
#define ETH_RSS_IP ( \
ETH_RSS_IPV4 | \
--
1.8.3.1
Re: [dpdk-dev] [PATCH 2/5] lib/ring: add template to support different element sizes
> > > > > +++ b/lib/librte_ring/rte_ring_template.h
> > > > > @@ -0,0 +1,330 @@
> > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > + * Copyright (c) 2019 Arm Limited */
> > > > > +
> > > > > +#ifndef _RTE_RING_TEMPLATE_H_
> > > > > +#define _RTE_RING_TEMPLATE_H_
> > > > > +
> > > > > +#ifdef __cplusplus
> > > > > +extern "C" {
> > > > > +#endif
> > > > > +
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include #include
> > > > > +#include #include
> > > > > +
> > > > > +/* Ring API suffix name - used to append to API names */ #ifndef
> > > > > +RTE_RING_TMPLT_API_SUFFIX #error RTE_RING_TMPLT_API_SUFFIX
> > not
> > > > > +defined #endif
> > > > > +
> > > > > +/* Ring's element size in bits, should be a power of 2 */ #ifndef
> > > > > +RTE_RING_TMPLT_ELEM_SIZE #error RTE_RING_TMPLT_ELEM_SIZE
> > not
> > > > defined
> > > > > +#endif
> > > > > +
> > > > > +/* Type of ring elements */
> > > > > +#ifndef RTE_RING_TMPLT_ELEM_TYPE
> > > > > +#error RTE_RING_TMPLT_ELEM_TYPE not defined #endif
> > > > > +
> > > > > +#define _rte_fuse(a, b) a##_##b
> > > > > +#define __rte_fuse(a, b) _rte_fuse(a, b) #define
> > > > > +__RTE_RING_CONCAT(a) __rte_fuse(a, RTE_RING_TMPLT_API_SUFFIX)
> > > > > +
> > > > > +/* Calculate the memory size needed for a ring */
> > > > > +RTE_RING_TMPLT_EXPERIMENTAL ssize_t
> > > > > +__RTE_RING_CONCAT(rte_ring_get_memsize)(unsigned count);
> > > > > +
> > > > > +/* Create a new ring named *name* in memory. */
> > > > > +RTE_RING_TMPLT_EXPERIMENTAL struct rte_ring *
> > > > > +__RTE_RING_CONCAT(rte_ring_create)(const char *name, unsigned
> > count,
> > > > > + int socket_id, unsigned flags);
> > > >
> > > >
> > > > Just an idea - probably same thing can be achieved in a different way.
> > > > Instead of all these defines - replace ENQUEUE_PTRS/DEQUEUE_PTRS
> > > > macros with static inline functions and then make all internal
> > > > functions,
> > i.e.
> > > > __rte_ring_do_dequeue()
> > > > to accept enqueue/dequeue function pointer as a parameter.
> > > > Then let say default rte_ring_mc_dequeue_bulk will do:
> > > >
> > > > rte_ring_mc_dequeue_bulk(struct rte_ring *r, void **obj_table,
> > > > unsigned int n, unsigned int *available) {
> > > > return __rte_ring_do_dequeue(r, obj_table, n,
> > RTE_RING_QUEUE_FIXED,
> > > > __IS_MC, available, dequeue_ptr_default); }
> > > >
> > > > Then if someone will like to define ring functions forelt_size==X,
> > > > all he would need to do:
> > > > 1. define his own enqueue/dequeuer functions.
> > > > 2. do something like:
> > > > rte_ring_mc_dequeue_bulk(struct rte_ring *r, void **obj_table,
> > > > unsigned int n, unsigned int *available) {
> > > > return __rte_ring_do_dequeue(r, obj_table, n,
> > RTE_RING_QUEUE_FIXED,
> > > > __IS_MC, available, dequeue_X); }
> > > >
> > > > Konstantin
> > > Thanks for the feedback/idea. The goal of this patch was to make it
> > > simple enough to define APIs to store any element size without code
> > duplication.
> >
> > Well, then if we store elt_size inside the ring, it should be easy enough
> > to add
> > to the API generic functions that would use memcpy(or rte_memcpy) for
> > enqueue/dequeue.
> > Yes, it might be slower than existing (8B per elem), but might be still
> > acceptable.
> The element size will be a constant in most use cases. If we keep the element
> size as a parameter, it allows the compiler to do any loop
> unrolling and auto-vectorization optimizations on copying.
> Storing the element size will result in additional memory access.
I understand that, but for you case (rcu defer queue) you probably need highest
possible performance, right?
I am sure there will be other cases where such slight perf degradation is
acceptatble.
>
> >
> > >With this patch, the user has to write ~4 lines of code to get APIs for
> > >any element size. I would like to keep the goal still the same.
> > >
> > > If we have to avoid the macro-fest, the main problem that needs to be
> > > addressed is - how to represent different sizes of element types in a
> > > generic
> > way? IMO, we can do this by defining the element type to be a multiple of
> > uint32_t (I do not think we need to go to uint16_t).
> > >
> > > For ex:
> > > rte_ring_mp_enqueue_bulk_objs(struct rte_ring *r,
> > > uint32_t *obj_table, unsigned int num_objs,
> > > unsigned int n,
> > > enum rte_ring_queue_behavior behavior, unsigned int is_sp,
> > > unsigned int *free_space) { }
> > >
> > > This approach would ensure that we have generic enough APIs and they
> > > can be used for elements of any size. But the element itself needs to be a
> > multiple of 32b - I think this should not
Re: [dpdk-dev] [PATCH v3 2/3] lib/rcu: add resource reclamation APIs
> -Original Message-
> From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com]
> Sent: Thursday, October 3, 2019 7:42 AM
> To: Ananyev, Konstantin ;
> step...@networkplumber.org; paul...@linux.ibm.com
> Cc: Wang, Yipeng1 ; Medvedkin, Vladimir
> ; Ruifeng Wang (Arm Technology
> China) ; Dharmik Thakkar ;
> Honnappa Nagarahalli
> ; dev@dpdk.org; nd ; nd
>
> Subject: RE: [PATCH v3 2/3] lib/rcu: add resource reclamation APIs
>
> >
> > > +
> > > +/* Reclaim resources from the defer queue. */ int
> > > +rte_rcu_qsbr_dq_reclaim(struct rte_rcu_qsbr_dq *dq) {
> > > + uint32_t max_cnt;
> > > + uint32_t cnt;
> > > + void *token;
> > > + uint64_t *tmp;
> > > + uint32_t i;
> > > +
> > > + if (dq == NULL) {
> > > + rte_log(RTE_LOG_ERR, rte_rcu_log_type,
> > > + "%s(): Invalid input parameter\n", __func__);
> > > + rte_errno = EINVAL;
> > > +
> > > + return 1;
> > > + }
> > > +
> > > + /* Anything to reclaim? */
> > > + if (rte_ring_count(dq->r) == 0)
> > > + return 0;
> > > +
> > > + /* Reclaim at the max 1/16th the total number of entries. */
> > > + max_cnt = dq->size >> RTE_RCU_QSBR_MAX_RECLAIM_LIMIT;
> > > + max_cnt = (max_cnt == 0) ? dq->size : max_cnt;
> > > + cnt = 0;
> > > +
> > > + /* Check reader threads quiescent state and reclaim resources */
> > > + while ((cnt < max_cnt) && (rte_ring_peek(dq->r, &token) == 0) &&
> > > + (rte_rcu_qsbr_check(dq->v, (uint64_t)((uintptr_t)token), false)
> >
> > One more thing I forgot to ask - how this construct supposed to work on 32
> > bit machines?
> > peek() will return 32-bit value, while qsbr_check() operates with 64bit
> > tokens...
> > As I understand in that case you need to peek() 2 elems.
> Yes, that is the intention. Ring APIs with desired element size will help
> address the 32b machines.
Or serialized dequeue :)
>
> > Might work, but still think better to introduce serialize version of
> > ring_dequeue() See my other mail about re_ring_peek().
> >
> >
> > > + == 1)) {
> > > + (void)rte_ring_sc_dequeue(dq->r, &token);
> > > + /* The resource to dequeue needs to be a multiple of 64b
> > > + * due to the limitation of the rte_ring implementation.
> > > + */
> > > + for (i = 0, tmp = (uint64_t *)dq->e; i < dq->esize/8;
> > > + i++, tmp++)
> > > + (void)rte_ring_sc_dequeue(dq->r,
> > > + (void *)(uintptr_t)tmp);
> > > + dq->f(dq->p, dq->e);
> > > +
> > > + cnt++;
> > > + }
> > > +
> > > + rte_log(RTE_LOG_INFO, rte_rcu_log_type,
> > > + "%s(): Reclaimed %u resources\n", __func__, cnt);
> > > +
> > > + if (cnt == 0) {
> > > + /* No resources were reclaimed */
> > > + rte_errno = EAGAIN;
> > > + return 1;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +/* Delete a defer queue. */
> > > +int
> > > +rte_rcu_qsbr_dq_delete(struct rte_rcu_qsbr_dq *dq) {
> > > + if (dq == NULL) {
> > > + rte_log(RTE_LOG_ERR, rte_rcu_log_type,
> > > + "%s(): Invalid input parameter\n", __func__);
> > > + rte_errno = EINVAL;
> > > +
> > > + return 1;
> > > + }
> > > +
> > > + /* Reclaim all the resources */
> > > + if (rte_rcu_qsbr_dq_reclaim(dq) != 0)
> > > + /* Error number is already set by the reclaim API */
> > > + return 1;
> > > +
> > > + rte_ring_free(dq->r);
> > > + rte_free(dq);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > int rte_rcu_log_type;
> > >
> > > RTE_INIT(rte_rcu_register)
> > > diff --git a/lib/librte_rcu/rte_rcu_qsbr.h
> > > b/lib/librte_rcu/rte_rcu_qsbr.h index c80f15c00..185d4b50a 100644
> > > --- a/lib/librte_rcu/rte_rcu_qsbr.h
> > > +++ b/lib/librte_rcu/rte_rcu_qsbr.h
> > > @@ -34,6 +34,7 @@ extern "C" {
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > extern int rte_rcu_log_type;
> > >
> > > @@ -109,6 +110,67 @@ struct rte_rcu_qsbr {
> > >*/
> > > } __rte_cache_aligned;
> > >
> > > +/**
> > > + * Call back function called to free the resources.
> > > + *
> > > + * @param p
> > > + * Pointer provided while creating the defer queue
> > > + * @param e
> > > + * Pointer to the resource data stored on the defer queue
> > > + *
> > > + * @return
> > > + * None
> > > + */
> > > +typedef void (*rte_rcu_qsbr_free_resource)(void *p, void *e);
> > > +
> > > +#define RTE_RCU_QSBR_DQ_NAMESIZE RTE_RING_NAMESIZE
> > > +
> > > +/**
> > > + * Trigger automatic reclamation after 1/8th the defer queue is full.
> > > + */
> > > +#define RTE_RCU_QSBR_AUTO_RECLAIM_LIMIT 3
> > > +
> > > +/**
> > > + * Reclaim at the max 1/16th the total number of resources.
> > > + */
> > > +#define RTE_RCU_QSBR_MAX_RECLAIM_LIMIT 4
> > > +
> > > +/**
> > > + * Parameters used when creating the defer queue.
> > > + */
> > > +struct rte_rcu_qsbr_dq_parameters {
> > > + const char *name;
> > > + /**< Name of the queue. */
> > > + uint32_t s
Re: [dpdk-dev] [PATCH] net: re-add qede to meson
On 10/3/2019 9:38 AM, Jerin Jacob wrote:
> On Thu, Oct 3, 2019 at 1:48 PM David Marchand
> wrote:
>>
>> qede has been dropped from the drivers/net meson.
>> Add it again.
>>
>> Fixes: 9a8864c8b5da ("net/octeontx2: add build and doc infrastructure")
>>
>> Signed-off-by: David Marchand
>
> Reviewed-by: Jerin Jacob
Reviewed-by: Ferruh Yigit
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH v3 2/3] lib/rcu: add resource reclamation APIs
Hi Honnappa,
> > > Add resource reclamation APIs to make it simple for applications and
> > > libraries to integrate rte_rcu library.
> > >
> > > Signed-off-by: Honnappa Nagarahalli
> > > Reviewed-by: Ola Liljedhal
> > > Reviewed-by: Ruifeng Wang
> > > ---
> > > app/test/test_rcu_qsbr.c | 291 -
> > > lib/librte_rcu/meson.build | 2 +
> > > lib/librte_rcu/rte_rcu_qsbr.c | 185 ++
> > > lib/librte_rcu/rte_rcu_qsbr.h | 169 +
> > > lib/librte_rcu/rte_rcu_qsbr_pvt.h | 46 +
> > > lib/librte_rcu/rte_rcu_version.map | 4 +
> > > lib/meson.build| 6 +-
> > > 7 files changed, 700 insertions(+), 3 deletions(-) create mode
> > > 100644 lib/librte_rcu/rte_rcu_qsbr_pvt.h
> > >
> > > diff --git a/lib/librte_rcu/rte_rcu_qsbr.c
> > > b/lib/librte_rcu/rte_rcu_qsbr.c index ce7f93dd3..76814f50b 100644
> > > --- a/lib/librte_rcu/rte_rcu_qsbr.c
> > > +++ b/lib/librte_rcu/rte_rcu_qsbr.c
> > > @@ -21,6 +21,7 @@
> > > #include
> > >
> > > #include "rte_rcu_qsbr.h"
> > > +#include "rte_rcu_qsbr_pvt.h"
> > >
> > > /* Get the memory size of QSBR variable */ size_t @@ -267,6 +268,190
> > > @@ rte_rcu_qsbr_dump(FILE *f, struct rte_rcu_qsbr *v)
> > > return 0;
> > > }
> > >
> > > +/* Create a queue used to store the data structure elements that can
> > > + * be freed later. This queue is referred to as 'defer queue'.
> > > + */
> > > +struct rte_rcu_qsbr_dq *
> > > +rte_rcu_qsbr_dq_create(const struct rte_rcu_qsbr_dq_parameters
> > > +*params) {
> > > + struct rte_rcu_qsbr_dq *dq;
> > > + uint32_t qs_fifo_size;
> > > +
> > > + if (params == NULL || params->f == NULL ||
> > > + params->v == NULL || params->name == NULL ||
> > > + params->size == 0 || params->esize == 0 ||
> > > + (params->esize % 8 != 0)) {
> > > + rte_log(RTE_LOG_ERR, rte_rcu_log_type,
> > > + "%s(): Invalid input parameter\n", __func__);
> > > + rte_errno = EINVAL;
> > > +
> > > + return NULL;
> > > + }
> > > +
> > > + dq = rte_zmalloc(NULL,
> > > + (sizeof(struct rte_rcu_qsbr_dq) + params->esize),
> > > + RTE_CACHE_LINE_SIZE);
> > > + if (dq == NULL) {
> > > + rte_errno = ENOMEM;
> > > +
> > > + return NULL;
> > > + }
> > > +
> > > + /* round up qs_fifo_size to next power of two that is not less than
> > > + * max_size.
> > > + */
> > > + qs_fifo_size = rte_align32pow2params->esize/8) + 1)
> > > + * params->size) + 1);
> > > + dq->r = rte_ring_create(params->name, qs_fifo_size,
> > > + SOCKET_ID_ANY, 0);
> >
> > If it is going to be not MT safe, then why not to create the ring with
> > (RING_F_SP_ENQ | RING_F_SC_DEQ) flags set?
> Agree.
>
> > Though I think it could be changed to allow MT safe multiple enqeue/single
> > dequeue, see below.
> The MT safe issue is due to reclaim code. The reclaim code has the following
> sequence:
>
> rte_ring_peek
> rte_rcu_qsbr_check
> rte_ring_dequeue
>
> This entire sequence needs to be atomic as the entry cannot be dequeued
> without knowing that the grace period for that entry is over.
I understand that, though I believe at least it should be possible to support
multiple-enqueue/single dequeuer and reclaim mode.
With serialized dequeue() even multiple dequeue should be possible.
> Note that due to optimizations in rte_rcu_qsbr_check API, this sequence
> should not be large in most cases. I do not have ideas on how to
> make this sequence lock-free.
>
> If the writer is on the control plane, most use cases will use mutex locks
> for synchronization if they are multi-threaded. That lock should be
> enough to provide the thread safety for these APIs.
In that is case, why do we need ring at all?
For sure people can create their own queue quite easily with mutex and TAILQ.
If performance is not an issue, they can even add pthread_cond to it, and have
an ability
for the consumer to sleep/wakeup on empty/full queue.
>
> If the writer is multi-threaded and lock-free, then one should use per thread
> defer queue.
If that's the only working model, then the question is why do we need that API
at all?
Just simple array with counter or linked-list should do for majority of cases.
>
> >
> > > + if (dq->r == NULL) {
> > > + rte_log(RTE_LOG_ERR, rte_rcu_log_type,
> > > + "%s(): defer queue create failed\n", __func__);
> > > + rte_free(dq);
> > > + return NULL;
> > > + }
> > > +
> > > + dq->v = params->v;
> > > + dq->size = params->size;
> > > + dq->esize = params->esize;
> > > + dq->f = params->f;
> > > + dq->p = params->p;
> > > +
> > > + return dq;
> > > +}
> > > +
> > > +/* Enqueue one resource to the defer queue to free after the grace
> > > + * period is over.
> > > + */
> > > +int rte_rcu_qsbr_dq_enqueue(struct rte_rcu_qsbr_dq *dq, void *e) {
> > > + uint64_t token;
> > > + uint64_t
Re: [dpdk-dev] [PATCH 2/5] lib/ring: add template to support different element sizes
>
> > > > > > +++ b/lib/librte_ring/rte_ring_template.h
> > > > > > @@ -0,0 +1,330 @@
> > > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > > + * Copyright (c) 2019 Arm Limited */
> > > > > > +
> > > > > > +#ifndef _RTE_RING_TEMPLATE_H_
> > > > > > +#define _RTE_RING_TEMPLATE_H_
> > > > > > +
> > > > > > +#ifdef __cplusplus
> > > > > > +extern "C" {
> > > > > > +#endif
> > > > > > +
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include #include
> > > > > > +#include #include
> > > > > > +
> > > > > > +/* Ring API suffix name - used to append to API names */ #ifndef
> > > > > > +RTE_RING_TMPLT_API_SUFFIX #error RTE_RING_TMPLT_API_SUFFIX
> > > not
> > > > > > +defined #endif
> > > > > > +
> > > > > > +/* Ring's element size in bits, should be a power of 2 */ #ifndef
> > > > > > +RTE_RING_TMPLT_ELEM_SIZE #error RTE_RING_TMPLT_ELEM_SIZE
> > > not
> > > > > defined
> > > > > > +#endif
> > > > > > +
> > > > > > +/* Type of ring elements */
> > > > > > +#ifndef RTE_RING_TMPLT_ELEM_TYPE
> > > > > > +#error RTE_RING_TMPLT_ELEM_TYPE not defined #endif
> > > > > > +
> > > > > > +#define _rte_fuse(a, b) a##_##b
> > > > > > +#define __rte_fuse(a, b) _rte_fuse(a, b) #define
> > > > > > +__RTE_RING_CONCAT(a) __rte_fuse(a, RTE_RING_TMPLT_API_SUFFIX)
> > > > > > +
> > > > > > +/* Calculate the memory size needed for a ring */
> > > > > > +RTE_RING_TMPLT_EXPERIMENTAL ssize_t
> > > > > > +__RTE_RING_CONCAT(rte_ring_get_memsize)(unsigned count);
> > > > > > +
> > > > > > +/* Create a new ring named *name* in memory. */
> > > > > > +RTE_RING_TMPLT_EXPERIMENTAL struct rte_ring *
> > > > > > +__RTE_RING_CONCAT(rte_ring_create)(const char *name, unsigned
> > > count,
> > > > > > + int socket_id, unsigned flags);
> > > > >
> > > > >
> > > > > Just an idea - probably same thing can be achieved in a different way.
> > > > > Instead of all these defines - replace ENQUEUE_PTRS/DEQUEUE_PTRS
> > > > > macros with static inline functions and then make all internal
> > > > > functions,
> > > i.e.
> > > > > __rte_ring_do_dequeue()
> > > > > to accept enqueue/dequeue function pointer as a parameter.
> > > > > Then let say default rte_ring_mc_dequeue_bulk will do:
> > > > >
> > > > > rte_ring_mc_dequeue_bulk(struct rte_ring *r, void **obj_table,
> > > > > unsigned int n, unsigned int *available) {
> > > > > return __rte_ring_do_dequeue(r, obj_table, n,
> > > RTE_RING_QUEUE_FIXED,
> > > > > __IS_MC, available, dequeue_ptr_default); }
> > > > >
> > > > > Then if someone will like to define ring functions forelt_size==X,
> > > > > all he would need to do:
> > > > > 1. define his own enqueue/dequeuer functions.
> > > > > 2. do something like:
> > > > > rte_ring_mc_dequeue_bulk(struct rte_ring *r, void **obj_table,
> > > > > unsigned int n, unsigned int *available) {
> > > > > return __rte_ring_do_dequeue(r, obj_table, n,
> > > RTE_RING_QUEUE_FIXED,
> > > > > __IS_MC, available, dequeue_X); }
> > > > >
> > > > > Konstantin
> > > > Thanks for the feedback/idea. The goal of this patch was to make it
> > > > simple enough to define APIs to store any element size without code
> > > duplication.
> > >
> > > Well, then if we store elt_size inside the ring, it should be easy enough
> > > to add
> > > to the API generic functions that would use memcpy(or rte_memcpy) for
> > > enqueue/dequeue.
> > > Yes, it might be slower than existing (8B per elem), but might be still
> > > acceptable.
> > The element size will be a constant in most use cases. If we keep the
> > element size as a parameter, it allows the compiler to do any loop
> > unrolling and auto-vectorization optimizations on copying.
> > Storing the element size will result in additional memory access.
>
> I understand that, but for you case (rcu defer queue) you probably need
> highest possible performance, right?
Meant 'don't need' of course :)
> I am sure there will be other cases where such slight perf degradation is
> acceptatble.
>
> >
> > >
> > > >With this patch, the user has to write ~4 lines of code to get APIs for
> > > >any element size. I would like to keep the goal still the same.
> > > >
> > > > If we have to avoid the macro-fest, the main problem that needs to be
> > > > addressed is - how to represent different sizes of element types in a
> > > > generic
> > > way? IMO, we can do this by defining the element type to be a multiple of
> > > uint32_t (I do not think we need to go to uint16_t).
> > > >
> > > > For ex:
> > > > rte_ring_mp_enqueue_bulk_objs(struct rte_ring *r,
> > > > uint32_t *obj_table, unsigned int num_objs,
> > > > unsigned int n,
> > > > enum rte_ring_queue_behavior behavior, unsigned int
Re: [dpdk-dev] [PATCH v2 20/20] net/bnxt: handle flow flush handling
On 10/3/2019 12:26 AM, Ajit Khaparde wrote: > We are not freeing all the flows when a flow_flush is called. > Iterate through all the flows belonging to all the VNICs in use and > free the filters. For the patch title "handle flow flush handling", I think here 'handle' means fixing the "flow flush handling", I am updating that way. Can you please send the fixes tag for it, I can update later in the next-net? Same question for other patches in this patchset that start with "handle xxx", is that handle means fix something? If so can you please send commit log updates for them too? Thanks. > > Reviewed-by: Rahul Gupta > Reviewed-by: Venkat Duvvuru > Reviewed-by: Kalesh Anakkur Purayil > Signed-off-by: Ajit Khaparde
Re: [dpdk-dev] [PATCH v5 00/10] example/l2fwd-event: introduce l2fwd-event example
Hi Jerin, > -Original Message- > From: Jerin Jacob > Sent: Thursday, October 3, 2019 4:04 PM > To: Pavan Nikhilesh > Cc: Jerin Jacob ; Richardson, Bruce > ; Akhil Goyal ; dpdk- > dev ; Van Haaren, Harry ; > mattias.ronnb...@ericsson.com; liang.j...@intel.com; Gujjar, Abhinandan > S ; Rao, Nikhil ; > Hemant Agrawal ; erik.g.carri...@intel.com > Subject: Re: [dpdk-dev] [PATCH v5 00/10] example/l2fwd-event: introduce > l2fwd-event example > Importance: High > > On Thu, Oct 3, 2019 at 2:28 AM wrote: > > > > From: Pavan Nikhilesh > > > > This patchset adds a new application to demonstrate the usage of event > > mode. The poll mode is also available to help with the transition. > > > > The following new command line parameters are added: > > --mode: Dictates the mode of operation either poll or event. > > --eventq_sync: Dictates event synchronization mode either atomic or > > ordered. > > > > Based on event device capability the configuration is done as follows: > > - A single event device is enabled. > > - The number of event ports is equal to the number of worker > > cores enabled in the core mask. Additional event ports might > > be configured based on Rx/Tx adapter capability. > > - The number of event queues is equal to the number of ethernet > > ports. If Tx adapter doesn't have internal port capability then > > an additional single link event queue is used to enqueue events > > to Tx adapter. > > - Each event port is linked to all existing event queues. > > - Dedicated Rx/Tx adapters for each Ethernet port. > > > > v5 Changes: > > - Redo poll mode datapath by removing all the static globals. > > - Fix event queue configuration when required queues are not available. > > - Fix Rx/Tx adapter creation based on portmask. > > - Update release notes. > > - Unroll macro used to generate event mode functions. > > > > > Adding all eventdev maintainers. > > I have some minor comments on Documentation. Other than that, The series > looks good to me in general. > Anyone else planning to review this code. If yes, We will wait for merging > this > patch after RC1. > If no, then we can merge in RC1 if no objection. [Hemant] On a high level this series looks good to us. However currently we are in the process of testing it. Will you please wait for our ack? Currently we are trying to completed it before RC1 Regards, Hemant
Re: [dpdk-dev] [PATCH v2 1/3] test/crypto: add more AES GCM tests for QAT PMD
Hi Adam, > -Original Message- > From: Dybkowski, AdamX > Sent: Friday, September 27, 2019 4:48 PM > To: dev@dpdk.org; Trahe, Fiona ; Kusztal, ArkadiuszX > ; akhil.go...@nxp.com > Cc: Dybkowski, AdamX > Subject: [PATCH v2 1/3] test/crypto: add more AES GCM tests for QAT PMD > > This patch adds 256-bit AES GCM tests for QAT PMD > (which already existed for AESNI and OpenSSL) and also adds > a number of negative unit tests for AES GCM for QAT PMD, in order > to verify authenticated encryption and decryption with modified data. > > Signed-off-by: Adam Dybkowski > --- These are a great set of tests to add, thanks. However, I find the silent terminology misleading. as the fn is not silent, other errors may print, debug may print and depending on the flag passed in the compare error may print. Also, if the test fails for some other reason than the one it should, this will be missed. What you want to do is catch specific expected errors so I'd suggest following: leave test_authenticated_encryption() name as is. Add a fail_expected enum to crypto_unittest_params, with elements like NONE, DIGEST_CORRUPT, ENCRYPTED_DATA_CORRUPT, UNENCRYPTED_DATA_CORRUPT Don't suppress the errors, instead in wrapper fns, print "Negative test - errors are expected" at top of each negative test, corrupt the input and set the appropriate fail. In test_authenticated_encryption() and test_authenticated_encryption() use the enum to check for the expected failure. Does that make sense?
Re: [dpdk-dev] [PATCH v5 00/10] example/l2fwd-event: introduce l2fwd-event example
On Thu, Oct 3, 2019 at 6:10 PM Hemant Agrawal wrote: > > Hi Jerin, > > > -Original Message- > > From: Jerin Jacob > > Sent: Thursday, October 3, 2019 4:04 PM > > To: Pavan Nikhilesh > > Cc: Jerin Jacob ; Richardson, Bruce > > ; Akhil Goyal ; dpdk- > > dev ; Van Haaren, Harry ; > > mattias.ronnb...@ericsson.com; liang.j...@intel.com; Gujjar, Abhinandan > > S ; Rao, Nikhil ; > > Hemant Agrawal ; erik.g.carri...@intel.com > > Subject: Re: [dpdk-dev] [PATCH v5 00/10] example/l2fwd-event: introduce > > l2fwd-event example > > Importance: High > > > > On Thu, Oct 3, 2019 at 2:28 AM wrote: > > > > > > From: Pavan Nikhilesh > > > > > > This patchset adds a new application to demonstrate the usage of event > > > mode. The poll mode is also available to help with the transition. > > > > > > The following new command line parameters are added: > > > --mode: Dictates the mode of operation either poll or event. > > > --eventq_sync: Dictates event synchronization mode either atomic or > > > ordered. > > > > > > Based on event device capability the configuration is done as follows: > > > - A single event device is enabled. > > > - The number of event ports is equal to the number of worker > > > cores enabled in the core mask. Additional event ports might > > > be configured based on Rx/Tx adapter capability. > > > - The number of event queues is equal to the number of ethernet > > > ports. If Tx adapter doesn't have internal port capability then > > > an additional single link event queue is used to enqueue events > > > to Tx adapter. > > > - Each event port is linked to all existing event queues. > > > - Dedicated Rx/Tx adapters for each Ethernet port. > > > > > > v5 Changes: > > > - Redo poll mode datapath by removing all the static globals. > > > - Fix event queue configuration when required queues are not available. > > > - Fix Rx/Tx adapter creation based on portmask. > > > - Update release notes. > > > - Unroll macro used to generate event mode functions. > > > > > > > > > > Adding all eventdev maintainers. > > > > I have some minor comments on Documentation. Other than that, The series > > looks good to me in general. > > Anyone else planning to review this code. If yes, We will wait for merging > > this > > patch after RC1. > > If no, then we can merge in RC1 if no objection. > [Hemant] > On a high level this series looks good to us. However currently we are in the > process of testing it. > Will you please wait for our ack? Currently we are trying to completed it > before RC1 OK. Will for NXP's Ack. > > Regards, > Hemant >
Re: [dpdk-dev] [PATCH] cryptodev: fix invalid dev_id after a pmd close
Hi Julien
>
> Each cryptodev are indexed with its dev_id in the global
> rte_crypto_devices variable. nb_devs is incremented / decremented each
> time a cryptodev is created / deleted. The goal of nb_devs is to prevent
> the user to get an invalid dev_id.
>
> Let's imagine DPDK has configured N cryptodevs. If the cryptodev=1 is
> removed at runtime, the latest cryptodev N cannot be accessible, because
> nb_devs=N-1.
>
> In order to prevent this kind of behavior, let's remove the check with
> nb_devs and iterate in all the rte_crypto_devices elements: if data is
> not NULL, that means a valid cryptodev is available.
>
> Fixes: d11b0f30df88 ("cryptodev: introduce API and framework for crypto
> devices")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Julien Meunier
> ---
> lib/librte_cryptodev/rte_cryptodev.c | 42 --
> --
> 1 file changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> b/lib/librte_cryptodev/rte_cryptodev.c
> index 43bc335..c8c7ffd 100644
> --- a/lib/librte_cryptodev/rte_cryptodev.c
> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> @@ -49,9 +49,7 @@ struct rte_cryptodev *rte_cryptodevs = rte_crypto_devices;
>
> static struct rte_cryptodev_global cryptodev_globals = {
> .devs = rte_crypto_devices,
> - .data = { NULL },
> - .nb_devs= 0,
> - .max_devs = RTE_CRYPTO_MAX_DEVS
> + .data = { NULL }
> };
>
> /* spinlock for crypto device callbacks */
> @@ -512,7 +510,7 @@ rte_cryptodev_pmd_get_named_dev(const char *name)
> if (name == NULL)
> return NULL;
>
> - for (i = 0; i < cryptodev_globals.max_devs; i++) {
> + for (i = 0; i < RTE_CRYPTO_MAX_DEVS; i++) {
> dev = &cryptodev_globals.devs[i];
>
> if ((dev->attached == RTE_CRYPTODEV_ATTACHED) &&
> @@ -523,12 +521,21 @@ rte_cryptodev_pmd_get_named_dev(const char
> *name)
> return NULL;
> }
>
> +static uint8_t
> +rte_cryptodev_is_valid_device_data(uint8_t dev_id)
> +{
> + if (rte_crypto_devices[dev_id].data == NULL)
> + return 0;
> +
> + return 1;
> +}
> +
> unsigned int
> rte_cryptodev_pmd_is_valid_dev(uint8_t dev_id)
> {
> struct rte_cryptodev *dev = NULL;
>
> - if (dev_id >= cryptodev_globals.nb_devs)
> + if (!rte_cryptodev_is_valid_device_data(dev_id))
> return 0;
>
> dev = rte_cryptodev_pmd_get_dev(dev_id);
> @@ -547,12 +554,15 @@ rte_cryptodev_get_dev_id(const char *name)
> if (name == NULL)
> return -1;
>
> - for (i = 0; i < cryptodev_globals.nb_devs; i++)
> + for (i = 0; i < RTE_CRYPTO_MAX_DEVS; i++) {
> + if (!rte_cryptodev_is_valid_device_data(i))
> + continue;
> if ((strcmp(cryptodev_globals.devs[i].data->name, name)
> == 0) &&
> (cryptodev_globals.devs[i].attached ==
> RTE_CRYPTODEV_ATTACHED))
> return i;
> + }
>
> return -1;
> }
> @@ -560,7 +570,13 @@ rte_cryptodev_get_dev_id(const char *name)
> uint8_t
> rte_cryptodev_count(void)
> {
> - return cryptodev_globals.nb_devs;
> + uint8_t i, dev_count = 0;
> +
> + for (i = 0; i < RTE_CRYPTO_MAX_DEVS; i++)
> + if (cryptodev_globals.devs[i].data != NULL)
> + dev_count++;
> +
> + return dev_count;
> }
Why do you want to remove the nb_devs? We can have it updated
(incremented/decremented)
While allocate/release of the device.
The point is, whenever somebody call rte_cryptodev_count() it will do a lookup
of valid data
pointer.
>
> uint8_t
> @@ -568,7 +584,7 @@ rte_cryptodev_device_count_by_driver(uint8_t
> driver_id)
> {
> uint8_t i, dev_count = 0;
>
> - for (i = 0; i < cryptodev_globals.max_devs; i++)
> + for (i = 0; i < RTE_CRYPTO_MAX_DEVS; i++)
> if (cryptodev_globals.devs[i].driver_id == driver_id &&
> cryptodev_globals.devs[i].attached ==
> RTE_CRYPTODEV_ATTACHED)
> @@ -583,9 +599,10 @@ rte_cryptodev_devices_get(const char *driver_name,
> uint8_t *devices,
> {
> uint8_t i, count = 0;
> struct rte_cryptodev *devs = cryptodev_globals.devs;
> - uint8_t max_devs = cryptodev_globals.max_devs;
>
> - for (i = 0; i < max_devs && count < nb_devices; i++) {
> + for (i = 0; i < RTE_CRYPTO_MAX_DEVS && count < nb_devices; i++) {
> + if (!rte_cryptodev_is_valid_device_data(i))
> + continue;
>
> if (devs[i].attached == RTE_CRYPTODEV_ATTACHED) {
> int cmp;
> @@ -736,8 +753,6 @@ rte_cryptodev_pmd_allocate(const char *name, int
> socket_id)
> TAILQ_INIT(&(cryptodev->link_intr_cbs));
>
> cry
Re: [dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support
03/09/2019 12:59, jer...@marvell.com: > Added eBPF arm64 JIT support to improve the eBPF program performance > on arm64. > > lib/librte_bpf/bpf_jit_arm64.c | 1451 I am concerned about duplicating the BPF JIT effort in DPDK and Linux. Could we try to pull the Linux JIT? Is the license the only issue? After a quick discussion, it seems the Linux authors are OK to arrange their JIT code for sharing with userspace projects.
Re: [dpdk-dev] [PATCH v2 2/3] common/qat: add new QAT GEN3 definitions
> -Original Message- > From: Dybkowski, AdamX > Sent: Friday, September 27, 2019 4:48 PM > To: dev@dpdk.org; Trahe, Fiona ; Kusztal, ArkadiuszX > ; akhil.go...@nxp.com > Cc: Dybkowski, AdamX > Subject: [PATCH v2 2/3] common/qat: add new QAT GEN3 definitions > > This patch adds few definitions specific to GEN3 QAT. > > Signed-off-by: Adam Dybkowski Acked-by: Fiona Trahe
Re: [dpdk-dev] [PATCH v1 1/3] lib/ethdev: add ethdev op to get hash index
Hi, On 9/14/19 8:52 AM, vattun...@marvell.com wrote: From: Vamsi Attunuru Some networking devices may use custom algos for computing hash indices and spread the packets accordingly. Patch adds a eth_dev op to get the hash index correspond to the given hash value received on the given port. Some of use cases where applications would compute hash index from hash value upfront and it can predict the packets come to a specific queue. Signed-off-by: Vamsi Attunuru I'm sorry, but the purpose of the API and provided functionality is unclear for me from above description.
Re: [dpdk-dev] [PATCH v2 3/3] crypto/qat: handle Single Pass Crypto Requests on GEN3 QAT
Hi Adam,
> -Original Message-
> From: Dybkowski, AdamX
> Sent: Friday, September 27, 2019 4:48 PM
> To: dev@dpdk.org; Trahe, Fiona ; Kusztal, ArkadiuszX
> ; akhil.go...@nxp.com
> Cc: Dybkowski, AdamX
> Subject: [PATCH v2 3/3] crypto/qat: handle Single Pass Crypto Requests on
> GEN3 QAT
>
> This patch improves the performance of AES GCM by using
> the Single Pass Crypto Request functionality when running
> on GEN3 QAT. Falls back to classic chained mode on older
> hardware.
>
> Signed-off-by: Adam Dybkowski
> ---
> doc/guides/rel_notes/release_19_11.rst | 7 +++
> drivers/crypto/qat/qat_sym.c | 13 +++-
> drivers/crypto/qat/qat_sym_session.c | 86 --
> drivers/crypto/qat/qat_sym_session.h | 9 ++-
> 4 files changed, 107 insertions(+), 8 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_19_11.rst
> b/doc/guides/rel_notes/release_19_11.rst
> index 573683da4..4817b7f23 100644
> --- a/doc/guides/rel_notes/release_19_11.rst
> +++ b/doc/guides/rel_notes/release_19_11.rst
> @@ -61,6 +61,13 @@ New Features
>Added stateful decompression support in the Intel QuickAssist Technology
> PMD.
>Please note that stateful compression is not supported.
>
> +* **Enabled Single Pass GCM acceleration on QAT GEN3.**
> +
> + Added support for Single Pass GCM, available on QAT GEN3 only (Intel
> + QuickAssist Technology C4xxx). It is automatically chosen instead of the
> + classic chained mode when running on QAT GEN3, significantly improving
> + the performance of AES GCM operations.
> +
> Removed Items
> -
>
> diff --git a/drivers/crypto/qat/qat_sym.c b/drivers/crypto/qat/qat_sym.c
> index 46ef27a6d..5ff4aa1e5 100644
> --- a/drivers/crypto/qat/qat_sym.c
> +++ b/drivers/crypto/qat/qat_sym.c
> @@ -1,5 +1,5 @@
> /* SPDX-License-Identifier: BSD-3-Clause
> - * Copyright(c) 2015-2018 Intel Corporation
> + * Copyright(c) 2015-2019 Intel Corporation
> */
>
> #include
> @@ -12,6 +12,7 @@
>
> #include "qat_sym.h"
>
> +
> /** Decrypt a single partial block
> * Depends on openssl libcrypto
> * Uses ECB+XOR to do CFB encryption, same result, more performant
> @@ -195,7 +196,8 @@ qat_sym_build_request(void *in_op, uint8_t *out_msg,
> rte_mov128((uint8_t *)qat_req, (const uint8_t *)&(ctx->fw_req));
> qat_req->comn_mid.opaque_data = (uint64_t)(uintptr_t)op;
> cipher_param = (void *)&qat_req->serv_specif_rqpars;
> - auth_param = (void *)((uint8_t *)cipher_param + sizeof(*cipher_param));
> + auth_param = (void *)((uint8_t *)cipher_param +
> + ICP_QAT_FW_HASH_REQUEST_PARAMETERS_OFFSET);
>
> if (ctx->qat_cmd == ICP_QAT_FW_LA_CMD_HASH_CIPHER ||
> ctx->qat_cmd == ICP_QAT_FW_LA_CMD_CIPHER_HASH) {
> @@ -593,6 +595,13 @@ qat_sym_build_request(void *in_op, uint8_t *out_msg,
> qat_req->comn_mid.dest_data_addr = dst_buf_start;
> }
>
> + /* Handle Single-Pass GCM */
> + if (ctx->is_single_pass) {
> + cipher_param->spc_aad_addr = op->sym->aead.aad.phys_addr;
> + cipher_param->spc_auth_res_addr =
> + op->sym->aead.digest.phys_addr;
> + }
> +
> #if RTE_LOG_DP_LEVEL >= RTE_LOG_DEBUG
> QAT_DP_HEXDUMP_LOG(DEBUG, "qat_req:", qat_req,
> sizeof(struct icp_qat_fw_la_bulk_req));
> diff --git a/drivers/crypto/qat/qat_sym_session.c
> b/drivers/crypto/qat/qat_sym_session.c
> index e5167b3fa..7d0f4a69d 100644
> --- a/drivers/crypto/qat/qat_sym_session.c
> +++ b/drivers/crypto/qat/qat_sym_session.c
> @@ -450,7 +450,7 @@ qat_sym_session_set_parameters(struct rte_cryptodev *dev,
> break;
> case ICP_QAT_FW_LA_CMD_CIPHER_HASH:
> if (xform->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
> - ret = qat_sym_session_configure_aead(xform,
> + ret = qat_sym_session_configure_aead(dev, xform,
> session);
> if (ret < 0)
> return ret;
> @@ -467,7 +467,7 @@ qat_sym_session_set_parameters(struct rte_cryptodev *dev,
> break;
> case ICP_QAT_FW_LA_CMD_HASH_CIPHER:
> if (xform->type == RTE_CRYPTO_SYM_XFORM_AEAD) {
> - ret = qat_sym_session_configure_aead(xform,
> + ret = qat_sym_session_configure_aead(dev, xform,
> session);
> if (ret < 0)
> return ret;
> @@ -503,6 +503,72 @@ qat_sym_session_set_parameters(struct rte_cryptodev *dev,
> return 0;
> }
>
> +static int
> +qat_sym_session_handle_single_pass(struct qat_sym_dev_private *internals,
> + struct qat_sym_session *session,
> + struct rte_crypto_aead_xform *aead_xform)
> +{
> + enum qat_device_gen qat_dev_gen = internals->qat_dev->qat_dev_gen;
> +
> + if (qat_dev_gen == QAT_GEN3 &&
> +
Re: [dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support
On Thu, Oct 3, 2019 at 6:21 PM Thomas Monjalon wrote: > > 03/09/2019 12:59, jer...@marvell.com: > > Added eBPF arm64 JIT support to improve the eBPF program performance > > on arm64. > > > > lib/librte_bpf/bpf_jit_arm64.c | 1451 > > I am concerned about duplicating the BPF JIT effort in DPDK and Linux. > Could we try to pull the Linux JIT? > Is the license the only issue? That's one issue. > > After a quick discussion, it seems the Linux authors are OK to arrange > their JIT code for sharing with userspace projects. I did a clean room implementation considering some optimization for DPDK etc(Like if stack is not used then don't push stack etc) and wherever Linux can be improved, I have submitted the patch also to Linux as well.(Some more pending as well) https://github.com/torvalds/linux/commit/504792e07a44844f24e9d79913e4a2f8373cd332 And Linux has a framework for instruction generation for debugging etc. So We can not copy and paste the code from Linux as is. My view to keep a different code base optimize for DPDK use cases and library requirements(for example, tail call is not supported in DPDK). For arm64/x86 case the code is done so it is not worth sync with Linux. For new architecture, it can be if possible. Konstantin, Your thoughts? > >
Re: [dpdk-dev] [PATCH v2 17/20] net/bnxt: drop untagged frames when specified
On 10/3/2019 12:25 AM, Ajit Khaparde wrote:
> When a drop action for L2 filters is specified, support it.
>
> Signed-off-by: Ajit Khaparde
> Reviewed-by: Rahul Gupta
> Reviewed-by: Somnath Kotur
> Reviewed-by: Kalesh Anakkur Purayil
<...>
> @@ -1121,19 +1152,27 @@ bnxt_validate_and_parse_flow(struct rte_eth_dev *dev,
> break;
> case RTE_FLOW_ACTION_TYPE_DROP:
> vnic0 = &bp->vnic_info[0];
> + filter->dst_id = vnic0->fw_vnic_id;
> + filter->valid_flags |= BNXT_FLOW_L2_DROP_FLAG;
> filter1 = bnxt_get_l2_filter(bp, filter, vnic0);
> if (filter1 == NULL) {
> + rte_flow_error_set(error,
> +ENOSPC,
> +RTE_FLOW_ERROR_TYPE_ACTION,
> +act,
> +"Filter not available");
> rc = -ENOSPC;
> goto ret;
> }
>
> - filter->fw_l2_filter_id = filter1->fw_l2_filter_id;
> if (filter->filter_type == HWRM_CFA_EM_FILTER)
> filter->flags =
> HWRM_CFA_EM_FLOW_ALLOC_INPUT_FLAGS_DROP;
> - else
> + else if (filter->filter_type == HWRM_CFA_NTUPLE_FILTER)
> filter->flags =
> HWRM_CFA_NTUPLE_FILTER_ALLOC_INPUT_FLAGS_DROP;
> +
> + bnxt_update_filter_flags_en(filter, filter1);
This function gets three parameter [1], you are breaking the build here and
fixing it later in the patches, I will fix this while merging.
But please test patch by patch build next time.
[1]
bnxt_update_filter_flags_en(filter, filter1, use_ntuple);
Re: [dpdk-dev] [PATCH v2 00/20] bnxt patchset to improve rte flow support
On 10/3/2019 12:25 AM, Ajit Khaparde wrote:
> Among other changes, this patchset adds support to:
> - create filters with RSS action.
> - create source MAC filters.
> - use user provided priority to place rule appropriately in HW.
>
> This patch has been rebased to dpdk-next-net commit
> 8587a8b9eddefa39e4ceac7e9385efcc5e73307c
>
> Please apply.
>
>
> Ajit Khaparde (13):
> net/bnxt: return standard error codes for HWRM command
> net/bnxt: refactor code to allow dynamic creation of VNIC
> net/bnxt: allow flow creation when RSS is enabled
> net/bnxt: add support to create SMAC and inner DMAC filters
> net/bnxt: add support for RSS action
> net/bnxt: parse priority attribute for flow creation
> net/bnxt: delete and flush L2 filters cleanly
> net/bnxt: cleanup vnic after flow validate
> net/bnxt: allow only unicast MAC address filter creation
> net/bnxt: check device is started before flow creation
> net/bnxt: handle cleanup if flow creation fails
> net/bnxt: drop untagged frames when specified
> net/bnxt: handle flow flush handling
>
> Kalesh AP (2):
> net/bnxt: fix an issue in setting default MAC address
> net/bnxt: fix multicast filter programming
>
> Rahul Gupta (1):
> net/bnxt: properly handle ring cleanup in case of error
>
> Somnath Kotur (1):
> net/bnxt: check for invalid VNIC ID in vnic tpa cfg
>
> Venkat Duvvuru (3):
> net/bnxt: validate RSS hash key length
> net/bnxt: synchronize between flow related functions
> net/bnxt: fix VLAN filtering code path
32-bit build error [1] fixed while merging, please confirm the fix in the repo.
[1]
In file included from .../drivers/net/bnxt/bnxt_flow.c:14:
.../drivers/net/bnxt/bnxt_flow.c: In function ‘bnxt_update_filter_flags_en’:
.../drivers/net/bnxt/bnxt.h:579:50: error: format ‘%lx’ expects argument of type
‘long unsigned int’, but argument 6 has type ‘uint64_t’ {aka ‘long long unsigned
int’} [-Werror=format=]
579 | rte_log(RTE_LOG_ ## level, bnxt_logtype_driver, "%s(): " fmt, \
| ^~~~
.../drivers/net/bnxt/bnxt.h:583:2: note: in expansion of macro ‘PMD_DRV_LOG_RAW’
583 | PMD_DRV_LOG_RAW(level, fmt, ## args)
| ^~~
.../drivers/net/bnxt/bnxt_flow.c:997:2: note: in expansion of macro
‘PMD_DRV_LOG’
997 | PMD_DRV_LOG(DEBUG, "l2_filter: %p fw_l2_filter_id %lx l2_ref_cnt %d\n",
| ^~~
.../drivers/net/bnxt/bnxt_flow.c:997:54: note: format string is defined here
997 | PMD_DRV_LOG(DEBUG, "l2_filter: %p fw_l2_filter_id %lx l2_ref_cnt %d\n",
|~~^
| |
| long unsigned int
|%llx
[dpdk-dev] [PATCH 2/6] examples/l3fwd-vf: remove example from DPDK
The main l3fwd app should work with both PF and VF devices, so remove the VF-only l3fwd example. Signed-off-by: Bruce Richardson --- MAINTAINERS |3 - doc/guides/sample_app_ug/index.rst|1 - .../sample_app_ug/l3_forward_virtual.rst | 98 -- examples/Makefile |1 - examples/l3fwd-vf/Makefile| 62 - examples/l3fwd-vf/main.c | 1072 - examples/l3fwd-vf/meson.build | 12 - examples/meson.build |2 +- 8 files changed, 1 insertion(+), 1250 deletions(-) delete mode 100644 doc/guides/sample_app_ug/l3_forward_virtual.rst delete mode 100644 examples/l3fwd-vf/Makefile delete mode 100644 examples/l3fwd-vf/main.c delete mode 100644 examples/l3fwd-vf/meson.build diff --git a/MAINTAINERS b/MAINTAINERS index 330a4d77d..92c3f6af4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1458,9 +1458,6 @@ F: examples/l2fwd-cat/ F: examples/l3fwd/ F: doc/guides/sample_app_ug/l3_forward.rst -F: examples/l3fwd-vf/ -F: doc/guides/sample_app_ug/l3_forward_virtual.rst - F: examples/link_status_interrupt/ F: doc/guides/sample_app_ug/link_status_intr.rst diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index 076346a60..d212f81fe 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -29,7 +29,6 @@ Sample Applications User Guides l3_forward l3_forward_power_man l3_forward_access_ctrl -l3_forward_virtual link_status_intr load_balancer server_node_efd diff --git a/doc/guides/sample_app_ug/l3_forward_virtual.rst b/doc/guides/sample_app_ug/l3_forward_virtual.rst deleted file mode 100644 index 21eab8da3..0 --- a/doc/guides/sample_app_ug/l3_forward_virtual.rst +++ /dev/null @@ -1,98 +0,0 @@ -.. SPDX-License-Identifier: BSD-3-Clause -Copyright(c) 2010-2014 Intel Corporation. - -L3 Forwarding in a Virtualization Environment Sample Application - - -The L3 Forwarding in a Virtualization Environment sample application is a simple example of packet processing using the DPDK. -The application performs L3 forwarding that takes advantage of Single Root I/O Virtualization (SR-IOV) features -in a virtualized environment. - -Overview - - -The application demonstrates the use of the hash and LPM libraries in the DPDK to implement packet forwarding. -The initialization and run-time paths are very similar to those of the :doc:`l3_forward`. -The forwarding decision is taken based on information read from the input packet. - -The lookup method is either hash-based or LPM-based and is selected at compile time. -When the selected lookup method is hash-based, a hash object is used to emulate the flow classification stage. -The hash object is used in correlation with the flow table to map each input packet to its flow at runtime. - -The hash lookup key is represented by the DiffServ 5-tuple composed of the following fields read from the input packet: -Source IP Address, Destination IP Address, Protocol, Source Port and Destination Port. -The ID of the output interface for the input packet is read from the identified flow table entry. -The set of flows used by the application is statically configured and loaded into the hash at initialization time. -When the selected lookup method is LPM based, an LPM object is used to emulate the forwarding stage for IPv4 packets. -The LPM object is used as the routing table to identify the next hop for each input packet at runtime. - -The LPM lookup key is represented by the Destination IP Address field read from the input packet. -The ID of the output interface for the input packet is the next hop returned by the LPM lookup. -The set of LPM rules used by the application is statically configured and loaded into the LPM object at the initialization time. - -.. note:: - -Please refer to :ref:`l2_fwd_vf_setup` for virtualized test case setup. - -Compiling the Application -- - -To compile the sample application see :doc:`compiling`. - -The application is located in the ``l3fwd-vf`` sub-directory. - -Running the Application - -The application has a number of command line options: - -.. code-block:: console - -./build/l3fwd-vf [EAL options] -- -p PORTMASK --config(port,queue,lcore)[,(port,queue,lcore)] [--no-numa] - -where, - -* --p PORTMASK: Hexadecimal bitmask of ports to configure - -* --config (port,queue,lcore)[,(port,queue,lcore]: determines which queues from which ports are mapped to which cores - -* --no-numa: optional, disables numa awareness - -For example, consider a dual processor socket platform with 8 physical cores, where cores 0-7 and 16-23 appear on socket 0, -while cores 8-15 and 24-31 appear on socket 1. - -To enable L3 forwarding between
[dpdk-dev] [PATCH 0/6] remove a few example applications
As discussed by the DPDK technical board e.g. [1][2] and on the DPDK mailing list [3], we have a lot of example applications shipped with DPDK - a number which increases with each DPDK release, and not all of which are probably needed any more. Therefore, this set removes 5 example applications from the repository. The removal of each app is relatively straight-forward, though the use of a table in the intro section of the sample app guide document makes removing each app individually more difficult, as the table needs to be reformed. Rather than increasing the diff by reformatting the table each time, or the opposite approach of doing all table removals in one shot at the end of the set, we have taken a compromise approach here, and each example table entry is cleared once the example is removed, and the table is finally rebalanced once at the end, by just compressing up the spaces on each side. [1] https://mails.dpdk.org/archives/dev/2019-May/132288.html [2] https://mails.dpdk.org/archives/dev/2019-June/135847.html [3] https://mails.dpdk.org/archives/dev/2019-July/138676.html Bruce Richardson (3): examples/exception_path: remove example from DPDK examples/l3fwd-vf: remove example from DPDK doc: close up gaps in sample app guide table Ciara Power (3): examples/quota-watermark: remove example from DPDK examples/netmap-compat: remove example from DPDK examples/load_balancer: remove example from DPDK MAINTAINERS | 15 - doc/guides/sample_app_ug/exception_path.rst | 281 - doc/guides/sample_app_ug/index.rst|5 - doc/guides/sample_app_ug/intro.rst| 30 +- .../sample_app_ug/l3_forward_virtual.rst | 98 -- doc/guides/sample_app_ug/load_balancer.rst| 201 .../sample_app_ug/netmap_compatibility.rst| 130 -- doc/guides/sample_app_ug/quota_watermark.rst | 465 --- examples/Makefile |5 - examples/exception_path/Makefile | 57 - examples/exception_path/main.c| 589 - examples/exception_path/meson.build | 11 - examples/l3fwd-vf/Makefile| 62 - examples/l3fwd-vf/main.c | 1072 - examples/l3fwd-vf/meson.build | 12 - examples/load_balancer/Makefile | 62 - examples/load_balancer/config.c | 1030 examples/load_balancer/init.c | 520 examples/load_balancer/main.c | 76 -- examples/load_balancer/main.h | 351 -- examples/load_balancer/meson.build| 12 - examples/load_balancer/runtime.c | 642 -- examples/meson.build |9 +- examples/netmap_compat/Makefile | 22 - examples/netmap_compat/bridge/Makefile| 35 - examples/netmap_compat/bridge/bridge.c| 343 -- examples/netmap_compat/lib/compat_netmap.c| 899 -- examples/netmap_compat/lib/compat_netmap.h| 51 - examples/netmap_compat/meson.build| 10 - examples/netmap_compat/netmap/netmap.h| 289 - examples/netmap_compat/netmap/netmap_user.h | 95 -- examples/quota_watermark/Makefile | 16 - examples/quota_watermark/include/conf.h | 19 - examples/quota_watermark/meson.build | 10 - examples/quota_watermark/qw/Makefile | 22 - examples/quota_watermark/qw/args.c| 78 -- examples/quota_watermark/qw/args.h| 12 - examples/quota_watermark/qw/init.c| 164 --- examples/quota_watermark/qw/init.h| 14 - examples/quota_watermark/qw/main.c| 365 -- examples/quota_watermark/qw/main.h| 31 - examples/quota_watermark/qwctl/Makefile | 22 - examples/quota_watermark/qwctl/commands.c | 196 --- examples/quota_watermark/qwctl/commands.h | 12 - examples/quota_watermark/qwctl/qwctl.c| 67 -- examples/quota_watermark/qwctl/qwctl.h| 12 - 46 files changed, 17 insertions(+), 8502 deletions(-) delete mode 100644 doc/guides/sample_app_ug/exception_path.rst delete mode 100644 doc/guides/sample_app_ug/l3_forward_virtual.rst delete mode 100644 doc/guides/sample_app_ug/load_balancer.rst delete mode 100644 doc/guides/sample_app_ug/netmap_compatibility.rst delete mode 100644 doc/guides/sample_app_ug/quota_watermark.rst delete mode 100644 examples/exception_path/Makefile delete mode 100644 examples/exception_path/main.c delete mode 100644 examples/exception_path/meson.build delete mode 100644 examples/l3fwd-vf/Makefile delete mode 100644 examples/l3fwd-vf/main.c delete mode 100644 examples/l3fwd-vf/meson.build delete mode 100644 examples/load_balancer/Makefile delete mode 100644 examples/load_balancer/config.c delete mode 100644 examples/load_balancer/init.c delete mode 100644 examples/l
[dpdk-dev] [PATCH 1/6] examples/exception_path: remove example from DPDK
The example app shows the use of TUN/TAP with DPDK, but DPDK has a built-in TAP PMD, so this example is obsolete and so can be removed. Signed-off-by: Bruce Richardson --- MAINTAINERS | 3 - doc/guides/sample_app_ug/exception_path.rst | 281 -- doc/guides/sample_app_ug/index.rst | 1 - doc/guides/sample_app_ug/intro.rst | 2 +- examples/Makefile | 1 - examples/exception_path/Makefile| 57 -- examples/exception_path/main.c | 589 examples/exception_path/meson.build | 11 - examples/meson.build| 2 +- 9 files changed, 2 insertions(+), 945 deletions(-) delete mode 100644 doc/guides/sample_app_ug/exception_path.rst delete mode 100644 examples/exception_path/Makefile delete mode 100644 examples/exception_path/main.c delete mode 100644 examples/exception_path/meson.build diff --git a/MAINTAINERS b/MAINTAINERS index b3d9aaddd..330a4d77d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1427,9 +1427,6 @@ Other Example Applications F: examples/ethtool/ F: doc/guides/sample_app_ug/ethtool.rst -F: examples/exception_path/ -F: doc/guides/sample_app_ug/exception_path.rst - M: Marko Kovacevic F: examples/fips_validation/ F: doc/guides/sample_app_ug/fips_validation.rst diff --git a/doc/guides/sample_app_ug/exception_path.rst b/doc/guides/sample_app_ug/exception_path.rst deleted file mode 100644 index a5590870c..0 --- a/doc/guides/sample_app_ug/exception_path.rst +++ /dev/null @@ -1,281 +0,0 @@ -.. SPDX-License-Identifier: BSD-3-Clause -Copyright(c) 2010-2014 Intel Corporation. - -Exception Path Sample Application -= - -The Exception Path sample application is a simple example that demonstrates the use of the DPDK -to set up an exception path for packets to go through the Linux* kernel. -This is done by using virtual TAP network interfaces. -These can be read from and written to by the DPDK application and -appear to the kernel as a standard network interface. - -Overview - - -The application creates two threads for each NIC port being used. -One thread reads from the port and writes the data unmodified to a thread-specific TAP interface. -The second thread reads from a TAP interface and writes the data unmodified to the NIC port. - -The packet flow through the exception path application is as shown in the following figure. - -.. _figure_exception_path_example: - -.. figure:: img/exception_path_example.* - - Packet Flow - - -To make throughput measurements, kernel bridges must be setup to forward data between the bridges appropriately. - -Compiling the Application -- - -To compile the sample application see :doc:`compiling`. - -The application is located in the ``exception_path`` sub-directory. - -Running the Application - -The application requires a number of command line options: - -.. code-block:: console - -.build/exception_path [EAL options] -- -p PORTMASK -i IN_CORES -o OUT_CORES - -where: - -* -p PORTMASK: A hex bitmask of ports to use - -* -i IN_CORES: A hex bitmask of cores which read from NIC - -* -o OUT_CORES: A hex bitmask of cores which write to NIC - -Refer to the *DPDK Getting Started Guide* for general information on running applications -and the Environment Abstraction Layer (EAL) options. - -The number of bits set in each bitmask must be the same. -The coremask -c or the corelist -l parameter of the EAL options should include IN_CORES and OUT_CORES. -The same bit must not be set in IN_CORES and OUT_CORES. -The affinities between ports and cores are set beginning with the least significant bit of each mask, that is, -the port represented by the lowest bit in PORTMASK is read from by the core represented by the lowest bit in IN_CORES, -and written to by the core represented by the lowest bit in OUT_CORES. - -For example to run the application with two ports and four cores: - -.. code-block:: console - -./build/exception_path -l 0-3 -n 4 -- -p 3 -i 3 -o c - -Getting Statistics -~~ - -While the application is running, statistics on packets sent and -received can be displayed by sending the SIGUSR1 signal to the application from another terminal: - -.. code-block:: console - -killall -USR1 exception_path - -The statistics can be reset by sending a SIGUSR2 signal in a similar way. - -Explanation - -The following sections provide some explanation of the code. - -Initialization -~~ - -Setup of the mbuf pool, driver and queues is similar to the setup done in the :ref:`l2_fwd_app_real_and_virtual`. -In addition, the TAP interfaces must also be created. -A TAP interface is created for each lcore that is being used. -The code for creating the TAP interface is as follows: - -.. code-block:: c - -/* - * Create a tap network interface, or use existing o
[dpdk-dev] [PATCH 3/6] examples/quota-watermark: remove example from DPDK
From: Ciara Power Original DPDK rings code had explicit support for a single watermark per-ring, but more recent releases of DPDK had a more general mechanism where each enqueue or dequeue call could return the remaining elements/free-slots in the ring. Therefore, this example is not as relevant as before and can be removed. Signed-off-by: Ciara Power --- MAINTAINERS | 3 - doc/guides/sample_app_ug/index.rst | 1 - doc/guides/sample_app_ug/intro.rst | 2 +- doc/guides/sample_app_ug/quota_watermark.rst | 465 --- examples/Makefile| 1 - examples/meson.build | 2 +- examples/quota_watermark/Makefile| 16 - examples/quota_watermark/include/conf.h | 19 - examples/quota_watermark/meson.build | 10 - examples/quota_watermark/qw/Makefile | 22 - examples/quota_watermark/qw/args.c | 78 examples/quota_watermark/qw/args.h | 12 - examples/quota_watermark/qw/init.c | 164 --- examples/quota_watermark/qw/init.h | 14 - examples/quota_watermark/qw/main.c | 365 --- examples/quota_watermark/qw/main.h | 31 -- examples/quota_watermark/qwctl/Makefile | 22 - examples/quota_watermark/qwctl/commands.c| 196 examples/quota_watermark/qwctl/commands.h| 12 - examples/quota_watermark/qwctl/qwctl.c | 67 --- examples/quota_watermark/qwctl/qwctl.h | 12 - 21 files changed, 2 insertions(+), 1512 deletions(-) delete mode 100644 doc/guides/sample_app_ug/quota_watermark.rst delete mode 100644 examples/quota_watermark/Makefile delete mode 100644 examples/quota_watermark/include/conf.h delete mode 100644 examples/quota_watermark/meson.build delete mode 100644 examples/quota_watermark/qw/Makefile delete mode 100644 examples/quota_watermark/qw/args.c delete mode 100644 examples/quota_watermark/qw/args.h delete mode 100644 examples/quota_watermark/qw/init.c delete mode 100644 examples/quota_watermark/qw/init.h delete mode 100644 examples/quota_watermark/qw/main.c delete mode 100644 examples/quota_watermark/qw/main.h delete mode 100644 examples/quota_watermark/qwctl/Makefile delete mode 100644 examples/quota_watermark/qwctl/commands.c delete mode 100644 examples/quota_watermark/qwctl/commands.h delete mode 100644 examples/quota_watermark/qwctl/qwctl.c delete mode 100644 examples/quota_watermark/qwctl/qwctl.h diff --git a/MAINTAINERS b/MAINTAINERS index 92c3f6af4..7be363327 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1474,9 +1474,6 @@ F: doc/guides/sample_app_ug/performance_thread.rst F: examples/ptpclient/ -F: examples/quota_watermark/ -F: doc/guides/sample_app_ug/quota_watermark.rst - M: Bruce Richardson M: John McNamara F: examples/rxtx_callbacks/ diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index d212f81fe..dafe8553f 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -36,7 +36,6 @@ Sample Applications User Guides multi_process qos_metering qos_scheduler -quota_watermark timer packet_ordering vmdq_dcb_forwarding diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst index 7299253bf..6e0af6301 100644 --- a/doc/guides/sample_app_ug/intro.rst +++ b/doc/guides/sample_app_ug/intro.rst @@ -43,7 +43,7 @@ applications that are available in the examples directory of DPDK: +---+--+ | Hello World | QoS Scheduler | +---+--+ -| Internet Protocol (IP) Fragmentation | Quota and Watermark | +| Internet Protocol (IP) Fragmentation | | +---+--+ | IP Pipeline | RX/TX Callbacks | +---+--+ diff --git a/doc/guides/sample_app_ug/quota_watermark.rst b/doc/guides/sample_app_ug/quota_watermark.rst deleted file mode 100644 index 125e6fb73..0 --- a/doc/guides/sample_app_ug/quota_watermark.rst +++ /dev/null @@ -1,465 +0,0 @@ -.. SPDX-License-Identifier: BSD-3-Clause -Copyright(c) 2010-2017 Intel Corporation. - -Quota and Watermark Sample Application -== - -The Quota and Watermark sample application is a simple example of packet -processing using Data Plane Development Kit (DPDK) that showcases the use -of a quota as the maximum number of packets enqueue/dequeue at a time and -low and high thresholds, or watermarks, to signal low and high ring usage -respectively. - -Additi
[dpdk-dev] [PATCH 4/6] examples/netmap-compat: remove example from DPDK
From: Ciara Power Rather than providing a shim layer on top of netmap, we should instead encourage users to create apps using the DPDK APIs directly. Signed-off-by: Ciara Power --- MAINTAINERS | 3 - doc/guides/sample_app_ug/index.rst| 1 - doc/guides/sample_app_ug/intro.rst| 2 +- .../sample_app_ug/netmap_compatibility.rst| 130 --- examples/Makefile | 1 - examples/meson.build | 2 +- examples/netmap_compat/Makefile | 22 - examples/netmap_compat/bridge/Makefile| 35 - examples/netmap_compat/bridge/bridge.c| 343 --- examples/netmap_compat/lib/compat_netmap.c| 899 -- examples/netmap_compat/lib/compat_netmap.h| 51 - examples/netmap_compat/meson.build| 10 - examples/netmap_compat/netmap/netmap.h| 289 -- examples/netmap_compat/netmap/netmap_user.h | 95 -- 14 files changed, 2 insertions(+), 1881 deletions(-) delete mode 100644 doc/guides/sample_app_ug/netmap_compatibility.rst delete mode 100644 examples/netmap_compat/Makefile delete mode 100644 examples/netmap_compat/bridge/Makefile delete mode 100644 examples/netmap_compat/bridge/bridge.c delete mode 100644 examples/netmap_compat/lib/compat_netmap.c delete mode 100644 examples/netmap_compat/lib/compat_netmap.h delete mode 100644 examples/netmap_compat/meson.build delete mode 100644 examples/netmap_compat/netmap/netmap.h delete mode 100644 examples/netmap_compat/netmap/netmap_user.h diff --git a/MAINTAINERS b/MAINTAINERS index 7be363327..6b9fa4dc2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1464,9 +1464,6 @@ F: doc/guides/sample_app_ug/link_status_intr.rst F: examples/load_balancer/ F: doc/guides/sample_app_ug/load_balancer.rst -F: examples/netmap_compat/ -F: doc/guides/sample_app_ug/netmap_compatibility.rst - L-threads - EXPERIMENTAL M: John McNamara F: examples/performance-thread/ diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index dafe8553f..5f4924df6 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -43,7 +43,6 @@ Sample Applications User Guides vhost_scsi vhost_crypto vdpa -netmap_compatibility ip_pipeline test_pipeline eventdev_pipeline diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst index 6e0af6301..39af887da 100644 --- a/doc/guides/sample_app_ug/intro.rst +++ b/doc/guides/sample_app_ug/intro.rst @@ -31,7 +31,7 @@ applications that are available in the examples directory of DPDK: .. table:: **Some of the DPDK Sample applications** +---+--+ -| Bonding | Netmap Compatibility | +| Bonding | | +---+--+ | Command Line | Packet Ordering | +---+--+ diff --git a/doc/guides/sample_app_ug/netmap_compatibility.rst b/doc/guides/sample_app_ug/netmap_compatibility.rst deleted file mode 100644 index 219613e2a..0 --- a/doc/guides/sample_app_ug/netmap_compatibility.rst +++ /dev/null @@ -1,130 +0,0 @@ -.. SPDX-License-Identifier: BSD-3-Clause -Copyright(c) 2010-2014 Intel Corporation. - -Netmap Compatibility Sample Application -=== - -Introduction - - -The Netmap compatibility library provides a minimal set of APIs to give programs written against the Netmap APIs -the ability to be run, with minimal changes to their source code, using the DPDK to perform the actual packet I/O. - -Since Netmap applications use regular system calls, like ``open()``, ``ioctl()`` and -``mmap()`` to communicate with the Netmap kernel module performing the packet I/O, -the ``compat_netmap`` library provides a set of similar APIs to use in place of those system calls, -effectively turning a Netmap application into a DPDK application. - -The provided library is currently minimal and doesn't support all the features that Netmap supports, -but is enough to run simple applications, such as the bridge example detailed below. - -Knowledge of Netmap is required to understand the rest of this section. -Please refer to the Netmap distribution for details about Netmap. - -Available APIs --- - -The library provides the following drop-in replacements for system calls usually used in Netmap applications: - -* ``rte_netmap_close()`` - -* ``rte_netmap_ioctl()`` - -* ``rte_netmap_open()`` - -* ``rte_netmap_mmap()`` - -* ``rte_netmap_poll()`` - -They use the same signature as their libc counterparts, and can be used as drop-in rep
[dpdk-dev] [PATCH 6/6] doc: close up gaps in sample app guide table
Following the removal of some sample applications, close up the gaps introduced in the table so that it is formatted nicely for the next release. Signed-off-by: Bruce Richardson --- doc/guides/sample_app_ug/intro.rst | 30 +- 1 file changed, 13 insertions(+), 17 deletions(-) diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst index 981e50f94..dcfe70db2 100644 --- a/doc/guides/sample_app_ug/intro.rst +++ b/doc/guides/sample_app_ug/intro.rst @@ -31,37 +31,33 @@ applications that are available in the examples directory of DPDK: .. table:: **Some of the DPDK Sample applications** +---+--+ -| Bonding | | +| Bonding | Packet Ordering | +---+--+ -| Command Line | Packet Ordering | +| Command Line | Performance Thread | +---+--+ -| Distributor | Performance Thread | +| Distributor | Precision Time Protocol (PTP) Client | +---+--+ -| Ethtool | Precision Time Protocol (PTP) Client | - +---+--+ -| | Quality of Service (QoS) Metering| +| Ethtool | Quality of Service (QoS) Metering| +---+--+ | Hello World | QoS Scheduler | +---+--+ -| Internet Protocol (IP) Fragmentation | | - +---+--+ -| IP Pipeline | RX/TX Callbacks | +| Internet Protocol (IP) Fragmentation | RX/TX Callbacks | +---+--+ -| IP Reassembly | Server node EFD | +| IP Pipeline | Server node EFD | +---+--+ -| IPsec Security Gateway| Basic Forwarding/Skeleton App | +| IP Reassembly | Basic Forwarding/Skeleton App | +---+--+ -| IPv4 multicast| Tunnel End Point (TEP) termination | +| IPsec Security Gateway| Tunnel End Point (TEP) termination | +---+--+ -| Kernel NIC Interface | Timer | +| IPv4 multicast| Timer | +---+--+ -| Network Layer 2 Forwarding + variants | Vhost | +| Kernel NIC Interface | Vhost | +---+--+ -| Network Layer 3 Forwarding + variants | Vhost Xen | +| Network Layer 2 Forwarding + variants | Vhost Xen | +---+--+ -| Link Status Interrupt | VMDQ Forwarding | +| Network Layer 3 Forwarding + variants | VMDQ Forwarding | +---+--+ -| | VMDQ and DCB Forwarding | +| Link Status Interrupt | VMDQ and DCB Forwarding | +---+--+ | Multi-process | VM Power Management | +---+--+ -- 2.21.0
[dpdk-dev] [PATCH 5/6] examples/load_balancer: remove example from DPDK
From: Ciara Power This example can be removed because DPDK now has a range of libraries, especially rte_eventdev, that did not exist previously for load balancing, making this less relevant. Also, modern NIC cards have greater ability to do load balancing, e.g. using RSS, over a wider range of fields than earlier cards did. Signed-off-by: Ciara Power --- MAINTAINERS|3 - doc/guides/sample_app_ug/index.rst |1 - doc/guides/sample_app_ug/intro.rst |2 +- doc/guides/sample_app_ug/load_balancer.rst | 201 examples/Makefile |1 - examples/load_balancer/Makefile| 62 -- examples/load_balancer/config.c| 1030 examples/load_balancer/init.c | 520 -- examples/load_balancer/main.c | 76 -- examples/load_balancer/main.h | 351 --- examples/load_balancer/meson.build | 12 - examples/load_balancer/runtime.c | 642 examples/meson.build |1 - 13 files changed, 1 insertion(+), 2901 deletions(-) delete mode 100644 doc/guides/sample_app_ug/load_balancer.rst delete mode 100644 examples/load_balancer/Makefile delete mode 100644 examples/load_balancer/config.c delete mode 100644 examples/load_balancer/init.c delete mode 100644 examples/load_balancer/main.c delete mode 100644 examples/load_balancer/main.h delete mode 100644 examples/load_balancer/meson.build delete mode 100644 examples/load_balancer/runtime.c diff --git a/MAINTAINERS b/MAINTAINERS index 6b9fa4dc2..3db771bd7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1461,9 +1461,6 @@ F: doc/guides/sample_app_ug/l3_forward.rst F: examples/link_status_interrupt/ F: doc/guides/sample_app_ug/link_status_intr.rst -F: examples/load_balancer/ -F: doc/guides/sample_app_ug/load_balancer.rst - L-threads - EXPERIMENTAL M: John McNamara F: examples/performance-thread/ diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index 5f4924df6..191eebb56 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -30,7 +30,6 @@ Sample Applications User Guides l3_forward_power_man l3_forward_access_ctrl link_status_intr -load_balancer server_node_efd service_cores multi_process diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst index 39af887da..981e50f94 100644 --- a/doc/guides/sample_app_ug/intro.rst +++ b/doc/guides/sample_app_ug/intro.rst @@ -61,7 +61,7 @@ applications that are available in the examples directory of DPDK: +---+--+ | Link Status Interrupt | VMDQ Forwarding | +---+--+ -| Load Balancer | VMDQ and DCB Forwarding | +| | VMDQ and DCB Forwarding | +---+--+ | Multi-process | VM Power Management | +---+--+ diff --git a/doc/guides/sample_app_ug/load_balancer.rst b/doc/guides/sample_app_ug/load_balancer.rst deleted file mode 100644 index 8f2abdfb8..0 --- a/doc/guides/sample_app_ug/load_balancer.rst +++ /dev/null @@ -1,201 +0,0 @@ -.. SPDX-License-Identifier: BSD-3-Clause -Copyright(c) 2010-2014 Intel Corporation. - -Load Balancer Sample Application - - -The Load Balancer sample application demonstrates the concept of isolating the packet I/O task -from the application-specific workload. -Depending on the performance target, -a number of logical cores (lcores) are dedicated to handle the interaction with the NIC ports (I/O lcores), -while the rest of the lcores are dedicated to performing the application processing (worker lcores). -The worker lcores are totally oblivious to the intricacies of the packet I/O activity and -use the NIC-agnostic interface provided by software rings to exchange packets with the I/O cores. - -Overview - - -The architecture of the Load Balance application is presented in the following figure. - -.. _figure_load_bal_app_arch: - -.. figure:: img/load_bal_app_arch.* - - Load Balancer Application Architecture - - -For the sake of simplicity, the diagram illustrates a specific case of two I/O RX and two I/O TX lcores off loading the packet I/O -overhead incurred by four NIC ports from four worker cores, with each I/O lcore handling RX/TX for two NIC ports. - -I/O RX Logical Cores - - -Each I/O RX lcore performs packet RX from its assigned NIC RX rings and then distributes the receive
[dpdk-dev] 18.11.3 (LTS) patches review and test
Hi all, Here is a list of patches targeted for LTS release 18.11.3. The planned date for the final release is 14th October. Please note the commits since RC1 below. They are primarily to address some build issues for 32-bit with meson and FreeBSD. As such, I would expect that most RC1 testing is still valid and does not need to be repeated. Please help with testing and validation of your use cases and report any issues/results in reply to this mail. For the final release the fixes and reported validations will be added to the release notes. A release candidate tarball can be found at: https://dpdk.org/browse/dpdk-stable/tag/?id=v18.11.3-rc2 These patches are located at branch 18.11 of dpdk-stable repo: https://dpdk.org/browse/dpdk-stable/ Commits since RC1: 9e7c637c6 build: add libatomic dependency for 32-bit clang 6c576d41c mem: mark unused function in 32-bit builds 7ffe32a15 build: remove unnecessary large file support defines 5c3c20a8a build: enable large file support on 32-bit 5633216d4 net/nfp: disable for 32-bit meson builds c97d4cd35 build: set RTE_ARCH_64 based on pointer size 86e56d5f9 ethdev: fix endian annotation for SPI item d908ee9de build: enable BSD features visibility for FreeBSD Thanks. Kevin Traynor --- Aaron Conole (2): test/flow_classify: fix undefined behavior acl: fix undefined behavior of bit shifts Adam Dybkowski (1): compress/zlib: fix error handling Aideen McLoughlin (1): net/pcap: fix possible mbuf double freeing Ajit Khaparde (6): net/bnxt: fix TSO net/bnxt: check for error conditions in Tx path net/bnxt: fix RSS RETA indirection table ops net/bnxt: save the number of EM flow count net/bnxt: fix compiler warning net/bnxt: remove unnecessary interrupt disable Akash Saxena (1): crypto/openssl: remove useless check before freeing Ali Alnubani (3): examples/ip_fragmentation: fix Tx queues init net/mlx5: fix 32-bit build doc: fix link about bifurcated model in Linux guide Amit Gupta (2): net/thunderx: fix crash on detach app/testpmd: fix latency stats deinit on signal Anatoly Burakov (4): eal/freebsd: fix init completion eal/freebsd: fix config creation vfio: use contiguous mapping for IOVA as VA mode test: enable installing app with meson Andrew Lee (1): net/sfc/base: fix signed/unsigned mismatch Andrew Rybchenko (16): ethdev: fix Tx prepare documentation to use positive errno net/atlantic: fix Tx prepare to set positive rte_errno net/e1000: fix Tx prepare to set positive rte_errno net/enic: fix Tx prepare to set positive rte_errno net/fm10k: fix Tx prepare to set positive rte_errno net/i40e: fix Tx prepare to set positive rte_errno net/iavf: fix Tx prepare to set positive rte_errno net/ixgbe: fix Tx prepare to set positive rte_errno net/qede: fix Tx prepare to set positive rte_errno net/vmxnet3: fix Tx prepare to set positive rte_errno ethdev: avoid error on PCI unplug of closed port net/sfc: ensure that device is closed on removal ethdev: avoid getting uninitialized info for bad port net/sfc: fix power of 2 round up when align has smaller type net/sfc: fix align to power of 2 when align has smaller type net/sfc: unify power of 2 alignment check macro Andrius Sirvys (2): usertools: replace unsafe input function usertools: fix input handling in telemetry script Andy Pei (1): net/i40e: fix crash when TxQ/RxQ set to 0 in VF Ankur Dwivedi (1): app/crypto-perf: fix CSV format Arek Kusztal (2): crypto/openssl: fix usage of non constant time memcmp crypto/openssl: fix free of asymmetric crypto keys Asaf Penso (2): net/mlx5: fix condition for link update fallback net/mlx5: check memory allocation in flow creation Bao-Long Tran (2): examples/l3fwd-vf: remove unused Rx/Tx configuration doc: remove useless Rx configuration in l2fwd guide Bernard Iremonger (1): flow_classify: fix out-of-bounds access Bruce Richardson (11): examples: fix make clean when using pkg-config kernel/freebsd: fix module build on latest head test: add rawdev autotest to meson examples: fix pkg-config detection with older make doc: fix build with latest meson build: set RTE_ARCH_64 based on pointer size net/nfp: disable for 32-bit meson builds build: enable large file support on 32-bit build: remove unnecessary large file support defines mem: mark unused function in 32-bit builds build: add libatomic dependency for 32-bit clang Chenbo Xia (1): crypto/virtio: check PCI config read Congwen Zhang (1): net/ixgbe/base: fix product version check David Harton (1): net/ena: fix admin CQ polling for 32-bit David Hunt (2): examples/power: fix FreeBSD meson lib dependency examples/power: fix strcpy buffer overrun
Re: [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs
> -Original Message-
> From: Stephen Hemminger
> Sent: Monday 30 September 2019 18:12
> To: Loftus, Ciara
> Cc: dev@dpdk.org; Ye, Xiaolong ; Laatz, Kevin
> ; Richardson, Bruce
> Subject: Re: [dpdk-dev] [PATCH v2 2/3] net/af_xdp: support pinning of IRQs
>
> On Mon, 30 Sep 2019 16:42:04 +
> Ciara Loftus wrote:
>
> > +/* drivers supported for the queue_irq option */
> > +enum supported_drivers {
> > + I40E_DRIVER,
> > + IXGBE_DRIVER,
> > + MLX5_DRIVER,
> > + NUM_DRIVERS
> > +};
>
> Anything device specific like this raises a red flag to me.
>
> This regex etc, seems like a huge hack. Is there a better way using
> irqbalance and smp_affinity in kernel drivers?
>
> NACK
Hi Stephen,
Thanks for looking at the patch. I understand your concern however
unfortunately I haven't been able to identify a way to achieve the desired
outcome by using your suggestions of irqbalance and smp_affinity. Did you have
something specific in mind or are aware of any generic way of retrieving
interrupt numbers for NICs regardless of vendor or range?
I think this feature is really important for the usability of this PMD. Without
it, to configure the IRQs the user has to open up /proc/interrupts, trawl
through it and identify the correct IRQ number for their given NIC and qid (the
format for which is unlikely to be known off-hand), and manually pin them by
writing the appropriate values in the appropriate format to the appropriate
file - prone to error if not automated IMO.
If the user fails to set the affinity it's probably fine for a single pmd,
however with multiple pmds all irqs will by default land on core 0 and lead to
terrible performance.
It should be possible to rework the code to remove the regexes and use a direct
string compare. Would that make the solution more palatable?
Let me know what you think.
Thanks,
Ciara
Re: [dpdk-dev] [RFC PATCH 1/9] security: introduce CPU Crypto action type and API
Hi Konstantin, > > Hi Akhil, > > > > > > > > > > > > > > > This action type allows the burst of symmetric > > > > > > > > > > > > > > crypto > > > workload > > > > > using > > > > > > > > the > > > > > > > > > > > > same > > > > > > > > > > > > > > algorithm, key, and direction being processed by CPU > cycles > > > > > > > > > > synchronously. > > > > > > > > > > > > > > This flexible action type does not require external > hardware > > > > > > > > involvement, > > > > > > > > > > > > > > having the crypto workload processed synchronously, > and is > > > > > more > > > > > > > > > > > > performant > > > > > > > > > > > > > > than Cryptodev SW PMD due to the saved cycles on > removed > > > > > "async > > > > > > > > > > mode > > > > > > > > > > > > > > simulation" as well as 3 cacheline access of the > > > > > > > > > > > > > > crypto > ops. > > > > > > > > > > > > > > > > > > > > > > > > > > Does that mean application will not call the > > > > > cryptodev_enqueue_burst > > > > > > > > and > > > > > > > > > > > > corresponding dequeue burst. > > > > > > > > > > > > > > > > > > > > > > > > Yes, instead it just call > rte_security_process_cpu_crypto_bulk(...) > > > > > > > > > > > > > > > > > > > > > > > > > It would be a new API something like process_packets > > > > > > > > > > > > > and > it > > > will > > > > > have > > > > > > > > the > > > > > > > > > > > > crypto processed packets while returning from the API? > > > > > > > > > > > > > > > > > > > > > > > > Yes, though the plan is that API will operate on raw > > > > > > > > > > > > data > buffers, > > > > > not > > > > > > > > mbufs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I still do not understand why we cannot do with the > > > conventional > > > > > > > > crypto lib > > > > > > > > > > > > only. > > > > > > > > > > > > > As far as I can understand, you are not doing any > > > > > > > > > > > > > protocol > > > > > processing > > > > > > > > or > > > > > > > > > > any > > > > > > > > > > > > value add > > > > > > > > > > > > > To the crypto processing. IMO, you just need a > synchronous > > > > > crypto > > > > > > > > > > processing > > > > > > > > > > > > API which > > > > > > > > > > > > > Can be defined in cryptodev, you don't need to > > > > > > > > > > > > > re-create a > > > crypto > > > > > > > > session > > > > > > > > > > in > > > > > > > > > > > > the name of > > > > > > > > > > > > > Security session in the driver just to do a > > > > > > > > > > > > > synchronous > > > processing. > > > > > > > > > > > > > > > > > > > > > > > > I suppose your question is why not to have > > > > > > > > > > > > rte_crypot_process_cpu_crypto_bulk(...) instead? > > > > > > > > > > > > The main reason is that would require disruptive > > > > > > > > > > > > changes in > > > existing > > > > > > > > > > cryptodev > > > > > > > > > > > > API > > > > > > > > > > > > (would cause ABI/API breakage). > > > > > > > > > > > > Session for RTE_SECURITY_ACTION_TYPE_CPU_CRYPTO > need > > > > > some > > > > > > > > extra > > > > > > > > > > > > information > > > > > > > > > > > > that normal crypto_sym_xform doesn't contain > > > > > > > > > > > > (cipher offset from the start of the buffer, might be > something > > > extra > > > > > in > > > > > > > > > > future). > > > > > > > > > > > > > > > > > > > > > > Cipher offset will be part of rte_crypto_op. > > > > > > > > > > > > > > > > > > > > fill/read (+ alloc/free) is one of the main things that > > > > > > > > > > slowdown > > > current > > > > > > > > crypto-op > > > > > > > > > > approach. > > > > > > > > > > That's why the general idea - have all data that wouldn't > > > > > > > > > > change > > > from > > > > > packet > > > > > > > > to > > > > > > > > > > packet > > > > > > > > > > included into the session and setup it once at > > > > > > > > > > session_init(). > > > > > > > > > > > > > > > > > > I agree that you cannot use crypto-op. > > > > > > > > > You can have the new API in crypto. > > > > > > > > > As per the current patch, you only need cipher_offset which > > > > > > > > > you > can > > > have > > > > > it as > > > > > > > > a parameter until > > > > > > > > > You get it approved in the crypto xform. I believe it will be > beneficial > > > in > > > > > case of > > > > > > > > other crypto cases as well. > > > > > > > > > We can have cipher offset at both places(crypto-op and > > > cipher_xform). It > > > > > will > > > > > > > > give flexibility to the user to > > > > > > > > > override it. > > > > > > > > > > > > > > > > After having another thought on your proposal: > > > > > > > > Probably we can introduce new rte_crypto_sym_xform_types for > CPU > > > > > related > > > > > > > > stuff here? > > > > > > > > > > > > > > I also thought of adding new xforms, but that wont serve the > > > > > > > purpose > for > > > > > may be all the cases. > > > > > > > You would be needing all information currently available in the > current > > > > > xforms. > >
Re: [dpdk-dev] [PATCH 01/13] ethdev: support setup function for hairpin queue
Hi Ori, @Thomas, @Ferruh, please, see question below. On 10/2/19 3:19 PM, Ori Kam wrote: Hi Andrew, Sorry it took me some time to responded, (I'm on vacation 😊) I think we are in most cases in agreement. The only open issue is the checks so please see my comments below. As soon as we get to understanding about this issue, I will start working on V2. Thanks, Ori [snip] @@ -1769,6 +1793,60 @@ int rte_eth_rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id, struct rte_mempool *mb_pool); /** + * @warning + * @b EXPERIMENTAL: this API may change, or be removed, without prior + notice + * + * Allocate and set up a hairpin receive queue for an Ethernet device. + * + * The function set up the selected queue to be used in hairpin. + * + * @param port_id + * The port identifier of the Ethernet device. + * @param rx_queue_id + * The index of the receive queue to set up. + * The value must be in the range [0, nb_rx_queue - 1] previously supplied + * to rte_eth_dev_configure(). Is any Rx queue may be setup as hairpin queue? Can it be still used for regular traffic? No if a queue is used as hairpin it can't be used for normal traffic. This is also why I like the idea of two different functions, in order to create This distinction. If so, do we need at least debug-level checks in Tx/Rx burst functions? Is it required to patch rte flow RSS action to ensure that Rx queues of only one kind are specified? What about attempt to add Rx/Tx callbacks for hairpin queues? I think the checks should be done in PMD level. Since from high level they are the same. Sorry, I don't understand why. If something could be checked on generic level, it should be done to avoid duplication in all drivers. The issue with this approach is that at the ethdev level we don't know anything about the queue. This will mean that we will need to add extra functions to query the queue type for each PMD. We could also assume that if to get type function exist in the pmd then the queue is always standard queue. So my suggestion if you would like to move the checks is to add queue type enum in the ethdev level, and add function call to query the queue type. What do you think? I would consider to use dev_data rx_queue_state and tx_queue_state to keep the information to have it directly available without extra function calls. Or add extra information. dev_data is internal and it looks like not a problem. What do you think? Call backs for Rx/Tx doesn't make sense, since the idea is to bypass the CPU. If so, I think rte_eth_add_tx_callback() should be patched to return an error if specified queue is hairpin. Same for Rx. Any other cases? Same answer as above. [snip] Andrew.
Re: [dpdk-dev] 18.11.3 (LTS) patches review and test
On 26/09/2019 08:41, Yu, PingX wrote:
> Kevin,
> FYi.
>> 2. [dpdk-stable 18.11.3] meson build error on ub1604-i86
> Q1: What are the error logs?
> Please see below Error info.
>
> Q2: Is it a regression for you? i.e. did this test pass with 18.11.2?
> No, it isn't a regression. We don't test it on 18.11.1 and 18.11.2 before,
> another the test result is still failed after testing.
> dpdk-stable V18.11.2 commitID(06c4b12a5968caea61e96f7d6bd29d2726fbe255)，test
> failed.
> dpdk-stable V18.11.1 commitID(16ece46735c9b70b7033ca7ae095930e9038d9fd)，test
> failed, the same mistake.
>
> Error info：
> ninja: Entering directory `build-gcc-static'
> [296/1419] Compiling C object
> 'drivers/a715181@@tmp_rte_common_dpaax@sta/common_dpaax_dpaax_iova_table.c.o'.
> FAILED:
> drivers/a715181@@tmp_rte_common_dpaax@sta/common_dpaax_dpaax_iova_table.c.o
> gcc -Idrivers/a715181@@tmp_rte_common_dpaax@sta -Idrivers -I../drivers
> -Idrivers/common/dpaax -I../drivers/common/dpaax -I. -I../ -Iconfig
> -I../config -Ilib/librte_eal/common -I../lib/librte_eal/common
> -Ilib/librte_eal/common/include -I../lib/librte_eal/common/include
> -Ilib/librte_eal/common/include/arch/x86
> -I../lib/librte_eal/common/include/arch/x86
> -I../lib/librte_eal/linuxapp/eal/include
> -Ilib/librte_eal/linuxapp/eal/../../../librte_compat
> -I../lib/librte_eal/linuxapp/eal/../../../librte_compat -Ilib/librte_eal
> -I../lib/librte_eal -Ilib/librte_kvargs/../librte_eal/common/include
> -I../lib/librte_kvargs/../librte_eal/common/include -Ilib/librte_kvargs
> -I../lib/librte_kvargs -Ilib/librte_compat -I../lib/librte_compat
> -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
> -Werror -O3 -include rte_config.h -Wsign-compare -Wcast-qual
> -Wno-pointer-to-int-cast -fPIC -march=native -D_GNU_SOURCE
> -DALLOW_EXPERIMENTAL_API -MD -MQ
> 'drivers/a715181@@tmp_rte_common_dpaax@sta/common_dpaax_dpaax_iova_table.c.o'
> -MF
> 'drivers/a715181@@tmp_rte_common_dpaax@sta/common_dpaax_dpaax_iova_table.c.o.d'
> -o
> 'drivers/a715181@@tmp_rte_common_dpaax@sta/common_dpaax_dpaax_iova_table.c.o'
> -c ../drivers/common/dpaax/dpaax_iova_table.c
> In file included from ../drivers/common/dpaax/dpaax_iova_table.c:8:0:
> ../drivers/common/dpaax/dpaax_iova_table.c: In function ‘read_memory_node’:
> ../drivers/common/dpaax/dpaax_logs.h:18:39: error: format ‘%lu’ expects
> argument of type ‘long unsigned int’, but argument 5 has type ‘__off64_t {aka
> long long int}’ [-Werror=format=]
> rte_log(RTE_LOG_DEBUG, dpaax_logger, "dpaax: %s(): " fmt "\n", \
>^
> ../drivers/common/dpaax/dpaax_iova_table.c:102:2: note: in expansion of macro
> ‘DPAAX_DEBUG’
> DPAAX_DEBUG("Size of device-tree mem node: %lu", statbuf.st_size);
> ^
> ../drivers/common/dpaax/dpaax_logs.h:18:39: error: format ‘%lu’ expects
> argument of type ‘long unsigned int’, but argument 5 has type ‘__off64_t {aka
> long long int}’ [-Werror=format=]
> rte_log(RTE_LOG_DEBUG, dpaax_logger, "dpaax: %s(): " fmt "\n", \
>^
> ../drivers/common/dpaax/dpaax_iova_table.c:121:3: note: in expansion of macro
> ‘DPAAX_DEBUG’
>DPAAX_DEBUG("Invalid memory node values or count. (size=%lu)",
>^
> cc1: all warnings being treated as errors [301/1419] Compiling C object
> 'lib/76b5a35@@rte_pipeline@sta/librte_pipeline_rte_table_action.c.o'.
> ninja: build stopped: subcommand failed.
>
Thanks Yu Ping, I reproduced and applied the commits to fix this. It
should be fixed now in RC2 (see other mail). If you could re-run this
test to confirm same for you, that would be great.
Kevin.
>> 3. [dpdk-stable 18.11.3] config\x86\meson.build error on WIN10
>
> Windows support was not added until DPDK 19.05.
>
> [Ping]Got it. Confirm with the test result of 18.11, we don't test
> meson.build on WIN10. Tks for your information.
>
> Regards,
> Yu Ping
>
>
> -Original Message-
> From: Kevin Traynor [mailto:ktray...@redhat.com]
> Sent: Thursday, September 26, 2019 12:07 AM
> To: Yu, PingX ; sta...@dpdk.org; dev@dpdk.org
> Cc: Akhil Goyal ; Ali Alnubani ;
> Walker, Benjamin ; David Christensen
> ; Hemant Agrawal ; Stokes,
> Ian ; Jerin Jacob ; Mcnamara, John
> ; Ju-Hyoung Lee ; Luca
> Boccassi ; Pei Zhang ; Xu, Qian Q
> ; Raslan Darawsheh ; Thomas
> Monjalon ; Peng, Yuan ; Chen,
> Zhaoyan
> Subject: 18.11.3 (LTS) patches review and test
>
> On 19/09/2019 11:22, Yu, PingX wrote:
>> Hi all,
>> Update Intel test result here.
>>
>
> Hi Yu Ping,
>
> Thanks for testing. Some comments/questions on the failures,
>
>> # Basic Intel(R) NIC testing
>> * PF(i40e): Pass
>> * PF(ixgbe): Pass
>> * VF: Pass
>> * Build or compile: 3 bugs are found.
>> 1. [dpdk-stable 18.11.3] compile error on freebsd12
>
> ok, I've figured this out and will send a patch.
>
>> 2. [dpdk-stable 18.11.3] meson build error on ub1604-i86
>
> What are the error logs? Is it a regression for you? i.e. did this
Re: [dpdk-dev] [PATCH 2/2] test/crypto: add negative test support for dpaaX
> > Signed-off-by: Hemant Agrawal > --- > app/test/test_cryptodev.c | 20 > 1 file changed, 20 insertions(+) > Added description of the patch and altered patch title. Patchset Acked-by: Akhil Goyal Applied to dpdk-next-crypto Thanks.
Re: [dpdk-dev] [PATCH] cryptodev: fix pmd allocation on multi-process
>
>
> > Primary process is responsible to initialize the data struct of each
> > crypto devices.
> >
> > Secondary process should not override this data during the
> > initialization.
> >
> > Fixes: d11b0f30df88 ("cryptodev: introduce API and framework for crypto
> > devices")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Julien Meunier
> Acked-by: Akhil Goyal
Applied to dpdk-next-crypto
Thanks.
Re: [dpdk-dev] [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by sessionless
Hi Shally,
Any more comments on this patch.
If not please Ack.
Regards,
Akhil
> -Original Message-
> From: Shally Verma
> Sent: Sunday, September 8, 2019 11:49 AM
> To: Arek Kusztal ; dev@dpdk.org
> Cc: Akhil Goyal ; fiona.tr...@intel.com; Anoob Joseph
>
> Subject: RE: [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by
> sessionless
>
> Hi Arek
>
> Only these changes looks good to me but do you have working PMD to back this?
> Also, documentation updates?
>
> Thanks
> Shally
>
> > -Original Message-
> > From: Arek Kusztal
> > Sent: Friday, September 6, 2019 5:28 PM
> > To: dev@dpdk.org
> > Cc: akhil.go...@nxp.com; fiona.tr...@intel.com; Shally Verma
> > ; Anoob Joseph ; Arek
> > Kusztal
> > Subject: [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by
> > sessionless
> >
> > External Email
> >
> > --
> > This commit adds asymmetric session-less option to rte_crypto_asym_op.
> > Feature flag for sessionless is added to rte_cryptodev.
> >
> > Signed-off-by: Arek Kusztal
> > ---
> > lib/librte_cryptodev/rte_crypto_asym.h | 9 +++--
> > lib/librte_cryptodev/rte_cryptodev.h | 2 ++
> > 2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > b/lib/librte_cryptodev/rte_crypto_asym.h
> > index 4fbef2f..0d34ce8 100644
> > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > @@ -522,8 +522,13 @@ struct rte_crypto_dsa_op_param {
> > *
> > */
> > struct rte_crypto_asym_op {
> > - struct rte_cryptodev_asym_session *session;
> > - /**< Handle for the initialised session context */
> > + RTE_STD_C11
> > + union {
> > + struct rte_cryptodev_asym_session *session;
> > + /**< Handle for the initialised session context */
> > + struct rte_crypto_asym_xform *xform;
> > + /**< Session-less API crypto operation parameters */
> > + };
> >
> > __extension__
> > union {
> > diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> > b/lib/librte_cryptodev/rte_cryptodev.h
> > index e175b83..c6ffa3b 100644
> > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > @@ -448,6 +448,8 @@ rte_cryptodev_asym_get_xform_enum(enum
> > rte_crypto_asym_xform_type *xform_enum, /**< Support RSA Private Key
> > OP with CRT (quintuple) Keys */
> > #define RTE_CRYPTODEV_FF_DIGEST_ENCRYPTED (1ULL << 19)
> > /**< Support encrypted-digest operations where digest is appended to data
> > */
> > +#define RTE_CRYPTODEV_FF_ASYM_SESSIONLESS (1ULL << 20)
> > +/**< Support asymmetric session-less operations */
> >
> >
> > /**
> > --
> > 2.1.0
Re: [dpdk-dev] [PATCH v2 00/20] bnxt patchset to improve rte flow support
On 10/3/2019 12:25 AM, Ajit Khaparde wrote: > Among other changes, this patchset adds support to: > - create filters with RSS action. > - create source MAC filters. > - use user provided priority to place rule appropriately in HW. > > This patch has been rebased to dpdk-next-net commit > 8587a8b9eddefa39e4ceac7e9385efcc5e73307c > > Please apply. > > > Ajit Khaparde (13): > net/bnxt: return standard error codes for HWRM command > net/bnxt: refactor code to allow dynamic creation of VNIC > net/bnxt: allow flow creation when RSS is enabled > net/bnxt: add support to create SMAC and inner DMAC filters > net/bnxt: add support for RSS action > net/bnxt: parse priority attribute for flow creation > net/bnxt: delete and flush L2 filters cleanly > net/bnxt: cleanup vnic after flow validate > net/bnxt: allow only unicast MAC address filter creation > net/bnxt: check device is started before flow creation > net/bnxt: handle cleanup if flow creation fails > net/bnxt: drop untagged frames when specified > net/bnxt: handle flow flush handling > > Kalesh AP (2): > net/bnxt: fix an issue in setting default MAC address > net/bnxt: fix multicast filter programming > > Rahul Gupta (1): > net/bnxt: properly handle ring cleanup in case of error > > Somnath Kotur (1): > net/bnxt: check for invalid VNIC ID in vnic tpa cfg > > Venkat Duvvuru (3): > net/bnxt: validate RSS hash key length > net/bnxt: synchronize between flow related functions > net/bnxt: fix VLAN filtering code path Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] common/cpt: add support for new firmware
> > Hi Akhil, Pablo, > > From my end, this patch is good to go. > > Thanks, > Anoob > > > -Original Message- > > From: Anoob Joseph > > Sent: Wednesday, August 14, 2019 3:11 PM > > To: Akhil Goyal ; Pablo de Lara > > > > Cc: Ankur Dwivedi ; Jerin Jacob Kollanukkaran > > ; Narayana Prasad Raju Athreya > > ; dev@dpdk.org; Anoob Joseph > > > > Subject: [PATCH] common/cpt: add support for new firmware > > > > From: Ankur Dwivedi > > > > With the latest firmware, there are few changes for zuc and snow3g. > > > > 1. The iv_source is present in bitfield 7 of minor opcode. In the old > > firmware > this > > was present in bitfield 6. > > > > 2. Algorithm type is a 2 bit field in new firmware. In the old firmware it > > was > > named as cipher type and it was a 1 bit field. > > > > Signed-off-by: Ankur Dwivedi > > Signed-off-by: Anoob Joseph > > --- >From next time please delegate patch accordingly if the patch is intended for >next-crypto Applied to dpdk-next-crypto Thanks.
Re: [dpdk-dev] [PATCH] drivers/octeontx2: fix parser error to ol_flags translation
On Thu, Oct 3, 2019 at 12:03 PM Sunil Kumar Kori wrote:
>
> NPC errors were incorrectly translated to ol_flag as
> error code enum was not in sync with NPC profile.
>
> Fixes: 371d3212cbed ("common/octeontx2: add build infrastructure and HW
> definition")
>
> Signed-off-by: Sunil Kumar Kori
Changed subject to drivers/octeontx2: fix checksum flag translation
Cc: sta...@dpdk.org
Acked-by: Jerin Jacob
Applied to dpdk-next-net-mrvl/master. Thanks
> ---
> drivers/common/octeontx2/hw/otx2_npc.h | 7 ---
> drivers/net/octeontx2/otx2_lookup.c| 2 +-
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/common/octeontx2/hw/otx2_npc.h
> b/drivers/common/octeontx2/hw/otx2_npc.h
> index 0f85d7fdb..8045bed11 100644
> --- a/drivers/common/octeontx2/hw/otx2_npc.h
> +++ b/drivers/common/octeontx2/hw/otx2_npc.h
> @@ -132,6 +132,7 @@ enum npc_kpu_err_code {
> NPC_EC_NOERR = 0, /* has to be zero */
> NPC_EC_UNK,
> NPC_EC_IH_LENGTH,
> + NPC_EC_EDSA_UNK,
> NPC_EC_L2_K1,
> NPC_EC_L2_K2,
> NPC_EC_L2_K3,
> @@ -245,9 +246,6 @@ enum npc_kpu_lf_ltype {
> NPC_LT_LF_TU_3RD_NSH,
> };
>
> -/* Don't modify Ltypes upto SCTP, otherwise it will
> - * effect flow tag calculation and thus RSS.
> - */
> enum npc_kpu_lg_ltype {
> NPC_LT_LG_TU_IP = 1,
> NPC_LT_LG_TU_IP6,
> @@ -255,6 +253,9 @@ enum npc_kpu_lg_ltype {
> NPC_LT_LG_TU_ETHER_IN_NSH,
> };
>
> +/* Don't modify Ltypes upto SCTP, otherwise it will
> + * effect flow tag calculation and thus RSS.
> + */
> enum npc_kpu_lh_ltype {
> NPC_LT_LH_TU_TCP = 1,
> NPC_LT_LH_TU_UDP,
> diff --git a/drivers/net/octeontx2/otx2_lookup.c
> b/drivers/net/octeontx2/otx2_lookup.c
> index 99199d08a..6cdca9b33 100644
> --- a/drivers/net/octeontx2/otx2_lookup.c
> +++ b/drivers/net/octeontx2/otx2_lookup.c
> @@ -272,13 +272,13 @@ nix_create_rx_ol_flags_array(void *mem)
> val |= PKT_RX_IP_CKSUM_GOOD;
> break;
> case NPC_ERRLEV_NIX:
> + val |= PKT_RX_IP_CKSUM_GOOD;
> if (errcode == NIX_RX_PERRCODE_OL4_CHK) {
> val |= PKT_RX_OUTER_L4_CKSUM_BAD;
> val |= PKT_RX_L4_CKSUM_BAD;
> } else if (errcode == NIX_RX_PERRCODE_IL4_CHK) {
> val |= PKT_RX_L4_CKSUM_BAD;
> } else {
> - val |= PKT_RX_IP_CKSUM_GOOD;
> val |= PKT_RX_L4_CKSUM_GOOD;
> }
> break;
> --
> 2.17.2
>
Re: [dpdk-dev] [PATCH] net/qede: only access sw rx ring index for debug
On Fri, Sep 27, 2019 at 4:59 PM David Marchand
wrote:
>
> Caught by clang, this idx value is only used for a debug message when
> the mbufs allocation fails.
> No need to use idx as a temporary storage.
>
> Fixes: 8f2312474529 ("net/qede: fix performance bottleneck in Rx path")
> Cc: sta...@dpdk.org
Rasesh, Shahed,
Please review this patch.
>
> Signed-off-by: David Marchand
> ---
> drivers/net/qede/qede_rxtx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
> index c38cbb9..1fbeba2 100644
> --- a/drivers/net/qede/qede_rxtx.c
> +++ b/drivers/net/qede/qede_rxtx.c
> @@ -46,8 +46,6 @@ static inline int qede_alloc_rx_bulk_mbufs(struct
> qede_rx_queue *rxq, int count)
> int i, ret = 0;
> uint16_t idx;
>
> - idx = rxq->sw_rx_prod & NUM_RX_BDS(rxq);
> -
> if (count > QEDE_MAX_BULK_ALLOC_COUNT)
> count = QEDE_MAX_BULK_ALLOC_COUNT;
>
> @@ -56,7 +54,9 @@ static inline int qede_alloc_rx_bulk_mbufs(struct
> qede_rx_queue *rxq, int count)
> PMD_RX_LOG(ERR, rxq,
>"Failed to allocate %d rx buffers "
> "sw_rx_prod %u sw_rx_cons %u mp entries %u free
> %u",
> - count, idx, rxq->sw_rx_cons & NUM_RX_BDS(rxq),
> + count,
> + rxq->sw_rx_prod & NUM_RX_BDS(rxq),
> + rxq->sw_rx_cons & NUM_RX_BDS(rxq),
> rte_mempool_avail_count(rxq->mb_pool),
> rte_mempool_in_use_count(rxq->mb_pool));
> return -ENOMEM;
> --
> 1.8.3.1
>
Re: [dpdk-dev] [PATCH v3 0/3] add fallback session
Hi Anoob,
> > > > > I've few more observations regarding the proposed feature.
> > > > >
> > > > > 1. From what I understood, if an ESP packet ends up on an
> > > > > unprotected interface and doesn't have 'PKT_RX_SEC_OFFLOAD' bit
> > > > > set, then the packet
> > > > would be looked up to see the associated SA and then fallback
> > > > session is figured out and then further processing is done.
> > > > >
> > > > > Can you confirm if I understood the sequence correctly? If yes,
> > > > > then aren't we doing an extra lookup in the s/w? The packet may be
> > > > > looked by the h/w using rte_flow and that information could be
> > > > > used to determine the
> > > > SA. Also, if the ESP packet is expected to be forwarded, then the
> > > > above logic will add an unnecessary lookup even after your h/w has
> > > > detected that the packet need not be security processed.
> > > >
> > > > Not sure I understood your whole statement above.
> > > > AFAIK, right now (with dpdk master) for unprotected iface it works like
> > > > that:
> > > >
> > > > 1. slit incoming traffic into 3 groups: ESP packets, IPv4 packets, IPv6
> > packets.
> > > > For ESP packets:
> > > > 2. perform SAD lookup
> > > > a. if it fails (non SA found for that SPI), then drop the packet.
> > > > b. otherwise (SA found) process the packet using found SA
> > > >
> > > > What fall-back patch adds:
> > > > Before step 2.b check:
> > > > does that SA has its primary session with type INLINE-CRYPTO and
> > > > does HW fail to do IPsec realted processing for it (by some reason)?
> > > > If yes, then mark this packet to be processed by fall-back session.
> > > > if (MBUF_NO_SEC_OFFLOAD(pkt) && sa->fallback_sessions > 0) {
> > > > uintptr_t intsa = (uintptr_t)sa;
> > > > intsa |= IPSEC_SA_OFFLOAD_FALLBACK_FLAG;
> > > > result_sa = (void *)intsa; }
> > > >
> > > > So from my perspective, no additional lookup where introduced.
> > >
> > > [Anoob] For inline processing, h/w does a lookup and figures out the
> > > security
> > processing to be done on the packet.
> > > "rte_security_get_userdata()" allows s/w to further segregate that
> > > info. In this approach, I believe we don't consider how such info from
> > > h/w can
> > be used.
> >
> > Right now it is not the case with ipsec-secgw:
>
> [Anoob] Are you saying there is no h/w lookup involved when doing inline
> crypto processing? Then I'm confused. My understanding is that
> rte_flow with ACTION type as SECURITY is being used to setup h/w lookups.
I am saying that current ipsec-secgw code for each inbound ESP packet *always*
does SW lookup.
No matter did HW lookup take place already and does information about that
lookup is available
via mbuf in some way or not.
Just look at the ipsec-secgw code yourself:
nb_rx = rte_eth_rx_burst(portid, queueid, pkts, MAX_PKT_BURST);
if (nb_rx > 0)
process_pkts(qconf, pkts, nb_rx, portid);
Inside process_pkts()
http://lxr.dpdk.org/dpdk/latest/ident/prepare_one_packet
it first calls prepare_traffic() which does sort of de-muxing:
put packet in one of 3 arrays:
1) ESP packets
2) non ESP IPv4 packets
3) non ESP IPv6 packets
Also it checks is PKT_RX_SEC_OFFLOAD set for that packet.
If yes, it retrieves associated security user-data and stores it inside private
mbuf area.
Then it goes into process_pkts_inbound()
http://lxr.dpdk.org/dpdk/latest/ident/process_pkts_inbound
and here for all ESP packets:
legacy code path:
ipsec_inbound()->inbound_sa_lookup()->single_inbound_lookup()
for librte_ipsec code path:
inbound_sa_lookup()->single_inbound_lookup()
single_inbound_lookup() is the one that does actual SW lookup for each input
packet.
http://lxr.dpdk.org/dpdk/latest/ident/single_inbound_lookup
>
> > for each inbound ESP packet it *always* does a lookup in SW based SADB, and
> > if
> > lookup fails - drops the packet (see 2.a above).
> > So, I still not see any additional lookups introduced with the patch.
>
> [Anoob] In case of inline crypto, you could do that. No disagreement. But
> that doesn't mean that is the only way. If PMDs can retrieve info
> about h/w lookups and pass it on to the upper layers, isn't that the better
> approach?
Please let's keep our conversation in a constructive way.
We are not discussing what could be done in theory, but a particular patch for
ipsec-secgw:
Right now ipsec-secgw does a SW lookup for each inbound ESP packet
(no matter what HW offload does) and this patch doesn't introduce
any extra SW lookups.
If you are not happy with current ipsec-secgw approach, that's fine -
feel free to submit RFC/patch to fix that, or start a discussion in a new
thread.
I just don't see why we have to discuss it in context of this patch.
>
> >
> > >
> > > > Also AFAIK, right now there is no possibility to configure
> > > > ipsec-secgw to BYPASS some ESP traffic.
> > > > Should we do it (to conform to ipsec RFC) - that's probably subject
> > > > of ano
Re: [dpdk-dev] [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by sessionless
Sent from Workspace ONE Boxer
On 03-Oct-2019 7:58 PM, Akhil Goyal wrote:
>
> Hi Shally,
>
> Any more comments on this patch.
> If not please Ack.
>
> Regards,
> Akhil
>
> > -Original Message-
> > From: Shally Verma
> > Sent: Sunday, September 8, 2019 11:49 AM
> > To: Arek Kusztal ; dev@dpdk.org
> > Cc: Akhil Goyal ; fiona.tr...@intel.com; Anoob Joseph
> >
> > Subject: RE: [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by
> > sessionless
> >
> > Hi Arek
> >
> > Only these changes looks good to me but do you have working PMD to back
> > this?
> > Also, documentation updates?
> >
> > Thanks
> > Shally
> >
> > > -Original Message-
> > > From: Arek Kusztal
> > > Sent: Friday, September 6, 2019 5:28 PM
> > > To: dev@dpdk.org
> > > Cc: akhil.go...@nxp.com; fiona.tr...@intel.com; Shally Verma
> > > ; Anoob Joseph ; Arek
> > > Kusztal
> > > Subject: [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by
> > > sessionless
> > >
> > > External Email
> > >
> > > --
> > > This commit adds asymmetric session-less option to rte_crypto_asym_op.
> > > Feature flag for sessionless is added to rte_cryptodev.
> > >
> > > Signed-off-by: Arek Kusztal
> > > ---
Acked-by: Shally Verma < shal...@marvell.com>
> > > lib/librte_cryptodev/rte_crypto_asym.h | 9 +++--
> > > lib/librte_cryptodev/rte_cryptodev.h | 2 ++
> > > 2 files changed, 9 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/lib/librte_cryptodev/rte_crypto_asym.h
> > > b/lib/librte_cryptodev/rte_crypto_asym.h
> > > index 4fbef2f..0d34ce8 100644
> > > --- a/lib/librte_cryptodev/rte_crypto_asym.h
> > > +++ b/lib/librte_cryptodev/rte_crypto_asym.h
> > > @@ -522,8 +522,13 @@ struct rte_crypto_dsa_op_param {
> > > *
> > > */
> > > struct rte_crypto_asym_op {
> > > - struct rte_cryptodev_asym_session *session;
> > > - /**< Handle for the initialised session context */
> > > + RTE_STD_C11
> > > + union {
> > > + struct rte_cryptodev_asym_session *session;
> > > + /**< Handle for the initialised session context */
> > > + struct rte_crypto_asym_xform *xform;
> > > + /**< Session-less API crypto operation parameters */
> > > + };
> > >
> > > __extension__
> > > union {
> > > diff --git a/lib/librte_cryptodev/rte_cryptodev.h
> > > b/lib/librte_cryptodev/rte_cryptodev.h
> > > index e175b83..c6ffa3b 100644
> > > --- a/lib/librte_cryptodev/rte_cryptodev.h
> > > +++ b/lib/librte_cryptodev/rte_cryptodev.h
> > > @@ -448,6 +448,8 @@ rte_cryptodev_asym_get_xform_enum(enum
> > > rte_crypto_asym_xform_type *xform_enum, /**< Support RSA Private Key
> > > OP with CRT (quintuple) Keys */
> > > #define RTE_CRYPTODEV_FF_DIGEST_ENCRYPTED (1ULL << 19)
> > > /**< Support encrypted-digest operations where digest is appended to data
> > > */
> > > +#define RTE_CRYPTODEV_FF_ASYM_SESSIONLESS (1ULL << 20)
> > > +/**< Support asymmetric session-less operations */
> > >
> > >
> > > /**
> > > --
> > > 2.1.0
>
Re: [dpdk-dev] [PATCH] net/octeontx2: allow vfs to enable back pressure
On Fri, Aug 30, 2019 at 9:35 AM Nithin Dabilpuram
wrote:
>
> Allow VFs to enable backpressure for performance reasons.
> The backpressure control is with kernel AF driver that will enable
> backpressure even if one PF/VF requests it and disable it only
> after all the PFs/VFs request for disable.
>
> Signed-off-by: Nithin Dabilpuram
Applied to dpdk-next-net-mrvl/master. Thanks
> ---
> drivers/net/octeontx2/otx2_flow_ctrl.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/drivers/net/octeontx2/otx2_flow_ctrl.c
> b/drivers/net/octeontx2/otx2_flow_ctrl.c
> index 419ad97..1d00e46 100644
> --- a/drivers/net/octeontx2/otx2_flow_ctrl.c
> +++ b/drivers/net/octeontx2/otx2_flow_ctrl.c
> @@ -14,9 +14,6 @@ otx2_nix_rxchan_bpid_cfg(struct rte_eth_dev *eth_dev, bool
> enb)
> struct nix_bp_cfg_rsp *rsp;
> int rc;
>
> - if (otx2_dev_is_vf(dev))
> - return 0;
> -
> if (enb) {
> req = otx2_mbox_alloc_msg_nix_bp_enable(mbox);
> req->chan_base = 0;
> @@ -53,9 +50,6 @@ otx2_nix_flow_ctrl_get(struct rte_eth_dev *eth_dev,
> struct otx2_mbox *mbox = dev->mbox;
> int rc;
>
> - if (otx2_dev_is_vf(dev))
> - return -ENOTSUP;
> -
> req = otx2_mbox_alloc_msg_cgx_cfg_pause_frm(mbox);
> req->set = 0;
>
> @@ -143,9 +137,6 @@ otx2_nix_flow_ctrl_set(struct rte_eth_dev *eth_dev,
> uint8_t tx_pause, rx_pause;
> int rc = 0;
>
> - if (otx2_dev_is_vf(dev))
> - return -ENOTSUP;
> -
> if (fc_conf->high_water || fc_conf->low_water || fc_conf->pause_time
> ||
> fc_conf->mac_ctrl_frame_fwd || fc_conf->autoneg) {
> otx2_info("Flowctrl parameter is not supported");
> @@ -198,9 +189,6 @@ otx2_nix_update_flow_ctrl_mode(struct rte_eth_dev
> *eth_dev)
> struct otx2_eth_dev *dev = otx2_eth_pmd_priv(eth_dev);
> struct rte_eth_fc_conf fc_conf;
>
> - if (otx2_dev_is_vf(dev))
> - return 0;
> -
> memset(&fc_conf, 0, sizeof(struct rte_eth_fc_conf));
> /* Both Rx & Tx flow ctrl get enabled(RTE_FC_FULL) in HW
> * by AF driver, update those info in PMD structure.
> --
> 2.8.4
>
Re: [dpdk-dev] [PATCH 0/8] eBPF arm64 JIT support
Hi everyone, > > On Thu, Oct 3, 2019 at 6:21 PM Thomas Monjalon wrote: > > > > 03/09/2019 12:59, jer...@marvell.com: > > > Added eBPF arm64 JIT support to improve the eBPF program performance > > > on arm64. > > > > > > lib/librte_bpf/bpf_jit_arm64.c | 1451 > > > > I am concerned about duplicating the BPF JIT effort in DPDK and Linux. > > Could we try to pull the Linux JIT? > > Is the license the only issue? > > That's one issue. > > > > > After a quick discussion, it seems the Linux authors are OK to arrange > > their JIT code for sharing with userspace projects. > > I did a clean room implementation considering some optimization for > DPDK etc(Like if stack is not used then don't push stack etc) > and wherever Linux can be improved, I have submitted the patch also to > Linux as well.(Some more pending as well) > > https://github.com/torvalds/linux/commit/504792e07a44844f24e9d79913e4a2f8373cd332 > > And Linux has a framework for instruction generation for debugging > etc. So We can not copy and paste the code > from Linux as is. > > My view to keep a different code base optimize for DPDK use cases and > library requirements(for example, tail call is not supported in DPDK). > For arm64/x86 case the code is done so it is not worth sync with > Linux. For new architecture, it can be if possible. > > Konstantin, > Your thoughts? > My thought would be that if we have JIT eBPF compiler already in DPDK for one arch (x86) there is absolutely no reason why we shouldn't allow it for different arch (arm). About having a common code-base with Linux eBPF JITs implementation - I think it is a very good idea, but I don’t' think it could be achieved without significant effort. DPDK and Linux JIT code-generators differ quite a bit. So my suggestion - let's go ahead and integrate Jerin patch into 19.11, meanwhile start talking with linux guys how common JIT code-base could be achieved. Konstantin
Re: [dpdk-dev] [PATCH 0/2] use pkg-config to find Netcope dependencies
On 9/14/2019 10:36 AM, Thomas Monjalon wrote: > The libraries required for Netcope PMDs can be found in > https://www.netcope.com/en/company/community-support/dpdk-libsze2 > > These libraries are compatible with pkg-config, which is a better solution > than directly looking for libraries and includes. > These patches are using exclusively pkg-config with meson. > > > Thomas Monjalon (2): > net/nfb: fix dependency check > net/szedata2: fix dependency check Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] net/octeontx2: use updated LB ltypes
On Sun, Sep 29, 2019 at 9:59 AM Vivek Kumar Sharma
wrote:
>
> Ping!
>
>
> Thanks,
> Vivek
>
>
> From: viveksha...@marvell.com
> Sent: 06 September 2019 05:43
> To: dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran; Vivek Kumar Sharma
> Subject: [PATCH] net/octeontx2: use updated LB ltypes
>
> From: Vivek Sharma
>
> Update LB ltypes and use the updated ones so as replace
> LB_STAG and LB_QINQ by single LB_STAG_QINQ ltype.
>
> Signed-off-by: Vivek Sharma
Changed the subject to net/octeontx2: update KPU parser profile
Acked-by: Jerin Jacob
Applied to dpdk-next-net-mrvl/master. Thanks
> ---
> drivers/common/octeontx2/hw/otx2_npc.h | 9 +++--
> drivers/net/octeontx2/otx2_flow_parse.c | 4 ++--
> drivers/net/octeontx2/otx2_lookup.c | 2 +-
> drivers/net/octeontx2/otx2_vlan.c | 14 +-
> 4 files changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/common/octeontx2/hw/otx2_npc.h
> b/drivers/common/octeontx2/hw/otx2_npc.h
> index 0f85d7f..5eccb9e 100644
> --- a/drivers/common/octeontx2/hw/otx2_npc.h
> +++ b/drivers/common/octeontx2/hw/otx2_npc.h
> @@ -186,10 +186,15 @@ enum npc_kpu_la_ltype {
> enum npc_kpu_lb_ltype {
> NPC_LT_LB_ETAG = 1,
> NPC_LT_LB_CTAG,
> - NPC_LT_LB_STAG,
> + NPC_LT_LB_STAG_QINQ,
> NPC_LT_LB_BTAG,
> - NPC_LT_LB_QINQ,
> NPC_LT_LB_ITAG,
> + NPC_LT_LB_DSA,
> + NPC_LT_LB_DSA_VLAN,
> + NPC_LT_LB_EDSA,
> + NPC_LT_LB_EDSA_VLAN,
> + NPC_LT_LB_EXDSA,
> + NPC_LT_LB_EXDSA_VLAN,
> };
>
> enum npc_kpu_lc_ltype {
> diff --git a/drivers/net/octeontx2/otx2_flow_parse.c
> b/drivers/net/octeontx2/otx2_flow_parse.c
> index 6670c1a..71650b5 100644
> --- a/drivers/net/octeontx2/otx2_flow_parse.c
> +++ b/drivers/net/octeontx2/otx2_flow_parse.c
> @@ -599,11 +599,11 @@ otx2_flow_parse_lb(struct otx2_parse_state *pst)
> lt = NPC_LT_LB_CTAG;
> break;
> case 2:
> - lt = NPC_LT_LB_STAG;
> + lt = NPC_LT_LB_STAG_QINQ;
> lflags = NPC_F_STAG_CTAG;
> break;
> case 3:
> - lt = NPC_LT_LB_STAG;
> + lt = NPC_LT_LB_STAG_QINQ;
> lflags = NPC_F_STAG_STAG_CTAG;
> break;
> default:
> diff --git a/drivers/net/octeontx2/otx2_lookup.c
> b/drivers/net/octeontx2/otx2_lookup.c
> index 99199d0..2511386 100644
> --- a/drivers/net/octeontx2/otx2_lookup.c
> +++ b/drivers/net/octeontx2/otx2_lookup.c
> @@ -88,7 +88,7 @@ nix_create_non_tunnel_ptype_array(uint16_t *ptype)
> val = RTE_PTYPE_UNKNOWN;
>
> switch (lb) {
> - case NPC_LT_LB_QINQ:
> + case NPC_LT_LB_STAG_QINQ:
> val |= RTE_PTYPE_L2_ETHER_QINQ;
> break;
> case NPC_LT_LB_CTAG:
> diff --git a/drivers/net/octeontx2/otx2_vlan.c
> b/drivers/net/octeontx2/otx2_vlan.c
> index c01089b..14e3ee9 100644
> --- a/drivers/net/octeontx2/otx2_vlan.c
> +++ b/drivers/net/octeontx2/otx2_vlan.c
> @@ -300,8 +300,11 @@ nix_vlan_mcam_config(struct rte_eth_dev *eth_dev,
>
> /* Adds vlan_id & LB CTAG flag to MCAM KW */
> if (flags & VLAN_ID_MATCH) {
> - entry.kw[kwi] |= NPC_LT_LB_CTAG << mkex->lb_lt_offset;
> - entry.kw_mask[kwi] |= 0xFULL << mkex->lb_lt_offset;
> + entry.kw[kwi] |= (NPC_LT_LB_CTAG | NPC_LT_LB_STAG_QINQ)
> + << mkex->lb_lt_offset;
> + entry.kw_mask[kwi] |=
> + (0xF & ~(NPC_LT_LB_CTAG ^ NPC_LT_LB_STAG_QINQ))
> + << mkex->lb_lt_offset;
>
> mcam_data = ((uint32_t)vlan_id << 16);
> mcam_mask = (BIT_ULL(16) - 1) << 16;
> @@ -313,15 +316,16 @@ nix_vlan_mcam_config(struct rte_eth_dev *eth_dev,
>
> /* Adds LB STAG flag to MCAM KW */
> if (flags & QINQ_F_MATCH) {
> - entry.kw[kwi] |= NPC_LT_LB_STAG << mkex->lb_lt_offset;
> + entry.kw[kwi] |= NPC_LT_LB_STAG_QINQ << mkex->lb_lt_offset;
> entry.kw_mask[kwi] |= 0xFULL << mkex->lb_lt_offset;
> }
>
> /* Adds LB CTAG & LB STAG flags to MCAM KW */
> if (flags & VTAG_F_MATCH) {
> - entry.kw[kwi] |= (NPC_LT_LB_CTAG | NPC_LT_LB_STAG)
> + entry.kw[kwi] |= (NPC_LT_LB_CTAG | NPC_LT_LB_STAG_QINQ)
> << mkex->lb_lt_offset;
> - entry.kw_mask[kwi] |= (NPC_LT_LB_CTAG & NPC_LT_LB_STAG)
> + entry.kw_mask[kwi] |=
> + (0xF & ~(NPC_LT_LB_CTAG ^ NPC_LT_LB_STAG_QINQ))
> << mkex->lb_lt_offset;
> }
>
Re: [dpdk-dev] DPDK Release Status Meeting 3/10/2019
On Thu, 3 Oct 2019 12:14:46 +0100 Ferruh Yigit wrote: > Open > > > * The time of the meeting is not good for the US timezone, we talked about > changing the time of the meeting but not had enough time to discuss it. > If you have any preferences, please comment. In the past (at OSDL) we had a meeting with rotating time slot so that one geography got the night owl slot each rotation.
Re: [dpdk-dev] [PATCH v3] net/octeontx2: add tx desc status dev ops
On Fri, Sep 6, 2019 at 6:13 PM wrote:
>
> From: Kiran Kumar K
>
> Adding support for tx descriptor status dev ops for octeontx2.
>
> Signed-off-by: Kiran Kumar K
# Fixed check-git-log.sh issue(Subject changed to net/octeontx2: add
Tx descriptor status op)
# Tx descriptor status = Y update was missing in
doc/guides/nics/features/octeontx2_vec.ini and
doc/guides/nics/features/octeontx2_vf.ini
Acked-by: Jerin Jacob
Fixed above and Applied to dpdk-next-net-mrvl/master. Thanks
> ---
> V3 Changes:
> * Added version info in subject
>
> V2 Changes:
> * Fixed check for num of tx desc
>
> doc/guides/nics/features/octeontx2.ini | 1 +
> drivers/net/octeontx2/otx2_ethdev.c | 1 +
> drivers/net/octeontx2/otx2_ethdev.h | 1 +
> drivers/net/octeontx2/otx2_ethdev_ops.c | 38 -
> 4 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/doc/guides/nics/features/octeontx2.ini
> b/doc/guides/nics/features/octeontx2.ini
> index 66952328b..b89959994 100644
> --- a/doc/guides/nics/features/octeontx2.ini
> +++ b/doc/guides/nics/features/octeontx2.ini
> @@ -39,6 +39,7 @@ Packet type parsing = Y
> Timesync = Y
> Timestamp offload= Y
> Rx descriptor status = Y
> +Tx descriptor status = Y
> Basic stats = Y
> Stats per queue = Y
> Extended stats = Y
> diff --git a/drivers/net/octeontx2/otx2_ethdev.c
> b/drivers/net/octeontx2/otx2_ethdev.c
> index b84128fef..696c85cb8 100644
> --- a/drivers/net/octeontx2/otx2_ethdev.c
> +++ b/drivers/net/octeontx2/otx2_ethdev.c
> @@ -1646,6 +1646,7 @@ static const struct eth_dev_ops otx2_eth_dev_ops = {
> .rx_queue_count = otx2_nix_rx_queue_count,
> .rx_descriptor_done = otx2_nix_rx_descriptor_done,
> .rx_descriptor_status = otx2_nix_rx_descriptor_status,
> + .tx_descriptor_status = otx2_nix_tx_descriptor_status,
> .tx_done_cleanup = otx2_nix_tx_done_cleanup,
> .pool_ops_supported = otx2_nix_pool_ops_supported,
> .filter_ctrl = otx2_nix_dev_filter_ctrl,
> diff --git a/drivers/net/octeontx2/otx2_ethdev.h
> b/drivers/net/octeontx2/otx2_ethdev.h
> index 7b15d6bc8..1c660cb1e 100644
> --- a/drivers/net/octeontx2/otx2_ethdev.h
> +++ b/drivers/net/octeontx2/otx2_ethdev.h
> @@ -377,6 +377,7 @@ uint32_t otx2_nix_rx_queue_count(struct rte_eth_dev
> *eth_dev, uint16_t qidx);
> int otx2_nix_tx_done_cleanup(void *txq, uint32_t free_cnt);
> int otx2_nix_rx_descriptor_done(void *rxq, uint16_t offset);
> int otx2_nix_rx_descriptor_status(void *rx_queue, uint16_t offset);
> +int otx2_nix_tx_descriptor_status(void *tx_queue, uint16_t offset);
>
> void otx2_nix_promisc_config(struct rte_eth_dev *eth_dev, int en);
> void otx2_nix_promisc_enable(struct rte_eth_dev *eth_dev);
> diff --git a/drivers/net/octeontx2/otx2_ethdev_ops.c
> b/drivers/net/octeontx2/otx2_ethdev_ops.c
> index 7c6532b6f..ab07e4bc0 100644
> --- a/drivers/net/octeontx2/otx2_ethdev_ops.c
> +++ b/drivers/net/octeontx2/otx2_ethdev_ops.c
> @@ -274,7 +274,7 @@ otx2_nix_rx_descriptor_status(void *rx_queue, uint16_t
> offset)
> struct otx2_eth_rxq *rxq = rx_queue;
> uint32_t head, tail;
>
> - if (rxq->qlen >= offset)
> + if (rxq->qlen <= offset)
> return -EINVAL;
>
> nix_rx_head_tail_get(otx2_eth_pmd_priv(rxq->eth_dev),
> @@ -286,6 +286,42 @@ otx2_nix_rx_descriptor_status(void *rx_queue, uint16_t
> offset)
> return RTE_ETH_RX_DESC_AVAIL;
> }
>
> +static void
> +nix_tx_head_tail_get(struct otx2_eth_dev *dev,
> +uint32_t *head, uint32_t *tail, uint16_t queue_idx)
> +{
> + uint64_t reg, val;
> +
> + if (head == NULL || tail == NULL)
> + return;
> +
> + reg = (((uint64_t)queue_idx) << 32);
> + val = otx2_atomic64_add_nosync(reg, (int64_t *)
> + (dev->base + NIX_LF_SQ_OP_STATUS));
> + if (val & OP_ERR)
> + val = 0;
> +
> + *tail = (uint32_t)((val >> 28) & 0x3F);
> + *head = (uint32_t)((val >> 20) & 0x3F);
> +}
> +
> +int
> +otx2_nix_tx_descriptor_status(void *tx_queue, uint16_t offset)
> +{
> + struct otx2_eth_txq *txq = tx_queue;
> + uint32_t head, tail;
> +
> + if (txq->qconf.nb_desc <= offset)
> + return -EINVAL;
> +
> + nix_tx_head_tail_get(txq->dev, &head, &tail, txq->sq);
> +
> + if (nix_offset_has_packet(head, tail, offset))
> + return RTE_ETH_TX_DESC_DONE;
> + else
> + return RTE_ETH_TX_DESC_FULL;
> +}
> +
> /* It is a NOP for octeontx2 as HW frees the buffer on xmit */
> int
> otx2_nix_tx_done_cleanup(void *txq, uint32_t free_cnt)
> --
> 2.17.1
>
Re: [dpdk-dev] [PATCH] net/octeontx2: extract nvgre as ltype
On Wed, Sep 11, 2019 at 2:49 PM wrote: > > From: Kiran Kumar K > > Adding change to sync RTE Flow with KPU profile to extract > NVGRE as ltype. > > Signed-off-by: Kiran Kumar K Acked-by: Jerin Jacob Applied to dpdk-next-net-mrvl/master. Thanks > --- > drivers/net/octeontx2/otx2_flow_parse.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/octeontx2/otx2_flow_parse.c > b/drivers/net/octeontx2/otx2_flow_parse.c > index 6670c1a70..a811cb90c 100644 > --- a/drivers/net/octeontx2/otx2_flow_parse.c > +++ b/drivers/net/octeontx2/otx2_flow_parse.c > @@ -458,7 +458,7 @@ otx2_flow_parse_ld(struct otx2_parse_state *pst) > info.hw_hdr_len = 4; > break; > case RTE_FLOW_ITEM_TYPE_NVGRE: > - lt = NPC_LT_LD_GRE; > + lt = NPC_LT_LD_NVGRE; > lflags = NPC_F_GRE_NVGRE; > info.def_mask = &rte_flow_item_nvgre_mask; > info.len = sizeof(struct rte_flow_item_nvgre); > -- > 2.17.1 >
Re: [dpdk-dev] [PATCH v5 1/4] examples/ipsec-secgw: ipsec_sa structure cleanup
Hi Marcin, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marcin Smoczynski > Sent: Friday, September 27, 2019 4:55 PM > To: ano...@marvell.com; akhil.go...@nxp.com; Ananyev, Konstantin > > Cc: dev@dpdk.org; Smoczynski, MarcinX > Subject: [dpdk-dev] [PATCH v5 1/4] examples/ipsec-secgw: ipsec_sa > structure cleanup Minor nit. ./devtools/check-git-log.sh -1 Wrong headline format: examples/ipsec-secgw: ipsec_sa structure cleanup > Cleanup ipsec_sa structure by removing every field that is already in the > rte_ipsec_session structure: > * cryptodev/security session union > * action type > * offload flags > * security context > References to abovementioned fields are changed to direct references to > matching fields of rte_ipsec_session structure. > > Such refactoring is needed to introduce many sessions per SA feature, e.g. > fallback session for inline offload processing. > > Acked-by: Konstantin Ananyev > Signed-off-by: Marcin Smoczynski Tested-by: Bernard Iremonger
Re: [dpdk-dev] [PATCH v5 2/4] examples/ipsec-secgw: add fallback session feature
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marcin Smoczynski > Sent: Friday, September 27, 2019 4:55 PM > To: ano...@marvell.com; akhil.go...@nxp.com; Ananyev, Konstantin > > Cc: dev@dpdk.org; Smoczynski, MarcinX > Subject: [dpdk-dev] [PATCH v5 2/4] examples/ipsec-secgw: add fallback > session feature > > Inline processing is limited to a specified subset of traffic. It is often > unable to > handle more complicated situations, such as fragmented traffic. When using > inline processing such traffic is dropped. > > Introduce fallback session for inline processing allowing processing packets > that normally would be dropped. A fallback session is configured by adding > 'fallback' keyword with 'lookaside-none' or 'lookaside-protocol' parameter to > an SA configuration. > > Using IPsec anti-replay window or ESN feature with fallback session is not yet > supported when primary session is of type 'inline-protocol-offload' or > fallback session is 'lookaside-protocol' > because SA sequence number is not synchronized between software and > hardware sessions. Fallback sessions are also limited to ingress IPsec > traffic. > > Fallback session feature is not available in the legacy mode. > > Acked-by: Konstantin Ananyev > Signed-off-by: Marcin Smoczynski Tested-by: Bernard Iremonger
Re: [dpdk-dev] [PATCH v5 4/4] examples/ipsec-secgw: add offload fallback tests
Hi Marcin,
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Marcin Smoczynski
> Sent: Friday, September 27, 2019 4:55 PM
> To: ano...@marvell.com; akhil.go...@nxp.com; Ananyev, Konstantin
>
> Cc: dev@dpdk.org; Smoczynski, MarcinX
> Subject: [dpdk-dev] [PATCH v5 4/4] examples/ipsec-secgw: add offload
> fallback tests
>
> Add tests for offload fallback feature; add inbound config modificator
> SGW_CFG_XPRM_IN (offload fallback setting can be set only for inbound
> SAs). Tests are using cryptodev for outbound SA.
>
> To test fragmentation with QAT set:
> MULTI_SEG_TEST="--reassemble=4096 --cryptodev_mask=0x"
The environment variable MULTI_SEG_TEST should be documented in the ipsec-secgw
guide, section
49.6 Test directory, along side the other environment variables.
> Acked-by: Konstantin Ananyev
> Signed-off-by: Marcin Smoczynski
Tested-by: Bernard Iremonger
> ---
> examples/ipsec-secgw/test/trs_aesgcm_common_defs.sh | 4 ++--
> .../test/trs_aesgcm_inline_crypto_fallback_defs.sh | 5 +
> examples/ipsec-secgw/test/tun_aesgcm_common_defs.sh | 6 --
> .../test/tun_aesgcm_inline_crypto_fallback_defs.sh | 5 +
> 4 files changed, 16 insertions(+), 4 deletions(-) create mode 100644
> examples/ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh
> create mode 100644 examples/ipsec-
> secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh
>
> diff --git a/examples/ipsec-secgw/test/trs_aesgcm_common_defs.sh
> b/examples/ipsec-secgw/test/trs_aesgcm_common_defs.sh
> index f6c5bf5a7..17f2f86d2 100644
> --- a/examples/ipsec-secgw/test/trs_aesgcm_common_defs.sh
> +++ b/examples/ipsec-secgw/test/trs_aesgcm_common_defs.sh
> @@ -29,11 +29,11 @@ sp ipv6 out esp bypass pri 1 sport 0:65535 dport
> 0:65535 #SA in rules sa in 7 aead_algo aes-128-gcm \ aead_key
> de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \ -mode
> transport ${SGW_CFG_XPRM}
> +mode transport ${SGW_CFG_XPRM} ${SGW_CFG_XPRM_IN}
>
> sa in 9 aead_algo aes-128-gcm \
> aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \ -
> mode transport ${SGW_CFG_XPRM}
> +mode transport ${SGW_CFG_XPRM} ${SGW_CFG_XPRM_IN}
>
> #SA out rules
> sa out 7 aead_algo aes-128-gcm \
> diff --git a/examples/ipsec-
> secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh b/examples/ipsec-
> secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh
> new file mode 100644
> index 0..875a7457d
> --- /dev/null
> +++ b/examples/ipsec-
> secgw/test/trs_aesgcm_inline_crypto_fallback_defs.s
> +++ h
> @@ -0,0 +1,5 @@
> +#! /bin/bash
> +
> +. ${DIR}/trs_aesgcm_defs.sh
> +
> +SGW_CFG_XPRM_IN='port_id 0 type inline-crypto-offload fallback
> lookaside-none'
> diff --git a/examples/ipsec-secgw/test/tun_aesgcm_common_defs.sh
> b/examples/ipsec-secgw/test/tun_aesgcm_common_defs.sh
> index 278377967..7490baded 100644
> --- a/examples/ipsec-secgw/test/tun_aesgcm_common_defs.sh
> +++ b/examples/ipsec-secgw/test/tun_aesgcm_common_defs.sh
> @@ -29,11 +29,13 @@ sp ipv6 out esp bypass pri 1 sport 0:65535 dport
> 0:65535 #SA in rules sa in 7 aead_algo aes-128-gcm \ aead_key
> de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \ -mode ipv4-
> tunnel src ${REMOTE_IPV4} dst ${LOCAL_IPV4} ${SGW_CFG_XPRM}
> +mode ipv4-tunnel src ${REMOTE_IPV4} dst ${LOCAL_IPV4}
> ${SGW_CFG_XPRM} \
> +${SGW_CFG_XPRM_IN}
>
> sa in 9 aead_algo aes-128-gcm \
> aead_key de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef:de:ad:be:ef \ -
> mode ipv6-tunnel src ${REMOTE_IPV6} dst ${LOCAL_IPV6}
> ${SGW_CFG_XPRM}
> +mode ipv6-tunnel src ${REMOTE_IPV6} dst ${LOCAL_IPV6}
> ${SGW_CFG_XPRM} \
> +${SGW_CFG_XPRM_IN}
>
> #SA out rules
> sa out 7 aead_algo aes-128-gcm \
> diff --git a/examples/ipsec-
> secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh b/examples/ipsec-
> secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh
> new file mode 100644
> index 0..696848432
> --- /dev/null
> +++ b/examples/ipsec-
> secgw/test/tun_aesgcm_inline_crypto_fallback_defs.s
> +++ h
> @@ -0,0 +1,5 @@
> +#! /bin/bash
> +
> +. ${DIR}/tun_aesgcm_defs.sh
> +
> +SGW_CFG_XPRM_IN='port_id 0 type inline-crypto-offload fallback
> lookaside-none'
> --
> 2.17.1
Regards,
Bernard.
Re: [dpdk-dev] [PATCH v8 1/7] ethdev: add set ptype function
>-Original Message-
>From: dev On Behalf Of Andrew Rybchenko
>Sent: Thursday, October 3, 2019 1:11 PM
>To: Pavan Nikhilesh Bhagavatula ; Jerin
>Jacob Kollanukkaran ; John McNamara
>; Marko Kovacevic
>; Thomas Monjalon
>; Ferruh Yigit
>Cc: dev@dpdk.org
>Subject: Re: [dpdk-dev] [PATCH v8 1/7] ethdev: add set ptype function
>
>On 10/3/19 12:36 AM, pbhagavat...@marvell.com wrote:
>> From: Pavan Nikhilesh
>>
>> Add `rte_eth_dev_set_supported_ptypes` function that will allow the
>> application to inform the PMD the packet types it is interested in.
>> Based on the ptypes set PMDs can optimize their Rx path.
>>
>> -If application doesn’t want any ptype information it can call
>> `rte_eth_dev_set_supported_ptypes(ethdev_id,
>RTE_PTYPE_UNKNOWN, NULL, 0)`
>> and PMD may skip packet type processing and set
>rte_mbuf::packet_type to
>> RTE_PTYPE_UNKNOWN.
>>
>> -If application doesn’t call `rte_eth_dev_set_supported_ptypes` PMD
>can
>> return `rte_mbuf::packet_type` with
>`rte_eth_dev_get_supported_ptypes`.
>>
>> -If application is interested only in L2/L3 layer, it can inform the PMD
>> to update `rte_mbuf::packet_type` with L2/L3 ptype by calling
>> `rte_eth_dev_set_supported_ptypes(ethdev_id,
>> RTE_PTYPE_L2_MASK | RTE_PTYPE_L3_MASK, NULL,
>0)`.
>>
>> Suggested-by: Konstantin Ananyev
>> Signed-off-by: Pavan Nikhilesh
>
>With few fixes below:
>Reviewed-by: Andrew Rybchenko
>
>[snip]
>
>> diff --git a/lib/librte_ethdev/rte_ethdev.c
>b/lib/librte_ethdev/rte_ethdev.c
>> index 17d183e1f..57bc12b56 100644
>> --- a/lib/librte_ethdev/rte_ethdev.c
>> +++ b/lib/librte_ethdev/rte_ethdev.c
>> @@ -2602,6 +2602,65 @@
>rte_eth_dev_get_supported_ptypes(uint16_t port_id, uint32_t
>ptype_mask,
>> return j;
>> }
>>
>> +int
>> +rte_eth_dev_set_supported_ptypes(uint16_t port_id, uint32_t
>ptype_mask,
>> + uint32_t *set_ptypes, unsigned int
>num)
>> +{
>> +unsigned int i, j;
>> +struct rte_eth_dev *dev;
>> +const uint32_t *all_ptypes;
>> +
>> +RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
>> +dev = &rte_eth_devices[port_id];
>> +
>> +if (num > 0 && set_ptypes == NULL)
>> +return -EINVAL;
>> +
>> +if (*dev->dev_ops->dev_supported_ptypes_get == NULL ||
>> +*dev->dev_ops->dev_supported_ptypes_set
>== NULL) {
>> +if (num > 0)
>> +set_ptypes[0] = RTE_PTYPE_UNKNOWN;
>> +return 0;
>> +}
>> +
>> +if (ptype_mask == 0) {
>> +if (num > 0)
>> +set_ptypes[0] = RTE_PTYPE_UNKNOWN;
>> +
>> +return (*dev->dev_ops-
>>dev_supported_ptypes_set)(dev,
>> +ptype_mask);
>> +}
>> +
>> +all_ptypes = (*dev->dev_ops-
>>dev_supported_ptypes_get)(dev);
>> +if (all_ptypes == NULL) {
>> +if (num > 0)
>> +set_ptypes[0] = RTE_PTYPE_UNKNOWN;
>> +
>> +return 0;
>> +}
>> +
>> +/*
>> + * Accodommodate as many set_ptypes as possible. If the
>supplied
>> + * set_ptypes array is insufficient fill it partially.
>> + */
>> +for (i = 0, j = 0; set_ptypes != NULL &&
>> +(all_ptypes[i] !=
>RTE_PTYPE_UNKNOWN); ++i) {
>> +if (ptype_mask & all_ptypes[i]) {
>> +if (j < num - 1) {
>> +set_ptypes[j] = all_ptypes[i];
>> +j++;
>> +continue;
>> +}
>> +break;
>> +}
>> +}
>> +
>> +if (set_ptypes != NULL)
>> +set_ptypes[j] = RTE_PTYPE_UNKNOWN;
>
>Initially I thought that we are safe here, but now realized that we
>can write more than num here, e.g. if set_ptypes is not NULL, but num
>is 0.
>I think the right condition here is (j < num) since it guarantees that
>set_ptype is not NULL as well (since num is greater than 0 if unsigned j
>is less than num).
Ack will send v9.
>
>> +
>> +return (*dev->dev_ops->dev_supported_ptypes_set)(dev,
>ptype_mask);
>> +}
>> +
>> void
>> rte_eth_macaddr_get(uint16_t port_id, struct rte_ether_addr
>*mac_addr)
>> {
>> diff --git a/lib/librte_ethdev/rte_ethdev.h
>b/lib/librte_ethdev/rte_ethdev.h
>> index d9871782e..c577a9172 100644
>> --- a/lib/librte_ethdev/rte_ethdev.h
>> +++ b/lib/librte_ethdev/rte_ethdev.h
>> @@ -2431,6 +2431,42 @@ int rte_eth_dev_fw_version_get(uint16_t
>port_id,
>>*/
>> int rte_eth_dev_get_supported_ptypes(uint16_t port_id, uint32_t
>ptype_mask,
>> uint32_t *ptypes, int num);
>> +/**
>> + * @warning
>> + * @b EXPERIMENTAL: this API may change without prior notice.
>> + *
>> + * Inform Ethernet device of the packet types classification in which
>> + * the recipient is interested.
>> + *
>> + * Application can use this function to set only specific ptypes that it's
>> + * interested. This information can be used by the PMD to optimize
>Rx path.
>> + *
>> +
Re: [dpdk-dev] [PATCH 01/13] ethdev: support setup function for hairpin queue
Hi Andrew, @Thomas Monjalon, @Ferruh Yigit Please comment if you have any issues with my answer. Thanks, Ori > -Original Message- > From: Andrew Rybchenko > Sent: Thursday, October 3, 2019 4:26 PM > To: Ori Kam ; Thomas Monjalon > ; Ferruh Yigit > Cc: dev@dpdk.org; jingjing...@intel.com; step...@networkplumber.org > Subject: Re: [dpdk-dev] [PATCH 01/13] ethdev: support setup function for > hairpin queue > > Hi Ori, > > @Thomas, @Ferruh, please, see question below. > > On 10/2/19 3:19 PM, Ori Kam wrote: > > Hi Andrew, > > > > Sorry it took me some time to responded, (I'm on vacation 😊) > > I think we are in most cases in agreement. The only open issue is the > > checks so please see my comments below. > > As soon as we get to understanding about this issue, I will start working > > on V2. > > > > Thanks, > > Ori > > [snip] > > >>> @@ -1769,6 +1793,60 @@ int rte_eth_rx_queue_setup(uint16_t > port_id, > >> uint16_t rx_queue_id, > >>> struct rte_mempool *mb_pool); > >>> > >>> /** > >>> + * @warning > >>> + * @b EXPERIMENTAL: this API may change, or be removed, without > prior > >>> + notice > >>> + * > >>> + * Allocate and set up a hairpin receive queue for an Ethernet > >>> device. > >>> + * > >>> + * The function set up the selected queue to be used in hairpin. > >>> + * > >>> + * @param port_id > >>> + * The port identifier of the Ethernet device. > >>> + * @param rx_queue_id > >>> + * The index of the receive queue to set up. > >>> + * The value must be in the range [0, nb_rx_queue - 1] previously > supplied > >>> + * to rte_eth_dev_configure(). > >> Is any Rx queue may be setup as hairpin queue? > >> Can it be still used for regular traffic? > >> > > No if a queue is used as hairpin it can't be used for normal traffic. > > This is also why I like the idea of two different functions, in order to > create > > This distinction. > If so, do we need at least debug-level checks in Tx/Rx burst functions? > Is it required to patch rte flow RSS action to ensure that Rx queues of > only one kind are specified? > What about attempt to add Rx/Tx callbacks for hairpin queues? > > >>> I think the checks should be done in PMD level. Since from high level they > are the > >>> same. > >> Sorry, I don't understand why. If something could be checked on generic > level, > >> it should be done to avoid duplication in all drivers. > > The issue with this approach is that at the ethdev level we don't know > anything about the queue. > > This will mean that we will need to add extra functions to query the queue > type for each PMD. > > We could also assume that if to get type function exist in the pmd then the > queue is always standard queue. > > So my suggestion if you would like to move the checks is to add queue type > enum in the ethdev level, and add > > function call to query the queue type. What do you think? > > I would consider to use dev_data rx_queue_state and tx_queue_state to > keep the information to have it directly available without extra function > calls. Or add extra information. dev_data is internal and it looks like not > a problem. What do you think? > I like the new state idea, it will save some memory in the dev_data, compared to having it in the dev_data. Will also avoid extra ABI change. > >>> Call backs for Rx/Tx doesn't make sense, since the idea is to bypass the > CPU. > >> If so, I think rte_eth_add_tx_callback() should be patched to return an > >> error > >> if specified queue is hairpin. Same for Rx. > >> Any other cases? > >> > > Same answer as above. > > [snip] > > Andrew.
Re: [dpdk-dev] [PATCH] net/qede: only access sw rx ring index for debug
>From: David Marchand
>Sent: Friday, September 27, 2019 4:29 AM
>
>--
>Caught by clang, this idx value is only used for a debug message when the
>mbufs allocation fails.
>No need to use idx as a temporary storage.
>
>Fixes: 8f2312474529 ("net/qede: fix performance bottleneck in Rx path")
>Cc: sta...@dpdk.org
>
>Signed-off-by: David Marchand
>---
Acked-by: Rasesh Mody
Thanks!
-Rasesh
> drivers/net/qede/qede_rxtx.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
>index c38cbb9..1fbeba2 100644
>--- a/drivers/net/qede/qede_rxtx.c
>+++ b/drivers/net/qede/qede_rxtx.c
>@@ -46,8 +46,6 @@ static inline int qede_alloc_rx_bulk_mbufs(struct
>qede_rx_queue *rxq, int count)
> int i, ret = 0;
> uint16_t idx;
>
>- idx = rxq->sw_rx_prod & NUM_RX_BDS(rxq);
>-
> if (count > QEDE_MAX_BULK_ALLOC_COUNT)
> count = QEDE_MAX_BULK_ALLOC_COUNT;
>
>@@ -56,7 +54,9 @@ static inline int qede_alloc_rx_bulk_mbufs(struct
>qede_rx_queue *rxq, int count)
> PMD_RX_LOG(ERR, rxq,
> "Failed to allocate %d rx buffers "
> "sw_rx_prod %u sw_rx_cons %u mp entries %u free
>%u",
>- count, idx, rxq->sw_rx_cons & NUM_RX_BDS(rxq),
>+ count,
>+ rxq->sw_rx_prod & NUM_RX_BDS(rxq),
>+ rxq->sw_rx_cons & NUM_RX_BDS(rxq),
> rte_mempool_avail_count(rxq->mb_pool),
> rte_mempool_in_use_count(rxq->mb_pool));
> return -ENOMEM;
>--
>1.8.3.1
Re: [dpdk-dev] [PATCH] net/qede: only access sw rx ring index for debug
>From: dev On Behalf Of Jerin Jacob
>Sent: Thursday, October 03, 2019 7:40 AM
>
>On Fri, Sep 27, 2019 at 4:59 PM David Marchand
> wrote:
>>
>> Caught by clang, this idx value is only used for a debug message when
>> the mbufs allocation fails.
>> No need to use idx as a temporary storage.
>>
>> Fixes: 8f2312474529 ("net/qede: fix performance bottleneck in Rx
>> path")
>> Cc: sta...@dpdk.org
>
>Rasesh, Shahed,
>
>Please review this patch.
Acked.
Thanks!
-Rasesh
>
>>
>> Signed-off-by: David Marchand
>> ---
>> drivers/net/qede/qede_rxtx.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/qede/qede_rxtx.c
>> b/drivers/net/qede/qede_rxtx.c index c38cbb9..1fbeba2 100644
>> --- a/drivers/net/qede/qede_rxtx.c
>> +++ b/drivers/net/qede/qede_rxtx.c
>> @@ -46,8 +46,6 @@ static inline int qede_alloc_rx_bulk_mbufs(struct
>qede_rx_queue *rxq, int count)
>> int i, ret = 0;
>> uint16_t idx;
>>
>> - idx = rxq->sw_rx_prod & NUM_RX_BDS(rxq);
>> -
>> if (count > QEDE_MAX_BULK_ALLOC_COUNT)
>> count = QEDE_MAX_BULK_ALLOC_COUNT;
>>
>> @@ -56,7 +54,9 @@ static inline int qede_alloc_rx_bulk_mbufs(struct
>qede_rx_queue *rxq, int count)
>> PMD_RX_LOG(ERR, rxq,
>>"Failed to allocate %d rx buffers "
>> "sw_rx_prod %u sw_rx_cons %u mp entries %u free
>> %u",
>> - count, idx, rxq->sw_rx_cons & NUM_RX_BDS(rxq),
>> + count,
>> + rxq->sw_rx_prod & NUM_RX_BDS(rxq),
>> + rxq->sw_rx_cons & NUM_RX_BDS(rxq),
>> rte_mempool_avail_count(rxq->mb_pool),
>> rte_mempool_in_use_count(rxq->mb_pool));
>> return -ENOMEM;
>> --
>> 1.8.3.1
>>
Re: [dpdk-dev] [PATCH 01/13] ethdev: support setup function for hairpin queue
Hi
On 26/09/2019 13:18, Andrew Rybchenko wrote:
> On 9/26/19 9:28 AM, Ori Kam wrote:
>> This commit introduce the RX/TX hairpin setup function.
>
> RX/TX should be Rx/Tx here and everywhere below.
>
>> Hairpin is RX/TX queue that is used by the nic in order to offload
>> wire to wire traffic.
>>
>> Each hairpin queue is binded to one or more queues from other type.
>> For example TX hairpin queue should be binded to at least 1 RX hairpin
>> queue and vice versa.
>
> How should application find out that hairpin queues are supported?
You might want to look this patch "[dpdk-dev] [PATCH v2 0/4] get Rx/Tx
packet burst mode information" from Haiyue Wang.
Where he adds a information bitmask to describe the capabilities of the PMD.
Ray K
> How many?
> How should application find out which ports/queues could be used for
> pining?
> Is hair-pinning domain on device level sufficient to expose limitations?
>
>> Signed-off-by: Ori Kam
>> ---
>> lib/librte_ethdev/rte_ethdev.c | 213
>> +++
>> lib/librte_ethdev/rte_ethdev.h | 145 +
>> lib/librte_ethdev/rte_ethdev_core.h | 18 +++
>> lib/librte_ethdev/rte_ethdev_version.map | 4 +
>> 4 files changed, 380 insertions(+)
>>
>> diff --git a/lib/librte_ethdev/rte_ethdev.c
>> b/lib/librte_ethdev/rte_ethdev.c
>> index 30b0c78..4021f38 100644
>> --- a/lib/librte_ethdev/rte_ethdev.c
>> +++ b/lib/librte_ethdev/rte_ethdev.c
>> @@ -1701,6 +1701,115 @@ struct rte_eth_dev *
>> }
>> int
>> +rte_eth_rx_hairpin_queue_setup(uint16_t port_id, uint16_t rx_queue_id,
>> + uint16_t nb_rx_desc, unsigned int socket_id,
>> + const struct rte_eth_rxconf *rx_conf,
>> + const struct rte_eth_hairpin_conf *hairpin_conf)
>
> Below code duplicates rte_eth_rx_queue_setup() a lot and it is very
> bad from maintenance point of view. Similar problem with Tx hairpin
> queue setup.
>
>> +{
>> + int ret;
>> + struct rte_eth_dev *dev;
>> + struct rte_eth_dev_info dev_info;
>> + struct rte_eth_rxconf local_conf;
>> + void **rxq;
>> +
>> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -EINVAL);
>> +
>> + dev = &rte_eth_devices[port_id];
>> + if (rx_queue_id >= dev->data->nb_rx_queues) {
>> + RTE_ETHDEV_LOG(ERR, "Invalid RX queue_id=%u\n", rx_queue_id);
>> + return -EINVAL;
>> + }
>> +
>> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->dev_infos_get, -ENOTSUP);
>> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_hairpin_queue_setup,
>> + -ENOTSUP);
>> +
>> + rte_eth_dev_info_get(port_id, &dev_info);
>> +
>> + /* Use default specified by driver, if nb_rx_desc is zero */
>> + if (nb_rx_desc == 0) {
>> + nb_rx_desc = dev_info.default_rxportconf.ring_size;
>> + /* If driver default is also zero, fall back on EAL default */
>> + if (nb_rx_desc == 0)
>> + nb_rx_desc = RTE_ETH_DEV_FALLBACK_RX_RINGSIZE;
>> + }
>> +
>> + if (nb_rx_desc > dev_info.rx_desc_lim.nb_max ||
>> + nb_rx_desc < dev_info.rx_desc_lim.nb_min ||
>> + nb_rx_desc % dev_info.rx_desc_lim.nb_align != 0) {
>> +
>> + RTE_ETHDEV_LOG(ERR,
>> + "Invalid value for nb_rx_desc(=%hu), should be: "
>> + "<= %hu, >= %hu, and a product of %hu\n",
>> + nb_rx_desc, dev_info.rx_desc_lim.nb_max,
>> + dev_info.rx_desc_lim.nb_min,
>> + dev_info.rx_desc_lim.nb_align);
>> + return -EINVAL;
>> + }
>> +
>> + if (dev->data->dev_started &&
>> + !(dev_info.dev_capa &
>> + RTE_ETH_DEV_CAPA_RUNTIME_RX_QUEUE_SETUP))
>> + return -EBUSY;
>> +
>> + if (dev->data->dev_started &&
>> + (dev->data->rx_queue_state[rx_queue_id] !=
>> + RTE_ETH_QUEUE_STATE_STOPPED))
>> + return -EBUSY;
>> +
>> + rxq = dev->data->rx_queues;
>> + if (rxq[rx_queue_id]) {
>> + RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->rx_queue_release,
>> + -ENOTSUP);
>> + (*dev->dev_ops->rx_queue_release)(rxq[rx_queue_id]);
>> + rxq[rx_queue_id] = NULL;
>> + }
>> +
>> + if (rx_conf == NULL)
>> + rx_conf = &dev_info.default_rxconf;
>> +
>> + local_conf = *rx_conf;
>> +
>> + /*
>> + * If an offloading has already been enabled in
>> + * rte_eth_dev_configure(), it has been enabled on all queues,
>> + * so there is no need to enable it in this queue again.
>> + * The local_conf.offloads input to underlying PMD only carries
>> + * those offloadings which are only enabled on this queue and
>> + * not enabled on all queues.
>> + */
>> + local_conf.offloads &= ~dev->data->dev_conf.rxmode.offloads;
>> +
>> + /*
>> + * New added offloadings for this queue are those not enabled in
>> + * rte_eth_dev_configure() and they must be per-queue type.
>> + * A pure per-port offloading can't be enabled on a queue while
>> + * disabled on
Re: [dpdk-dev] [PATCH v3 1/3] lib/ring: add peek API
> > Subject: [PATCH v3 1/3] lib/ring: add peek API
> >
> > From: Ruifeng Wang
> >
> > The peek API allows fetching the next available object in the ring
> > without dequeuing it. This helps in scenarios where dequeuing of
> > objects depend on their value.
> >
> > Signed-off-by: Dharmik Thakkar
> > Signed-off-by: Ruifeng Wang
> > Reviewed-by: Honnappa Nagarahalli
> > Reviewed-by: Gavin Hu
> > ---
> > lib/librte_ring/rte_ring.h | 30 ++
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/lib/librte_ring/rte_ring.h b/lib/librte_ring/rte_ring.h
> > index 2a9f768a1..d3d0d5e18 100644
> > --- a/lib/librte_ring/rte_ring.h
> > +++ b/lib/librte_ring/rte_ring.h
> > @@ -953,6 +953,36 @@ rte_ring_dequeue_burst(struct rte_ring *r, void
> **obj_table,
> > r->cons.single, available);
> > }
> >
> > +/**
> > + * Peek one object from a ring.
> > + *
> > + * The peek API allows fetching the next available object in the ring
> > + * without dequeuing it. This API is not multi-thread safe with
> > +respect
> > + * to other consumer threads.
> > + *
> > + * @param r
> > + * A pointer to the ring structure.
> > + * @param obj_p
> > + * A pointer to a void * pointer (object) that will be filled.
> > + * @return
> > + * - 0: Success, object available
> > + * - -ENOENT: Not enough entries in the ring.
> > + */
> > +__rte_experimental
> > +static __rte_always_inline int
> > +rte_ring_peek(struct rte_ring *r, void **obj_p)
>
> As it is not MT safe, then I think we need _sc_ in the name, to follow other
> rte_ring functions naming conventions
> (rte_ring_sc_peek() or so).
Agree
>
> As a better alternative what do you think about introducing a serialized
> versions of DPDK rte_ring dequeue functions?
> Something like that:
>
> /* same as original ring dequeue, but:
> * 1) move cons.head only if cons.head == const.tail
> * 2) don't update cons.tail
> */
> unsigned int
> rte_ring_serial_dequeue_bulk(struct rte_ring *r, void **obj_table, unsigned
> int n,
> unsigned int *available);
>
> /* sets both cons.head and cons.tail to cons.head + num */ void
> rte_ring_serial_dequeue_finish(struct rte_ring *r, uint32_t num);
>
> /* resets cons.head to const.tail value */ void
> rte_ring_serial_dequeue_abort(struct rte_ring *r);
>
> Then your dq_reclaim cycle function will look like that:
>
> const uint32_t nb_elt = dq->elt_size/8 + 1; uint32_t avl, n; uintptr_t
> elt[nb_elt]; ...
>
> do {
>
> /* read next elem from the queue */
> n = rte_ring_serial_dequeue_bulk(dq->r, elt, nb_elt, &avl);
> if (n == 0)
> break;
>
> /* wrong period, keep elem in the queue */ if (rte_rcu_qsbr_check(dr->v,
> elt[0]) != 1) {
> rte_ring_serial_dequeue_abort(dq->r);
> break;
> }
>
> /* can reclaim, remove elem from the queue */
> rte_ring_serial_dequeue_finish(dr->q, nb_elt);
>
>/*call reclaim function */
> dr->f(dr->p, elt);
>
> } while (avl >= nb_elt);
>
> That way, I think even rte_rcu_qsbr_dq_reclaim() can be MT safe.
> As long as actual reclamation callback itself is MT safe of course.
I think it is a great idea. The other writers would still be polling for the
current writer to update the tail or update the head. This makes it a blocking
solution.
We can make the other threads not poll i.e. they will quit reclaiming if they
see that other writers are dequeuing from the queue. The other way is to use
per thread queues.
The other requirement I see is to support unbounded-size data structures where
in the data structures do not have a pre-determined number of entries. Also,
currently the defer queue size is equal to the total number of entries in a
given data structure. There are plans to support dynamically resizable defer
queue. This means, memory allocation which will affect the lock-free-ness of
the solution.
So, IMO:
1) The API should provide the capability to support different algorithms - may
be through some flags?
2) The requirements for the ring are pretty unique to the problem we have here
(for ex: move the cons-head only if cons-tail is also the same, skip polling).
So, we should probably implement a ring with-in the RCU library?
>From the timeline perspective, adding all these capabilities would be
>difficult to get done with in 19.11 timeline. What I have here satisfies my
>current needs. I suggest that we make provisions in APIs now to support all
>these features, but do the implementation in the coming releases. Does this
>sound ok for you?
>
> > +{
> > + uint32_t prod_tail = r->prod.tail;
> > + uint32_t cons_head = r->cons.head;
> > + uint32_t count = (prod_tail - cons_head) & r->mask;
> > + unsigned int n = 1;
> > + if (count) {
> > + DEQUEUE_PTRS(r, &r[1], cons_head, obj_p, n, void *);
> > + return 0;
> > + }
> > + return -ENOENT;
> > +}
> > +
> > #ifdef __cplusplus
> > }
> > #endif
> > --
> > 2.17.1
Re: [dpdk-dev] [PATCH] vhost: add support to large linear mbufs
On Thu, 3 Oct 2019 18:57:32 +0200 Ilya Maximets wrote: > On 02.10.2019 20:15, Flavio Leitner wrote: > > On Wed, 2 Oct 2019 17:50:41 + > > Shahaf Shuler wrote: > > > >> Wednesday, October 2, 2019 3:59 PM, Flavio Leitner: > >>> Obrembski MichalX ; Stokes Ian > >>> > >>> Subject: Re: [dpdk-dev] [PATCH] vhost: add support to large linear > >>> mbufs > >>> > >>> > >>> Hi Shahaf, > >>> > >>> Thanks for looking into this, see my inline comments. > >>> > >>> On Wed, 2 Oct 2019 09:00:11 + > >>> Shahaf Shuler wrote: > >>> > Wednesday, October 2, 2019 11:05 AM, David Marchand: > > Subject: Re: [dpdk-dev] [PATCH] vhost: add support to large > > linear mbufs > > > > Hello Shahaf, > > > > On Wed, Oct 2, 2019 at 6:46 AM Shahaf Shuler > > wrote: > >> > >> > >> [...] > >> > > > > I am missing some piece here. > > Which pool would the PMD take those external buffers from? > > The mbuf is always taken from the single mempool associated w/ > the rxq. The buffer for the mbuf may be allocated (in case virtio > payload is bigger than current mbuf size) from DPDK hugepages or > any other system memory and be attached to the mbuf. > > You can see example implementation of it in mlx5 PMD (checkout > rte_pktmbuf_attach_extbuf call) > >>> > >>> Thanks, I wasn't aware of external buffers. > >>> > >>> I see that attaching external buffers of the correct size would be > >>> more efficient in terms of saving memory/avoiding sparsing. > >>> > >>> However, we still need to be prepared to the worse case scenario > >>> (all packets 64K), so that doesn't help with the total memory > >>> required. > >> > >> Am not sure why. > >> The allocation can be per demand. That is - only when you > >> encounter a large buffer. > >> > >> Having buffer allocated in advance will benefit only from removing > >> the cost of the rte_*malloc. However on such big buffers, and > >> further more w/ device offloads like TSO, am not sure that is an > >> issue. > > > > Now I see what you're saying. I was thinking we had to reserve the > > memory before, like mempool does, then get the buffers as needed. > > > > OK, I can give a try with rte_*malloc and see how it goes. > > This way we actually could have a nice API. For example, by > introducing some new flag RTE_VHOST_USER_NO_CHAINED_MBUFS (there > might be better name) which could be passed to driver_register(). > On receive, depending on this flag, function will create chained > mbufs or allocate new contiguous memory chunk and attach it as > an external buffer if the data could not be stored in a single > mbuf from the registered memory pool. > > Supporting external memory in mbufs will require some additional > work from the OVS side (e.g. better work with ol_flags), but > we'll have to do it anyway for upgrade to DPDK 19.11. Agreed. Looks like rte_malloc is fast enough after all. I have a PoC running iperf3 from VM to another baremetal using vhost-user client with TSO enabled: [...] [ 5] 140.00-141.00 sec 4.60 GBytes 39.5 Gbits/sec0 1.26 MBytes [ 5] 141.00-142.00 sec 4.65 GBytes 39.9 Gbits/sec0 1.26 MBytes [ 5] 142.00-143.00 sec 4.65 GBytes 40.0 Gbits/sec0 1.26 MBytes [ 5] 143.00-144.00 sec 4.65 GBytes 39.9 Gbits/sec9 1.04 MBytes [ 5] 144.00-145.00 sec 4.59 GBytes 39.4 Gbits/sec0 1.16 MBytes [ 5] 145.00-146.00 sec 4.58 GBytes 39.3 Gbits/sec0 1.26 MBytes [ 5] 146.00-147.00 sec 4.48 GBytes 38.5 Gbits/sec 700973 KBytes [...] (The physical link is 40Gbps) I will clean that, test more and post the patches soon. Thanks! fbl
[dpdk-dev] [PATCH] net/ixgbe: avoid multpile definitions of 'bool'
Compilation issue arises due to multiple definitions of 'bool'
in 'ixgbe_ethdev.h'.
Error:
'/dpdk/drivers/net/ixgbe/ixgbe_ethdev.c: In function
‘ixgbe_dev_setup_link_alarm_handler’:
/dpdk/drivers/net/ixgbe/ixgbe_ethdev.c:4075:43:
error: passing argument 3 of ‘ixgbe_get_link_capabilities’ from
incompatible pointer type [-Werror=incompatible-pointer-types]
ixgbe_get_link_capabilities(hw, &speed, &autoneg);
^
In file included from /dpdk/drivers/net/ixgbe/ixgbe_ethdev.c:41:0:
/dpdk/drivers/net/ixgbe/base/ixgbe_api.h:63:5: note: expected
‘bool * {aka int *}’ but argument is of type ‘_Bool *’'
Signed-off-by: Dharmik Thakkar
Reviewed-by: Honnappa Nagarahalli
---
drivers/net/ixgbe/base/ixgbe_osdep.h | 4 +---
drivers/net/ixgbe/ixgbe_ethdev.c | 7 ---
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ixgbe/base/ixgbe_osdep.h
b/drivers/net/ixgbe/base/ixgbe_osdep.h
index ea8dc1cbe570..844d1701f595 100644
--- a/drivers/net/ixgbe/base/ixgbe_osdep.h
+++ b/drivers/net/ixgbe/base/ixgbe_osdep.h
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -82,9 +83,6 @@ typedef int16_t s16;
typedef uint32_t u32;
typedef int32_ts32;
typedef uint64_t u64;
-#ifndef __cplusplus
-typedef intbool;
-#endif
#define mb() rte_mb()
#define wmb() rte_wmb()
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 7eb3d0567b58..2c5d2e5f9295 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2589,7 +2589,8 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(dev);
struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
uint32_t intr_vector = 0;
- int err, link_up = 0, negotiate = 0;
+ int err;
+ bool link_up = 0, negotiate = 0;
uint32_t speed = 0;
uint32_t allowed_speeds = 0;
int mask = 0;
@@ -3958,7 +3959,7 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
static int
ixgbevf_check_link(struct ixgbe_hw *hw, ixgbe_link_speed *speed,
- int *link_up, int wait_to_complete)
+ bool *link_up, int wait_to_complete)
{
struct ixgbe_adapter *adapter = container_of(hw,
struct ixgbe_adapter, hw);
@@ -4089,7 +4090,7 @@ ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
struct ixgbe_interrupt *intr =
IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
- int link_up;
+ bool link_up;
int diag;
int wait = 1;
--
2.17.1
Re: [dpdk-dev] [PATCH 2/5] lib/ring: add template to support different element sizes
> > > > > > > +++ b/lib/librte_ring/rte_ring_template.h
> > > > > > > @@ -0,0 +1,330 @@
> > > > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > > > + * Copyright (c) 2019 Arm Limited */
> > > > > > > +
> > > > > > > +#ifndef _RTE_RING_TEMPLATE_H_ #define
> _RTE_RING_TEMPLATE_H_
> > > > > > > +
> > > > > > > +#ifdef __cplusplus
> > > > > > > +extern "C" {
> > > > > > > +#endif
> > > > > > > +
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +#include #include
> > > > > > > +#include #include
> > > > > > > +
> > > > > > > +/* Ring API suffix name - used to append to API names */
> > > > > > > +#ifndef RTE_RING_TMPLT_API_SUFFIX #error
> > > > > > > +RTE_RING_TMPLT_API_SUFFIX
> > > > not
> > > > > > > +defined #endif
> > > > > > > +
> > > > > > > +/* Ring's element size in bits, should be a power of 2 */
> > > > > > > +#ifndef RTE_RING_TMPLT_ELEM_SIZE #error
> > > > > > > +RTE_RING_TMPLT_ELEM_SIZE
> > > > not
> > > > > > defined
> > > > > > > +#endif
> > > > > > > +
> > > > > > > +/* Type of ring elements */ #ifndef
> > > > > > > +RTE_RING_TMPLT_ELEM_TYPE #error
> RTE_RING_TMPLT_ELEM_TYPE
> > > > > > > +not defined #endif
> > > > > > > +
> > > > > > > +#define _rte_fuse(a, b) a##_##b #define __rte_fuse(a, b)
> > > > > > > +_rte_fuse(a, b) #define
> > > > > > > +__RTE_RING_CONCAT(a) __rte_fuse(a,
> > > > > > > +RTE_RING_TMPLT_API_SUFFIX)
> > > > > > > +
> > > > > > > +/* Calculate the memory size needed for a ring */
> > > > > > > +RTE_RING_TMPLT_EXPERIMENTAL ssize_t
> > > > > > > +__RTE_RING_CONCAT(rte_ring_get_memsize)(unsigned count);
> > > > > > > +
> > > > > > > +/* Create a new ring named *name* in memory. */
> > > > > > > +RTE_RING_TMPLT_EXPERIMENTAL struct rte_ring *
> > > > > > > +__RTE_RING_CONCAT(rte_ring_create)(const char *name,
> > > > > > > +unsigned
> > > > count,
> > > > > > > + int socket_id, unsigned flags);
> > > > > >
> > > > > >
> > > > > > Just an idea - probably same thing can be achieved in a different
> way.
> > > > > > Instead of all these defines - replace
> > > > > > ENQUEUE_PTRS/DEQUEUE_PTRS macros with static inline functions
> > > > > > and then make all internal functions,
> > > > i.e.
> > > > > > __rte_ring_do_dequeue()
> > > > > > to accept enqueue/dequeue function pointer as a parameter.
> > > > > > Then let say default rte_ring_mc_dequeue_bulk will do:
> > > > > >
> > > > > > rte_ring_mc_dequeue_bulk(struct rte_ring *r, void **obj_table,
> > > > > > unsigned int n, unsigned int *available) {
> > > > > > return __rte_ring_do_dequeue(r, obj_table, n,
> > > > RTE_RING_QUEUE_FIXED,
> > > > > > __IS_MC, available,
> > > > > > dequeue_ptr_default); }
> > > > > >
> > > > > > Then if someone will like to define ring functions
> > > > > > forelt_size==X, all he would need to do:
> > > > > > 1. define his own enqueue/dequeuer functions.
> > > > > > 2. do something like:
> > > > > > rte_ring_mc_dequeue_bulk(struct rte_ring *r, void **obj_table,
> > > > > > unsigned int n, unsigned int *available) {
> > > > > > return __rte_ring_do_dequeue(r, obj_table, n,
> > > > RTE_RING_QUEUE_FIXED,
> > > > > > __IS_MC, available, dequeue_X); }
> > > > > >
> > > > > > Konstantin
> > > > > Thanks for the feedback/idea. The goal of this patch was to make
> > > > > it simple enough to define APIs to store any element size
> > > > > without code
> > > > duplication.
> > > >
> > > > Well, then if we store elt_size inside the ring, it should be easy
> > > > enough to add to the API generic functions that would use
> > > > memcpy(or rte_memcpy) for enqueue/dequeue.
> > > > Yes, it might be slower than existing (8B per elem), but might be
> > > > still acceptable.
> > > The element size will be a constant in most use cases. If we keep
> > > the element size as a parameter, it allows the compiler to do any loop
> unrolling and auto-vectorization optimizations on copying.
> > > Storing the element size will result in additional memory access.
> >
> > I understand that, but for you case (rcu defer queue) you probably need
> highest possible performance, right?
>
> Meant 'don't need' of course :)
😊 understood. that is just one use case. It actually started as an option to
reduce memory usage in different places. You can look at the rte_hash changes
in this patch. I also have plans for further changes.
>
> > I am sure there will be other cases where such slight perf degradation is
> acceptatble.
> >
> > >
> > > >
> > > > >With this patch, the user has to write ~4 lines of code to get
> > > > >APIs for any element size. I would like to keep the goal still the
> > > > >same.
> > > > >
> > > > > If we have to avoid the macro-fest, the main problem that needs
> > > > > to be addres
[dpdk-dev] [PATCH] crypto/armv8: enable meson build
Add new meson.build file for crypto/armv8
Signed-off-by: Dharmik Thakkar
---
drivers/crypto/armv8/meson.build | 25 +
drivers/crypto/meson.build | 6 +++---
meson_options.txt| 2 ++
3 files changed, 30 insertions(+), 3 deletions(-)
create mode 100644 drivers/crypto/armv8/meson.build
diff --git a/drivers/crypto/armv8/meson.build b/drivers/crypto/armv8/meson.build
new file mode 100644
index ..1ef78fa5d8c7
--- /dev/null
+++ b/drivers/crypto/armv8/meson.build
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright(c) 2019 Arm Limited
+
+path = get_option('armv8_crypto_dir')
+if path == ''
+ build = false
+ reason = 'missing dependency, "armv8_crypto"'
+ subdir_done()
+endif
+
+inc_dir = path + '/asm/include'
+
+lib = cc.find_library('libarmv8_crypto', dirs: [path], required: false)
+if not lib.found()
+ build = false
+ reason = 'missing dependency, "armv8_crypto"'
+ subdir_done()
+else
+ ext_deps += lib
+ includes += include_directories(inc_dir)
+endif
+
+deps += ['bus_vdev']
+sources = files('rte_armv8_pmd.c', 'rte_armv8_pmd_ops.c')
+allow_experimental_apis = true
diff --git a/drivers/crypto/meson.build b/drivers/crypto/meson.build
index 83e78860ebee..605dcdd5f4d6 100644
--- a/drivers/crypto/meson.build
+++ b/drivers/crypto/meson.build
@@ -1,9 +1,9 @@
# SPDX-License-Identifier: BSD-3-Clause
# Copyright(c) 2017 Intel Corporation
-drivers = ['aesni_gcm', 'aesni_mb', 'caam_jr', 'ccp', 'dpaa_sec', 'dpaa2_sec',
- 'kasumi', 'mvsam', 'null', 'octeontx', 'openssl', 'qat', 'scheduler',
- 'snow3g', 'virtio', 'zuc']
+drivers = ['aesni_gcm', 'aesni_mb', 'armv8', 'caam_jr', 'ccp', 'dpaa_sec',
+ 'dpaa2_sec', 'kasumi', 'mvsam', 'null', 'octeontx', 'openssl', 'qat',
+ 'scheduler', 'snow3g', 'virtio', 'zuc']
std_deps = ['cryptodev'] # cryptodev pulls in all other needed deps
config_flag_fmt = 'RTE_LIBRTE_@0@_PMD'
diff --git a/meson_options.txt b/meson_options.txt
index 448f3e63dcf2..4c0413918a34 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -2,6 +2,8 @@
option('allow_invalid_socket_id', type: 'boolean', value: false,
description: 'allow out-of-range NUMA socket id\'s for platforms that
don\'t report the value correctly')
+option('armv8_crypto_dir', type: 'string', value: '',
+ description: 'path to the armv8_crypto library installation directory')
option('drivers_install_subdir', type: 'string', value: 'dpdk/pmds-',
description: 'Subdirectory of libdir where to install PMDs. Defaults to
using a versioned subdirectory.')
option('enable_docs', type: 'boolean', value: false,
--
2.17.1
Re: [dpdk-dev] 18.11.3 (LTS) patches review and test
Hi Kevin, The testings from Red Hat get PASS result. Below 13 testing scenarios look good with v18.11.3-rc1. Testing scenarios: (1)Guest with device assignment(PF) throughput testing(1G hugepage size): PASS (2)Guest with device assignment(PF) throughput testing(2M hugepage size): PASS (3)Guest with device assignment(VF) throughput testing: PASS (4)PVP (host dpdk testpmd as vswitch) 1Q: throughput testing: PASS (5)PVP vhost-user 2Q throughput testing: PASS (6)PVP vhost-user 2Q - cross numa node throughput testing: PASS (7)Guest with vhost-user 2 queues throughput testing: PASS (8)vhost-user reconnect with dpdk-client, qemu-server: qemu reconnect: PASS (9)PVP 1Q live migration testing: PASS (10)PVP 2Q cross numa node live migration testing: PASS (11)Guest with ovs+dpdk+vhost-user 1Q live migration testing: PASS (12)Guest with ovs+dpdk+vhost-user 1Q live migration testing (2M): PASS (13)Guest with ovs+dpdk+vhost-user 2Q live migration testing: PASS Versions: kernel 4.18.0 dpdk: git://dpdk.org/dpdk-stable remotes/origin/18.11 commit d908ee9de303b1c4f22410f0fd5be710ae1eb5fc Hardware info: # lscpu Architecture:x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 32 On-line CPU(s) list: 0-31 Thread(s) per core: 1 Core(s) per socket: 16 Socket(s): 2 NUMA node(s):2 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Gold 6130 CPU @ 2.10GHz Stepping:4 CPU MHz: 2100.028 BogoMIPS:4200.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache:1024K L3 cache:22528K NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30 NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd mba ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm arat pln pts pku ospke md_clear flush_l1d # lspci | grep Eth 5e:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01) 5e:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01) 5f:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01) 5f:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 (rev 01) Best regards, Pei - Original Message - From: "Kevin Traynor" To: sta...@dpdk.org Cc: dev@dpdk.org, "Akhil Goyal" , "Ali Alnubani" , "benjamin walker" , "David Christensen" , "Hemant Agrawal" , "Ian Stokes" , "Jerin Jacob" , "John McNamara" , "Ju-Hyoung Lee" , "Kevin Traynor" , "Luca Boccassi" , "Pei Zhang" , "pingx yu" , "qian q xu" , "Raslan Darawsheh" , "Thomas Monjalon" , "yuan peng" , "zhaoyan chen" Sent: Saturday, September 14, 2019 12:31:00 AM Subject: 18.11.3 (LTS) patches review and test Hi all, Here is a list of patches targeted for LTS release 18.11.3. The planned date for the final release is 9th October. Please help with testing and validation of your use cases and report any issues/results in reply to this mail. For the final release the fixes and reported validations will be added to the release notes. A release candidate tarball can be found at: https://dpdk.org/browse/dpdk-stable/tag/?id=v18.11.3-rc1 These patches are located at branch 18.11 of dpdk-stable repo: https://dpdk.org/browse/dpdk-stable/ Thanks. Kevin Traynor --- Aaron Conole (2): test/flow_classify: fix undefined behavior acl: fix undefined behavior of bit shifts Adam Dybkowski (1): compress/zlib: fix error handling Aideen McLoughlin (1): net/pcap: fix possible mbuf double freeing Ajit Khaparde (6): net/bnxt: fix TSO net/bnxt: check for error conditions in Tx path net/bnxt: fix RSS RETA indirection table ops net/bnxt: save the number of EM flow count net/bnxt: fix compiler warning net/bnxt: remove unnecessary interrupt disable Akash Saxena (1): crypto/openssl: remove useless check before freeing Ali Alnubani (3): examples/ip_fragmentation: fix Tx queues init net/mlx5: fix 32-bit build doc: fix link about bifurcated
Re: [dpdk-dev] [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by sessionless
> -Original Message- > From: Arek Kusztal > Sent: Friday, September 6, 2019 5:28 PM > To: dev@dpdk.org > Cc: akhil.go...@nxp.com; fiona.tr...@intel.com; Shally Verma > ; Anoob Joseph ; Arek > Kusztal > Subject: [EXT] [PATCH v2] cryptodev: extend api of asymmetric crypto by > sessionless > > External Email > > -- > This commit adds asymmetric session-less option to rte_crypto_asym_op. > Feature flag for sessionless is added to rte_cryptodev. > > Signed-off-by: Arek Kusztal > --- > lib/librte_cryptodev/rte_crypto_asym.h | 9 +++-- > lib/librte_cryptodev/rte_cryptodev.h | 2 ++ > 2 files changed, 9 insertions(+), 2 deletions(-) > Acked-by: Anoob Joseph
[dpdk-dev] [PATCH v2 1/9] net/bnxt: increase tqm entry allocation
From: Lance Richardson
The current TQM backing store size isn't sufficient to allow 512
transmit rings. Fix by correcting TQM SP queue size calculation.
Fixes: f8168ca0e690 ("net/bnxt: support thor controller")
Cc: sta...@dpdk.org
Signed-off-by: Lance Richardson
Reviewed-by: Ajit Khaparde
Reviewed-by: Kalesh Anakkur Purayil
---
drivers/net/bnxt/bnxt_ethdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 02eacf7965..0e893cc956 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -4292,7 +4292,9 @@ int bnxt_alloc_ctx_mem(struct bnxt *bp)
if (rc)
return rc;
- entries = ctx->qp_max_l2_entries;
+ entries = ctx->qp_max_l2_entries +
+ ctx->vnic_max_vnic_entries +
+ ctx->tqm_min_entries_per_ring;
entries = bnxt_roundup(entries, ctx->tqm_entries_multiple);
entries = clamp_t(uint32_t, entries, ctx->tqm_min_entries_per_ring,
ctx->tqm_max_entries_per_ring);
--
2.20.1 (Apple Git-117)
[dpdk-dev] [PATCH v2 2/9] net/bnxt: fix ring alignment for thor-based adapters
From: Lance Richardson
When using transmit/receive queue sizes smaller than 256, alignment
requirements are not being met for Thor-based adapters. Fix by
forcing memory addresses used for transmit/receive/aggregation ring
allocations to be on 4K boundaries.
Fixes: f8168ca0e690 ("net/bnxt: support thor controller")
Signed-off-by: Lance Richardson
Reviewed-by: Ajit Kumar Khaparde
---
drivers/net/bnxt/bnxt_ring.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/bnxt/bnxt_ring.c b/drivers/net/bnxt/bnxt_ring.c
index a3e5a68714..4662e94132 100644
--- a/drivers/net/bnxt/bnxt_ring.c
+++ b/drivers/net/bnxt/bnxt_ring.c
@@ -162,18 +162,21 @@ int bnxt_alloc_rings(struct bnxt *bp, uint16_t qidx,
int nq_ring_len = BNXT_CHIP_THOR(bp) ? cp_ring_len : 0;
int tx_ring_start = nq_ring_start + nq_ring_len;
+ tx_ring_start = RTE_ALIGN(tx_ring_start, 4096);
int tx_ring_len = tx_ring_info ?
RTE_CACHE_LINE_ROUNDUP(tx_ring_info->tx_ring_struct->ring_size *
sizeof(struct tx_bd_long)) : 0;
tx_ring_len = RTE_ALIGN(tx_ring_len, 4096);
int rx_ring_start = tx_ring_start + tx_ring_len;
+ rx_ring_start = RTE_ALIGN(rx_ring_start, 4096);
int rx_ring_len = rx_ring_info ?
RTE_CACHE_LINE_ROUNDUP(rx_ring_info->rx_ring_struct->ring_size *
sizeof(struct rx_prod_pkt_bd)) : 0;
rx_ring_len = RTE_ALIGN(rx_ring_len, 4096);
int ag_ring_start = rx_ring_start + rx_ring_len;
+ ag_ring_start = RTE_ALIGN(ag_ring_start, 4096);
int ag_ring_len = rx_ring_len * AGG_RING_SIZE_FACTOR;
ag_ring_len = RTE_ALIGN(ag_ring_len, 4096);
--
2.20.1 (Apple Git-117)
[dpdk-dev] [PATCH v2 0/9] bnxt patchset
Apart form fixes support for Thor and vector PMD, this patchset adds support for LRO on Thor based adapters and CoS classification. Patchset against dpdk-next-net, has been compiled & tested on an x86_64 system. Please apply. Lance Richardson (8): net/bnxt: increase tqm entry allocation net/bnxt: fix ring alignment for thor-based adapters net/bnxt: add support for LRO on thor adapters net/bnxt: use common receive transmit nq ring net/bnxt: fix stats context calculation net/bnxt: use correct default Rx queue for thor net/bnxt: advertise scatter receive offload capability net/bnxt: improve CPR handling in vector PMD Venkat Duvvuru (1): net/bnxt: add support for CoS classification drivers/net/bnxt/bnxt.h| 27 - drivers/net/bnxt/bnxt_ethdev.c | 45 +++- drivers/net/bnxt/bnxt_hwrm.c | 131 --- drivers/net/bnxt/bnxt_hwrm.h | 14 ++- drivers/net/bnxt/bnxt_ring.c | 142 + drivers/net/bnxt/bnxt_ring.h | 3 +- drivers/net/bnxt/bnxt_rxq.c| 11 +- drivers/net/bnxt/bnxt_rxq.h| 1 - drivers/net/bnxt/bnxt_rxr.c| 99 + drivers/net/bnxt/bnxt_rxr.h| 41 +-- drivers/net/bnxt/bnxt_rxtx_vec_sse.c | 26 + drivers/net/bnxt/bnxt_txq.c| 4 +- drivers/net/bnxt/bnxt_txq.h| 1 - drivers/net/bnxt/bnxt_txr.c| 25 - drivers/net/bnxt/bnxt_vnic.h | 1 + drivers/net/bnxt/hsi_struct_def_dpdk.h | 28 - 16 files changed, 398 insertions(+), 201 deletions(-) -- 2.20.1 (Apple Git-117)
[dpdk-dev] [PATCH v2 4/9] net/bnxt: add support for CoS classification
From: Venkat Duvvuru
Class of Service (CoS) is a way to manage multiple types of
traffic over a network to offer different types of services
to applications. CoS classification (priority to cosqueue) is
determined by the user and configured through the PF driver.
DPDK driver queries this configuration and maps the cos queue
ids to different VNICs. This patch adds this support.
Signed-off-by: Venkat Duvvuru
Reviewed-by: Santoshkumar Karanappa Rastapur
Reviewed-by: Kalesh Anakkur Purayil
Reviewed-by: Somnath Kotur
Reviewed-by: Ajit Khaparde
---
drivers/net/bnxt/bnxt.h| 10 ++-
drivers/net/bnxt/bnxt_ethdev.c | 30 +++--
drivers/net/bnxt/bnxt_hwrm.c | 84 +++---
drivers/net/bnxt/bnxt_hwrm.h | 13 +++-
drivers/net/bnxt/bnxt_ring.c | 18 --
drivers/net/bnxt/bnxt_rxq.c| 3 +-
drivers/net/bnxt/bnxt_vnic.h | 1 +
drivers/net/bnxt/hsi_struct_def_dpdk.h | 28 -
8 files changed, 149 insertions(+), 38 deletions(-)
diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index ad97e0e593..5cfe5ee2c7 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -470,8 +470,10 @@ struct bnxt {
uint32_tflow_flags;
#define BNXT_FLOW_FLAG_L2_HDR_SRC_FILTER_ENBIT(0)
-
pthread_mutex_t flow_lock;
+
+ uint32_tvnic_cap_flags;
+#define BNXT_VNIC_CAP_COS_CLASSIFY BIT(0)
unsigned intrx_nr_rings;
unsigned intrx_cp_nr_rings;
unsigned intrx_num_qs_per_vnic;
@@ -523,8 +525,10 @@ struct bnxt {
uint16_thwrm_max_ext_req_len;
struct bnxt_link_info link_info;
- struct bnxt_cos_queue_info cos_queue[BNXT_COS_QUEUE_COUNT];
- uint8_t tx_cosq_id;
+ struct bnxt_cos_queue_info rx_cos_queue[BNXT_COS_QUEUE_COUNT];
+ struct bnxt_cos_queue_info tx_cos_queue[BNXT_COS_QUEUE_COUNT];
+ uint8_t tx_cosq_id[BNXT_COS_QUEUE_COUNT];
+ uint8_t rx_cosq_cnt;
uint8_t max_tc;
uint8_t max_lltc;
uint8_t max_q;
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 4fc182b8cc..9adcd94ff8 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -308,6 +308,25 @@ static int bnxt_init_chip(struct bnxt *bp)
goto err_out;
}
+ if (!(bp->vnic_cap_flags & BNXT_VNIC_CAP_COS_CLASSIFY))
+ goto skip_cosq_cfg;
+
+ for (j = 0, i = 0; i < BNXT_COS_QUEUE_COUNT; i++) {
+ if (bp->rx_cos_queue[i].id != 0xff) {
+ struct bnxt_vnic_info *vnic = &bp->vnic_info[j++];
+
+ if (!vnic) {
+ PMD_DRV_LOG(ERR,
+ "Num pools more than FW profile\n");
+ rc = -EINVAL;
+ goto err_out;
+ }
+ vnic->cos_queue_id = bp->rx_cos_queue[i].id;
+ bp->rx_cosq_cnt++;
+ }
+ }
+
+skip_cosq_cfg:
rc = bnxt_mq_rx_configure(bp);
if (rc) {
PMD_DRV_LOG(ERR, "MQ mode configure failure rc: %x\n", rc);
@@ -4540,7 +4559,7 @@ static int bnxt_init_fw(struct bnxt *bp)
if (rc)
return -EIO;
- rc = bnxt_hwrm_cfa_adv_flow_mgmt_qcaps(bp);
+ rc = bnxt_hwrm_vnic_qcaps(bp);
if (rc)
return rc;
@@ -4548,16 +4567,19 @@ static int bnxt_init_fw(struct bnxt *bp)
if (rc)
return rc;
- /* Get the MAX capabilities for this function */
+ /* Get the MAX capabilities for this function.
+* This function also allocates context memory for TQM rings and
+* informs the firmware about this allocated backing store memory.
+*/
rc = bnxt_hwrm_func_qcaps(bp);
if (rc)
return rc;
- rc = bnxt_hwrm_vnic_qcaps(bp);
+ rc = bnxt_hwrm_func_qcfg(bp, &mtu);
if (rc)
return rc;
- rc = bnxt_hwrm_func_qcfg(bp, &mtu);
+ rc = bnxt_hwrm_cfa_adv_flow_mgmt_qcaps(bp);
if (rc)
return rc;
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 9f30214c99..76ef004237 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -700,6 +700,7 @@ int bnxt_hwrm_func_qcaps(struct bnxt *bp)
return rc;
}
+/* VNIC cap covers capability of all VNICs. So no need to pass vnic_id */
int bnxt_hwrm_vnic_qcaps(struct bnxt *bp)
{
int rc = 0;
@@ -714,6 +715,12 @@ int bnxt_hwrm_vnic_qcaps(struct bnxt *bp)
HWRM_CHECK_RESULT();
+ if (rte_le_to_cpu_32(resp->flags) &
+ HWRM_VNIC_QCAPS_OUTPUT_FLAGS_COS_A
[dpdk-dev] [PATCH v2 3/9] net/bnxt: add support for LRO on thor adapters
From: Lance Richardson
Add support for LRO for adapters based on Thor (BCM57508).
Reviewed-by: Kalesh Anakkur Purayil
Signed-off-by: Lance Richardson
Signed-off-by: Ajit Khaparde
---
drivers/net/bnxt/bnxt.h| 16
drivers/net/bnxt/bnxt_ethdev.c | 4 ++
drivers/net/bnxt/bnxt_hwrm.c | 33 +---
drivers/net/bnxt/bnxt_hwrm.h | 1 +
drivers/net/bnxt/bnxt_ring.c | 14 ---
drivers/net/bnxt/bnxt_ring.h | 1 -
drivers/net/bnxt/bnxt_rxq.c| 4 +-
drivers/net/bnxt/bnxt_rxr.c| 72 +-
drivers/net/bnxt/bnxt_rxr.h| 41 +++
9 files changed, 149 insertions(+), 37 deletions(-)
diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index c34582c0ad..ad97e0e593 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -37,6 +37,21 @@
#define BNXT_MAX_RX_RING_DESC 8192
#define BNXT_DB_SIZE 0x80
+#define TPA_MAX_AGGS 64
+#define TPA_MAX_AGGS_TH1024
+
+#define TPA_MAX_NUM_SEGS 32
+#define TPA_MAX_SEGS_TH8 /* 32 segments in 4-segment units */
+#define TPA_MAX_SEGS 5 /* 32 segments in log2 units */
+
+#define BNXT_TPA_MAX_AGGS(bp) \
+ (BNXT_CHIP_THOR(bp) ? TPA_MAX_AGGS_TH : \
+TPA_MAX_AGGS)
+
+#define BNXT_TPA_MAX_SEGS(bp) \
+ (BNXT_CHIP_THOR(bp) ? TPA_MAX_SEGS_TH : \
+ TPA_MAX_SEGS)
+
#ifdef RTE_ARCH_ARM64
#define BNXT_NUM_ASYNC_CPR(bp) (BNXT_STINGRAY(bp) ? 0 : 1)
#else
@@ -525,6 +540,7 @@ struct bnxt {
uint16_tmax_rx_em_flows;
uint16_tmax_vnics;
uint16_tmax_stat_ctx;
+ uint16_tmax_tpa_v2;
uint16_tfirst_vf_id;
uint16_tvlan;
#define BNXT_OUTER_TPID_MASK 0x
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 0e893cc956..4fc182b8cc 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -4553,6 +4553,10 @@ static int bnxt_init_fw(struct bnxt *bp)
if (rc)
return rc;
+ rc = bnxt_hwrm_vnic_qcaps(bp);
+ if (rc)
+ return rc;
+
rc = bnxt_hwrm_func_qcfg(bp, &mtu);
if (rc)
return rc;
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 011cd05ae0..9f30214c99 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -700,6 +700,27 @@ int bnxt_hwrm_func_qcaps(struct bnxt *bp)
return rc;
}
+int bnxt_hwrm_vnic_qcaps(struct bnxt *bp)
+{
+ int rc = 0;
+ struct hwrm_vnic_qcaps_input req = {.req_type = 0 };
+ struct hwrm_vnic_qcaps_output *resp = bp->hwrm_cmd_resp_addr;
+
+ HWRM_PREP(req, VNIC_QCAPS, BNXT_USE_CHIMP_MB);
+
+ req.target_id = rte_cpu_to_le_16(0x);
+
+ rc = bnxt_hwrm_send_message(bp, &req, sizeof(req), BNXT_USE_CHIMP_MB);
+
+ HWRM_CHECK_RESULT();
+
+ bp->max_tpa_v2 = rte_le_to_cpu_16(resp->max_aggs_supported);
+
+ HWRM_UNLOCK();
+
+ return rc;
+}
+
int bnxt_hwrm_func_reset(struct bnxt *bp)
{
int rc = 0;
@@ -1959,8 +1980,11 @@ int bnxt_hwrm_vnic_tpa_cfg(struct bnxt *bp,
struct hwrm_vnic_tpa_cfg_input req = {.req_type = 0 };
struct hwrm_vnic_tpa_cfg_output *resp = bp->hwrm_cmd_resp_addr;
- if (BNXT_CHIP_THOR(bp))
- return 0;
+ if (BNXT_CHIP_THOR(bp) && !bp->max_tpa_v2) {
+ if (enable)
+ PMD_DRV_LOG(ERR, "No HW support for LRO\n");
+ return -ENOTSUP;
+ }
if (vnic->fw_vnic_id == INVALID_HW_RING_ID) {
PMD_DRV_LOG(DEBUG, "Invalid vNIC ID\n");
@@ -1981,9 +2005,8 @@ int bnxt_hwrm_vnic_tpa_cfg(struct bnxt *bp,
HWRM_VNIC_TPA_CFG_INPUT_FLAGS_GRO |
HWRM_VNIC_TPA_CFG_INPUT_FLAGS_AGG_WITH_ECN |
HWRM_VNIC_TPA_CFG_INPUT_FLAGS_AGG_WITH_SAME_GRE_SEQ);
- req.max_agg_segs = rte_cpu_to_le_16(5);
- req.max_aggs =
- rte_cpu_to_le_16(HWRM_VNIC_TPA_CFG_INPUT_MAX_AGGS_MAX);
+ req.max_agg_segs = rte_cpu_to_le_16(BNXT_TPA_MAX_AGGS(bp));
+ req.max_aggs = rte_cpu_to_le_16(BNXT_TPA_MAX_SEGS(bp));
req.min_agg_len = rte_cpu_to_le_32(512);
}
req.vnic_id = rte_cpu_to_le_16(vnic->fw_vnic_id);
diff --git a/drivers/net/bnxt/bnxt_hwrm.h b/drivers/net/bnxt/bnxt_hwrm.h
index 07181d4020..8912a4ed3e 100644
--- a/drivers/net/bnxt/bnxt_hwrm.h
+++ b/drivers/net/bnxt/bnxt_hwrm.h
@@ -110,6 +110,7 @@ int bnxt_hwrm_vnic_alloc(struct bnxt *bp, struct
bnxt_vnic_info *vnic);
int bnxt_hwrm_vnic_cfg(struct bnxt *bp, struct bnxt_vnic_info *vnic);
int bnxt_hwrm_vnic_qcfg(struct bnxt *bp, struct bnxt_vnic_info *vnic,
int16_t fw_vf_id);
+int bnxt_hwrm_v
[dpdk-dev] [PATCH v2 7/9] net/bnxt: use correct default Rx queue for thor
From: Lance Richardson
Use first receive queue assigned to VNIC as the default receive queue
when configuring Thor VNICs. This is necessary e.g. in order for flow
redirection to a specific receive queue to work correctly.
Fixes: f8168ca0e690 ("net/bnxt: support thor controller")
Signed-off-by: Lance Richardson
Reviewed-by: Ajit Kumar Khaparde
---
drivers/net/bnxt/bnxt_hwrm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index 1e65c3b80b..0d5362581e 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -1692,7 +1692,8 @@ int bnxt_hwrm_vnic_cfg(struct bnxt *bp, struct
bnxt_vnic_info *vnic)
HWRM_PREP(req, VNIC_CFG, BNXT_USE_CHIMP_MB);
if (BNXT_CHIP_THOR(bp)) {
- struct bnxt_rx_queue *rxq = bp->eth_dev->data->rx_queues[0];
+ struct bnxt_rx_queue *rxq =
+ bp->eth_dev->data->rx_queues[vnic->start_grp_id];
struct bnxt_rx_ring_info *rxr = rxq->rx_ring;
struct bnxt_cp_ring_info *cpr = rxq->cp_ring;
--
2.20.1 (Apple Git-117)
