Re: [dpdk-dev] [dpdk-stable] [PATCH] maintainers: add missing file
01/04/2019 13:05, Dekel Peled:
> This patch adds file to "Ethernet API" section of MAINTAINERS file:
> F: doc/guides/prog_guide/switch_representation.rst
>
> Fixes: b7f859c9a9a5 ("doc: add switch representation documentation")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dekel Peled
Acked-by: Thomas Monjalon
Applied, thanks
Re: [dpdk-dev] [PATCH v3] net/ixgbe: enable 10Mb/s link setup for x553
> -Original Message- > From: Zhao1, Wei > Sent: Monday, April 1, 2019 2:25 PM > To: dev@dpdk.org > Cc: sta...@dpdk.org; Zhang, Qi Z ; Lu, Wenzhuo > ; Stillwell Jr, Paul M ; > Zhao1, Wei > Subject: [PATCH v3] net/ixgbe: enable 10Mb/s link setup for x553 > > This patch enable 10Mb/s link for ixgbe x553. > This new device has own device id of 0x15E4 and 0x15E5, so ixgbe PMD driver > need to special check when setup link for these two types of device. > > Signed-off-by: Wei Zhao Acked-by: Qi Zhang Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH] net/ice: send driver version to firmware
> -Original Message-
> From: Yang, Qiming
> Sent: Thursday, April 4, 2019 10:28 AM
> To: Zhang, Qi Z ; Lu, Wenzhuo
> Cc: dev@dpdk.org; Stillwell Jr, Paul M
> Subject: RE: [PATCH] net/ice: send driver version to firmware
>
>
>
> -Original Message-
> From: Zhang, Qi Z
> Sent: Friday, March 29, 2019 9:30 AM
> To: Lu, Wenzhuo ; Yang, Qiming
>
> Cc: dev@dpdk.org; Stillwell Jr, Paul M ;
> Zhang, Qi Z
>
> Subject: [PATCH] net/ice: send driver version to firmware
>
> The driver must send its version information to the firmware, so the firmware
> knows the driver is up. Otherwise, it will cause unexpected OS package
> downloading when multiple driver instances running on the same device.
>
> Signed-off-by: Paul M Stillwell Jr
> Signed-off-by: Qi Zhang
> ---
> drivers/net/ice/base/ice_adminq_cmd.h | 12
> drivers/net/ice/base/ice_common.c | 36
> +++
> drivers/net/ice/base/ice_common.h | 3 +++
> drivers/net/ice/base/ice_type.h | 4
> drivers/net/ice/ice_ethdev.c | 21
> 5 files changed, 76 insertions(+)
>
> diff --git a/drivers/net/ice/base/ice_adminq_cmd.h
> b/drivers/net/ice/base/ice_adminq_cmd.h
> index d2ab9eeff..bbdca83fc 100644
> --- a/drivers/net/ice/base/ice_adminq_cmd.h
> +++ b/drivers/net/ice/base/ice_adminq_cmd.h
> @@ -38,6 +38,17 @@ struct ice_aqc_get_ver { };
>
>
> +/* Send driver version (indirect 0x0002) */ struct ice_aqc_driver_ver {
> + u8 major_ver;
> + u8 minor_ver;
> + u8 build_ver;
> + u8 subbuild_ver;
> + u8 reserved[4];
> + __le32 addr_high;
> + __le32 addr_low;
> +};
> +
>
> /* Queue Shutdown (direct 0x0003) */
> struct ice_aqc_q_shutdown {
> @@ -2182,6 +2193,7 @@ struct ice_aq_desc {
> u8 raw[16];
> struct ice_aqc_generic generic;
> struct ice_aqc_get_ver get_ver;
> + struct ice_aqc_driver_ver driver_ver;
> struct ice_aqc_q_shutdown q_shutdown;
> struct ice_aqc_req_res res_owner;
> struct ice_aqc_manage_mac_read mac_read; diff --git
> a/drivers/net/ice/base/ice_common.c b/drivers/net/ice/base/ice_common.c
> index 3d2e5f347..c74e4e1d4 100644
> --- a/drivers/net/ice/base/ice_common.c
> +++ b/drivers/net/ice/base/ice_common.c
> @@ -1512,6 +1512,42 @@ enum ice_status ice_aq_get_fw_ver(struct ice_hw
> *hw, struct ice_sq_cd *cd)
> return status;
> }
>
> +/**
> + * ice_aq_send_driver_ver
> + * @hw: pointer to the HW struct
> + * @dv: driver's major, minor version
> + * @cd: pointer to command details structure or NULL
> + *
> + * Send the driver version (0x0002) to the firmware */ enum ice_status
> +ice_aq_send_driver_ver(struct ice_hw *hw, struct ice_driver_ver *dv,
> +struct ice_sq_cd *cd)
> +{
> + struct ice_aqc_driver_ver *cmd;
> + struct ice_aq_desc desc;
> + u16 len;
> +
> + cmd = &desc.params.driver_ver;
> +
> + if (!dv)
> + return ICE_ERR_PARAM;
> +
> + ice_fill_dflt_direct_cmd_desc(&desc, ice_aqc_opc_driver_ver);
> +
> + desc.flags |= CPU_TO_LE16(ICE_AQ_FLAG_RD);
> + cmd->major_ver = dv->major_ver;
> + cmd->minor_ver = dv->minor_ver;
> + cmd->build_ver = dv->build_ver;
> + cmd->subbuild_ver = dv->subbuild_ver;
> +
> + len = 0;
> + while (len < sizeof(dv->driver_string) &&
> +IS_ASCII(dv->driver_string[len]) && dv->driver_string[len])
> + len++;
> +
> + return ice_aq_send_cmd(hw, &desc, dv->driver_string, len, cd); }
>
> /**
> * ice_aq_q_shutdown
> diff --git a/drivers/net/ice/base/ice_common.h
> b/drivers/net/ice/base/ice_common.h
> index e8f2ce9d8..58c66fdc0 100644
> --- a/drivers/net/ice/base/ice_common.h
> +++ b/drivers/net/ice/base/ice_common.h
> @@ -119,6 +119,9 @@ ice_aq_send_cmd(struct ice_hw *hw, struct ice_aq_desc
> *desc, enum ice_status ice_aq_get_fw_ver(struct ice_hw *hw, struct
> ice_sq_cd *cd);
>
> enum ice_status
> +ice_aq_send_driver_ver(struct ice_hw *hw, struct ice_driver_ver *dv,
> +struct ice_sq_cd *cd);
> +enum ice_status
> ice_aq_get_phy_caps(struct ice_port_info *pi, bool qual_mods, u8
> report_mode,
> struct ice_aqc_get_phy_caps_data *caps,
> struct ice_sq_cd *cd);
> diff --git a/drivers/net/ice/base/ice_type.h b/drivers/net/ice/base/ice_type.h
> index b0bdec2df..e4979b832 100644
> --- a/drivers/net/ice/base/ice_type.h
> +++ b/drivers/net/ice/base/ice_type.h
> @@ -22,6 +22,10 @@
> #define MIN_T(_t, _a, _b)min((_t)(_a), (_t)(_b))
> #endif
>
> +#ifndef IS_ASCII
> +#define IS_ASCII(_ch) ((_ch) < 0x80)
> +#endif
> +
> #include "ice_status.h"
> #include "ice_hw_autogen.h"
> #include "ice_devids.h"
> diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c index
> 85311dde0..922a211f1 100644
> --- a/drivers/net/ice/ice_ethdev.c
> +++ b/drivers/net/ice/ice_ethdev.c
> @@ -1244,6 +1244,21 @@ ice_setup_vsi(struct
[dpdk-dev] [PATCH v3 1/2] app/testpmd: fix Tx VLAN and QinQ dependency
Tx VLAN & QinQ insert enable need not depend on
Rx VLAN offload ETH_VLAN_EXTEND_OFFLOAD. For Tx VLAN
insert enable, error check is now to see if QinQ was enabled
but only single VLAN id is set.
Fixes: 6a34f91690d0 ("app/testpmd: fix error message when setting Tx VLAN")
Cc: xiao.w.w...@intel.com
Signed-off-by: Nithin Dabilpuram
---
v3:
* Add back error check in tx_vlan_set() to check if QinQ is
already enabled. Also fix headline.
v2:
* Split change into two seperate patches as suggested.
app/test-pmd/config.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index cadcb51..010e26d 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2962,7 +2962,6 @@ vlan_tpid_set(portid_t port_id, enum rte_vlan_type
vlan_type, uint16_t tp_id)
void
tx_vlan_set(portid_t port_id, uint16_t vlan_id)
{
- int vlan_offload;
struct rte_eth_dev_info dev_info;
if (port_id_is_invalid(port_id, ENABLED_WARN))
@@ -2970,8 +2969,8 @@ tx_vlan_set(portid_t port_id, uint16_t vlan_id)
if (vlan_id_is_invalid(vlan_id))
return;
- vlan_offload = rte_eth_dev_get_vlan_offload(port_id);
- if (vlan_offload & ETH_VLAN_EXTEND_OFFLOAD) {
+ if (ports[port_id].dev_conf.txmode.offloads &
+ DEV_TX_OFFLOAD_QINQ_INSERT) {
printf("Error, as QinQ has been enabled.\n");
return;
}
@@ -2990,7 +2989,6 @@ tx_vlan_set(portid_t port_id, uint16_t vlan_id)
void
tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t vlan_id_outer)
{
- int vlan_offload;
struct rte_eth_dev_info dev_info;
if (port_id_is_invalid(port_id, ENABLED_WARN))
@@ -3000,11 +2998,6 @@ tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t
vlan_id_outer)
if (vlan_id_is_invalid(vlan_id_outer))
return;
- vlan_offload = rte_eth_dev_get_vlan_offload(port_id);
- if (!(vlan_offload & ETH_VLAN_EXTEND_OFFLOAD)) {
- printf("Error, as QinQ hasn't been enabled.\n");
- return;
- }
rte_eth_dev_info_get(port_id, &dev_info);
if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_QINQ_INSERT) == 0) {
printf("Error: qinq insert not supported by port %d\n",
--
2.8.4
Re: [dpdk-dev] [PATCH] eal: fix typo in comment
01/04/2019 13:06, Dekel Peled:
> Remove redundant item 'a4' in comment.
>
> Fixes: 86c743cf9140 ("eal: define generic vector types")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dekel Peled
Applied, thanks
[dpdk-dev] [PATCH v3 2/2] app/testpmd: fix Tx QinQ set
Enable DEV_TX_OFFLOAD_VLAN_INSERT also along with
DEV_TX_OFFLOAD_VLAN_QINQ in tx_qinq_set() as it takes
both vlan id's as arguments.
Fixes: 597f9fafe13b ("app/testpmd: convert to new Tx offloads API")
Cc: shah...@mellanox.com
Signed-off-by: Nithin Dabilpuram
---
v3:
* Rename headline
v2:
* Split change into two seperate patches as suggested.
app/test-pmd/config.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 010e26d..f9cb129 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3006,7 +3006,8 @@ tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t
vlan_id_outer)
}
tx_vlan_reset(port_id);
- ports[port_id].dev_conf.txmode.offloads |= DEV_TX_OFFLOAD_QINQ_INSERT;
+ ports[port_id].dev_conf.txmode.offloads |= (DEV_TX_OFFLOAD_VLAN_INSERT |
+ DEV_TX_OFFLOAD_QINQ_INSERT);
ports[port_id].tx_vlan_id = vlan_id;
ports[port_id].tx_vlan_id_outer = vlan_id_outer;
}
--
2.8.4
Re: [dpdk-dev] [PATCH] virtio: fix buffer leak on vlan insert
On Thu, Apr 04, 2019 at 05:03:43PM -0700, Stephen Hemminger wrote:
The function rte_vlan_insert may allocate a new buffer for the
vlan header and return a different mbuf than originally passed.
In this case, the stored mbuf in txm[] array could point to wrong
buffer.
Fixes: dd856dfcb9e7 ("virtio: use any layout on Tx")
Signed-off-by: Stephen Hemminger
---
drivers/net/virtio/virtio_rxtx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index e6f3706d6fe1..2ae4232c181d 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -2003,6 +2003,8 @@ virtio_xmit_pkts_packed(void *tx_queue, struct rte_mbuf
**tx_pkts,
rte_pktmbuf_free(txm);
continue;
}
+ /* vlan_insert may add a header mbuf */
+ tx_pkts[nb_tx] = txm;
}
/* optimize ring usage */
Good catch. I think we have the same bug in virtio_xmit_pkts() and
virtio_xmit_pkts_inorder() and should fix these as well.
Thanks!
regards,
Jens
Re: [dpdk-dev] [PATCH] net/ixgbevf: remove MTU setting limitation
> -Original Message- > From: Zhao1, Wei > Sent: Wednesday, April 3, 2019 10:26 AM > To: David Harton ; dev@dpdk.org > Cc: Lu, Wenzhuo ; Ananyev, Konstantin > ; Zhang, Qi Z > Subject: RE: [dpdk-dev] [PATCH] net/ixgbevf: remove MTU setting limitation > > HI, > > Why not add some more code > " > if (rx_conf->offloads & DEV_RX_OFFLOAD_SCATTER) > dev->data->scattered_rx = 1; > " > > Into ixgbevf_dev_rx_init() to enable scatter mode when start device? > > > Reviewed-by: Wei Zhao > > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Harton > > Sent: Wednesday, April 3, 2019 9:19 AM > > To: dev@dpdk.org > > Cc: Lu, Wenzhuo ; Ananyev, Konstantin > > ; David Harton > > Subject: [dpdk-dev] [PATCH] net/ixgbevf: remove MTU setting limitation > > > > Currently, if requested MTU is bigger than mbuf size and scattered > > receive is not enabled, setting MTU to that value fails. > > > > This patch allows setting this special MTU when device is stopped, > > because scattered_rx will be re-configured during next port start and > > driver may enable scattered receive according new MTU value. > > > > After this patch, driver may select different receive function > > automatically after MTU set, according MTU values selected. > > > > Signed-off-by: David Harton Applied to dpdk-next-net-intel. Thanks Qi
Re: [dpdk-dev] [PATCH] doc: fix links to doxygen and sphinx sites
03/04/2019 13:04, Dekel Peled:
> Update broken links, replace with valid links.
>
> Fixes: 7798f17a0d62 ("doc: add documentation guidelines")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Dekel Peled
Applied, thanks
Re: [dpdk-dev] [PATCH ] doc: fix two typos in contributing guide
15/03/2019 11:39, Kovacevic, Marko:
> > This patch fixes two typos in the coding style part of DPDK contributing
> > guide:
> >
> > - The header entry should have .h file instead of .c file.
> > - The will->This will
> >
> > Fixes: 44a6dface13b ("doc: describe how to add new components")
+Cc: sta...@dpdk.org
> > Signed-off-by: Rami Rosen
>
> Acked-by: Marko Kovacevic
Applied, thanks
Re: [dpdk-dev] [PATCH] net/ice: stop lldp by default
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qiming Yang
> Sent: Wednesday, April 3, 2019 11:59 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming ; sta...@dpdk.org
> Subject: [dpdk-dev] [PATCH] net/ice: stop lldp by default
>
> This patch stopped lldp by default to avoid the statistics error.
>
> Fixes: f9cf4f864150 ("net/ice: support device initialization")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qiming Yang
> ---
> drivers/net/ice/ice_ethdev.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/ice/ice_ethdev.c b/drivers/net/ice/ice_ethdev.c index
> 1482ced..b3df282 100644
> --- a/drivers/net/ice/ice_ethdev.c
> +++ b/drivers/net/ice/ice_ethdev.c
> @@ -11,6 +11,7 @@
>
> #include "base/ice_sched.h"
> #include "base/ice_flow.h"
> +#include "base/ice_dcb.h"
> #include "ice_ethdev.h"
> #include "ice_rxtx.h"
>
> @@ -1406,6 +1407,10 @@ ice_dev_init(struct rte_eth_dev *dev)
> /* Disable double vlan by default */
> ice_vsi_config_double_vlan(vsi, FALSE);
>
> + ret = ice_aq_stop_lldp(hw, TRUE, NULL);
> + if (ret != ICE_SUCCESS)
> + PMD_INIT_LOG(DEBUG, "Failed to stop lldp");
I think we need to warning user here if LLDP can't be stopped.
> +
> /* register callback func to eal lib */
> rte_intr_callback_register(intr_handle,
> ice_interrupt_handler, dev);
> --
> 2.9.5
Re: [dpdk-dev] [EXT] Re: [PATCH] ethdev: fix DMA zone reserve not honoring size
On 4/5/19 1:23 AM, Thomas Monjalon wrote:
Hi,
02/04/2019 10:44, Andrew Rybchenko:
On 4/2/19 11:25 AM, Jerin Jacob Kollanukkaran wrote:
On Tue, 2019-04-02 at 10:36 +0300, Andrew Rybchenko wrote:
On 4/2/19 3:47 AM, Jerin Jacob Kollanukkaran wrote:
On Mon, 2019-04-01 at 10:30 +0300, Andrew Rybchenko wrote:
On 3/31/19 7:25 PM, Pavan Nikhilesh Bhagavatula wrote:
From: Pavan Nikhilesh
The `rte_eth_dma_zone_reserve()` is generally used to create HW
rings.
In some scenarios when a driver needs to reconfigure the ring
size
since the named memzone already exists it returns the previous
memzone
without checking if a different sized ring is requested.
Introduce a check to see if the ring size requested is
different from the previously created memzone length.
Fixes: 719dbebceb81 ("xen: allow determining DOM0 at runtime")
Cc: sta...@dpdk.org
Signed-off-by: Pavan Nikhilesh
[...]
@@ -3604,9 +3604,12 @@ rte_eth_dma_zone_reserve(const struct
mz = rte_memzone_lookup(z_name);
- if (mz)
+ if (mz && (mz->len == size))
return mz;
+ if (mz)
+ rte_memzone_free(mz);
NACK
I really don't like that API which should reserve does free if
requested
size does not match previously allocated.
Why? Is due to API name?
1. The problem really exists. The problem is bad and it very good
that you
caught it and came up with a patch. Many thanks.
I don't agree that the problem exists.
You are just trying to use a function for a goal which is
documented as not supported.
The documentation says nothing about size, alignment and different socket.
It is good that the behaviour is documented, but I can't say that it is
friendly.
Friendly behaviour would guarantee size, alignment and socket_id properties
preserved. Otherwise, it is too error-prone.
2. Silently free and reallocate memory is bad. Memory could be
used/mapped etc.
If I understand it correctly, Its been used while configuring
the device and it is per queue, If so, Is there any case where
memory in use in parallel in real world case with DPDK?
"in real world case with DPDK" is very fragile justification.
I simply don't want to dig in this way since it is very easy to make
a mistake or simply false assumption.
I agree.
A function, with "reserve" in the name, should not do any "free".
3. As an absolute minimum if we accept the behaviour it must be
documented
in the function description.
If so,
Can we have rte_eth_dma_zone_reservere_with_resize() then ?
or any another name, You would like to have?
4. I'd prefer an error if different size (or bigger) memzone is
requested,
but I understand that it can break existing drivers.
Yes some drivers may rely on the current behaviour.
But if you carefully check every drivers, you can change
this behaviour and return an error.
Thomas, Ferruh, what do you think?
I understand the motivation, but I don't think the solution is
correct.
What you think it has correct solution then?
See above plus handling in drivers or dedicated function with
better name as you suggest above.
Handling in driver means return error?
Yes.
Regarding API, Yes, We can add new API. What we will do that exiting
driver. Is up to driver maintainers to use the new API. I am fine with
either approach, Just asking the opinion.
You have mine, but I'd like to know what other ethdev maintainers
think about it.
In such case, I refer to the existing documentation.
For rte_eth_dma_zone_reserve, it says:
"
If the memzone is already created, then this function returns a ptr
to the old one.
"
Now I'm more confident that an error should be returned if memzone
already exists but its properties do not match requested.
Obviously, We can not allocate max ring size in init time.
If the NIC has support for 64K HW ring, We will be wasting too much
as it is per queue.
Yes, I agree that it is an overkill.
net/sfc tries to carefully free/reserve on NIC/queues reconfigure.
Yes, using rte_memzone_free looks saner.
Is there an API missing?
A function to check the size of the memzone? Is rte_memzone.len enough?
Re: [dpdk-dev] [PATCH] ethdev: claim device reset as async
On 4/5/19 1:01 AM, Thomas Monjalon wrote: Hi, You forgot to Cc Andrew, co-maintainer of ethdev. 20/03/2019 05:54, Qi Zhang: Device reset should be implemented in an async way since it is possible to be invoked in interrupt thread and sometimes to reset a device need to wait for some dependency, for example, a VF expects for PF ready or a NIC function as part of a SOC wait for the whole system reset complete, and all these time-consuming tasks will block the interrupt thread. The patch rename rte_eth_dev_reset to rte_eth_dev_reset_async and rework the implementation. It will spawn a new thread which will call ops->dev_reset, and when finished it will raise the event RTE_ETH_EVENT_RESET_COMPLETE. The application should always wait for this event before it continues to configure and restart the device. Signed-off-by: Qi Zhang --- - * When this function is called, it first stops the port and then calls the - * PMD specific dev_uninit( ) and dev_init( ) to return the port to initial - * state, in which no Tx and Rx queues are setup, as if the port has been - * reset and not started. The port keeps the port id it had before the - * function call. - * - * After calling rte_eth_dev_reset( ), the application should use - * rte_eth_dev_configure( ), rte_eth_rx_queue_setup( ), - * rte_eth_tx_queue_setup( ), and rte_eth_dev_start( ) - * to reconfigure the device as appropriate. - * - * Note: To avoid unexpected behavior, the application should stop calling - * Tx and Rx functions before calling rte_eth_dev_reset( ). For thread - * safety, all these controlling functions should be called from the same - * thread. + * @note + * Device reset may have the dependency, for example, a VF reset expects + * PF ready, or a NIC function as a part of a SOC need to wait for other + * parts of the system be ready, these are time-consuming tasks and will + * block current thread. + * + * As the name, rte_eth_dev_reset_async is an async API, it will spwan a + * new thread to call ops->dev_reset, once it is finished, it will raise + * the RTE_ETH_EVENT_RESET_COMPLETE event to notify application. That makes + * things easy for an application that want to reset the device from the + * interrupt thread since typically a RTE_ETH_EVENT_INTR_RESET handler is + * invoked in interrupt thread. The typical implementation of ops->dev_reset + * will do some hardware reset operations through calling dev_uninit() and + * dev_init(). + * + * Application should not assume device reset is finished after + * rte_eth_dev_reset_async return, it should always wait for a + * RTE_ETH_EVENT_RESET_COMPLETE event and check the reset result. + * If reset success, application should call rte_eth_dev_configure( ), + * rte_eth_rx_queue_setup( ), rte_eth_tx_queue_setup( ), + * and rte_eth_dev_start( ) to reconfigure the device as appropriate. + * + * @Note + * To avoid unexpected behavior, the application should stop calling + * Tx and Rx functions before calling rte_eth_dev_reset_async( ). * * @param port_id * The port identifier of the Ethernet device. @@ -1880,12 +1892,10 @@ void rte_eth_dev_close(uint16_t port_id); * - (0) if successful. * - (-EINVAL) if port identifier is invalid. * - (-ENOTSUP) if hardware doesn't support this function. - * - (-EPERM) if not ran from the primary process. - * - (-EIO) if re-initialisation failed or device is removed. * - (-ENOMEM) if the reset failed due to OOM. - * - (-EAGAIN) if the reset temporarily failed and should be retried later. + * - (<0) other errors from low level driver. */ -int rte_eth_dev_reset(uint16_t port_id); +int rte_eth_dev_reset_async(uint16_t port_id); Sorry I didn't check whether this API is better or not, but I know it cannot be accepted before proposing a deprecation notice. Perhaps you may keep the old API and just add the new one. Honestly, I never really agreed with the purpose of the reset API. So making it async or not, I have no real opinion... ... but spawning a new thread at each function call, I feel it is bad. I agree with Thomas. It looks very dangerous from locking point of view when a PMD callback is executed from dynamically created thread.
Re: [dpdk-dev] [PATCH] devargs: remove experimental from APIs
On Thu, Apr 04, 2019 at 10:10:15AM -0700, Stephen Hemminger wrote: > On Thu, 4 Apr 2019 11:45:45 + > Hemant Agrawal wrote: > > > These APIs are available in DPDK for last 4 releases > > and used by multiple drivers. > > > > Cc: gaetan.ri...@6wind.com > > > > Signed-off-by: Hemant Agrawal > > > > Acked-by: Stephen Hemminger Acked-by: Gaetan Rivet -- Gaëtan Rivet 6WIND
[dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
Currently, when symbols get promoted from the EXPERIMENTAL section to a
stable ABI section, the script complains they should go to the
EXPERIMENTAL section.
Example:
ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
expected to be added in the EXPERIMENTAL section of the version map
This is legit.
Moving from a stable ABI to another is also allowed, but must have gone
through the proper process.
Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
Cc: sta...@dpdk.org
Signed-off-by: David Marchand
---
devtools/check-symbol-change.sh | 44 +
1 file changed, 27 insertions(+), 17 deletions(-)
diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
index 020da7e..40eb953 100755
--- a/devtools/check-symbol-change.sh
+++ b/devtools/check-symbol-change.sh
@@ -105,27 +105,37 @@ check_for_rule_violations()
continue
fi
- if [ "$secname" != "EXPERIMENTAL" ]
+ oldsecname=$(sed -n \
+ "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
+
+ # A symbol can not enter a non experimental
+ # section directly
+ if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
then
- # Symbols that are getting added in a section
- # other than the experimental section
- # to be moving from an already supported
- # section or its a violation
- grep -q \
- "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
- if [ $? -ne 0 ]
- then
- echo -n "ERROR: symbol $symname "
- echo -n "is added in the $secname "
- echo -n "section, but is expected to "
- echo -n "be added in the EXPERIMENTAL "
- echo "section of the version map"
- ret=1
- fi
+ echo -n "ERROR: symbol $symname "
+ echo -n "is added in the $secname "
+ echo -n "section, but is expected to "
+ echo -n "be added in the EXPERIMENTAL "
+ echo "section of the version map"
+ ret=1
+ continue
+ fi
+
+ # This symbol is moving between two sections (the
+ # original section is not experimental).
+ # This can be legit, just warn.
+ if [ "$oldsecname" != 'EXPERIMENTAL' ]
+ then
+ echo -n "INFO: symbol $symname is being "
+ echo -n "moved from $oldsecname to $secname. "
+ echo -n "Ensure that it has gone through the "
+ echo "deprecation process"
+ continue
fi
else
- if [ "$secname" != "EXPERIMENTAL" ]
+ if ! grep -q "$mname $symname .* add" "$mapdb" && \
+ [ "$secname" != "EXPERIMENTAL" ]
then
# Just inform users that non-experimenal
# symbols need to go through a deprecation
--
1.8.3.1
Re: [dpdk-dev] [PATCH] doc: fix a typo in procinfo guide
25/03/2019 11:20, Kovacevic, Marko:
> > Subject: [PATCH] doc: fix a typo in procinfo guide
> >
> > This patch fixes a trivial info in proc info section.
> > informationi=>information.
> >
> > Fixes: 8a37f37fc243 ("app/procinfo: add --show-port")
> >
> > Signed-off-by: Rami Rosen
>
> Acked-by: Marko Kovacevic
Marked as superseded because of the big patch made with aspell.
Thanks
Re: [dpdk-dev] [PATCH] doc: fix abi check script examples
19/03/2019 18:19, Neil Horman:
> On Tue, Mar 19, 2019 at 03:05:18PM +0100, David Marchand wrote:
> > The doc examples are not aligned on the script following the
> > incriminated commit.
> >
> > Fixes: c4a5fe3bf832 ("devtools: rework ABI checker script")
> > Cc: sta...@dpdk.org
> >
> > Cc: Olivier Matz
> > Cc: Neil Horman
> > Signed-off-by: David Marchand
> > ---
> Acked-by: Neil Horman
Applied, thanks
[dpdk-dev] [Bug 239] ipsec-secgw fails to initialize when librte_ipsec is enabled
https://bugs.dpdk.org/show_bug.cgi?id=239 Bug ID: 239 Summary: ipsec-secgw fails to initialize when librte_ipsec is enabled Product: DPDK Version: unspecified Hardware: ARM OS: Linux Status: CONFIRMED Severity: normal Priority: Normal Component: examples Assignee: dev@dpdk.org Reporter: lbarto...@marvell.com Target Milestone: --- Created attachment 33 --> https://bugs.dpdk.org/attachment.cgi?id=33&action=edit ipsec_secgw_failure_log.txt repo http://dpdk.org/git/next/dpdk-next-crypto branch master commit 3331ddc doc: update ipsec lib for supported algos Ipsec-secgw example fails to initialize when librte_ipsec is enabled and when default configuration of ep0.cfg is used. It complains that two SP rules use the same SPI ./ipsec-secgw --log-level=8 -c 0xff -- -P -p 0x3 -u 0x1 --config "(1,0,0),(0,0,0)" -f ../ep0.cfg -l IPSEC: get_spi_proto: SPI 110 used simultaeously by IPv4(2) and IPv6 (2) SP rules EAL: Error - exiting with code: 1 Cause: failed to init inbound SAs Ipsec-secgw initializes successfully when used without librte_ipsec. Full log is attached. -- You are receiving this mail because: You are the assignee for the bug.
Re: [dpdk-dev] [PATCH v7 2/2] doc: add guide for debug and troubleshoot
01/04/2019 16:56, Mcnamara, John: > From: Varghese, Vipin > > doc/guides/howto/debug_troubleshoot_guide.rst | 465 ++ > > doc/guides/howto/index.rst| 1 + > > +.. note:: > > + > > + It is difficult to cover all possible issues; in a single attempt. > > + With ``feedback and suggestions from the community, more cases can be > > covered``. > > Do you really mean to `` quote (i.e., fixed width quote) the line above? I think the quote signs should be removed. But it would be nice to have such quote for all the code symbols used in this doc.
[dpdk-dev] [PATCH v2 1/1] net/mlx5: fix typos in comments
Fixes: 299d7dc28c37 ("net/mlx5: add representor recognition on Linux 5.x")
Signed-off-by: Viacheslav Ovsiienko
v2:
rebasing only
v1:
http://patches.dpdk.org/patch/52056/
---
drivers/net/mlx5/mlx5.c | 14 +++---
drivers/net/mlx5/mlx5_flow_tcf.c | 22 +++---
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index f571ba2..09f4a21 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -155,7 +155,7 @@ struct mlx5_dev_spawn_data {
* port dedicated IB device, the context will be used by only given
* port due to unification.
*
- * Routine first searches the context for the spesified IB device name,
+ * Routine first searches the context for the specified IB device name,
* if found the shared context assumed and reference counter is incremented.
* If no context found the new one is created and initialized with specified
* IB device context and parameters.
@@ -185,7 +185,7 @@ struct mlx5_dev_spawn_data {
goto exit;
}
}
- /* No device found, we have to create new sharted context. */
+ /* No device found, we have to create new shared context. */
assert(spawn->max_port);
sh = rte_zmalloc("ethdev shared ib context",
sizeof(struct mlx5_ibv_shared) +
@@ -305,7 +305,7 @@ struct mlx5_dev_spawn_data {
/**
* Initialize DR related data within private structure.
* Routine checks the reference counter and does actual
- * resources creation/iniialization only if counter is zero.
+ * resources creation/initialization only if counter is zero.
*
* @param[in] priv
* Pointer to the private device data structure.
@@ -1353,7 +1353,7 @@ struct mlx5_dev_spawn_data {
* Currently we support single E-Switch per PF configurations
* only and vport_id field contains the vport index for
* associated VF, which is deduced from representor port name.
-* For exapmple, let's have the IB device port 10, it has
+* For example, let's have the IB device port 10, it has
* attached network device eth0, which has port name attribute
* pf0vf2, we can deduce the VF number as 2, and set vport index
* as 3 (2+1). This assigning schema should be changed if the
@@ -1595,7 +1595,7 @@ struct mlx5_dev_spawn_data {
mlx5_set_link_up(eth_dev);
/*
* Even though the interrupt handler is not installed yet,
-* interrupts will still trigger on the asyn_fd from
+* interrupts will still trigger on the async_fd from
* Verbs context returned by ibv_open_device().
*/
mlx5_link_update(eth_dev, 0);
@@ -1772,7 +1772,7 @@ struct mlx5_dev_spawn_data {
}
ibv_match[nd] = NULL;
if (!nd) {
- /* No device macthes, just complain and bail out. */
+ /* No device matches, just complain and bail out. */
mlx5_glue->free_device_list(ibv_list);
DRV_LOG(WARNING,
"no Verbs device matches PCI device " PCI_PRI_FMT ","
@@ -1805,7 +1805,7 @@ struct mlx5_dev_spawn_data {
if (np > 1) {
/*
-* Signle IB device with multiple ports found,
+* Single IB device with multiple ports found,
* it may be E-Switch master device and representors.
* We have to perform identification trough the ports.
*/
diff --git a/drivers/net/mlx5/mlx5_flow_tcf.c b/drivers/net/mlx5/mlx5_flow_tcf.c
index 3006f83..fc04c9d 100644
--- a/drivers/net/mlx5/mlx5_flow_tcf.c
+++ b/drivers/net/mlx5/mlx5_flow_tcf.c
@@ -2916,7 +2916,7 @@ struct pedit_parser {
* VXLAN VNI in 24-bit wire format.
*
* @return
- * VXLAN VNI as a 32-bit integer value in network endian.
+ * VXLAN VNI as a 32-bit integer value in network endianness.
*/
static inline rte_be32_t
vxlan_vni_as_be32(const uint8_t vni[3])
@@ -4051,7 +4051,7 @@ struct pedit_parser {
nlh->nlmsg_flags |= NLM_F_ACK;
ret = mnl_socket_sendto(tcf->nl, nlh, nlh->nlmsg_len);
if (ret <= 0) {
- /* Message send error occurres. */
+ /* Message send error occurred. */
rte_errno = errno;
return -rte_errno;
}
@@ -4307,7 +4307,7 @@ struct tcf_nlcb_context {
* @param[in] tcf
* Context object initialized by mlx5_flow_tcf_context_create().
* @param[in] ifindex
- * Network inferface index to perform cleanup.
+ * Network interface index to perform cleanup.
*/
static void
flow_tcf_encap_local_cleanup(struct mlx5_flow_tcf_context *tcf,
@@ -4343,7 +4343,7 @@ struct tcf_nlcb_context {
}
/**
- * Collect neigh permament rules on specified network device.
+ * Collect neigh permanent rules on specified network device.
* This is callback routine called by libmnl mnl_cb_run() in loop for
* every messag
[dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
From: Qiming Yang
This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
problem when running with new version of the ethdev shared
library.
Signed-off-by: Qiming Yang
---
lib/librte_ethdev/rte_eth_ctrl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_ethdev/rte_eth_ctrl.h b/lib/librte_ethdev/rte_eth_ctrl.h
index 5ea8ae24c..b3416341b 100644
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_NVGRE,
RTE_TUNNEL_TYPE_IP_IN_GRE,
RTE_L2_TUNNEL_TYPE_E_TAG,
+ RTE_TUNNEL_TYPE_VXLAN_GPE,
RTE_TUNNEL_TYPE_MAX,
};
--
2.13.6
[dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
--- v5: 1. add ABI break notification in commit log of PATCH 1/5 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's comments) V4: 1. rebased to the latest code. 2. deleted misleading statement. V3: 1. fixed issue in release note. 2. fixed check patch issue. 3. spilted eal related change to a new patch. V2: 1. move testpmd related changes to a new patch. 2. added release note update. Qiming Yang (5): ethdev: add VXLAN-GPE macro net/i40e: add support for VXLAN-GPE net/i40e: support VXLAN-GPE classification app/testpmd: add VXLAN-GPE to tunnel type doc: add release note for VXLAN-GPE support app/test-pmd/cmdline.c | 19 --- doc/guides/rel_notes/release_19_05.rst | 7 +++ doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 +++ drivers/net/i40e/i40e_ethdev.c | 16 lib/librte_ethdev/rte_eth_ctrl.h| 1 + 5 files changed, 39 insertions(+), 15 deletions(-) -- 2.13.6
[dpdk-dev] [PATCH v5 3/5] net/i40e: support VXLAN-GPE classification
From: Qiming Yang Added VXLAN-GPE tunnel filter, supported filter to queue. Signed-off-by: Qiming Yang Acked-by: Qi Zhang --- drivers/net/i40e/i40e_ethdev.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c index f382013c4..5b01dc1f0 100644 --- a/drivers/net/i40e/i40e_ethdev.c +++ b/drivers/net/i40e/i40e_ethdev.c @@ -7722,6 +7722,9 @@ i40e_dev_tunnel_filter_set(struct i40e_pf *pf, case RTE_TUNNEL_TYPE_IP_IN_GRE: tun_type = I40E_AQC_ADD_CLOUD_TNL_TYPE_IP; break; + case RTE_TUNNEL_TYPE_VXLAN_GPE: + tun_type = I40E_AQC_ADD_CLOUD_TNL_TYPE_VXLAN_GPE; + break; default: /* Other tunnel types is not supported. */ PMD_DRV_LOG(ERR, "tunnel type is not supported."); -- 2.13.6
[dpdk-dev] [PATCH v5 2/5] net/i40e: add support for VXLAN-GPE
From: Qiming Yang
Add new protocol type VXLAN-GPE support for UDP tunnel.
inner IP/TCP/UDP checksum and RSS configuration shared
the same implementation of VXLAN.
Signed-off-by: Qiming Yang
Acke-by: Qi Zhang
---
drivers/net/i40e/i40e_ethdev.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index b031bf4c6..f382013c4 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -8370,7 +8370,7 @@ i40e_get_vxlan_port_idx(struct i40e_pf *pf, uint16_t port)
}
static int
-i40e_add_vxlan_port(struct i40e_pf *pf, uint16_t port)
+i40e_add_vxlan_port(struct i40e_pf *pf, uint16_t port, int udp_type)
{
int idx, ret;
uint8_t filter_idx;
@@ -8393,7 +8393,7 @@ i40e_add_vxlan_port(struct i40e_pf *pf, uint16_t port)
return -ENOSPC;
}
- ret = i40e_aq_add_udp_tunnel(hw, port, I40E_AQC_TUNNEL_TYPE_VXLAN,
+ ret = i40e_aq_add_udp_tunnel(hw, port, udp_type,
&filter_idx, NULL);
if (ret < 0) {
PMD_DRV_LOG(ERR, "Failed to add VXLAN UDP port %d", port);
@@ -8461,9 +8461,13 @@ i40e_dev_udp_tunnel_port_add(struct rte_eth_dev *dev,
switch (udp_tunnel->prot_type) {
case RTE_TUNNEL_TYPE_VXLAN:
- ret = i40e_add_vxlan_port(pf, udp_tunnel->udp_port);
+ ret = i40e_add_vxlan_port(pf, udp_tunnel->udp_port,
+ I40E_AQC_TUNNEL_TYPE_VXLAN);
+ break;
+ case RTE_TUNNEL_TYPE_VXLAN_GPE:
+ ret = i40e_add_vxlan_port(pf, udp_tunnel->udp_port,
+ I40E_AQC_TUNNEL_TYPE_VXLAN_GPE);
break;
-
case RTE_TUNNEL_TYPE_GENEVE:
case RTE_TUNNEL_TYPE_TEREDO:
PMD_DRV_LOG(ERR, "Tunnel type is not supported now.");
@@ -8492,6 +8496,7 @@ i40e_dev_udp_tunnel_port_del(struct rte_eth_dev *dev,
switch (udp_tunnel->prot_type) {
case RTE_TUNNEL_TYPE_VXLAN:
+ case RTE_TUNNEL_TYPE_VXLAN_GPE:
ret = i40e_del_vxlan_port(pf, udp_tunnel->udp_port);
break;
case RTE_TUNNEL_TYPE_GENEVE:
--
2.13.6
[dpdk-dev] [PATCH v5 5/5] doc: add release note for VXLAN-GPE support
From: Qiming Yang Updated release note. Signed-off-by: Qiming Yang --- doc/guides/rel_notes/release_19_05.rst | 7 +++ 1 file changed, 7 insertions(+) diff --git a/doc/guides/rel_notes/release_19_05.rst b/doc/guides/rel_notes/release_19_05.rst index 2acb42e45..62f4741e9 100644 --- a/doc/guides/rel_notes/release_19_05.rst +++ b/doc/guides/rel_notes/release_19_05.rst @@ -148,6 +148,13 @@ New Features Improved testpmd application performance on ARM platform. For ``macswap`` forwarding mode, NEON intrinsics were used to do swap to save CPU cycles. +* **Updated the i40e driver.** + + New features for PF: + + * Added support for VXLAN-GPE packet. + * Added support for VXLAN-GPE classification. + Removed Items - -- 2.13.6
[dpdk-dev] [PATCH v5 4/5] app/testpmd: add VXLAN-GPE to tunnel type
From: Qiming Yang
This patch added new item "vxlan-gpe" to tunnel_type to
support new VXLAN-GPE packet type, and its clasification.
Signed-off-by: Qiming Yang
---
app/test-pmd/cmdline.c | 19 ---
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 11 +++
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index ee50e4566..2ab03c111 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -376,12 +376,12 @@ static void cmd_help_long_parsed(void *parsed_result,
"filtered for VF(s) from port_id.\n\n"
"tunnel_filter add (port_id) (outer_mac) (inner_mac)
(ip_addr) "
- "(inner_vlan) (vxlan|nvgre|ipingre)
(imac-ivlan|imac-ivlan-tenid|"
+ "(inner_vlan) (vxlan|nvgre|ipingre|vxlan-gpe)
(imac-ivlan|imac-ivlan-tenid|"
"imac-tenid|imac|omac-imac-tenid|oip|iip) (tenant_id)
(queue_id)\n"
" add a tunnel filter of a port.\n\n"
"tunnel_filter rm (port_id) (outer_mac) (inner_mac)
(ip_addr) "
- "(inner_vlan) (vxlan|nvgre|ipingre)
(imac-ivlan|imac-ivlan-tenid|"
+ "(inner_vlan) (vxlan|nvgre|ipingre|vxlan-gpe)
(imac-ivlan|imac-ivlan-tenid|"
"imac-tenid|imac|omac-imac-tenid|oip|iip) (tenant_id)
(queue_id)\n"
" remove a tunnel filter of a port.\n\n"
@@ -863,7 +863,7 @@ static void cmd_help_long_parsed(void *parsed_result,
" for ports.\n\n"
"port config all rss (all|default|ip|tcp|udp|sctp|"
- "ether|port|vxlan|geneve|nvgre|none|)\n"
+
"ether|port|vxlan|geneve|nvgre|vxlan-gpe|none|)\n"
"Set the RSS mode.\n\n"
"port config port-id rss reta
(hash,queue)[,(hash,queue)]\n"
@@ -2190,7 +2190,7 @@ cmdline_parse_inst_t cmd_config_rss = {
.f = cmd_config_rss_parsed,
.data = NULL,
.help_str = "port config all rss "
-
"all|default|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|none|",
+
"all|default|ip|tcp|udp|sctp|ether|port|vxlan|geneve|nvgre|vxlan-gpe|none|",
.tokens = {
(void *)&cmd_config_rss_port,
(void *)&cmd_config_rss_keyword,
@@ -8758,6 +8758,8 @@ cmd_tunnel_filter_parsed(void *parsed_result,
if (!strcmp(res->tunnel_type, "vxlan"))
tunnel_filter_conf.tunnel_type = RTE_TUNNEL_TYPE_VXLAN;
+ else if (!strcmp(res->tunnel_type, "vxlan-gpe"))
+ tunnel_filter_conf.tunnel_type = RTE_TUNNEL_TYPE_VXLAN_GPE;
else if (!strcmp(res->tunnel_type, "nvgre"))
tunnel_filter_conf.tunnel_type = RTE_TUNNEL_TYPE_NVGRE;
else if (!strcmp(res->tunnel_type, "ipingre"))
@@ -8807,7 +8809,7 @@ cmdline_parse_token_ipaddr_t cmd_tunnel_filter_ip_value =
ip_value);
cmdline_parse_token_string_t cmd_tunnel_filter_tunnel_type =
TOKEN_STRING_INITIALIZER(struct cmd_tunnel_filter_result,
- tunnel_type, "vxlan#nvgre#ipingre");
+ tunnel_type, "vxlan#nvgre#ipingre#vxlan-gpe");
cmdline_parse_token_string_t cmd_tunnel_filter_filter_type =
TOKEN_STRING_INITIALIZER(struct cmd_tunnel_filter_result,
@@ -8931,6 +8933,8 @@ cmd_cfg_tunnel_udp_port_parsed(void *parsed_result,
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN;
} else if (!strcmp(res->tunnel_type, "geneve")) {
tunnel_udp.prot_type = RTE_TUNNEL_TYPE_GENEVE;
+ } else if (!strcmp(res->tunnel_type, "vxlan-gpe")) {
+ tunnel_udp.prot_type = RTE_TUNNEL_TYPE_VXLAN_GPE;
} else {
printf("Invalid tunnel type\n");
return;
@@ -8965,7 +8969,7 @@ cmdline_parse_token_string_t
cmd_config_tunnel_udp_port_action =
"add#rm");
cmdline_parse_token_string_t cmd_config_tunnel_udp_port_tunnel_type =
TOKEN_STRING_INITIALIZER(struct cmd_config_tunnel_udp_port, tunnel_type,
-"vxlan#geneve");
+"vxlan#geneve#vxlan-gpe");
cmdline_parse_token_num_t cmd_config_tunnel_udp_port_value =
TOKEN_NUM_INITIALIZER(struct cmd_config_tunnel_udp_port, udp_port,
UINT16);
@@ -8973,7 +8977,7 @@ cmdline_parse_token_num_t
cmd_config_tunnel_udp_port_value =
cmdline_parse_inst_t cmd_cfg_tunnel_udp_port = {
.f = cmd_cfg_tunnel_udp_port_parsed,
.data = NULL,
- .help_str = "port config udp_tunnel_port add|rm vxlan|geneve
",
+ .help_str = "port config udp_tunnel_port add|rm
vxlan|geneve|vxlan-gpe ",
.tokens = {
(void *)&cmd_config_tunnel_udp_port_port,
(void *)&cmd_config_tunnel_udp_port_config,
@@ -11987,6 +11991,7 @@ flowtype_
Re: [dpdk-dev] [EXT] Re: [PATCH v2] kni: add IOVA va support for kni
> -Original Message-
> From: Ferruh Yigit
> Sent: Wednesday, April 3, 2019 9:59 PM
> To: Kiran Kumar Kokkilagadda
> Cc: dev@dpdk.org; Jerin Jacob
> Subject: [EXT] Re: [dpdk-dev] [PATCH v2] kni: add IOVA va support for kni
>
> External Email
>
> --
> On 4/1/2019 10:51 AM, Kiran Kumar Kokkilagadda wrote:
> > From: Kiran Kumar K
> >
> > With current KNI implementation kernel module will work only in
> > IOVA=PA mode. This patch will add support for kernel module to work
> > with IOVA=VA mode.
>
> Thanks Kiran for removing the limitation, I have a few questions, can you
> please
> help me understand.
>
> And when this patch is ready, the restriction in 'linux/eal/eal.c', in
> 'rte_eal_init'
> should be removed, perhaps with this patch. I assume you already doing it to
> be
> able to test this patch.
>
User can choose the mode by passing --iova-mode=. I will remove the
rte_kni module restriction.
> >
> > The idea is to maintain a mapping in KNI module between user pages and
> > kernel pages and in fast path perform a lookup in this table and get
> > the kernel virtual address for corresponding user virtual address.
> >
> > In IOVA=VA mode, the memory allocated to the pool is physically and
> > virtually contiguous. We will take advantage of this and create a
> > mapping in the kernel.In kernel we need mapping for queues (tx_q,
> > rx_q,... slow path) and mbuf memory (fast path).
>
> Is it?
> As far as I know mempool can have multiple chunks and they can be both
> virtually and physically separated.
>
> And even for a single chunk, that will be virtually continuous, but will it be
> physically continuous?
>
You are right, it need not have to be physically contiguous. Will change the
description.
> >
> > At the KNI init time, in slow path we will create a mapping for the
> > queues and mbuf using get_user_pages similar to af_xdp. Using pool
> > memory base address, we will create a page map table for the mbuf,
> > which we will use in the fast path for kernel page translation.
> >
> > At KNI init time, we will pass the base address of the pool and size
> > of the pool to kernel. In kernel, using get_user_pages API, we will
> > get the pages with size PAGE_SIZE and store the mapping and start
> > address of user space in a table.
> >
> > In fast path for any user address perform PAGE_SHIFT (user_addr >>
> > PAGE_SHIFT) and subtract the start address from this value, we will
> > get the index of the kernel page with in the page map table.
> > Adding offset to this kernel page address, we will get the kernel
> > address for this user virtual address.
> >
> > For example user pool base address is X, and size is S that we passed
> > to kernel. In kernel we will create a mapping for this using get_user_pages.
> > Our page map table will look like [Y, Y+PAGE_SIZE, Y+(PAGE_SIZE*2)
> > ] and user start page will be U (we will get it from X >> PAGE_SHIFT).
> >
> > For any user address Z we will get the index of the page map table
> > using ((Z >> PAGE_SHIFT) - U). Adding offset (Z & (PAGE_SIZE - 1)) to
> > this address will give kernel virtual address.
> >
> > Signed-off-by: Kiran Kumar K
>
> <...>
>
> > +int
> > +kni_pin_pages(void *address, size_t size, struct page_info *mem) {
> > + unsigned int gup_flags = FOLL_WRITE;
> > + long npgs;
> > + int err;
> > +
> > + /* Get at least one page */
> > + if (size < PAGE_SIZE)
> > + size = PAGE_SIZE;
> > +
> > + /* Compute number of user pages based on page size */
> > + mem->npgs = (size + PAGE_SIZE - 1) / PAGE_SIZE;
> > +
> > + /* Allocate memory for the pages */
> > + mem->pgs = kcalloc(mem->npgs, sizeof(*mem->pgs),
> > + GFP_KERNEL | __GFP_NOWARN);
> > + if (!mem->pgs) {
> > + pr_err("%s: -ENOMEM\n", __func__);
> > + return -ENOMEM;
> > + }
> > +
> > + down_write(¤t->mm->mmap_sem);
> > +
> > + /* Get the user pages from the user address*/ #if
> LINUX_VERSION_CODE
> > +>= KERNEL_VERSION(4,9,0)
> > + npgs = get_user_pages((u64)address, mem->npgs,
> > + gup_flags, &mem->pgs[0], NULL);
> > +#else
> > + npgs = get_user_pages(current, current->mm, (u64)address, mem-
> >npgs,
> > + gup_flags, 0, &mem->pgs[0], NULL); #endif
> > + up_write(¤t->mm->mmap_sem);
>
> This should work even memory is physically not continuous, right? Where
> exactly physically continuous requirement is coming from?
>
Yes, it is not necessary to be physically contiguous.
> <...>
>
> > +
> > +/* Get the kernel address from the user address using
> > + * page map table. Will be used only in IOVA=VA mode */ static
> > +inline void* get_kva(uint64_t usr_addr, struct kni_dev *kni) {
> > + uint32_t index;
> > + /* User page - start user page will give the index
> > +* with in the page map table
> > +*/
> > + index = (usr_addr >> PAGE_SHIFT) - kni->va_info.
[dpdk-dev] [dpdk-announce] DPDK 18.08.1 released
Hi all, Here is a new stable release: https://fast.dpdk.org/rel/dpdk-18.08.1.tar.xz The git tree is at: https://dpdk.org/browse/dpdk-stable/?h=18.08 Information about the validation of this stable release can be found in the release note: http://doc.dpdk.org/guides-18.08/rel_notes/release_18_08.html#id1 Note, this is the only planned stable release for DPDK 18.08 and the 18.08 stable branch is no longer be maintained. Kevin Traynor --- app/pdump/main.c | 10 +- app/test-bbdev/test_bbdev_perf.c | 14 +- app/test-crypto-perf/cperf_test_vectors.c | 22 +- app/test-crypto-perf/main.c| 8 +- app/test-eventdev/test_order_atq.c | 2 +- app/test-eventdev/test_order_queue.c | 2 +- app/test-eventdev/test_perf_atq.c | 2 +- app/test-eventdev/test_perf_queue.c| 2 +- app/test-eventdev/test_pipeline_atq.c | 18 +- app/test-eventdev/test_pipeline_common.h | 8 +- app/test-eventdev/test_pipeline_queue.c| 18 +- app/test-pmd/cmdline.c | 42 +- app/test-pmd/cmdline_mtr.c | 40 +- app/test-pmd/cmdline_tm.c | 34 +- app/test-pmd/config.c | 14 +- app/test-pmd/csumonly.c| 8 +- app/test-pmd/flowgen.c | 4 +- app/test-pmd/parameters.c | 14 +- app/test-pmd/rxonly.c | 2 +- app/test-pmd/softnicfwd.c | 2 + app/test-pmd/testpmd.c | 51 +- app/test-pmd/testpmd.h | 3 +- buildtools/check-experimental-syms.sh | 6 + buildtools/symlink-drivers-solibs.sh | 2 +- config/arm/meson.build | 7 +- config/defconfig_arm64-armv8a-linuxapp-gcc | 1 + config/meson.build | 3 + config/rte_config.h| 6 +- devtools/check-symbol-change.sh| 10 +- doc/build-sdk-meson.txt| 4 +- doc/guides/contributing/coding_style.rst | 4 +- doc/guides/contributing/documentation.rst | 4 +- doc/guides/contributing/patches.rst| 14 +- doc/guides/contributing/stable.rst | 6 +- doc/guides/cryptodevs/features/qat.ini | 3 + doc/guides/cryptodevs/overview.rst | 2 +- doc/guides/cryptodevs/qat.rst | 3 +- doc/guides/eventdevs/opdl.rst | 2 +- doc/guides/freebsd_gsg/install_from_ports.rst | 2 +- doc/guides/howto/flow_bifurcation.rst | 2 +- doc/guides/howto/rte_flow.rst | 32 +- doc/guides/linux_gsg/nic_perf_intel_platform.rst | 2 +- doc/guides/linux_gsg/sys_reqs.rst | 6 +- doc/guides/nics/axgbe.rst | 2 +- doc/guides/nics/dpaa2.rst | 2 +- doc/guides/nics/ena.rst| 19 +- doc/guides/nics/enic.rst | 2 +- doc/guides/nics/features.rst | 7 +- doc/guides/nics/features/ena.ini | 1 + doc/guides/nics/features/failsafe.ini | 1 - doc/guides/nics/i40e.rst | 7 + doc/guides/nics/liquidio.rst | 8 - doc/guides/nics/mlx5.rst | 7 +- doc/guides/nics/virtio.rst | 2 +- doc/guides/prog_guide/cryptodev_lib.rst| 2 +- doc/guides/prog_guide/event_timer_adapter.rst | 4 +- doc/guides/prog_guide/switch_representation.rst| 4 +- doc/guides/rel_notes/release_18_05.rst | 10 +- doc/guides/rel_notes/release_18_08.rst | 454 +- doc/guides/sample_app_ug/compiling.rst | 15 +- doc/guides/sample_app_ug/flow_filtering.rst| 2 +- doc/guides/sample_app_ug/ip_reassembly.rst | 4 +- doc/guides/sample_app_ug/ipv4_multicast.rst| 1 - doc/guides/sample_app_ug/vhost.rst | 2 +- doc/guides/testpmd_app_ug/run_app.rst | 2 +- doc/guides/testpmd_app_ug/testpmd_funcs.rst| 13 +- doc/guides/tools/pdump.rst | 10 - doc/guides/tools/testbbdev.rst | 3 +- drivers/bus/dpaa/base/fman/fman.c | 3 +- drivers/bus/fslmc/fslmc_bus.c | 4 + drivers/bus/pci/linux/pci.c| 34 +- drivers/bus/pci/linux/pci_uio.c| 2 +- drivers/bus/pci/linux/pci_vfio.c | 12 +- drivers/bus/vdev/vdev.c| 16 +- drivers/bus/vmbus/
Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> Sent: Friday, April 5, 2019 10:06 AM
> To: Yigit, Ferruh ; Zhang, Qi Z
> ; Iremonger, Bernard
> Cc: dev@dpdk.org; Yang, Qiming
> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>
> From: Qiming Yang
>
> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> problem when running with new version of the ethdev shared
> library.
>
> Signed-off-by: Qiming Yang
> ---
> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h
> b/lib/librte_ethdev/rte_eth_ctrl.h
> index 5ea8ae24c..b3416341b 100644
> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> RTE_TUNNEL_TYPE_NVGRE,
> RTE_TUNNEL_TYPE_IP_IN_GRE,
> RTE_L2_TUNNEL_TYPE_E_TAG,
> + RTE_TUNNEL_TYPE_VXLAN_GPE,
Not sure, why do you consider it as an ABI breakage?
Konstantin
> RTE_TUNNEL_TYPE_MAX,
> };
>
> --
> 2.13.6
Re: [dpdk-dev] [PATCH 1/1] net/mlx5: fix device probing for old kernel drivers
> -Original Message- > From: David Christensen > Sent: Thursday, April 4, 2019 22:06 > To: Slava Ovsiienko ; dev@dpdk.org > Cc: Shahaf Shuler > Subject: Re: [dpdk-dev] [PATCH 1/1] net/mlx5: fix device probing for old > kernel drivers > > > Retrieving network interface index via Netlink fails in case of old > > mlx5 kernel drivers installed >> Can you put a boundary on this statement with a kernel driver version? > > Dave As far as I know this setup experiences the problem (I debugged on): 4.15.32+ Ubuntu 16.04.5 LTS mlx5_core 5.0-0 (from Linux Upstream) standalone ConnextX-4LX virtual function These setups has no problem: 3.10.0-327 Red Hat7.2 mlx5_core 4.6-0.2.0 (from OFED) standalone ConnextX-4LX physical function 5.0rc7+ Red Hat 7.5 mlx5_core 5.0-0 standalone ConnextX-4LX physical function I'll try to get more information regarding other problematic configs. Regards, Slava
Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
>> Sent: Friday, April 5, 2019 10:06 AM
>> To: Yigit, Ferruh ; Zhang, Qi Z
>> ; Iremonger, Bernard
>> Cc: dev@dpdk.org; Yang, Qiming
>> Subject: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
>>
>> From: Qiming Yang
>>
>> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
>> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
>> problem when running with new version of the ethdev shared
>> library.
>>
>> Signed-off-by: Qiming Yang
>> ---
>> lib/librte_ethdev/rte_eth_ctrl.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/librte_ethdev/rte_eth_ctrl.h
>> b/lib/librte_ethdev/rte_eth_ctrl.h
>> index 5ea8ae24c..b3416341b 100644
>> --- a/lib/librte_ethdev/rte_eth_ctrl.h
>> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
>> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
>> RTE_TUNNEL_TYPE_NVGRE,
>> RTE_TUNNEL_TYPE_IP_IN_GRE,
>> RTE_L2_TUNNEL_TYPE_E_TAG,
>> +RTE_TUNNEL_TYPE_VXLAN_GPE,
>
> Not sure, why do you consider it as an ABI breakage?
I think it is API breakage instead of ABI.
This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
If the application is using the MAX enum item, with the new version of the
ethdev the MAX value will be different and this can break the app.
Like:
app_function(..) {
ret = lib_foo()
if (ret == RTE_TUNNEL_TYPE_MAX)
ret -1;
}
lib_foo(..) {
return RTE_TUNNEL_TYPE_MAX;
}
When app compiled, MAX was '7' and app is comparing ret value against '7', but
with new version of DPDK, 'lib_foo()' will return '8' instead.
> Konstantin
>
>> RTE_TUNNEL_TYPE_MAX,
>> };
>>
>> --
>> 2.13.6
>
Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
Hi,
Sorry for not catching it before, but I was not Cc.
Please use git send-email --to-cmd devtools/get-maintainer.sh
05/04/2019 11:42, Ferruh Yigit:
> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
> >> From: Qiming Yang
> >>
> >> This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
> >> This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
> >> problem when running with new version of the ethdev shared
> >> library.
> >>
> >> Signed-off-by: Qiming Yang
> >> ---
[...]
> >> --- a/lib/librte_ethdev/rte_eth_ctrl.h
> >> +++ b/lib/librte_ethdev/rte_eth_ctrl.h
> >> @@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
> >>RTE_TUNNEL_TYPE_NVGRE,
> >>RTE_TUNNEL_TYPE_IP_IN_GRE,
> >>RTE_L2_TUNNEL_TYPE_E_TAG,
> >> + RTE_TUNNEL_TYPE_VXLAN_GPE,
> >
> > Not sure, why do you consider it as an ABI breakage?
>
> I think it is API breakage instead of ABI.
>
> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
> If the application is using the MAX enum item, with the new version of the
> ethdev the MAX value will be different and this can break the app.
>
> Like:
>
> app_function(..) {
> ret = lib_foo()
> if (ret == RTE_TUNNEL_TYPE_MAX)
> ret -1;
> }
>
> lib_foo(..) {
> return RTE_TUNNEL_TYPE_MAX;
> }
>
>
> When app compiled, MAX was '7' and app is comparing ret value against '7', but
> with new version of DPDK, 'lib_foo()' will return '8' instead.
I would vote for ABI because it is a value change.
Anyway, it must be noticed in the release notes.
As we are already breaking ethdev ABI in this release,
and it is a very basic change, I agree to accept it in 19.05.
In future, we should make sure that such addition is possible
without any breakage.
Re: [dpdk-dev] [RFC 1/5] eal: add accessor functions for lcore_config
On Wed, Apr 3, 2019 at 7:16 PM Stephen Hemminger
wrote:
> diff --git a/lib/librte_eal/common/eal_common_lcore.c
> b/lib/librte_eal/common/eal_common_lcore.c
> index 1cbac42286ba..806204d9f73d 100644
> --- a/lib/librte_eal/common/eal_common_lcore.c
> +++ b/lib/librte_eal/common/eal_common_lcore.c
> @@ -16,6 +16,52 @@
> #include "eal_private.h"
> #include "eal_thread.h"
>
> +int rte_lcore_index(int lcore_id)
> +{
> + if (unlikely(lcore_id >= RTE_MAX_LCORE))
> + return -1;
> +
> + if (lcore_id < 0)
> + lcore_id = (int)rte_lcore_id();
> +
> + return lcore_config[lcore_id].core_index;
> +}
>
+
> +int rte_lcore_to_cpu_id(int lcore_id)
> +{
> + if (unlikely(lcore_id >= RTE_MAX_LCORE))
> + return -1;
> +
> + if (lcore_id < 0)
> + lcore_id = (int)rte_lcore_id();
> +
> + return lcore_config[lcore_id].core_id;
> +}
> +
> +rte_cpuset_t rte_lcore_cpuset(unsigned lcore_id)
>
unsigned int
+{
> + return lcore_config[lcore_id].cpuset;
> +}
>
I am a bit skeptical at what dpaa wants to do with this.
Anyway, it can be used when we want to check the current cpuset.
+
> +unsigned
>
unsigned int
+rte_lcore_to_socket_id(unsigned int lcore_id)
> +{
> + return lcore_config[lcore_id].socket_id;
> +}
> +
> +enum rte_lcore_state_t
> +rte_lcore_state(unsigned lcore_id)
>
unsigned int
+{
> + return lcore_config[lcore_id].state;
> +}
>
This is a duplicate for existing rte_eal_get_lcore_state() in
lib/librte_eal/common/eal_common_launch.c.
So either we keep rte_eal_get_lcore_state() or we replace it with this new
one.
+
> +int
> +rte_lcore_return_code(unsigned lcore_id)
>
unsigned int
+{
> + return lcore_config[lcore_id].ret;
> +}
>
+
> +
>
Double blank line.
static int
> socket_id_cmp(const void *a, const void *b)
> {
>
--
David Marchand
Re: [dpdk-dev] [PATCH v5 1/5] ethdev: add VXLAN-GPE macro
On 4/5/2019 11:37 AM, Thomas Monjalon wrote:
> Hi,
>
> Sorry for not catching it before, but I was not Cc.
> Please use git send-email --to-cmd devtools/get-maintainer.sh
>
> 05/04/2019 11:42, Ferruh Yigit:
>> On 4/5/2019 10:36 AM, Ananyev, Konstantin wrote:
>>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qi Zhang
From: Qiming Yang
This patch added VXLAN-GPE macro in rte_eth_tunnel_type.
This patch will break the ABI, RTE_TUNNEL_TYPE_MAX will have
problem when running with new version of the ethdev shared
library.
Signed-off-by: Qiming Yang
---
> [...]
--- a/lib/librte_ethdev/rte_eth_ctrl.h
+++ b/lib/librte_ethdev/rte_eth_ctrl.h
@@ -229,6 +229,7 @@ enum rte_eth_tunnel_type {
RTE_TUNNEL_TYPE_NVGRE,
RTE_TUNNEL_TYPE_IP_IN_GRE,
RTE_L2_TUNNEL_TYPE_E_TAG,
+ RTE_TUNNEL_TYPE_VXLAN_GPE,
>>>
>>> Not sure, why do you consider it as an ABI breakage?
>>
>> I think it is API breakage instead of ABI.
>>
>> This changes the value of the 'RTE_TUNNEL_TYPE_MAX'
>> If the application is using the MAX enum item, with the new version of the
>> ethdev the MAX value will be different and this can break the app.
>>
>> Like:
>>
>> app_function(..) {
>> ret = lib_foo()
>> if (ret == RTE_TUNNEL_TYPE_MAX)
>> ret -1;
>> }
>>
>> lib_foo(..) {
>> return RTE_TUNNEL_TYPE_MAX;
>> }
>>
>>
>> When app compiled, MAX was '7' and app is comparing ret value against '7',
>> but
>> with new version of DPDK, 'lib_foo()' will return '8' instead.
>
> I would vote for ABI because it is a value change.
>
> Anyway, it must be noticed in the release notes.
>
> As we are already breaking ethdev ABI in this release,
> and it is a very basic change, I agree to accept it in 19.05.
+1
>
> In future, we should make sure that such addition is possible
> without any breakage.
+1. Otherwise there is no escape from it and adding a new tunnel type shouldn't
cause and ABI/API breakage.
Re: [dpdk-dev] [PATCH v3] app/test/ipsec: fix test initialisation
>
> Fix xform initialisation.
> Fix testsuite_setup.
> Remove unused variables.
>
> Fixes: 05fe65eb66b2 ("test/ipsec: introduce functional test")
> Fixes: 59d7353b0df0 ("test/ipsec: fix test suite setup")
>
> Signed-off-by: Bernard Iremonger
> ---
> Changes in v3:
> drop changes to logic around rte_cryptodev_dequeue_burst()
>
> app/test/test_ipsec.c | 34 +++---
> 1 file changed, 15 insertions(+), 19 deletions(-)
>
Acked-by: Konstantin Ananyev
> --
> 2.7.4
Re: [dpdk-dev] [PATCH v3 0/2] examples/ipsec-secgw: fix 1st pkt dropped
> > This patchset fixes the issue of the first inbound packet > being dropped for inline crypto. > > Changes in v3: > -- > The previous refactoring of the create_session() function has been dropped. > The create_session() function is now called from sa_init() at startup. > > The following functions have been added: > crypto_devid_fill() in ipsec-secgw.c > check_cryptodev_capability() in ipsec.c > check_cryptodev_aead_capability() in ipsec.c > create_sec_session() and create_crypto_session() in ipsec.c > > The create_session() function has been refactored to call > the create_sec_session() and create_crypto_session() functions. > > > Changes in v2: > -- > The first three patches of the v1 have been squashed. > The commit message for the squashed patch has been updated. > Patches 4,5 and 6 of the v1 have been dropped from this patchset. > A patch to fix the test scripts has been added. > > Bernard Iremonger (2): > examples/ipsec-secgw: fix 1st packet dropped for inline crypto > examples/ipsec-secgw/test: fix inline test scripts > > examples/ipsec-secgw/ipsec-secgw.c | 271 +++-- > examples/ipsec-secgw/ipsec.c | 569 > ++- > examples/ipsec-secgw/ipsec.h | 10 +- > examples/ipsec-secgw/ipsec_process.c | 38 +- > examples/ipsec-secgw/sa.c| 42 +- > examples/ipsec-secgw/test/trs_aesgcm_defs.sh | 10 - > examples/ipsec-secgw/test/tun_aesgcm_defs.sh | 10 - > 7 files changed, 495 insertions(+), 455 deletions(-) > > -- As ipsec lib and these tests were introduced in 19.02, I don't think you need to cc stable. Apart from that: Series Acked-by: Konstantin Ananyev > 2.7.4
Re: [dpdk-dev] [PATCH v2 1/3] bus/fslmc: cleanup unused firmware code
On 05/04/19 3:13 AM, Thomas Monjalon wrote:
> 04/04/2019 23:29, Ferruh Yigit:
>> On 4/4/2019 8:23 AM, Shreyansh Jain wrote:
>>> Removes some unused firmware code which was added in last bump
>>> of the firmware version. No current features uses these APIs.
>>>
>>> Signed-off-by: Shreyansh Jain
>>
>> <...>
>>
>>> diff --git a/drivers/bus/fslmc/mc/fsl_dpci.h
>>> b/drivers/bus/fslmc/mc/fsl_dpci.h
>>> index 9af9097e5..cf3d15267 100644
>>> --- a/drivers/bus/fslmc/mc/fsl_dpci.h
>>> +++ b/drivers/bus/fslmc/mc/fsl_dpci.h
>>> @@ -108,27 +108,6 @@ int dpci_get_attributes(struct fsl_mc_io *mc_io,
>>> uint16_t token,
>>> struct dpci_attr *attr);
>>>
>>> -/**
>>> - * struct dpci_peer_attr - Structure representing the peer DPCI attributes
>>> - * @peer_id: DPCI peer id; if no peer is connected returns
>>> (-1)
>>> - * @num_of_priorities: The pper's number of receive priorities;
>>> determines the
>>> - * number of transmit priorities for the local DPCI object
>>> - */
>>> -struct dpci_peer_attr {
>>> - int peer_id;
>>> - uint8_t num_of_priorities;
>>> -};
>>> -
>>> -int dpci_get_peer_attributes(struct fsl_mc_io *mc_io,
>>> -uint32_t cmd_flags,
>>> -uint16_t token,
>>> -struct dpci_peer_attr *attr);
>>> -
>>> -int dpci_get_link_state(struct fsl_mc_io *mc_io,
>>> - uint32_t cmd_flags,
>>> - uint16_t token,
>>> - int *up);
>>
>> These needs to be removed from .map file too.
Wow! indeed a great catch.
And, yup, my bad. Sorry! I wish I had your eye-for-detail.
>
> Removed from master.
> Thanks for the catch.
>
>
Re: [dpdk-dev] [PATCH] devtools: accept experimental symbol promotion
On Fri, Apr 05, 2019 at 10:17:47AM +0200, David Marchand wrote:
> Currently, when symbols get promoted from the EXPERIMENTAL section to a
> stable ABI section, the script complains they should go to the
> EXPERIMENTAL section.
>
> Example:
> ERROR: symbol rte_devargs_add is added in the DPDK_19.05 section, but is
> expected to be added in the EXPERIMENTAL section of the version map
>
> This is legit.
> Moving from a stable ABI to another is also allowed, but must have gone
> through the proper process.
>
> Fixes: 4bec48184e33 ("devtools: add checks for ABI symbol addition")
> Cc: sta...@dpdk.org
>
> Signed-off-by: David Marchand
> ---
> devtools/check-symbol-change.sh | 44
> +
> 1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/devtools/check-symbol-change.sh b/devtools/check-symbol-change.sh
> index 020da7e..40eb953 100755
> --- a/devtools/check-symbol-change.sh
> +++ b/devtools/check-symbol-change.sh
> @@ -105,27 +105,37 @@ check_for_rule_violations()
> continue
> fi
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + oldsecname=$(sed -n \
> + "s#$mname $symname \(.*\) del#\1#p" "$mapdb")
> +
> + # A symbol can not enter a non experimental
> + # section directly
> + if [ $? -ne 0 ] && [ "$secname" != 'EXPERIMENTAL' ]
> then
> - # Symbols that are getting added in a section
> - # other than the experimental section
> - # to be moving from an already supported
> - # section or its a violation
> - grep -q \
> - "$mname $symname [^EXPERIMENTAL] del" "$mapdb"
> - if [ $? -ne 0 ]
> - then
> - echo -n "ERROR: symbol $symname "
> - echo -n "is added in the $secname "
> - echo -n "section, but is expected to "
> - echo -n "be added in the EXPERIMENTAL "
> - echo "section of the version map"
> - ret=1
> - fi
> + echo -n "ERROR: symbol $symname "
> + echo -n "is added in the $secname "
> + echo -n "section, but is expected to "
> + echo -n "be added in the EXPERIMENTAL "
> + echo "section of the version map"
> + ret=1
> + continue
> + fi
> +
> + # This symbol is moving between two sections (the
> + # original section is not experimental).
> + # This can be legit, just warn.
> + if [ "$oldsecname" != 'EXPERIMENTAL' ]
> + then
> + echo -n "INFO: symbol $symname is being "
> + echo -n "moved from $oldsecname to $secname. "
> + echo -n "Ensure that it has gone through the "
> + echo "deprecation process"
> + continue
> fi
> else
>
> - if [ "$secname" != "EXPERIMENTAL" ]
> + if ! grep -q "$mname $symname .* add" "$mapdb" && \
> +[ "$secname" != "EXPERIMENTAL" ]
> then
> # Just inform users that non-experimenal
> # symbols need to go through a deprecation
> --
> 1.8.3.1
>
>
Acked-by: Neil Horman
Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
On 4/5/2019 10:05 AM, Qi Zhang wrote: > --- > v5: > 1. add ABI break notification in commit log of PATCH 1/5 > 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's >comments) > > V4: > 1. rebased to the latest code. > 2. deleted misleading statement. > > V3: > 1. fixed issue in release note. > 2. fixed check patch issue. > 3. spilted eal related change to a new patch. > > V2: > 1. move testpmd related changes to a new patch. > 2. added release note update. > > > Qiming Yang (5): > ethdev: add VXLAN-GPE macro > net/i40e: add support for VXLAN-GPE > net/i40e: support VXLAN-GPE classification > app/testpmd: add VXLAN-GPE to tunnel type > doc: add release note for VXLAN-GPE support For series, Reviewed-by: Ferruh Yigit
Re: [dpdk-dev] [PATCH v2 1/3] bus/fslmc: cleanup unused firmware code
On 4/5/2019 12:19 PM, Shreyansh Jain wrote:
> On 05/04/19 3:13 AM, Thomas Monjalon wrote:
>> 04/04/2019 23:29, Ferruh Yigit:
>>> On 4/4/2019 8:23 AM, Shreyansh Jain wrote:
Removes some unused firmware code which was added in last bump
of the firmware version. No current features uses these APIs.
Signed-off-by: Shreyansh Jain
>>>
>>> <...>
>>>
diff --git a/drivers/bus/fslmc/mc/fsl_dpci.h
b/drivers/bus/fslmc/mc/fsl_dpci.h
index 9af9097e5..cf3d15267 100644
--- a/drivers/bus/fslmc/mc/fsl_dpci.h
+++ b/drivers/bus/fslmc/mc/fsl_dpci.h
@@ -108,27 +108,6 @@ int dpci_get_attributes(struct fsl_mc_io *mc_io,
uint16_t token,
struct dpci_attr *attr);
-/**
- * struct dpci_peer_attr - Structure representing the peer DPCI attributes
- * @peer_id: DPCI peer id; if no peer is connected returns
(-1)
- * @num_of_priorities:The pper's number of receive priorities;
determines the
- *number of transmit priorities for the local
DPCI object
- */
-struct dpci_peer_attr {
- int peer_id;
- uint8_t num_of_priorities;
-};
-
-int dpci_get_peer_attributes(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- uint16_t token,
- struct dpci_peer_attr *attr);
-
-int dpci_get_link_state(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- uint16_t token,
- int *up);
>>>
>>> These needs to be removed from .map file too.
>
> Wow! indeed a great catch.
we have a script for it ;)
./devtools/check-symbol-maps.sh
> And, yup, my bad. Sorry! I wish I had your eye-for-detail.
>
>>
>> Removed from master.
>> Thanks for the catch.
>>
>>
Re: [dpdk-dev] [PATCH v2 1/3] bus/fslmc: cleanup unused firmware code
On 05/04/19 4:49 PM, Shreyansh Jain wrote:
> On 05/04/19 3:13 AM, Thomas Monjalon wrote:
>> 04/04/2019 23:29, Ferruh Yigit:
>>> On 4/4/2019 8:23 AM, Shreyansh Jain wrote:
Removes some unused firmware code which was added in last bump
of the firmware version. No current features uses these APIs.
Signed-off-by: Shreyansh Jain
>>>
>>> <...>
>>>
diff --git a/drivers/bus/fslmc/mc/fsl_dpci.h
b/drivers/bus/fslmc/mc/fsl_dpci.h
index 9af9097e5..cf3d15267 100644
--- a/drivers/bus/fslmc/mc/fsl_dpci.h
+++ b/drivers/bus/fslmc/mc/fsl_dpci.h
@@ -108,27 +108,6 @@ int dpci_get_attributes(struct fsl_mc_io *mc_io,
uint16_t token,
struct dpci_attr *attr);
-/**
- * struct dpci_peer_attr - Structure representing the peer DPCI attributes
- * @peer_id: DPCI peer id; if no peer is connected returns
(-1)
- * @num_of_priorities:The pper's number of receive priorities;
determines the
- *number of transmit priorities for the local
DPCI object
- */
-struct dpci_peer_attr {
- int peer_id;
- uint8_t num_of_priorities;
-};
-
-int dpci_get_peer_attributes(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- uint16_t token,
- struct dpci_peer_attr *attr);
-
-int dpci_get_link_state(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- uint16_t token,
- int *up);
>>>
>>> These needs to be removed from .map file too.
>
> Wow! indeed a great catch.
> And, yup, my bad. Sorry! I wish I had your eye-for-detail.
>
>>
>> Removed from master.
>> Thanks for the catch.
Thomas,
I still see this applied on the master and net-next.
Can you tell me how do you want me to do - send a fresh series or just
the delta change for map file?
Re: [dpdk-dev] [PATCH v5 0/5] This patch set supported new packet type
On 4/5/2019 12:31 PM, Ferruh Yigit wrote: > On 4/5/2019 10:05 AM, Qi Zhang wrote: >> --- >> v5: >> 1. add ABI break notification in commit log of PATCH 1/5 >> 2. fix missing help string/document in testpmd cmdline (Bernard Iremonger's >>comments) >> >> V4: >> 1. rebased to the latest code. >> 2. deleted misleading statement. >> >> V3: >> 1. fixed issue in release note. >> 2. fixed check patch issue. >> 3. spilted eal related change to a new patch. >> >> V2: >> 1. move testpmd related changes to a new patch. >> 2. added release note update. >> >> >> Qiming Yang (5): >> ethdev: add VXLAN-GPE macro >> net/i40e: add support for VXLAN-GPE >> net/i40e: support VXLAN-GPE classification >> app/testpmd: add VXLAN-GPE to tunnel type >> doc: add release note for VXLAN-GPE support > > For series, > Reviewed-by: Ferruh Yigit > Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH v2 1/3] ethdev: add actions to modify TCP header fields
On 4/4/19 4:25 PM, Adrien Mazarguil wrote:
Hi Ori,
(trimming message down a bit)
On Thu, Apr 04, 2019 at 09:01:52AM +, Ori Kam wrote:
Hi Adrien,
PSB
From: Adrien Mazarguil
On Wed, Apr 03, 2019 at 10:49:09AM +, Dekel Peled wrote:
Thanks, PSB.
From: Adrien Mazarguil
I still don't agree with the wording as it implies one must combine this
action
with the TCP pattern item or else, while one should simply ensure the
presence of TCP traffic somehow. This may be done by a prior filtering rule.
So here's a generic suggestion which could be used with pretty much all
modifying actions (other actions have the same problem and will have to be
fixed as well eventually):
Using this action on non-matching traffic results in undefined behavior.
This comment applies to all instances in this patch.
I accept your suggestion, indeed the existing actions have the problematic
condition.
However I would like to currently leave this patch as-is for consistency.
I will send a fix patch for next release, applying the updated text to all
modify-header actions.
Please do it now as it's much more difficult to change an existing API
later (think deprecation notices and endless discussions); even seemingly
minor documentation issues like this one may affect applications.
I agree that changing API is not easy. This is why I think we should keep Dekel
patch,
there is a number of API and consistency is very important. Also the PMD is
based on the current
description that such command should fail.
So lets keep it this way if you want to change all API then and only then this
API should be changed.
Wait, I'm not asking Delek to modify existing code/APIs right now, only to
document these new actions properly from the start so we don't have to do it
later (you even acknowledged it's more difficult that way).
So I fail to understand why it's so important for their documentation to be
consistent with unrelated and badly documented actions?
Note the change I'm asking for at the API level doesn't affect PMD code,
which remains free to put extra limitations (namely the presence of TCP
pattern items). It's just that these limitations have nothing to do in the
API itself.
It's either 2 actions with 1 parameters, or 1 action with 2 parameters.
The current implementation is more straight-forward in my opinion.
I generally also prefer the one action per thing to do approach, but seeing
the kind of actions you're adding, I fear we'll soon end up with lots of
similar rte_flow_action_* structures modifying a single 32-bit value in some
way.
So for the same reasons as above, I think it's the right time to define a
shared structure to rule them all, or maybe even let users provide a
rte_be32_t/uint32_t/whatever pointer directly as a conf pointer (not
as straightforward to document though).
An object to rule them all would look something like that:
union rte_flow_integer {
rte_be64_t be64;
rte_le64_t le64;
uint64_t u64;
int64_t i64;
rte_be32_t be32;
rte_le32_t le32;
uint32_t u32;
int32_t i32;
uint8_t u8;
int8_t i8;
};
Then actions that need a single integer value only have to document which
field is relevant to them. How about that?
I like the idea (plus 16-bit options). We already have too many
rte_flow_action_* structures with single integer in it.
Like my previous comment. I understand your idea, but it has no huge advantage
compared to the
suggested one by Dekel which also match all other API.
Currently for each action we have a direct command, which is easy to understand
by using your idea we break this concept.
Yes, although not all actions have a configuration structure. Those that do
indeed have a rte_flow_action_* counterpart, but it doesn't have to be
unique, see RTE_FLOW_ITEM_GTP/GTPC/GTPU for instance.
Likewise this patch adds struct rte_flow_action_modify_tcp_seq shared by
RTE_FLOW_ACTION_TYPE_INC_TCP_SEQ and RTE_FLOW_ACTION_TYPE_DEC_TCP_SEQ
although they lack a common prefix (inc_tcp/dec_tcp vs. modify_tcp). The
type to use is covered by documentation and that's fine.
So why not go a little further and share the exact same structure with
RTE_FLOW_ACTION_TYPE_INC_TCP_ACK and RTE_FLOW_ACTION_TYPE_DEC_TCP_ACK?
Shouldn't these action be RTE_FLOW_ACTION_TYPE_MOD_TCP_{ACK,SEQ}
with singed 32-bit integer parameter (negative to decrement, positive to
increment)? IMHO, having INC and DEC is too artificial and just bloat API
and code.
And while there, why not plan for subsequent actions that take a single
integer value of some kind, because modifying existing APIs once upstream is
complicated... See where I'm going?
There is no issue with having a large number of actions, it is even easer to
read and document if each action is dedicated,
as you can also see from OVS.
I'm actually fine with a large number of actions (rte_flow can support 2^31
unique actions). Not so much with a large number of identical configuration
s
[dpdk-dev] [PATCH v2] meter: replace color definitions with rte_color values
This patch implements the changes proposed in the deprecation
note[1].
Replace mulitple color definitions in various places such as
rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined
in rte_meter.h.
[1] https://mails.dpdk.org/archives/dev/2019-January/123861.html
Signed-off-by: Jasvinder Singh
---
v2:
- rebase to latest dpdk head
app/proc-info/main.c| 36 +++---
app/test-pmd/cmdline_mtr.c | 46 +++
app/test-pmd/cmdline_tm.c | 22 ++--
app/test/test_meter.c | 126 ++--
app/test/test_sched.c | 6 +-
doc/guides/rel_notes/deprecation.rst| 5 -
doc/guides/rel_notes/release_19_05.rst | 7 +-
drivers/net/softnic/rte_eth_softnic_cli.c | 14 +--
drivers/net/softnic/rte_eth_softnic_flow.c | 12 +-
drivers/net/softnic/rte_eth_softnic_meter.c | 26 ++--
drivers/net/softnic/rte_eth_softnic_tm.c| 28 ++---
examples/ip_pipeline/cli.c | 20 ++--
examples/qos_meter/main.h | 10 +-
examples/qos_meter/rte_policer.c| 4 +-
examples/qos_meter/rte_policer.h| 12 +-
examples/qos_sched/app_thread.c | 2 +-
lib/librte_ethdev/rte_mtr.c | 2 +-
lib/librte_ethdev/rte_mtr.h | 10 +-
lib/librte_ethdev/rte_mtr_driver.h | 2 +-
lib/librte_ethdev/rte_tm.h | 14 +--
lib/librte_meter/Makefile | 2 +-
lib/librte_meter/meson.build| 2 +-
lib/librte_meter/rte_meter.h| 91 +++---
lib/librte_pipeline/rte_table_action.c | 50
lib/librte_pipeline/rte_table_action.h | 8 +-
lib/librte_sched/rte_sched.c| 12 +-
lib/librte_sched/rte_sched.h| 6 +-
27 files changed, 284 insertions(+), 291 deletions(-)
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index 3cd53416d..a89b51bb3 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -873,21 +873,21 @@ show_tm(void)
printf(" - mark support:\n");
printf("\t -- vlan dei: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_vlan_dei_supported[RTE_TM_GREEN],
- cap.mark_vlan_dei_supported[RTE_TM_YELLOW],
- cap.mark_vlan_dei_supported[RTE_TM_RED]);
+ cap.mark_vlan_dei_supported[RTE_COLOR_GREEN],
+ cap.mark_vlan_dei_supported[RTE_COLOR_YELLOW],
+ cap.mark_vlan_dei_supported[RTE_COLOR_RED]);
printf("\t -- ip ecn tcp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_ecn_tcp_supported[RTE_TM_GREEN],
- cap.mark_ip_ecn_tcp_supported[RTE_TM_YELLOW],
- cap.mark_ip_ecn_tcp_supported[RTE_TM_RED]);
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_RED]);
printf("\t -- ip ecn sctp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_ecn_sctp_supported[RTE_TM_GREEN],
- cap.mark_ip_ecn_sctp_supported[RTE_TM_YELLOW],
- cap.mark_ip_ecn_sctp_supported[RTE_TM_RED]);
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_RED]);
printf("\t -- ip dscp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_dscp_supported[RTE_TM_GREEN],
- cap.mark_ip_dscp_supported[RTE_TM_YELLOW],
- cap.mark_ip_dscp_supported[RTE_TM_RED]);
+ cap.mark_ip_dscp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_dscp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_dscp_supported[RTE_COLOR_RED]);
printf(" - mask stats (0x%"PRIx64")"
" dynamic update (0x%"PRIx64")\n",
@@ -1004,12 +1004,12 @@ show_tm(void)
" pkts (%"PRIu64") bytes (%"PRIu64")\n"
"\t -- RED:"
" pkts (%"PRIu64") bytes (%"PRIu64")\n",
- stats.leaf.n_pkts_dropped[RTE_TM_GREEN],
- stats.leaf.n_bytes_dropped[RTE_TM_GREEN],
- stats.leaf.n_pkts_dropped[RTE_TM_YELLOW],
- stats.leaf.n_bytes_dropped[RTE_TM_YELLOW],
- stats.leaf.n_pkts_dropped[RTE_TM_RED],
- stats.leaf.n_bytes_dropped[RTE_TM_RED]);
+ stats.leaf.n_pkts_dropped[RTE_COLOR_GREEN],
+
[dpdk-dev] [PATCH v4 1/2] app/testpmd: fix Tx VLAN and QinQ dependency
From: Nithin Dabilpuram
Tx VLAN & QinQ insert enable need not depend on
Rx VLAN offload ETH_VLAN_EXTEND_OFFLOAD. For Tx VLAN
insert enable, error check is now to see if QinQ was enabled
but only single VLAN id is set.
Fixes: 6a34f91690d0 ("app/testpmd: fix error message when setting Tx VLAN")
Cc: xiao.w.w...@intel.com
Signed-off-by: Nithin Dabilpuram
Acked-by: Bernard Iremonger
---
v4:
* Resend v3 from different mailserver to avoid
CRLF
v3:
* Add back error check in tx_vlan_set() to check if QinQ is
already enabled. Also fix headline.
v2:
* Split change into two seperate patches as suggested.
app/test-pmd/config.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index cadcb51..010e26d 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -2962,7 +2962,6 @@ vlan_tpid_set(portid_t port_id, enum rte_vlan_type
vlan_type, uint16_t tp_id)
void
tx_vlan_set(portid_t port_id, uint16_t vlan_id)
{
- int vlan_offload;
struct rte_eth_dev_info dev_info;
if (port_id_is_invalid(port_id, ENABLED_WARN))
@@ -2970,8 +2969,8 @@ tx_vlan_set(portid_t port_id, uint16_t vlan_id)
if (vlan_id_is_invalid(vlan_id))
return;
- vlan_offload = rte_eth_dev_get_vlan_offload(port_id);
- if (vlan_offload & ETH_VLAN_EXTEND_OFFLOAD) {
+ if (ports[port_id].dev_conf.txmode.offloads &
+ DEV_TX_OFFLOAD_QINQ_INSERT) {
printf("Error, as QinQ has been enabled.\n");
return;
}
@@ -2990,7 +2989,6 @@ tx_vlan_set(portid_t port_id, uint16_t vlan_id)
void
tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t vlan_id_outer)
{
- int vlan_offload;
struct rte_eth_dev_info dev_info;
if (port_id_is_invalid(port_id, ENABLED_WARN))
@@ -3000,11 +2998,6 @@ tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t
vlan_id_outer)
if (vlan_id_is_invalid(vlan_id_outer))
return;
- vlan_offload = rte_eth_dev_get_vlan_offload(port_id);
- if (!(vlan_offload & ETH_VLAN_EXTEND_OFFLOAD)) {
- printf("Error, as QinQ hasn't been enabled.\n");
- return;
- }
rte_eth_dev_info_get(port_id, &dev_info);
if ((dev_info.tx_offload_capa & DEV_TX_OFFLOAD_QINQ_INSERT) == 0) {
printf("Error: qinq insert not supported by port %d\n",
--
2.8.4
[dpdk-dev] [PATCH v4 2/2] app/testpmd: fix Tx QinQ set
From: Nithin Dabilpuram
Enable DEV_TX_OFFLOAD_VLAN_INSERT also along with
DEV_TX_OFFLOAD_VLAN_QINQ in tx_qinq_set() as it takes
both vlan id's as arguments.
Fixes: 597f9fafe13b ("app/testpmd: convert to new Tx offloads API")
Cc: shah...@mellanox.com
Signed-off-by: Nithin Dabilpuram
Acked-by: Bernard Iremonger
---
v4:
* Resend v3 from different mailserver to avoid
CRLF
v3:
* Rename headline
v2:
* Split change into two seperate patches as suggested.
app/test-pmd/config.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 010e26d..f9cb129 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -3006,7 +3006,8 @@ tx_qinq_set(portid_t port_id, uint16_t vlan_id, uint16_t
vlan_id_outer)
}
tx_vlan_reset(port_id);
- ports[port_id].dev_conf.txmode.offloads |= DEV_TX_OFFLOAD_QINQ_INSERT;
+ ports[port_id].dev_conf.txmode.offloads |= (DEV_TX_OFFLOAD_VLAN_INSERT |
+ DEV_TX_OFFLOAD_QINQ_INSERT);
ports[port_id].tx_vlan_id = vlan_id;
ports[port_id].tx_vlan_id_outer = vlan_id_outer;
}
--
2.8.4
[dpdk-dev] [PATCH] net/sfc: improve Rx free threshold default
Rx refill in one bulk (which is just 8 descriptors) by default is too aggressive and makes too many MMIO writes (Rx doorbells) if packet rate is high. Setting default to 1/8 of Rx descriptors number shows good performance results. Anyway it is a default value which may be overridden by Rx configuration provided by application. Signed-off-by: Andrew Rybchenko --- drivers/net/sfc/sfc_rx.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/net/sfc/sfc_rx.c b/drivers/net/sfc/sfc_rx.c index 4b1d01e66..5d8c2765c 100644 --- a/drivers/net/sfc/sfc_rx.c +++ b/drivers/net/sfc/sfc_rx.c @@ -974,6 +974,7 @@ sfc_rx_qinit(struct sfc_adapter *sa, unsigned int sw_index, struct sfc_rxq *rxq; struct sfc_dp_rx_qcreate_info info; struct sfc_dp_rx_hw_limits hw_limits; + uint16_t rx_free_thresh; memset(&hw_limits, 0, sizeof(hw_limits)); hw_limits.rxq_max_entries = sa->rxq_max_entries; @@ -1043,8 +1044,22 @@ sfc_rx_qinit(struct sfc_adapter *sa, unsigned int sw_index, rxq = &sa->rxq_ctrl[sw_index]; rxq->evq = evq; rxq->hw_index = sw_index; + /* +* If Rx refill threshold is specified (its value is non zero) in +* Rx configuration, use specified value. Otherwise use 1/8 of +* the Rx descriptors number as the default. It allows to keep +* Rx ring full-enough and does not refill too aggressive if +* packet rate is high. +* +* Since PMD refills in bulks waiting for full bulk may be +* refilled (basically round down), it is better to round up +* here to mitigate it a bit. +*/ + rx_free_thresh = (rx_conf->rx_free_thresh != 0) ? + rx_conf->rx_free_thresh : EFX_DIV_ROUND_UP(nb_rx_desc, 8); + /* Rx refill threshold cannot be smaller than refill bulk */ rxq_info->refill_threshold = - RTE_MAX(rx_conf->rx_free_thresh, SFC_RX_REFILL_BULK); + RTE_MAX(rx_free_thresh, SFC_RX_REFILL_BULK); rxq_info->refill_mb_pool = mb_pool; rxq->buf_size = buf_size; -- 2.17.1
Re: [dpdk-dev] [PATCH v4 1/2] app/testpmd: fix Tx VLAN and QinQ dependency
On 4/5/2019 1:04 PM, Nithin Dabilpuram wrote:
> From: Nithin Dabilpuram
>
> Tx VLAN & QinQ insert enable need not depend on
> Rx VLAN offload ETH_VLAN_EXTEND_OFFLOAD. For Tx VLAN
> insert enable, error check is now to see if QinQ was enabled
> but only single VLAN id is set.
>
> Fixes: 6a34f91690d0 ("app/testpmd: fix error message when setting Tx VLAN")
> Cc: xiao.w.w...@intel.com
>
> Signed-off-by: Nithin Dabilpuram
> Acked-by: Bernard Iremonger
> ---
> v4:
> * Resend v3 from different mailserver to avoid
> CRLF
> v3:
> * Add back error check in tx_vlan_set() to check if QinQ is
> already enabled. Also fix headline.
> v2:
> * Split change into two seperate patches as suggested.
>
Hi Nithin,
I just merged the v3 and about to send the mail :)
What is different in v4? avoid CRLF?
Re: [dpdk-dev] [PATCH v2 1/3] bus/fslmc: cleanup unused firmware code
05/04/2019 13:38, Shreyansh Jain:
> On 05/04/19 4:49 PM, Shreyansh Jain wrote:
> > On 05/04/19 3:13 AM, Thomas Monjalon wrote:
> >> 04/04/2019 23:29, Ferruh Yigit:
> >>> On 4/4/2019 8:23 AM, Shreyansh Jain wrote:
> Removes some unused firmware code which was added in last bump
> of the firmware version. No current features uses these APIs.
>
> Signed-off-by: Shreyansh Jain
> >>>
> >>> <...>
> >>>
> diff --git a/drivers/bus/fslmc/mc/fsl_dpci.h
> b/drivers/bus/fslmc/mc/fsl_dpci.h
> index 9af9097e5..cf3d15267 100644
> --- a/drivers/bus/fslmc/mc/fsl_dpci.h
> +++ b/drivers/bus/fslmc/mc/fsl_dpci.h
> @@ -108,27 +108,6 @@ int dpci_get_attributes(struct fsl_mc_io *mc_io,
> uint16_t token,
> struct dpci_attr *attr);
>
> -/**
> - * struct dpci_peer_attr - Structure representing the peer DPCI
> attributes
> - * @peer_id:DPCI peer id; if no peer is connected returns
> (-1)
> - * @num_of_priorities: The pper's number of receive priorities;
> determines the
> - * number of transmit priorities for the local
> DPCI object
> - */
> -struct dpci_peer_attr {
> -int peer_id;
> -uint8_t num_of_priorities;
> -};
> -
> -int dpci_get_peer_attributes(struct fsl_mc_io *mc_io,
> - uint32_t cmd_flags,
> - uint16_t token,
> - struct dpci_peer_attr *attr);
> -
> -int dpci_get_link_state(struct fsl_mc_io *mc_io,
> -uint32_t cmd_flags,
> -uint16_t token,
> -int *up);
> >>>
> >>> These needs to be removed from .map file too.
> >
> > Wow! indeed a great catch.
> > And, yup, my bad. Sorry! I wish I had your eye-for-detail.
> >
> >>
> >> Removed from master.
> >> Thanks for the catch.
>
> Thomas,
> I still see this applied on the master and net-next.
> Can you tell me how do you want me to do - send a fresh series or just
> the delta change for map file?
I don't see them.
Please update master and check again.
Re: [dpdk-dev] [PATCH v2] examples/multi_process/symmetric_mp: fix link check
On 27-Mar-19 11:33 AM, Akhil Goyal wrote:
link check is done for primary process for the ports
which are given in the port mask and not the complete
set of ports.
Fixes: d3641ae86313 ("examples: update link status checks")
Cc: sta...@dpdk.org
Signed-off-by: Akhil Goyal
---
Acked-by: Anatoly Burakov
--
Thanks,
Anatoly
Re: [dpdk-dev] [PATCH 1/1] net/mlx5: fix device probing for old kernel drivers
The patch allowing to retrieve the network interface index and name via Netlink: https://www.spinics.net/lists/linux-rdma/msg62948.html In Linux tree: 5b2cc79d (Leon Romanovsky 2018-03-27 20:40:49 +0300 270) So, the problem depends on ib_core module version - 4.16 supports getting ifindex via Netlink, 4.15 does not. Mellanox OFED brings its own ib_core module, that's why it works over ancient 3.10.327. I'll update log message of my patch to describe the matter. With best regards, Slava > -Original Message- > From: Slava Ovsiienko > Sent: Friday, April 5, 2019 12:38 > To: 'David Christensen' ; dev@dpdk.org > Cc: Shahaf Shuler ; Ali Alnubani > > Subject: RE: [dpdk-dev] [PATCH 1/1] net/mlx5: fix device probing for old > kernel drivers > > > -Original Message- > > From: David Christensen > > Sent: Thursday, April 4, 2019 22:06 > > To: Slava Ovsiienko ; dev@dpdk.org > > Cc: Shahaf Shuler > > Subject: Re: [dpdk-dev] [PATCH 1/1] net/mlx5: fix device probing for > > old kernel drivers > > > > > Retrieving network interface index via Netlink fails in case of old > > > mlx5 kernel drivers installed > >> Can you put a boundary on this statement with a kernel driver version? > > > > Dave > > As far as I know this setup experiences the problem (I debugged on): > 4.15.32+ > Ubuntu 16.04.5 LTS > mlx5_core 5.0-0 (from Linux Upstream) > standalone ConnextX-4LX virtual function > > These setups has no problem: > 3.10.0-327 > Red Hat7.2 > mlx5_core 4.6-0.2.0 (from OFED) > standalone ConnextX-4LX physical function > > 5.0rc7+ > Red Hat 7.5 > mlx5_core 5.0-0 > standalone ConnextX-4LX physical function > > I'll try to get more information regarding other problematic configs. > > Regards, > Slava
Re: [dpdk-dev] [PATCH v2] lib/cfgfile: replace strcat with strlcat
27/03/2019 12:37, Ferruh Yigit:
> On 3/26/2019 10:04 AM, Chaitanya Babu, TalluriX wrote:
> > From: Yigit, Ferruh
> >> On 3/8/2019 2:02 PM, Bruce Richardson wrote:
> >>> On Fri, Mar 08, 2019 at 12:45:50PM +, Chaitanya Babu Talluri wrote:
> Replace strcat with strlcat to avoid buffer overflow.
>
> Fixes: a6a47ac9c2 ("cfgfile: rework load function")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Chaitanya Babu Talluri
>
> ---
> @@ -224,10 +225,11 @@ rte_cfgfile_load_with_params(const char
> >> *filename, int flags,
> _strip(split[1], strlen(split[1]));
> char *end = memchr(split[1], '\\',
> strlen(split[1]));
>
> +size_t split_len = strlen(split[1]) + 1;
> while (end != NULL) {
> if (*(end+1) ==
> params->comment_character)
> >> {
> *end = '\0';
> -strcat(split[1], end+1);
> +strlcat(split[1], end+1,
> split_len);
> >>>
> >>> I don't think this will do what you want. Remember that strlcat takes
> >>> the total length of the buffer, which means that if split_len is set
> >>> to the current length (as you do before the while statement), then
> >>> passing that as the length parameter will cause strlcat to do nothing,
> >>> since it sees the buffer as already full.
> >>
> >> The logic doesn't lengthen the 'split[1]' content, indeed it reduces the
> >> initial
> >> size although it uses string concatenation, that is why it should be OK to
> >> use
> >> 'split_len' here.
> >>
> >> What code does is, it finds specific char in 'split' buffer and removes it
> >> by
> >> shifting remaining chars one byte to the left. So it shouldn't pass the
> >> initial size
> >> of the buffer.
> >>
> >> There is a overlapping strings concern, which 'strcat' & 'strlcat' don't
> >> support,
> >> but I guess it is OK here since we are sure that strings are separated by a
> >> NULL, so where a char read and written should be different although overall
> >> dst and src buffers overlap.
> >
> > Yes, although the same string is manipulated the split string (*end = '\0')
> > is separated with NULL.
> > Strlcat works fine here and expected concatenation is happening.
> > If there are no further comments request for ACK please.
>
> Acked-by: Ferruh Yigit
Applied, thanks
Re: [dpdk-dev] [PATCH v2 1/3] bus/fslmc: cleanup unused firmware code
On 05/04/19 6:05 PM, Thomas Monjalon wrote:
> 05/04/2019 13:38, Shreyansh Jain:
>> On 05/04/19 4:49 PM, Shreyansh Jain wrote:
>>> On 05/04/19 3:13 AM, Thomas Monjalon wrote:
04/04/2019 23:29, Ferruh Yigit:
> On 4/4/2019 8:23 AM, Shreyansh Jain wrote:
>> Removes some unused firmware code which was added in last bump
>> of the firmware version. No current features uses these APIs.
>>
>> Signed-off-by: Shreyansh Jain
>
> <...>
>
>> diff --git a/drivers/bus/fslmc/mc/fsl_dpci.h
>> b/drivers/bus/fslmc/mc/fsl_dpci.h
>> index 9af9097e5..cf3d15267 100644
>> --- a/drivers/bus/fslmc/mc/fsl_dpci.h
>> +++ b/drivers/bus/fslmc/mc/fsl_dpci.h
>> @@ -108,27 +108,6 @@ int dpci_get_attributes(struct fsl_mc_io *mc_io,
>> uint16_t token,
>> struct dpci_attr *attr);
>>
>> -/**
>> - * struct dpci_peer_attr - Structure representing the peer DPCI
>> attributes
>> - * @peer_id:DPCI peer id; if no peer is connected returns
>> (-1)
>> - * @num_of_priorities: The pper's number of receive priorities;
>> determines the
>> - * number of transmit priorities for the local
>> DPCI object
>> - */
>> -struct dpci_peer_attr {
>> -int peer_id;
>> -uint8_t num_of_priorities;
>> -};
>> -
>> -int dpci_get_peer_attributes(struct fsl_mc_io *mc_io,
>> - uint32_t cmd_flags,
>> - uint16_t token,
>> - struct dpci_peer_attr *attr);
>> -
>> -int dpci_get_link_state(struct fsl_mc_io *mc_io,
>> -uint32_t cmd_flags,
>> -uint16_t token,
>> -int *up);
>
> These needs to be removed from .map file too.
>>>
>>> Wow! indeed a great catch.
>>> And, yup, my bad. Sorry! I wish I had your eye-for-detail.
>>>
Removed from master.
Thanks for the catch.
>>
>> Thomas,
>> I still see this applied on the master and net-next.
>> Can you tell me how do you want me to do - send a fresh series or just
>> the delta change for map file?
>
> I don't see them.
> Please update master and check again.
>
>
Once again, my bad - I thought when you mentioned "removed from master"
meant you removed the patch. But, now I realize you meant "removed the
symbols from map file".
Thanks for doing my work.
Re: [dpdk-dev] [PATCH v2] examples/multi_process/symmetric_mp: fix link check
27/03/2019 12:33, Akhil Goyal:
> link check is done for primary process for the ports
> which are given in the port mask and not the complete
> set of ports.
>
> Fixes: d3641ae86313 ("examples: update link status checks")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Akhil Goyal
> ---
> for (portid = 0; portid < port_num; portid++) {
The logic of this loop is wrong.
The port ids may be not contiguous.
Look at RTE_ETH_FOREACH_DEV* for such iteration.
> - if ((port_mask & (1 << portid)) == 0)
> + if ((mask & (1 << portid)) == 0)
> continue;
[...]
> - check_all_ports_link_status((uint8_t)num_ports, (~0x0));
> + check_all_ports_link_status(rte_eth_dev_count(), port_mask);
The function rte_eth_dev_count is deprecated.
It should be noticed when compiling.
On more comment, I think such wrong implementation is existing
in many examples:
% git grep -l 'check_all_ports_link_status(.*num'
app/test/test_pmd_perf.c
examples/link_status_interrupt/main.c
examples/load_balancer/init.c
examples/multi_process/client_server_mp/mp_server/init.c
examples/multi_process/symmetric_mp/main.c
examples/server_node_efd/server/init.c
Re: [dpdk-dev] [PATCH v4 1/2] app/testpmd: fix Tx VLAN and QinQ dependency
Hi Ferruh,
Yes, our mail server had some issue and was inserting CRLF chars. So I sent
the same v3 as v4 from gmail.
Thanks
Nithin
On Fri, Apr 5, 2019 at 5:36 PM Ferruh Yigit wrote:
> On 4/5/2019 1:04 PM, Nithin Dabilpuram wrote:
> > From: Nithin Dabilpuram
> >
> > Tx VLAN & QinQ insert enable need not depend on
> > Rx VLAN offload ETH_VLAN_EXTEND_OFFLOAD. For Tx VLAN
> > insert enable, error check is now to see if QinQ was enabled
> > but only single VLAN id is set.
> >
> > Fixes: 6a34f91690d0 ("app/testpmd: fix error message when setting Tx
> VLAN")
> > Cc: xiao.w.w...@intel.com
> >
> > Signed-off-by: Nithin Dabilpuram
> > Acked-by: Bernard Iremonger
> > ---
> > v4:
> > * Resend v3 from different mailserver to avoid
> > CRLF
> > v3:
> > * Add back error check in tx_vlan_set() to check if QinQ is
> > already enabled. Also fix headline.
> > v2:
> > * Split change into two seperate patches as suggested.
> >
>
> Hi Nithin,
>
> I just merged the v3 and about to send the mail :)
>
> What is different in v4? avoid CRLF?
>
>
[dpdk-dev] [PATCH v2] reta_query: Doc requirements on reta_conf
Clarify the fact that mask bits should be set in rte_eth_reta_query. v2: - Change documentation string as suggested by Ferruh Signed-off-by: Tom Barbette --- lib/librte_ethdev/rte_ethdev.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/librte_ethdev/rte_ethdev.h b/lib/librte_ethdev/rte_ethdev.h index e254da8b1..2a49fd2e2 100644 --- a/lib/librte_ethdev/rte_ethdev.h +++ b/lib/librte_ethdev/rte_ethdev.h @@ -2941,7 +2941,8 @@ int rte_eth_dev_rss_reta_update(uint16_t port_id, * @param port_id * The port identifier of the Ethernet device. * @param reta_conf - * RETA to query. + * RETA to query. For each requested reta entry, corresponding bit + * in mask must be set. * @param reta_size * Redirection table size. The table size can be queried by * rte_eth_dev_info_get(). -- 2.17.1
Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
On 04/04/2019 14:10, Bruce Richardson wrote: > On Thu, Apr 04, 2019 at 02:05:27PM +0100, Ray Kinsella wrote: >> >> >> On 04/04/2019 13:02, Luca Boccassi wrote: >>> On Thu, 2019-04-04 at 11:54 +0100, Bruce Richardson wrote: On Thu, Apr 04, 2019 at 10:29:19AM +0100, Burakov, Anatoly wrote: > On 03-Apr-19 4:42 PM, Ray Kinsella wrote: >> > I would be too, with certain exceptions - rte_mbuf for one. Any structures > that are used by applications cannot be made opaque, as apps do not want to > pay the cost of having to call a function every time they want to access > something from one of those structures. These the layout of these structures really must become sacrosanct. As Stephen points out, there may be room for a one more change - fool me once - to future poof the structure but after, that these structure will become very hard to change. > > Thankfully for us, we have plenty of other structures that we can work on > in the meantime that can be made private to avoid ABI breaks! :-) I suggest > we work through those first, allowing us to hone our ABI-break avoidance > skills. > > /Bruce >
[dpdk-dev] [PATCH v2 1/1] net/mlx5: fix device probing for old kernel drivers
Retrieving network interface index via Netlink fails in
case of old ib_core kernel driver installed - mlx5_nl_ifindex()
routine fails due to RDMA_NLDEV_ATTR_NDEV_INDEX attribute is not
supported by the old driver.
The patch allowing to retrieve the network interface index and
name via Netlink [1]. So, the problem depends on ib_core module
version - 4.16 supports getting ifindex via Netlink, 4.15 does not.
This error was ignored in previous versions of MLX5 PMD probing
routine. For single device ifindex was retrieved via sysfs
and link control was not lost, so problem just was not noticed.
In order to support MLX5 PMD functioning over old kernel driver
this patch adds ifindex retrieving via sysfs into probing routine.
It is worth to note this method works for master/standalone
device only.
[1] https://www.spinics.net/lists/linux-rdma/msg62948.html
Linux tree: 5b2cc79d (Leon Romanovsky 2018-03-27 20:40:49 +0300 270)
Fixes: ad74bc619504 ("net/mlx5: support multiport IB device during probing")
Signed-off-by: Viacheslav Ovsiienko
---
v2:
comments and log message update
v1:
http://patches.dpdk.org/patch/52192/
drivers/net/mlx5/mlx5.c| 36
drivers/net/mlx5/mlx5.h| 1 +
drivers/net/mlx5/mlx5_ethdev.c | 28 ++--
3 files changed, 47 insertions(+), 18 deletions(-)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index 09f4a21..b7e6234 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -1888,12 +1888,40 @@ struct mlx5_dev_spawn_data {
list[ns].ifindex = mlx5_nl_ifindex
(nl_rdma, list[ns].ibv_dev->name, 1);
if (!list[ns].ifindex) {
+ char ifname[IF_NAMESIZE];
+
/*
-* No network interface index found for the
-* specified device, it means there it is not
-* a representor/master.
+* Netlink failed, it may happen with old
+* ib_core kernel driver (before 4.16).
+* We can assume there is old driver because
+* here we are processing single ports IB
+* devices. Let's try sysfs to retrieve
+* the ifindex. The method works for
+* master device only.
*/
- continue;
+ if (nd > 1) {
+ /*
+* Multiple devices found, assume
+* representors, can not distinguish
+* master/representor and retrieve
+* ifindex via sysfs.
+*/
+ continue;
+ }
+ ret = mlx5_get_master_ifname
+ (ibv_match[i]->ibdev_path, &ifname);
+ if (!ret)
+ list[ns].ifindex =
+ if_nametoindex(ifname);
+ if (!list[ns].ifindex) {
+ /*
+* No network interface index found
+* for the specified device, it means
+* there it is neither representor
+* nor master.
+*/
+ continue;
+ }
}
ret = -1;
if (nl_route >= 0)
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index ef05d9f..c9b2251 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -364,6 +364,7 @@ struct mlx5_priv {
/* mlx5_ethdev.c */
int mlx5_get_ifname(const struct rte_eth_dev *dev, char
(*ifname)[IF_NAMESIZE]);
+int mlx5_get_master_ifname(const char *ibdev_path, char
(*ifname)[IF_NAMESIZE]);
unsigned int mlx5_ifindex(const struct rte_eth_dev *dev);
int mlx5_ifreq(const struct rte_eth_dev *dev, int req, struct ifreq *ifr);
int mlx5_get_mtu(struct rte_eth_dev *dev, uint16_t *mtu);
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 9ae9ddd..1e6fe19 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -127,21 +127,18 @@ struct ethtool_link_settings {
* @return
* 0 on success, a negative errno value otherwise and rte_errno is set.
*/
-static int
-m
[dpdk-dev] [PATCH v5 0/4] bidirect guest channel
From: Marcin Hajkowski Extend guest channel API to allow bidirectional communication. Modify power manager host and guest side to communicate in both directions. --- v5: * enhance logging v4: * [vm_power_manager] treat 0 as valid socket id * [guest_manager] use user level logs * correct code formatting v3: * fix global_fds[lcore_id] comparison to invalid value * check 0 to verify if read function actually read some data * define _NACK cmd instead of _NAK * simplify rte_power_guest_channel_receive_msg func logic v2: * send ack only if power operation return positive value * log diffent error for unexpected incoming command and error during ack/nak cmd sending Marcin Hajkowski (4): power: fix invalid socket indicator value power: extend guest channel API for reading power: process incoming confirmation cmds power: send confirmation cmd to vm guest examples/vm_power_manager/channel_monitor.c | 68 +++-- examples/vm_power_manager/guest_cli/Makefile | 1 + .../guest_cli/vm_power_cli_guest.c| 73 +++ lib/librte_power/channel_commands.h | 5 ++ lib/librte_power/guest_channel.c | 72 -- lib/librte_power/guest_channel.h | 35 + lib/librte_power/rte_power_version.map| 1 + 7 files changed, 230 insertions(+), 25 deletions(-) -- 2.17.2
[dpdk-dev] [PATCH v5 1/4] power: fix invalid socket indicator value
From: Marcin Hajkowski
Currently 0 is being used for not connected slot indication.
This is not consistent with linux doc which identifies 0 as valid
(connected) slot, thus modification was done to change it.
Fixes: cd0d5547 ("power: vm communication channels in guest")
Cc: sta...@dpdk.org
Signed-off-by: Marcin Hajkowski
Reviewed-by: Maxime Coquelin
Acked-by: Anatoly Burakov
---
lib/librte_power/guest_channel.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/librte_power/guest_channel.c b/lib/librte_power/guest_channel.c
index c17ea46b4..9cf7d2cb2 100644
--- a/lib/librte_power/guest_channel.c
+++ b/lib/librte_power/guest_channel.c
@@ -19,7 +19,7 @@
#define RTE_LOGTYPE_GUEST_CHANNEL RTE_LOGTYPE_USER1
-static int global_fds[RTE_MAX_LCORE];
+static int global_fds[RTE_MAX_LCORE] = { [0 ... RTE_MAX_LCORE-1] = -1 };
int
guest_channel_host_connect(const char *path, unsigned int lcore_id)
@@ -35,7 +35,7 @@ guest_channel_host_connect(const char *path, unsigned int
lcore_id)
return -1;
}
/* check if path is already open */
- if (global_fds[lcore_id] != 0) {
+ if (global_fds[lcore_id] != -1) {
RTE_LOG(ERR, GUEST_CHANNEL, "Channel(%u) is already open with
fd %d\n",
lcore_id, global_fds[lcore_id]);
return -1;
@@ -84,7 +84,7 @@ guest_channel_host_connect(const char *path, unsigned int
lcore_id)
return 0;
error:
close(fd);
- global_fds[lcore_id] = 0;
+ global_fds[lcore_id] = -1;
return -1;
}
@@ -100,7 +100,7 @@ guest_channel_send_msg(struct channel_packet *pkt, unsigned
int lcore_id)
return -1;
}
- if (global_fds[lcore_id] == 0) {
+ if (global_fds[lcore_id] < 0) {
RTE_LOG(ERR, GUEST_CHANNEL, "Channel is not connected\n");
return -1;
}
@@ -134,8 +134,8 @@ guest_channel_host_disconnect(unsigned int lcore_id)
lcore_id, RTE_MAX_LCORE-1);
return;
}
- if (global_fds[lcore_id] == 0)
+ if (global_fds[lcore_id] < 0)
return;
close(global_fds[lcore_id]);
- global_fds[lcore_id] = 0;
+ global_fds[lcore_id] = -1;
}
--
2.17.2
[dpdk-dev] [PATCH v5 4/4] power: send confirmation cmd to vm guest
From: Marcin Hajkowski
Use new guest channel API to send confirmation
message for received power command.
Signed-off-by: Marcin Hajkowski
---
examples/vm_power_manager/channel_monitor.c | 68 +++--
1 file changed, 62 insertions(+), 6 deletions(-)
diff --git a/examples/vm_power_manager/channel_monitor.c
b/examples/vm_power_manager/channel_monitor.c
index 7892d75de..ed580b36a 100644
--- a/examples/vm_power_manager/channel_monitor.c
+++ b/examples/vm_power_manager/channel_monitor.c
@@ -627,6 +627,41 @@ apply_policy(struct policy *pol)
apply_workload_profile(pol);
}
+static int
+write_binary_packet(struct channel_packet *pkt, struct channel_info *chan_info)
+{
+ int ret, buffer_len = sizeof(*pkt);
+ void *buffer = pkt;
+
+ if (chan_info->fd < 0) {
+ RTE_LOG(ERR, CHANNEL_MONITOR, "Channel is not connected\n");
+ return -1;
+ }
+
+ while (buffer_len > 0) {
+ ret = write(chan_info->fd, buffer, buffer_len);
+ if (ret == -1) {
+ if (errno == EINTR)
+ continue;
+ RTE_LOG(ERR, CHANNEL_MONITOR, "Write function failed
due to %s.\n",
+ strerror(errno));
+ return -1;
+ }
+ buffer = (char *)buffer + ret;
+ buffer_len -= ret;
+ }
+ return 0;
+}
+
+static int
+send_ack_for_received_cmd(struct channel_packet *pkt,
+ struct channel_info *chan_info,
+ uint32_t command)
+{
+ pkt->command = command;
+ return write_binary_packet(pkt, chan_info);
+}
+
static int
process_request(struct channel_packet *pkt, struct channel_info *chan_info)
{
@@ -650,33 +685,54 @@ process_request(struct channel_packet *pkt, struct
channel_info *chan_info)
RTE_LOG(DEBUG, CHANNEL_MONITOR, "Processing requested cmd for
cpu:%d\n",
core_num);
+ bool valid_unit = true;
+ int scale_res;
+
switch (pkt->unit) {
case(CPU_POWER_SCALE_MIN):
- power_manager_scale_core_min(core_num);
+ scale_res = power_manager_scale_core_min(core_num);
break;
case(CPU_POWER_SCALE_MAX):
- power_manager_scale_core_max(core_num);
+ scale_res = power_manager_scale_core_max(core_num);
break;
case(CPU_POWER_SCALE_DOWN):
- power_manager_scale_core_down(core_num);
+ scale_res = power_manager_scale_core_down(core_num);
break;
case(CPU_POWER_SCALE_UP):
- power_manager_scale_core_up(core_num);
+ scale_res = power_manager_scale_core_up(core_num);
break;
case(CPU_POWER_ENABLE_TURBO):
- power_manager_enable_turbo_core(core_num);
+ scale_res = power_manager_enable_turbo_core(core_num);
break;
case(CPU_POWER_DISABLE_TURBO):
- power_manager_disable_turbo_core(core_num);
+ scale_res = power_manager_disable_turbo_core(core_num);
break;
default:
+ valid_unit = false;
break;
}
+
+ if (valid_unit) {
+ ret = send_ack_for_received_cmd(pkt,
+ chan_info,
+ scale_res > 0 ?
+ CPU_POWER_CMD_ACK :
+ CPU_POWER_CMD_NACK);
+ if (ret < 0)
+ RTE_LOG(DEBUG, CHANNEL_MONITOR, "Error during
sending ack command.\n");
+ } else
+ RTE_LOG(DEBUG, CHANNEL_MONITOR, "Unexpected unit
type.\n");
+
}
if (pkt->command == PKT_POLICY) {
RTE_LOG(INFO, CHANNEL_MONITOR, "Processing policy request %s\n",
pkt->vm_name);
+ int ret = send_ack_for_received_cmd(pkt,
+ chan_info,
+ CPU_POWER_CMD_ACK);
+ if (ret < 0)
+ RTE_LOG(DEBUG, CHANNEL_MONITOR, "Error during sending
ack command.\n");
update_policy(pkt);
policy_is_set = 1;
}
--
2.17.2
[dpdk-dev] [PATCH v5 3/4] power: process incoming confirmation cmds
From: Marcin Hajkowski
Extend vm_power_guest to check incoming confirmations
of messages previously sent to host.
Signed-off-by: Marcin Hajkowski
---
examples/vm_power_manager/guest_cli/Makefile | 1 +
.../guest_cli/vm_power_cli_guest.c| 73 +++
2 files changed, 61 insertions(+), 13 deletions(-)
diff --git a/examples/vm_power_manager/guest_cli/Makefile
b/examples/vm_power_manager/guest_cli/Makefile
index e35a68d0f..67cf08193 100644
--- a/examples/vm_power_manager/guest_cli/Makefile
+++ b/examples/vm_power_manager/guest_cli/Makefile
@@ -18,6 +18,7 @@ SRCS-y := main.c vm_power_cli_guest.c parse.c
CFLAGS += -O3 -I$(RTE_SDK)/lib/librte_power/
CFLAGS += $(WERROR_FLAGS)
+CFLAGS += -DALLOW_EXPERIMENTAL_API
# workaround for a gcc bug with noreturn attribute
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
diff --git a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
index 2d9e7689a..49ed7b208 100644
--- a/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
+++ b/examples/vm_power_manager/guest_cli/vm_power_cli_guest.c
@@ -27,7 +27,7 @@
#define CHANNEL_PATH "/dev/virtio-ports/virtio.serial.port.poweragent"
-#define RTE_LOGTYPE_GUEST_CHANNEL RTE_LOGTYPE_USER1
+#define RTE_LOGTYPE_GUEST_CLI RTE_LOGTYPE_USER1
struct cmd_quit_result {
cmdline_fixed_string_t quit;
@@ -132,6 +132,32 @@ struct cmd_set_cpu_freq_result {
cmdline_fixed_string_t cmd;
};
+static int
+check_response_cmd(unsigned int lcore_id, int *result)
+{
+ struct channel_packet pkt;
+ int ret;
+
+ ret = rte_power_guest_channel_receive_msg(&pkt, lcore_id);
+ if (ret < 0)
+ return -1;
+
+ switch (pkt.command) {
+ case(CPU_POWER_CMD_ACK):
+ *result = 1;
+ break;
+ case(CPU_POWER_CMD_NACK):
+ *result = 0;
+ break;
+ default:
+ RTE_LOG(ERR, GUEST_CLI,
+ "Received invalid response from host, expecting
ACK/NACK.\n");
+ return -1;
+ }
+
+ return 0;
+}
+
static void
cmd_set_cpu_freq_parsed(void *parsed_result, struct cmdline *cl,
__attribute__((unused)) void *data)
@@ -139,20 +165,31 @@ cmd_set_cpu_freq_parsed(void *parsed_result, struct
cmdline *cl,
int ret = -1;
struct cmd_set_cpu_freq_result *res = parsed_result;
- if (!strcmp(res->cmd , "up"))
+ if (!strcmp(res->cmd, "up"))
ret = rte_power_freq_up(res->lcore_id);
- else if (!strcmp(res->cmd , "down"))
+ else if (!strcmp(res->cmd, "down"))
ret = rte_power_freq_down(res->lcore_id);
- else if (!strcmp(res->cmd , "min"))
+ else if (!strcmp(res->cmd, "min"))
ret = rte_power_freq_min(res->lcore_id);
- else if (!strcmp(res->cmd , "max"))
+ else if (!strcmp(res->cmd, "max"))
ret = rte_power_freq_max(res->lcore_id);
else if (!strcmp(res->cmd, "enable_turbo"))
ret = rte_power_freq_enable_turbo(res->lcore_id);
else if (!strcmp(res->cmd, "disable_turbo"))
ret = rte_power_freq_disable_turbo(res->lcore_id);
- if (ret != 1)
+
+ if (ret != 1) {
cmdline_printf(cl, "Error sending message: %s\n",
strerror(ret));
+ return;
+ }
+ int result;
+ ret = check_response_cmd(res->lcore_id, &result);
+ if (ret < 0) {
+ RTE_LOG(ERR, GUEST_CLI, "No confirmation for sent message
received\n");
+ } else {
+ cmdline_printf(cl, "%s received for message sent to host.\n",
+ result == 1 ? "ACK" : "NACK");
+ }
}
cmdline_parse_token_string_t cmd_set_cpu_freq =
@@ -185,16 +222,26 @@ struct cmd_send_policy_result {
};
static inline int
-send_policy(struct channel_packet *pkt)
+send_policy(struct channel_packet *pkt, struct cmdline *cl)
{
int ret;
ret = rte_power_guest_channel_send_msg(pkt, 1);
- if (ret == 0)
- return 1;
- RTE_LOG(DEBUG, POWER, "Error sending message: %s\n",
- ret > 0 ? strerror(ret) : "channel not connected");
- return -1;
+ if (ret < 0) {
+ RTE_LOG(ERR, GUEST_CLI, "Error sending message: %s\n",
+ ret > 0 ? strerror(ret) : "channel not
connected");
+ return -1;
+ }
+
+ int result;
+ ret = check_response_cmd(1, &result);
+ if (ret < 0) {
+ RTE_LOG(ERR, GUEST_CLI, "No confirmation for sent policy
received\n");
+ } else {
+ cmdline_printf(cl, "%s for sent policy received.\n",
+ result == 1 ? "ACK" : "NACK");
+ }
+ return 1;
}
static void
@@ -206,7 +253,7 @@ cmd_send_policy_parsed(void *parsed_result, struct cmdline
*cl,
[dpdk-dev] [PATCH v5 2/4] power: extend guest channel API for reading
From: Marcin Hajkowski
Added new experimental API rte_power_guest_channel_receive_msg
which gives possibility to receive messages send to guest.
Signed-off-by: Marcin Hajkowski
---
lib/librte_power/channel_commands.h| 5 +++
lib/librte_power/guest_channel.c | 60 ++
lib/librte_power/guest_channel.h | 35 +++
lib/librte_power/rte_power_version.map | 1 +
4 files changed, 101 insertions(+)
diff --git a/lib/librte_power/channel_commands.h
b/lib/librte_power/channel_commands.h
index e7b93a797..33fd53a6d 100644
--- a/lib/librte_power/channel_commands.h
+++ b/lib/librte_power/channel_commands.h
@@ -28,6 +28,11 @@ extern "C" {
#define CPU_POWER_SCALE_MIN 4
#define CPU_POWER_ENABLE_TURBO 5
#define CPU_POWER_DISABLE_TURBO 6
+
+/* Generic Power Command Response */
+#define CPU_POWER_CMD_ACK 1
+#define CPU_POWER_CMD_NACK 2
+
#define HOURS 24
#define MAX_VFS 10
diff --git a/lib/librte_power/guest_channel.c b/lib/librte_power/guest_channel.c
index 9cf7d2cb2..888423891 100644
--- a/lib/librte_power/guest_channel.c
+++ b/lib/librte_power/guest_channel.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
@@ -19,6 +20,9 @@
#define RTE_LOGTYPE_GUEST_CHANNEL RTE_LOGTYPE_USER1
+/* Timeout for incoming message in milliseconds. */
+#define TIMEOUT 10
+
static int global_fds[RTE_MAX_LCORE] = { [0 ... RTE_MAX_LCORE-1] = -1 };
int
@@ -125,6 +129,62 @@ int rte_power_guest_channel_send_msg(struct channel_packet
*pkt,
return guest_channel_send_msg(pkt, lcore_id);
}
+int power_guest_channel_read_msg(struct channel_packet *pkt,
+ unsigned int lcore_id)
+{
+ int ret;
+ struct pollfd fds;
+ void *buffer = pkt;
+ int buffer_len = sizeof(*pkt);
+
+ fds.fd = global_fds[lcore_id];
+ fds.events = POLLIN;
+
+ ret = poll(&fds, 1, TIMEOUT);
+ if (ret == 0) {
+ RTE_LOG(DEBUG, GUEST_CHANNEL, "Timeout occurred during poll
function.\n");
+ return -1;
+ } else if (ret < 0) {
+ RTE_LOG(ERR, GUEST_CHANNEL, "Error occurred during poll
function: %s\n",
+ strerror(ret));
+ return -1;
+ }
+
+ if (lcore_id >= RTE_MAX_LCORE) {
+ RTE_LOG(ERR, GUEST_CHANNEL, "Channel(%u) is out of range
0...%d\n",
+ lcore_id, RTE_MAX_LCORE-1);
+ return -1;
+ }
+
+ if (global_fds[lcore_id] < 0) {
+ RTE_LOG(ERR, GUEST_CHANNEL, "Channel is not connected\n");
+ return -1;
+ }
+
+ while (buffer_len > 0) {
+ ret = read(global_fds[lcore_id],
+ buffer, buffer_len);
+ if (ret < 0) {
+ if (errno == EINTR)
+ continue;
+ return -1;
+ }
+ if (ret == 0) {
+ RTE_LOG(ERR, GUEST_CHANNEL, "Expected more data, but
connection has been closed.\n");
+ return -1;
+ }
+ buffer = (char *)buffer + ret;
+ buffer_len -= ret;
+ }
+
+ return 0;
+}
+
+int rte_power_guest_channel_receive_msg(struct channel_packet *pkt,
+ unsigned int lcore_id)
+{
+ return power_guest_channel_read_msg(pkt, lcore_id);
+}
void
guest_channel_host_disconnect(unsigned int lcore_id)
diff --git a/lib/librte_power/guest_channel.h b/lib/librte_power/guest_channel.h
index 373d39898..7c385df39 100644
--- a/lib/librte_power/guest_channel.h
+++ b/lib/librte_power/guest_channel.h
@@ -68,6 +68,41 @@ int guest_channel_send_msg(struct channel_packet *pkt,
unsigned int lcore_id);
int rte_power_guest_channel_send_msg(struct channel_packet *pkt,
unsigned int lcore_id);
+/**
+ * Read a message contained in pkt over the Virtio-Serial
+ * from the host endpoint.
+ *
+ * @param pkt
+ * Pointer to a populated struct channel_packet
+ *
+ * @param lcore_id
+ * lcore_id.
+ *
+ * @return
+ * - 0 on success.
+ * - Negative on error.
+ */
+int power_guest_channel_read_msg(struct channel_packet *pkt,
+ unsigned int lcore_id);
+
+/**
+ * Receive a message contained in pkt over the Virtio-Serial
+ * from the host endpoint.
+ *
+ * @param pkt
+ * Pointer to a populated struct channel_packet
+ *
+ * @param lcore_id
+ * lcore_id.
+ *
+ * @return
+ * - 0 on success.
+ * - Negative on error.
+ */
+int __rte_experimental
+rte_power_guest_channel_receive_msg(struct channel_packet *pkt,
+ unsigned int lcore_id);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_power/rte_power_version.map
b/lib/librte_power/rte_power_version.map
index 042917360..69f5ea3f4 100644
--- a/lib/librte_power/rte_power_version.map
+++ b/lib/librte_power/rte_power_version.map
@@ -44,4 +44,5 @@ EXPERIMENTAL {
rt
[dpdk-dev] [PATCH v2 1/1] net/mlx5: fix sharing context destroy order
At the mlx5 device closing the shared IB context was destroyed
before cleanup routines completion. As it was found on some
setups (Netlink fails with old kernel drivers and we have to use
sysfs to retrieve interface index, this requires IB device name,
which is stored in shared context) the mlx5_nl_mac_addr_flush()
requires IB device name, and if shared context is removed it
causes the segmentation fault.
Fixes: 17e19bc4dde7 ("net/mlx5: add IB shared context alloc/free functions")
Signed-off-by: Viacheslav Ovsiienko
---
v2:
rebasing only
v1:
http://patches.dpdk.org/patch/52193/
drivers/net/mlx5/mlx5.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/mlx5/mlx5.c b/drivers/net/mlx5/mlx5.c
index b7e6234..475c93d 100644
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -593,9 +593,6 @@ struct mlx5_dev_spawn_data {
mlx5_mr_release(dev);
assert(priv->sh);
mlx5_free_shared_dr(priv);
- if (priv->sh)
- mlx5_free_shared_ibctx(priv->sh);
- priv->sh = NULL;
if (priv->rss_conf.rss_key != NULL)
rte_free(priv->rss_conf.rss_key);
if (priv->reta_idx != NULL)
@@ -608,6 +605,16 @@ struct mlx5_dev_spawn_data {
close(priv->nl_socket_rdma);
if (priv->tcf_context)
mlx5_flow_tcf_context_destroy(priv->tcf_context);
+ if (priv->sh) {
+ /*
+* Free the shared context in last turn, because the cleanup
+* routines above may use some shared fields, like
+* mlx5_nl_mac_addr_flush() uses ibdev_path for retrieveing
+* ifindex if Netlink fails.
+*/
+ mlx5_free_shared_ibctx(priv->sh);
+ priv->sh = NULL;
+ }
ret = mlx5_hrxq_ibv_verify(dev);
if (ret)
DRV_LOG(WARNING, "port %u some hash Rx queue still remain",
--
1.8.3.1
Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
On 04/04/2019 20:08, Wiles, Keith wrote: > > >> On Apr 4, 2019, at 11:56 AM, Kevin Traynor wrote: >> >> On 04/04/2019 11:54, Bruce Richardson wrote: >> > ABI breaks should be handled by the board. As for new APIs they are not so > bad and they do not need to be approved by the board just handled in the > normal way. For API changes (I guess that is ABI) needs to be handled by the > board unless we use the version control and maintain both APIs for a while. New APIs will be experimental in any case, as you say they are less of problem. I agree, if we can make a change and preserve API compatibility with versioning then everyone is happy. Changes only need be referred to the higher power in case on absolutely breakage - _but_ these need to become as rare as hens teeth. >> >>> I'm not sure I like the idea of planned ABI break releases - that strikes >>> me as a plan where we end up with the same number of ABI breaks as before, >>> just balled into one release. >>> >>> Question for Kevin, Luca and others who look at distro-packaging: is it the >>> case that each distro will only ship one version of DPDK, or is it possible >>> that if we have ABI breaks, a distro will provide two copies of DPDK >>> simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version? >>> >> >> It would probably double validation and maintenance, so it would require >> a lot of extra effort. >> >>> >>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK >>> ABI breaks, and having ABI breaks as a major event reserved only for >>> massive rework changes, such as major mbuf changes, or new memory layout or >>> similar. >>> >>> Regards, >>> /Bruce >>> >> > > Regards, > Keith >
Re: [dpdk-dev] [dpdk-techboard] DPDK ABI/API Stability
On 04/04/2019 21:13, Kevin Traynor wrote: > On 04/04/2019 20:08, Wiles, Keith wrote: >> >> >>> On Apr 4, 2019, at 11:56 AM, Kevin Traynor wrote: >>> >>> On 04/04/2019 11:54, Bruce Richardson wrote: >>> >>> My thoughts on the matter are: 1. I think we really need to do work to start hiding more of our data structures - like what Stephen's latest RFC does. This hiding should reduce the scope for ABI breaks. 2. Once done, I think we should commit to having an ABI break only in the rarest of circumstances, and only with very large justification. I want us to get to the point where DPDK releases can immediately be picked up by all linux distros and rolled out because they are ABI compatible. >>> >>> Maybe techboard should explicitly approve ABI breaks and new APIs (or >>> APIs at transition from experimental to core). Just as a way to get more >>> eyeballs and scrutiny on them. >> >> ABI breaks should be handled by the board. As for new APIs they are not so >> bad and they do not need to be approved by the board just handled in the >> normal way. For API changes (I guess that is ABI) needs to be handled by the >> board unless we use the version control and maintain both APIs for a while. >>> > > We'll only find out if they are bad when they need ABI breaks later :-) > > My point is a good way to avoid future ABI breaks is to have more > reviews on the APIs in the first place. Techboard approval might be one > way, or 3 acks or something else. +1 on this ... an API break should invite a higher level of scrutiny. > I'm not sure I like the idea of planned ABI break releases - that strikes me as a plan where we end up with the same number of ABI breaks as before, just balled into one release. Question for Kevin, Luca and others who look at distro-packaging: is it the case that each distro will only ship one version of DPDK, or is it possible that if we have ABI breaks, a distro will provide two copies of DPDK simultaneously, e.g. a 19.11 ABI version and a 20.11 ABI version? >>> >>> It would probably double validation and maintenance, so it would require >>> a lot of extra effort. >>> So, in short, I'm generally in favour of a zero-tolerance approach for DPDK ABI breaks, and having ABI breaks as a major event reserved only for massive rework changes, such as major mbuf changes, or new memory layout or similar. Regards, /Bruce >>> >> >> Regards, >> Keith >> >
Re: [dpdk-dev] [PATCH v4 1/2] app/testpmd: fix Tx VLAN and QinQ dependency
On 4/5/2019 2:10 PM, Nithin Kumar D wrote:
> Hi Ferruh,
>
> Yes, our mail server had some issue and was inserting CRLF chars. So I sent
> the same v3 as v4 from gmail.
If the content is same I will continue with v3, thanks.
>
> Thanks
> Nithin
>
> On Fri, Apr 5, 2019 at 5:36 PM Ferruh Yigit wrote:
>
>> On 4/5/2019 1:04 PM, Nithin Dabilpuram wrote:
>>> From: Nithin Dabilpuram
>>>
>>> Tx VLAN & QinQ insert enable need not depend on
>>> Rx VLAN offload ETH_VLAN_EXTEND_OFFLOAD. For Tx VLAN
>>> insert enable, error check is now to see if QinQ was enabled
>>> but only single VLAN id is set.
>>>
>>> Fixes: 6a34f91690d0 ("app/testpmd: fix error message when setting Tx
>> VLAN")
>>> Cc: xiao.w.w...@intel.com
>>>
>>> Signed-off-by: Nithin Dabilpuram
>>> Acked-by: Bernard Iremonger
>>> ---
>>> v4:
>>> * Resend v3 from different mailserver to avoid
>>> CRLF
>>> v3:
>>> * Add back error check in tx_vlan_set() to check if QinQ is
>>> already enabled. Also fix headline.
>>> v2:
>>> * Split change into two seperate patches as suggested.
>>>
>>
>> Hi Nithin,
>>
>> I just merged the v3 and about to send the mail :)
>>
>> What is different in v4? avoid CRLF?
>>
>>
Re: [dpdk-dev] [PATCH v2] doc: note validation and timeline required for stables
27/03/2019 18:25, Luca Boccassi: > On Wed, 2019-03-27 at 17:22 +, Kevin Traynor wrote: > > If a stable branch for a specific DPDK release is to proceed, > > along with needing a maintainer, there should also be commitment > > from major contributors for validation of the releases. > > > > Also, as decided in the March 27th techboard, to facilitate user > > planning, a release should be designated as a stable release > > no later than 1 month after it's initial master release. > > > > Signed-off-by: Kevin Traynor > > --- > > > > v2: add 1 month deadline to designate as stable release. > > I didn't add v1 acks, as this is something new. > > > > --- a/doc/guides/contributing/stable.rst > > +++ b/doc/guides/contributing/stable.rst > > @@ -27,5 +27,7 @@ Stable Releases > > > > Any major release of DPDK can be designated as a Stable Release if a > > -maintainer volunteers to maintain it. > > +maintainer volunteers to maintain it and there is a commitment from > > major > > +contributors to validate it before releases. If a release is to be > > designated > > +as a Stable Release, it should be done by 1 month after the master > > release. > > > > A Stable Release is used to backport fixes from an ``N`` release > > back to an > > Acked-by: Luca Boccassi Acked-by: Thomas Monjalon Applied, thanks
Re: [dpdk-dev] [PATCH v3 1/2] app/testpmd: fix Tx VLAN and QinQ dependency
On 4/5/2019 8:36 AM, Nithin Kumar Dabilpuram wrote:
> Tx VLAN & QinQ insert enable need not depend on
> Rx VLAN offload ETH_VLAN_EXTEND_OFFLOAD. For Tx VLAN
> insert enable, error check is now to see if QinQ was enabled
> but only single VLAN id is set.
>
> Fixes: 6a34f91690d0 ("app/testpmd: fix error message when setting Tx VLAN")
> Cc: xiao.w.w...@intel.com
>
> Signed-off-by: Nithin Dabilpuram
for series carried from prev version:
Acked-by: Bernard Iremonger
for series,
Reviewed-by: Ferruh Yigit
Series applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH v2] reta_query: Doc requirements on reta_conf
On 4/5/2019 2:13 PM, Tom Barbette wrote: > Clarify the fact that mask bits should be set in rte_eth_reta_query. > > v2: > - Change documentation string as suggested by Ferruh > > Signed-off-by: Tom Barbette Reviewed-by: Ferruh Yigit Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH v2] doc: update LTS section
07/02/2019 16:39, Kevin Traynor: > Update the LTS section to mention the branch, how LTS support ends > and update the currently maintained LTS branches. The current branches were updated in another patch. > Signed-off-by: Kevin Traynor > Acked-by: Aaron Conole > --- [...] > +At the end of the 2 years, a final X.11.N release will be made and at that > +point the LTS branch will no longer be maintained with no further releases. I think we could think about some extensions of the LTS period, if there are some volunteers. But for now, it is documenting the reality :) Acked-by: Thomas Monjalon Applied, thanks
[dpdk-dev] [PATCH 0/5] some small fixes
A few coverity fixes, along with a fix for one of the examples meson.build files which I caught along the way. Bruce Richardson (5): examples/vhost_scsi: fix header check for meson build examples/vhost_scsi: fix missing NULL-check for parameter net/i40e: fix dereference before NULL check in mbuf release app/testpmd: fix variable use before NULL check net/i40e: fix dereference before check when getting EEPROM app/test-pmd/cmdline.c | 4 ++-- drivers/net/i40e/i40e_ethdev.c | 5 +++-- drivers/net/i40e/i40e_rxtx.c | 4 ++-- examples/vhost_scsi/meson.build | 2 +- examples/vhost_scsi/vhost_scsi.c | 6 ++ 5 files changed, 14 insertions(+), 7 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH 2/5] examples/vhost_scsi: fix missing NULL-check for parameter
Coverity points out that there is a check in the main thread loop for the
ctrlr->bdev being NULL, but by that stage the pointer has already been
dereferenced. Therefore, for safety, before we enter the loop do an
initial check on the parameter structure.
Coverity issue: 158657
Fixes: db75c7af19bb ("examples/vhost_scsi: introduce a new sample app")
CC: sta...@dpdk.org
CC: Maxime Coquelin
CC: Tiwei Bie
CC: Zhihong Wang
Signed-off-by: Bruce Richardson
---
examples/vhost_scsi/vhost_scsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/examples/vhost_scsi/vhost_scsi.c b/examples/vhost_scsi/vhost_scsi.c
index 2908ff68b..a6465d089 100644
--- a/examples/vhost_scsi/vhost_scsi.c
+++ b/examples/vhost_scsi/vhost_scsi.c
@@ -285,6 +285,12 @@ ctrlr_worker(void *arg)
cpu_set_t cpuset;
pthread_t thread;
+ if (ctrlr == NULL || ctrlr->bdev == NULL) {
+ fprintf(stdout, "%s: Error, invalid argument passed to worker
thread\n",
+ __func__);
+ return NULL;
+ }
+
thread = pthread_self();
CPU_ZERO(&cpuset);
CPU_SET(0, &cpuset);
--
2.20.1
[dpdk-dev] [PATCH 1/5] examples/vhost_scsi: fix header check for meson build
The header check for the example app was looking for virtio_scsi.h without
the "linux/" prefix, which meant it was never getting found when it should
have been.
Fixes: 8d47a753b7cb ("examples/vhost_scsi: disable build if missing dependency")
CC: sta...@dpdk.org
CC: Maxime Coquelin
CC: Tiwei Bie
CC: Zhihong Wang
Signed-off-by: Bruce Richardson
---
examples/vhost_scsi/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/vhost_scsi/meson.build b/examples/vhost_scsi/meson.build
index ca1248023..e00a7dab1 100644
--- a/examples/vhost_scsi/meson.build
+++ b/examples/vhost_scsi/meson.build
@@ -10,7 +10,7 @@ if host_machine.system() != 'linux'
build = false
endif
-if not cc.has_header('virtio_scsi.h')
+if not cc.has_header('linux/virtio_scsi.h')
build = false
endif
--
2.20.1
[dpdk-dev] [PATCH 4/5] app/testpmd: fix variable use before NULL check
The value returned from rte_eth_dev_tx_offload_name() function is used
for string comparison before being checked for NULL. Move the NULL check
up to be done first.
Coverity issue: 279438
Fixes: c73a9071877a ("app/testpmd: add commands to test new offload API")
Cc: wei@intel.com
Cc: sta...@dpdk.org
Cc: Bernard Iremonger
Cc: Wenzhuo Lu
Signed-off-by: Bruce Richardson
---
app/test-pmd/cmdline.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index ee50e4566..2155ff241 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -18306,13 +18306,13 @@ search_tx_offload(const char *name)
single_offload = 1;
for (bit = 0; bit < sizeof(single_offload) * CHAR_BIT; bit++) {
single_name = rte_eth_dev_tx_offload_name(single_offload);
+ if (single_name == NULL)
+ break;
if (!strcasecmp(single_name, name)) {
found = 1;
break;
} else if (!strcasecmp(single_name, "UNKNOWN"))
break;
- else if (single_name == NULL)
- break;
single_offload <<= 1;
}
--
2.20.1
[dpdk-dev] [PATCH 3/5] net/i40e: fix dereference before NULL check in mbuf release
Coverity flags that the txq variable is used before it's checked for NULL.
Coverity issue: 195023
Fixes: 24853544c84c ("net/i40e: fix mbuf free in vector Tx")
Cc: qi.z.zh...@intel.com
CC: sta...@dpdk.org
Signed-off-by: Bruce Richardson
---
drivers/net/i40e/i40e_rxtx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 8f727fae6..5ce85eb52 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -2423,13 +2423,13 @@ i40e_tx_queue_release_mbufs(struct i40e_tx_queue *txq)
struct rte_eth_dev *dev;
uint16_t i;
- dev = &rte_eth_devices[txq->port_id];
-
if (!txq || !txq->sw_ring) {
PMD_DRV_LOG(DEBUG, "Pointer to rxq or sw_ring is NULL");
return;
}
+ dev = &rte_eth_devices[txq->port_id];
+
/**
* vPMD tx will not set sw_ring's mbuf to NULL after free,
* so need to free remains more carefully.
--
2.20.1
[dpdk-dev] [RFC] eal: make rte_rand() MT safe
The rte_rand() documentation left it unspecified if the rte_rand() was
multi-thread safe or not, and the implementation (based on lrand48())
was not.
This commit makes rte_rand() safe to use from any lcore thread by
using lrand48_r() and per-lcore random state structs. Besides the
obvious improvement in terms of correctness (for concurrent users),
this also much improves rte_rand() performance, since the threads no
longer shares state. For the single-threaded case, this patch causes
~10% rte_rand() performance degradation.
rte_srand() is left multi-thread unsafe, and external synchronization
is required to serialize rte_sand() calls from different lcore
threads, and a rte_srand() call with rte_rand() calls made by other
lcore threads.
The assumption is that the random number generators will be seeded
once, during startup.
Bugzilla ID: 114
Signed-off-by: Mattias Rönnblom
---
lib/librte_eal/common/include/rte_random.h | 25 -
lib/librte_eal/common/meson.build | 1 +
lib/librte_eal/common/rte_random.c | 65 ++
lib/librte_eal/freebsd/eal/Makefile| 1 +
lib/librte_eal/freebsd/eal/eal.c | 2 -
lib/librte_eal/linux/eal/Makefile | 1 +
lib/librte_eal/linux/eal/eal.c | 2 -
lib/librte_eal/rte_eal_version.map | 2 +
8 files changed, 80 insertions(+), 19 deletions(-)
create mode 100644 lib/librte_eal/common/rte_random.c
diff --git a/lib/librte_eal/common/include/rte_random.h
b/lib/librte_eal/common/include/rte_random.h
index b2ca1c209..bca85a672 100644
--- a/lib/librte_eal/common/include/rte_random.h
+++ b/lib/librte_eal/common/include/rte_random.h
@@ -16,7 +16,6 @@ extern "C" {
#endif
#include
-#include
/**
* Seed the pseudo-random generator.
@@ -25,14 +24,15 @@ extern "C" {
* value. It may need to be re-seeded by the user with a real random
* value.
*
+ * This function is not multi-thread safe in regards to other
+ * rte_srand() calls, nor is it in relation to concurrent rte_rand()
+ * calls.
+ *
* @param seedval
* The value of the seed.
*/
-static inline void
-rte_srand(uint64_t seedval)
-{
- srand48((long)seedval);
-}
+void
+rte_srand(uint64_t seedval);
/**
* Get a pseudo-random value.
@@ -41,18 +41,13 @@ rte_srand(uint64_t seedval)
* congruential algorithm and 48-bit integer arithmetic, called twice
* to generate a 64-bit value.
*
+ * If called from lcore threads, this function is thread-safe.
+ *
* @return
* A pseudo-random value between 0 and (1<<64)-1.
*/
-static inline uint64_t
-rte_rand(void)
-{
- uint64_t val;
- val = (uint64_t)lrand48();
- val <<= 32;
- val += (uint64_t)lrand48();
- return val;
-}
+uint64_t
+rte_rand(void);
#ifdef __cplusplus
}
diff --git a/lib/librte_eal/common/meson.build
b/lib/librte_eal/common/meson.build
index 0670e4102..bafd23207 100644
--- a/lib/librte_eal/common/meson.build
+++ b/lib/librte_eal/common/meson.build
@@ -35,6 +35,7 @@ common_sources = files(
'rte_keepalive.c',
'rte_malloc.c',
'rte_option.c',
+ 'rte_random.c',
'rte_reciprocal.c',
'rte_service.c'
)
diff --git a/lib/librte_eal/common/rte_random.c
b/lib/librte_eal/common/rte_random.c
new file mode 100644
index 0..9d519d03b
--- /dev/null
+++ b/lib/librte_eal/common/rte_random.c
@@ -0,0 +1,65 @@
+/* SPDX-License-Identifier: BSD-3-Clause
+ * Copyright(c) 2010-2014 Intel Corporation
+ * Copyright(c) 2019 Ericsson AB
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+
+struct rte_rand_data
+{
+ struct drand48_data data;
+} __rte_cache_aligned;
+
+static struct rte_rand_data rand_data[RTE_MAX_LCORE];
+
+void
+rte_srand(uint64_t seedval)
+{
+ unsigned i;
+
+ /* give the different lcores a different seed, to avoid a
+ situation where they generate the same sequence */
+ for (i = 0; i < RTE_MAX_LCORE; i++)
+ srand48_r((long)seedval + i, &rand_data[i].data);
+}
+
+static inline uint32_t
+__rte_rand48(struct drand48_data *data)
+{
+ long res;
+
+ lrand48_r(data, &res);
+
+ return (uint32_t)res;
+}
+
+uint64_t
+rte_rand(void)
+{
+ unsigned lcore_id;
+ struct drand48_data *data;
+ uint64_t val;
+
+ lcore_id = rte_lcore_id();
+
+ if (unlikely(lcore_id == LCORE_ID_ANY))
+ lcore_id = rte_get_master_lcore();
+
+ data = &rand_data[lcore_id].data;
+
+ val = __rte_rand48(data);
+ val <<= 32;
+ val += __rte_rand48(data);
+
+ return val;
+}
+
+RTE_INIT(rte_rand_init)
+{
+ rte_srand(rte_get_timer_cycles());
+}
diff --git a/lib/librte_eal/freebsd/eal/Makefile
b/lib/librte_eal/freebsd/eal/Makefile
index 19854ee2c..ca616c480 100644
--- a/lib/librte_eal/freebsd/eal/Makefile
+++ b/lib/librte_eal/freebsd/eal/Makefile
@@ -69,6 +69,7 @@ SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += malloc_mp.c
SRCS-$(CONFIG_RTE_EXEC_ENV_FREEBSD) += rte_keepalive.c
SRCS-$(C
[dpdk-dev] [PATCH 5/5] net/i40e: fix dereference before check when getting EEPROM
As flagged by coverity, the "info" structure is being explicitly
dereferenced before being checked later for a NULL value.
Coverity issue: 277241
Fixes: 98e60c0d43f1 ("net/i40e: add module EEPROM callbacks for i40e")
CC: sta...@dpdk.org
Cc: zijie@6wind.com
CC: Beilei Xing
CC: Qi Zhang
Signed-off-by: Bruce Richardson
---
drivers/net/i40e/i40e_ethdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index b031bf4c6..6450af016 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -11893,16 +11893,17 @@ static int i40e_get_module_eeprom(struct rte_eth_dev
*dev,
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
bool is_sfp = false;
i40e_status status;
- uint8_t *data = info->data;
+ uint8_t *data;
uint32_t value = 0;
uint32_t i;
- if (!info || !info->length || !data)
+ if (!info || !info->length || !info->data)
return -EINVAL;
if (hw->phy.link_info.module_type[0] == I40E_MODULE_TYPE_SFP)
is_sfp = true;
+ data = info->data;
for (i = 0; i < info->length; i++) {
u32 offset = i + info->offset;
u32 addr = is_sfp ? I40E_I2C_EEPROM_DEV_ADDR : 0;
--
2.20.1
Re: [dpdk-dev] [RFC] eal: make rte_rand() MT safe
On 2019-04-05 15:45, Mattias Rönnblom wrote: The rte_rand() documentation left it unspecified if the rte_rand() was multi-thread safe or not, and the implementation (based on lrand48()) was not. This commit makes rte_rand() safe to use from any lcore thread by using lrand48_r() and per-lcore random state structs. Besides the obvious improvement in terms of correctness (for concurrent users), this also much improves rte_rand() performance, since the threads no longer shares state. For the single-threaded case, this patch causes ~10% rte_rand() performance degradation. It's a little unclear to me, if lrand48_r() exists in FreeBSD or not. Could someone confirm? Another question I have is in which section of the version.map file the new symbols should go. Experimental, or 19.05? The source interface is backward compatible, but the functions are no longer inline functions in the header file, and thus needs to go somewhere to be properly exported.
[dpdk-dev] [PATCH v3] meter: replace color definitions with rte_color values
This patch implements the changes proposed in the deprecation
note[1]. Replace multiple color definitions in various places such as
rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined
in rte_meter.h.
This is simple search and replace exercise without any implementation
change.
[1] https://mails.dpdk.org/archives/dev/2019-January/123861.html
Signed-off-by: Jasvinder Singh
---
v3:
- fix commit message typo
v2:
- rebase to latest dpdk head
app/proc-info/main.c| 36 +++---
app/test-pmd/cmdline_mtr.c | 46 +++
app/test-pmd/cmdline_tm.c | 22 ++--
app/test/test_meter.c | 126 ++--
app/test/test_sched.c | 6 +-
doc/guides/rel_notes/deprecation.rst| 5 -
doc/guides/rel_notes/release_19_05.rst | 7 +-
drivers/net/softnic/rte_eth_softnic_cli.c | 14 +--
drivers/net/softnic/rte_eth_softnic_flow.c | 12 +-
drivers/net/softnic/rte_eth_softnic_meter.c | 26 ++--
drivers/net/softnic/rte_eth_softnic_tm.c| 28 ++---
examples/ip_pipeline/cli.c | 20 ++--
examples/qos_meter/main.h | 10 +-
examples/qos_meter/rte_policer.c| 4 +-
examples/qos_meter/rte_policer.h| 12 +-
examples/qos_sched/app_thread.c | 2 +-
lib/librte_ethdev/rte_mtr.c | 2 +-
lib/librte_ethdev/rte_mtr.h | 17 +--
lib/librte_ethdev/rte_mtr_driver.h | 2 +-
lib/librte_ethdev/rte_tm.h | 21 ++--
lib/librte_meter/Makefile | 2 +-
lib/librte_meter/meson.build| 2 +-
lib/librte_meter/rte_meter.h| 91 +++---
lib/librte_pipeline/rte_table_action.c | 50
lib/librte_pipeline/rte_table_action.h | 8 +-
lib/librte_sched/rte_sched.c| 12 +-
lib/librte_sched/rte_sched.h| 6 +-
27 files changed, 284 insertions(+), 305 deletions(-)
diff --git a/app/proc-info/main.c b/app/proc-info/main.c
index 3cd53416d..a89b51bb3 100644
--- a/app/proc-info/main.c
+++ b/app/proc-info/main.c
@@ -873,21 +873,21 @@ show_tm(void)
printf(" - mark support:\n");
printf("\t -- vlan dei: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_vlan_dei_supported[RTE_TM_GREEN],
- cap.mark_vlan_dei_supported[RTE_TM_YELLOW],
- cap.mark_vlan_dei_supported[RTE_TM_RED]);
+ cap.mark_vlan_dei_supported[RTE_COLOR_GREEN],
+ cap.mark_vlan_dei_supported[RTE_COLOR_YELLOW],
+ cap.mark_vlan_dei_supported[RTE_COLOR_RED]);
printf("\t -- ip ecn tcp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_ecn_tcp_supported[RTE_TM_GREEN],
- cap.mark_ip_ecn_tcp_supported[RTE_TM_YELLOW],
- cap.mark_ip_ecn_tcp_supported[RTE_TM_RED]);
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_ecn_tcp_supported[RTE_COLOR_RED]);
printf("\t -- ip ecn sctp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_ecn_sctp_supported[RTE_TM_GREEN],
- cap.mark_ip_ecn_sctp_supported[RTE_TM_YELLOW],
- cap.mark_ip_ecn_sctp_supported[RTE_TM_RED]);
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_ecn_sctp_supported[RTE_COLOR_RED]);
printf("\t -- ip dscp: GREEN (%d) YELLOW (%d) RED (%d)\n",
- cap.mark_ip_dscp_supported[RTE_TM_GREEN],
- cap.mark_ip_dscp_supported[RTE_TM_YELLOW],
- cap.mark_ip_dscp_supported[RTE_TM_RED]);
+ cap.mark_ip_dscp_supported[RTE_COLOR_GREEN],
+ cap.mark_ip_dscp_supported[RTE_COLOR_YELLOW],
+ cap.mark_ip_dscp_supported[RTE_COLOR_RED]);
printf(" - mask stats (0x%"PRIx64")"
" dynamic update (0x%"PRIx64")\n",
@@ -1004,12 +1004,12 @@ show_tm(void)
" pkts (%"PRIu64") bytes (%"PRIu64")\n"
"\t -- RED:"
" pkts (%"PRIu64") bytes (%"PRIu64")\n",
- stats.leaf.n_pkts_dropped[RTE_TM_GREEN],
- stats.leaf.n_bytes_dropped[RTE_TM_GREEN],
- stats.leaf.n_pkts_dropped[RTE_TM_YELLOW],
- stats.leaf.n_bytes_dropped[RTE_TM_YELLOW],
- stats.leaf.n_pkts_dropped[RTE_TM_RED],
- stats.leaf.n_
Re: [dpdk-dev] [PATCH v3] meter: replace color definitions with rte_color values
> -Original Message- > From: Singh, Jasvinder > Sent: Friday, April 5, 2019 2:55 PM > To: dev@dpdk.org > Cc: Dumitrescu, Cristian > Subject: [PATCH v3] meter: replace color definitions with rte_color values > > This patch implements the changes proposed in the deprecation > note[1]. Replace multiple color definitions in various places such as > rte_meter.h, rte_tm.h and rte_mtr.h with single rte_color defined > in rte_meter.h. > > This is simple search and replace exercise without any implementation > change. > > [1] https://mails.dpdk.org/archives/dev/2019-January/123861.html > > Signed-off-by: Jasvinder Singh > --- > v3: > - fix commit message typo > > v2: > - rebase to latest dpdk head > Acked-by: Cristian Dumitrescu
Re: [dpdk-dev] [PATCH] net/sfc: improve Rx free threshold default
On 4/5/2019 1:05 PM, Andrew Rybchenko wrote: > Rx refill in one bulk (which is just 8 descriptors) by default is too > aggressive and makes too many MMIO writes (Rx doorbells) if packet rate > is high. Setting default to 1/8 of Rx descriptors number shows good > performance results. Anyway it is a default value which may be > overridden by Rx configuration provided by application. > > Signed-off-by: Andrew Rybchenko Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH 3/5] net/i40e: fix dereference before NULL check in mbuf release
Acked-By: Rami Rosen
In this occasion I noticed that there is a typo in the code that appears in
the patch;
it should be "Pointer to txq" instead of "Pointer to rxq":
I would consider resending and fixing it on this occasion:
> if (!txq || !txq->sw_ring) {
> PMD_DRV_LOG(DEBUG, "Pointer to rxq or sw_ring is NULL");
>return;
>}
:
> Coverity flags that the txq variable is used before it's checked for NULL.
>
> Coverity issue: 195023
>
> Fixes: 24853544c84c ("net/i40e: fix mbuf free in vector Tx")
> Cc: qi.z.zh...@intel.com
> CC: sta...@dpdk.org
>
> Signed-off-by: Bruce Richardson
> ---
> drivers/net/i40e/i40e_rxtx.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
> index 8f727fae6..5ce85eb52 100644
> --- a/drivers/net/i40e/i40e_rxtx.c
> +++ b/drivers/net/i40e/i40e_rxtx.c
> @@ -2423,13 +2423,13 @@ i40e_tx_queue_release_mbufs(struct i40e_tx_queue
> *txq)
> struct rte_eth_dev *dev;
> uint16_t i;
>
> - dev = &rte_eth_devices[txq->port_id];
> -
> if (!txq || !txq->sw_ring) {
> PMD_DRV_LOG(DEBUG, "Pointer to rxq or sw_ring is NULL");
> return;
> }
>
> + dev = &rte_eth_devices[txq->port_id];
> +
> /**
> * vPMD tx will not set sw_ring's mbuf to NULL after free,
> * so need to free remains more carefully.
> --
> 2.20.1
>
>
Re: [dpdk-dev] [PATCH 4/5] app/testpmd: fix variable use before NULL check
Acked-by: Rami Rosen
Re: [dpdk-dev] [PATCH 5/5] net/i40e: fix dereference before check when getting EEPROM
Acked-By: Rami Rosen
Re: [dpdk-dev] [RFC] eal: make rte_rand() MT safe
On Fri, Apr 05, 2019 at 03:51:39PM +0200, Mattias Rönnblom wrote: > On 2019-04-05 15:45, Mattias Rönnblom wrote: > > The rte_rand() documentation left it unspecified if the rte_rand() was > > multi-thread safe or not, and the implementation (based on lrand48()) > > was not. > > > > This commit makes rte_rand() safe to use from any lcore thread by > > using lrand48_r() and per-lcore random state structs. Besides the > > obvious improvement in terms of correctness (for concurrent users), > > this also much improves rte_rand() performance, since the threads no > > longer shares state. For the single-threaded case, this patch causes > > ~10% rte_rand() performance degradation. > > > > It's a little unclear to me, if lrand48_r() exists in FreeBSD or not. Could > someone confirm? > Nothing shows up for me in the man pages for such a function on FreeBSD 12, so I suspect they aren't available. > Another question I have is in which section of the version.map file the new > symbols should go. Experimental, or 19.05? > I think it should be 19.05. Since the APIs have been around as inline functions for some time now, I don't see the point of having them be experimental for a time. > The source interface is backward compatible, but the functions are no longer > inline functions in the header file, and thus needs to go somewhere to be > properly exported. Regards, /Bruce
[dpdk-dev] [PATCH] power: fix non thread-safe power env modification
From: Marcin Hajkowski
Due to lack of thread safety in exisiting solution
use spinlock mechanism for atomic
modification of power environment related data.
Fixes: 445c6528b5 ("power: common interface for guest and host")
Cc: sta...@dpdk.org
Signed-off-by: Marcin Hajkowski
Acked-by: Anatoly Burakov
---
doc/guides/rel_notes/release_19_05.rst | 2 ++
lib/librte_power/rte_power.c | 30 ++
lib/librte_power/rte_power.h | 2 +-
3 files changed, 24 insertions(+), 10 deletions(-)
diff --git a/doc/guides/rel_notes/release_19_05.rst
b/doc/guides/rel_notes/release_19_05.rst
index c9d443e83..79f8ba76d 100644
--- a/doc/guides/rel_notes/release_19_05.rst
+++ b/doc/guides/rel_notes/release_19_05.rst
@@ -176,6 +176,8 @@ API Changes
``rte_vfio_container_dma_unmap`` have been extended with an option to
request mapping or un-mapping to the default vfio container fd.
+* power: ``rte_power_set_env`` and ``rte_power_unset_env`` functions
+ have been modified to be thread safe.
ABI Changes
---
diff --git a/lib/librte_power/rte_power.c b/lib/librte_power/rte_power.c
index a05fbef94..540d69be7 100644
--- a/lib/librte_power/rte_power.c
+++ b/lib/librte_power/rte_power.c
@@ -2,7 +2,7 @@
* Copyright(c) 2010-2014 Intel Corporation
*/
-#include
+#include
#include "rte_power.h"
#include "power_acpi_cpufreq.h"
@@ -12,7 +12,7 @@
enum power_management_env global_default_env = PM_ENV_NOT_SET;
-volatile uint32_t global_env_cfg_status = 0;
+static rte_spinlock_t global_env_cfg_lock = RTE_SPINLOCK_INITIALIZER;
/* function pointers */
rte_power_freqs_t rte_power_freqs = NULL;
@@ -30,9 +30,15 @@ rte_power_get_capabilities_t rte_power_get_capabilities;
int
rte_power_set_env(enum power_management_env env)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 0, 1) == 0) {
+ rte_spinlock_lock(&global_env_cfg_lock);
+
+ if (global_default_env != PM_ENV_NOT_SET) {
+ rte_spinlock_unlock(&global_env_cfg_lock);
return 0;
}
+
+ int ret = 0;
+
if (env == PM_ENV_ACPI_CPUFREQ) {
rte_power_freqs = power_acpi_cpufreq_freqs;
rte_power_get_freq = power_acpi_cpufreq_get_freq;
@@ -73,18 +79,24 @@ rte_power_set_env(enum power_management_env env)
} else {
RTE_LOG(ERR, POWER, "Invalid Power Management Environment(%d)
set\n",
env);
- rte_power_unset_env();
- return -1;
+ ret = -1;
}
- global_default_env = env;
- return 0;
+
+ if (ret == 0)
+ global_default_env = env;
+ else
+ global_default_env = PM_ENV_NOT_SET;
+
+ rte_spinlock_unlock(&global_env_cfg_lock);
+ return ret;
}
void
rte_power_unset_env(void)
{
- if (rte_atomic32_cmpset(&global_env_cfg_status, 1, 0) != 0)
- global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_lock(&global_env_cfg_lock);
+ global_default_env = PM_ENV_NOT_SET;
+ rte_spinlock_unlock(&global_env_cfg_lock);
}
enum power_management_env
diff --git a/lib/librte_power/rte_power.h b/lib/librte_power/rte_power.h
index dee7af345..47db69f33 100644
--- a/lib/librte_power/rte_power.h
+++ b/lib/librte_power/rte_power.h
@@ -26,7 +26,7 @@ enum power_management_env {PM_ENV_NOT_SET,
PM_ENV_ACPI_CPUFREQ, PM_ENV_KVM_VM,
/**
* Set the default power management implementation. If this is not called prior
* to rte_power_init(), then auto-detect of the environment will take place.
- * It is not thread safe.
+ * It is thread safe.
*
* @param env
* env. The environment in which to initialise Power Management for.
--
2.17.2
[dpdk-dev] [PATCH v2 0/5] some small fixes
A few coverity fixes, along with a fix for one of the examples meson.build files which I caught along the way. v2: include a typo fix identified by Rami Rosen. Bruce Richardson (5): examples/vhost_scsi: fix header check for meson build examples/vhost_scsi: fix missing NULL-check for parameter net/i40e: fix dereference before NULL check in mbuf release app/testpmd: fix variable use before NULL check net/i40e: fix dereference before check when getting EEPROM app/test-pmd/cmdline.c | 4 ++-- drivers/net/i40e/i40e_ethdev.c | 5 +++-- drivers/net/i40e/i40e_rxtx.c | 6 +++--- examples/vhost_scsi/meson.build | 2 +- examples/vhost_scsi/vhost_scsi.c | 6 ++ 5 files changed, 15 insertions(+), 8 deletions(-) -- 2.20.1
[dpdk-dev] [PATCH v2 1/5] examples/vhost_scsi: fix header check for meson build
The header check for the example app was looking for virtio_scsi.h without
the "linux/" prefix, which meant it was never getting found when it should
have been.
Fixes: 8d47a753b7cb ("examples/vhost_scsi: disable build if missing dependency")
CC: sta...@dpdk.org
CC: Maxime Coquelin
CC: Tiwei Bie
CC: Zhihong Wang
Signed-off-by: Bruce Richardson
---
examples/vhost_scsi/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/examples/vhost_scsi/meson.build b/examples/vhost_scsi/meson.build
index ca1248023..e00a7dab1 100644
--- a/examples/vhost_scsi/meson.build
+++ b/examples/vhost_scsi/meson.build
@@ -10,7 +10,7 @@ if host_machine.system() != 'linux'
build = false
endif
-if not cc.has_header('virtio_scsi.h')
+if not cc.has_header('linux/virtio_scsi.h')
build = false
endif
--
2.20.1
[dpdk-dev] [PATCH v2 3/5] net/i40e: fix dereference before NULL check in mbuf release
Coverity flags that the txq variable is used before it's checked for NULL.
Also fix typo in error message.
Coverity issue: 195023
Fixes: 24853544c84c ("net/i40e: fix mbuf free in vector Tx")
Cc: qi.z.zh...@intel.com
CC: sta...@dpdk.org
Signed-off-by: Bruce Richardson
Acked-By: Rami Rosen
---
V2: Fix typo or copy/paste error while fixing main issue
---
drivers/net/i40e/i40e_rxtx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/i40e/i40e_rxtx.c b/drivers/net/i40e/i40e_rxtx.c
index 8f727fae6..282e18bc1 100644
--- a/drivers/net/i40e/i40e_rxtx.c
+++ b/drivers/net/i40e/i40e_rxtx.c
@@ -2423,13 +2423,13 @@ i40e_tx_queue_release_mbufs(struct i40e_tx_queue *txq)
struct rte_eth_dev *dev;
uint16_t i;
- dev = &rte_eth_devices[txq->port_id];
-
if (!txq || !txq->sw_ring) {
- PMD_DRV_LOG(DEBUG, "Pointer to rxq or sw_ring is NULL");
+ PMD_DRV_LOG(DEBUG, "Pointer to txq or sw_ring is NULL");
return;
}
+ dev = &rte_eth_devices[txq->port_id];
+
/**
* vPMD tx will not set sw_ring's mbuf to NULL after free,
* so need to free remains more carefully.
--
2.20.1
[dpdk-dev] [PATCH v2 2/5] examples/vhost_scsi: fix missing NULL-check for parameter
Coverity points out that there is a check in the main thread loop for the
ctrlr->bdev being NULL, but by that stage the pointer has already been
dereferenced. Therefore, for safety, before we enter the loop do an
initial check on the parameter structure.
Coverity issue: 158657
Fixes: db75c7af19bb ("examples/vhost_scsi: introduce a new sample app")
CC: sta...@dpdk.org
CC: Maxime Coquelin
CC: Tiwei Bie
CC: Zhihong Wang
Signed-off-by: Bruce Richardson
---
examples/vhost_scsi/vhost_scsi.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/examples/vhost_scsi/vhost_scsi.c b/examples/vhost_scsi/vhost_scsi.c
index 2908ff68b..a6465d089 100644
--- a/examples/vhost_scsi/vhost_scsi.c
+++ b/examples/vhost_scsi/vhost_scsi.c
@@ -285,6 +285,12 @@ ctrlr_worker(void *arg)
cpu_set_t cpuset;
pthread_t thread;
+ if (ctrlr == NULL || ctrlr->bdev == NULL) {
+ fprintf(stdout, "%s: Error, invalid argument passed to worker
thread\n",
+ __func__);
+ return NULL;
+ }
+
thread = pthread_self();
CPU_ZERO(&cpuset);
CPU_SET(0, &cpuset);
--
2.20.1
[dpdk-dev] [PATCH v2 4/5] app/testpmd: fix variable use before NULL check
The value returned from rte_eth_dev_tx_offload_name() function is used
for string comparison before being checked for NULL. Move the NULL check
up to be done first.
Coverity issue: 279438
Fixes: c73a9071877a ("app/testpmd: add commands to test new offload API")
Cc: wei@intel.com
Cc: sta...@dpdk.org
Cc: Bernard Iremonger
Cc: Wenzhuo Lu
Signed-off-by: Bruce Richardson
Acked-by: Rami Rosen
---
app/test-pmd/cmdline.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index ee50e4566..2155ff241 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -18306,13 +18306,13 @@ search_tx_offload(const char *name)
single_offload = 1;
for (bit = 0; bit < sizeof(single_offload) * CHAR_BIT; bit++) {
single_name = rte_eth_dev_tx_offload_name(single_offload);
+ if (single_name == NULL)
+ break;
if (!strcasecmp(single_name, name)) {
found = 1;
break;
} else if (!strcasecmp(single_name, "UNKNOWN"))
break;
- else if (single_name == NULL)
- break;
single_offload <<= 1;
}
--
2.20.1
[dpdk-dev] [PATCH v2 5/5] net/i40e: fix dereference before check when getting EEPROM
As flagged by coverity, the "info" structure is being explicitly
dereferenced before being checked later for a NULL value.
Coverity issue: 277241
Fixes: 98e60c0d43f1 ("net/i40e: add module EEPROM callbacks for i40e")
CC: sta...@dpdk.org
Cc: zijie@6wind.com
CC: Beilei Xing
CC: Qi Zhang
Signed-off-by: Bruce Richardson
Acked-By: Rami Rosen
---
drivers/net/i40e/i40e_ethdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index b031bf4c6..6450af016 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -11893,16 +11893,17 @@ static int i40e_get_module_eeprom(struct rte_eth_dev
*dev,
struct i40e_hw *hw = I40E_DEV_PRIVATE_TO_HW(dev->data->dev_private);
bool is_sfp = false;
i40e_status status;
- uint8_t *data = info->data;
+ uint8_t *data;
uint32_t value = 0;
uint32_t i;
- if (!info || !info->length || !data)
+ if (!info || !info->length || !info->data)
return -EINVAL;
if (hw->phy.link_info.module_type[0] == I40E_MODULE_TYPE_SFP)
is_sfp = true;
+ data = info->data;
for (i = 0; i < info->length; i++) {
u32 offset = i + info->offset;
u32 addr = is_sfp ? I40E_I2C_EEPROM_DEV_ADDR : 0;
--
2.20.1
Re: [dpdk-dev] [PATCH v3 1/3] app/testpmd: fix mempool free on exit
On 4/4/2019 8:34 PM, Shahaf Shuler wrote:
> Allocated mempools were never free. it is bad practice.
+1
>
> Fixes: af75078fece3 ("first public release")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Shahaf Shuler
<...>
> @@ -835,7 +837,7 @@ setup_extmem(uint32_t nb_mbufs, uint32_t mbuf_sz, bool
> huge)
> /*
> * Configuration initialisation done once at init time.
> */
> -static void
> +static struct rte_mempool *
> mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
>unsigned int socket_id)
> {
> @@ -904,6 +906,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
> rte_exit(EXIT_FAILURE, "Invalid mempool creation
> mode\n");
> }
> }
> + return rte_mp;
>
> err:
> if (rte_mp == NULL) {
> @@ -913,6 +916,7 @@ mbuf_pool_create(uint16_t mbuf_seg_size, unsigned nb_mbuf,
> } else if (verbose_level > 0) {
> rte_mempool_dump(stdout, rte_mp);
> }
> + return NULL;
This return never reached, because a few lines above there is:
if (rte_mp == NULL) {
rte_exit(EXIT_FAILURE ...
And for above "return rte_mp;" case, it skips "if (verbose_level > 0)" checks
because of an early return.
So what do you think remove above "return rte_mp;", and move here, instead of
NULL return?
<...>
> @@ -264,6 +264,8 @@ extern struct fwd_engine ieee1588_fwd_engine;
>
> extern struct fwd_engine * fwd_engines[]; /**< NULL terminated array. */
>
> +extern struct rte_mempool *mempools[RTE_MAX_NUMA_NODES];
There is no other .c file using 'mempools', can drop the extern.
Re: [dpdk-dev] [PATCH 1/3] ethdev: add max burst size to device info
On 5/22/2018 11:17 PM, Thomas Monjalon wrote:
> 12/12/2017 11:05, Nikhil Agarwal:
>> Currently, if the rte_eth_rx_burst() function returns a value less than
>> *nb_pkts*, the application will assume that no more packets are present.
>>
>> Some of the hw queue based hardware can only support smaller burst for RX
>> and TX and thus break the expectation of the rx_burst API.
>>
>> This patch adds support to provide the maximum burst size that can be
>> supported by a given PMD. The dev_info is being memset to '0' in
>> rte_ethdev library. The value of '0' indicates that any value for burst
>> size can be supported i.e. no change for existing PMDs.
>>
>> The application can now use the lowest available max_burst_size value
>> for rte_eth_rx_burst.
>>
>> Signed-off-by: Nikhil Agarwal
>> ---
>> @@ -1047,6 +1047,7 @@ struct rte_eth_dev_info {
>> /** Configured number of rx/tx queues */
>> uint16_t nb_rx_queues; /**< Number of RX queues. */
>> uint16_t nb_tx_queues; /**< Number of TX queues. */
>> +uint16_t max_burst_size; /**< MAX burst size, 0 for no limit. */
>> };
>
> What is the status of this proposal?
>
> Recently, the preferred tuning have been added by
> "ethdev: support PMD-tuned Tx/Rx parameters"
> http://dpdk.org/commit/3be82f5cc5
Hi Nikhil, Hemant,
PMD returning preferred 'burst_size' support already added, I guess this
patchset is no more valid. I am updating this as rejected.
If something is missing or there are still some relevant pieces in this patch,
please send as a new version on top of latest head.
Thanks,
ferruh
Re: [dpdk-dev] [RFC] eal: make rte_rand() MT safe
On 2019-04-05 16:28, Bruce Richardson wrote: On Fri, Apr 05, 2019 at 03:51:39PM +0200, Mattias Rönnblom wrote: On 2019-04-05 15:45, Mattias Rönnblom wrote: The rte_rand() documentation left it unspecified if the rte_rand() was multi-thread safe or not, and the implementation (based on lrand48()) was not. This commit makes rte_rand() safe to use from any lcore thread by using lrand48_r() and per-lcore random state structs. Besides the obvious improvement in terms of correctness (for concurrent users), this also much improves rte_rand() performance, since the threads no longer shares state. For the single-threaded case, this patch causes ~10% rte_rand() performance degradation. It's a little unclear to me, if lrand48_r() exists in FreeBSD or not. Could someone confirm? Nothing shows up for me in the man pages for such a function on FreeBSD 12, so I suspect they aren't available. Could arc4random(3) be a good replacement on FreeBSD? It "can be called in almost all coding environments, including pthreads(3)" according to the man page, so assume it's MT safe.
Re: [dpdk-dev] [PATCH 1/3] ethdev: add max burst size to device info
On 4/5/2019 3:55 PM, Ferruh Yigit wrote:
> On 5/22/2018 11:17 PM, Thomas Monjalon wrote:
>> 12/12/2017 11:05, Nikhil Agarwal:
>>> Currently, if the rte_eth_rx_burst() function returns a value less than
>>> *nb_pkts*, the application will assume that no more packets are present.
>>>
>>> Some of the hw queue based hardware can only support smaller burst for RX
>>> and TX and thus break the expectation of the rx_burst API.
>>>
>>> This patch adds support to provide the maximum burst size that can be
>>> supported by a given PMD. The dev_info is being memset to '0' in
>>> rte_ethdev library. The value of '0' indicates that any value for burst
>>> size can be supported i.e. no change for existing PMDs.
>>>
>>> The application can now use the lowest available max_burst_size value
>>> for rte_eth_rx_burst.
>>>
>>> Signed-off-by: Nikhil Agarwal
>>> ---
>>> @@ -1047,6 +1047,7 @@ struct rte_eth_dev_info {
>>> /** Configured number of rx/tx queues */
>>> uint16_t nb_rx_queues; /**< Number of RX queues. */
>>> uint16_t nb_tx_queues; /**< Number of TX queues. */
>>> + uint16_t max_burst_size; /**< MAX burst size, 0 for no limit. */
>>> };
>>
>> What is the status of this proposal?
>>
>> Recently, the preferred tuning have been added by
>> "ethdev: support PMD-tuned Tx/Rx parameters"
>> http://dpdk.org/commit/3be82f5cc5
>
> Hi Nikhil, Hemant,
>
> PMD returning preferred 'burst_size' support already added, I guess this
> patchset is no more valid. I am updating this as rejected.
>
> If something is missing or there are still some relevant pieces in this patch,
> please send as a new version on top of latest head.
As reference, mentioned patches:
https://patches.dpdk.org/patch/32112/
https://patches.dpdk.org/patch/32113/
https://patches.dpdk.org/patch/32114/
Re: [dpdk-dev] [PATCH v2] doc: update contribution guideline for dependent work
On 5/24/2018 5:58 PM, Thomas Monjalon wrote: > 09/01/2018 16:44, Ferruh Yigit: >> +* If changes effect other parts of the project, update all those parts as >> well unless updating requires special knowledge. >> + For the cases where not all the effected code is updated, the submitter >> should ensure that changes don't break existing code. > > We should review it again in the technical board. > I think we should encourage asking for help to complete a patch > with community's help. self-nack This was process update patch, but it seems lack of consensus for now.
Re: [dpdk-dev] [dpdk-techboard] [PATCH v2] doc: update contribution guideline for dependent work
On 4/5/2019 4:00 PM, Ferruh Yigit wrote: > On 5/24/2018 5:58 PM, Thomas Monjalon wrote: >> 09/01/2018 16:44, Ferruh Yigit: >>> +* If changes effect other parts of the project, update all those parts as >>> well unless updating requires special knowledge. >>> + For the cases where not all the effected code is updated, the submitter >>> should ensure that changes don't break existing code. >> >> We should review it again in the technical board. >> I think we should encourage asking for help to complete a patch >> with community's help. > > self-nack > > This was process update patch, but it seems lack of consensus for now. > for reference, mentioned patch: https://patches.dpdk.org/patch/33250/
Re: [dpdk-dev] [PATCH v5] app/testpmd: add option ring-bind-lcpu to bind Q with CPU
On 1/25/2018 3:40 AM, Simon Guo wrote: > > Hi Konstantin, > On Thu, Jan 18, 2018 at 12:14:05PM +, Ananyev, Konstantin wrote: >> Hi Simon, >> >>> >>> Hi, Konstantin, >>> On Tue, Jan 16, 2018 at 12:38:35PM +, Ananyev, Konstantin wrote: > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of > wei.guo.si...@gmail.com > Sent: Saturday, January 13, 2018 2:35 AM > To: Lu, Wenzhuo > Cc: dev@dpdk.org; Thomas Monjalon ; Simon Guo > > Subject: [dpdk-dev] [PATCH v5] app/testpmd: add option ring-bind-lcpu to > bind Q with CPU > > From: Simon Guo > > Currently the rx/tx queue is allocated from the buffer pool on socket of: > - port's socket if --port-numa-config specified > - or ring-numa-config setting per port > > All the above will "bind" queue to single socket per port configuration. > But it can actually archieve better performance if one port's queue can > be spread across multiple NUMA nodes, and the rx/tx queue is allocated > per lcpu socket. > > This patch adds a new option "--ring-bind-lcpu"(no parameter). With > this, testpmd can utilize the PCI-e bus bandwidth on another NUMA > nodes. > > When --port-numa-config or --ring-numa-config option is specified, this > --ring-bind-lcpu option will be suppressed. Instead of introducing one more option - wouldn't it be better to allow user manually to define flows and assign them to particular lcores? Then the user will be able to create any FWD configuration he/she likes. Something like: lcore X add flow rxq N,Y txq M,Z Which would mean - on lcore X recv packets from port=N, rx_queue=Y, and send them through port=M,tx_queue=Z. >>> Thanks for the comment. >>> Will it be a too compliated solution for user since it will need to define >>> specifically for each lcore? We might have hundreds of lcores in current >>> modern platforms. >> >> Why for all lcores? >> Only for ones that will do packet forwarding. >> Also if configuration becomes too complex(/big) to be done manually >> user can write a script that will generate set of testpmd commands >> to achieve desired layout. > > It might not be an issue for skillful users, but it will be difficult > for others. --ring-bind-lcpu will help to simply this for them. Discussion seems not concluded for this patch, and it is sting idle for more than a year. I am marking the patch as rejected, if it is still relevant please send a new version on top of latest repo. Sorry for any inconvenience caused. For reference patch: https://patches.dpdk.org/patch/33771/
