[dpdk-dev] [PATCH] debug: update assertion macro
Update RTE_VERIFY macro to make it possible to use complex expressions
in RTE_ASSERT.
Signed-off-by: Ilya V. Matveychikov
Fixes: 148f963fb532 ("xen: core library changes")
Cc: bruce.richard...@intel.com
---
Now it's incorrect to use complex expressions for assertion
like RTE_ASSERT((1 + 2) == 3). This patch makes it possible.
lib/librte_eal/common/include/rte_debug.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/include/rte_debug.h
b/lib/librte_eal/common/include/rte_debug.h
index 79b67b3ec..fbb3bb5e5 100644
--- a/lib/librte_eal/common/include/rte_debug.h
+++ b/lib/librte_eal/common/include/rte_debug.h
@@ -86,7 +86,7 @@ void rte_dump_registers(void);
#endif
#defineRTE_VERIFY(exp) do {
\
if (unlikely(!(exp)))
\
- rte_panic("line %d\tassert \"" #exp "\" failed\n", __LINE__); \
+ rte_panic("line %d\tassert \"%s\" failed\n", __LINE__, #exp); \
} while (0)
/*
--
2.15.0
[dpdk-dev] [PATCH v3] net/i40e: determine number of queues per VF during run time
Without this patch, the number of queues per i40e VF is defined as 4
by CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4 in config/common_base.
It is fixed value determined in building time and can't be changed
during run time.
With this patch, the number of queues per i40e VF can be determinated
during run time. For example, if the PCI address of an i40e VF is
:bb.cc, with the EAL parameter -w :bb.cc,i40e-queue-num-per-vf=8
, the number of queues per VF is 8.
If there is no "i40e-queue-num-per-vf" setting in EAL parameters,
it is 4 by default as before. And if the value after the
"i40e-queue-num-per-vf" is invalid, it is set as 4 forcibly.
The valid values include 1, 2, 4, 8, 16 .
Signed-off-by: Wei Dai
---
v3: fix WARNING of coding style issues from checkpa...@dpdk.org
v2: fix WARNING of coding style issues from checkpa...@dpdk.org
---
config/common_base | 1 -
drivers/net/i40e/i40e_ethdev.c | 67 --
2 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/config/common_base b/config/common_base
index e74febe..4e20389 100644
--- a/config/common_base
+++ b/config/common_base
@@ -208,7 +208,6 @@ CONFIG_RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC=y
CONFIG_RTE_LIBRTE_I40E_INC_VECTOR=y
CONFIG_RTE_LIBRTE_I40E_16BYTE_RX_DESC=n
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF=64
-CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF=4
CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM=4
# interval up to 8160 us, aligned to 2 (or default value)
CONFIG_RTE_LIBRTE_I40E_ITR_INTERVAL=-1
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 811cc9f..b23a39e 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -3971,6 +3971,67 @@ i40e_get_cap(struct i40e_hw *hw)
return ret;
}
+static int i40e_pf_config_vf_rxq_number(struct rte_eth_dev *dev)
+{
+#define RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF 4
+#define I40E_QUEUE_NUM_PER_VF_ARG "i40e-queue-num-per-vf"
+
+ struct i40e_pf *pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+ char *s;
+ char *ps0, *ps1, *pv;
+ char *end;
+ unsigned long value;
+
+ if (!is_i40e_supported(dev))
+ return -ENOTSUP;
+
+ /* set default queue number per VF as 4 */
+ pf->vf_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
+
+ if (dev->device->devargs == NULL)
+ return 0;
+
+ s = rte_zmalloc(__func__, strlen(dev->device->devargs->args) + 1, 0);
+ if (s == NULL)
+ return -(ENOMEM);
+ strcpy(s, dev->device->devargs->args);
+
+ ps0 = s;
+ do {
+ while (isblank(*ps0))
+ ps0++;
+ pv = strchr(ps0, '=');
+ if (pv == NULL)
+ break;
+ ps1 = pv - 1;
+ *pv++ = 0;
+
+ while (isblank(*ps1))
+ *ps1-- = 0;
+
+ if (!strcmp(ps0, I40E_QUEUE_NUM_PER_VF_ARG)) {
+ errno = 0;
+ value = strtoul(pv, &end, 0);
+ if (errno != 0 || end == pv)
+ break;
+ if (value <= 16 && rte_is_power_of_2(value))
+ pf->vf_nb_qp_max = (uint16_t)value;
+ else
+ PMD_DRV_LOG(ERR, "Wrong VF queue number = %lu,"
+ " it must be power of 2 and equal or"
+ " less than 16 !", value);
+ break;
+ }
+ ps0 = strchr(pv, ',');
+ if (ps0 == NULL)
+ break;
+ ps0++;
+ } while (1);
+
+ rte_free(s);
+ return 0;
+}
+
static int
i40e_pf_parameter_init(struct rte_eth_dev *dev)
{
@@ -3983,6 +4044,9 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
PMD_INIT_LOG(ERR, "HW configuration doesn't support SRIOV");
return -EINVAL;
}
+
+ i40e_pf_config_vf_rxq_number(dev);
+
/* Add the parameter init for LFC */
pf->fc_conf.pause_time = I40E_DEFAULT_PAUSE_TIME;
pf->fc_conf.high_water[I40E_MAX_TRAFFIC_CLASS] =
I40E_DEFAULT_HIGH_WATER;
@@ -3992,7 +4056,6 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
pf->max_num_vsi = hw->func_caps.num_vsis;
pf->lan_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF;
pf->vmdq_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM;
- pf->vf_nb_qp_max = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
/* FDir queue/VSI allocation */
pf->fdir_qp_offset = 0;
@@ -4022,7 +4085,7 @@ i40e_pf_parameter_init(struct rte_eth_dev *dev)
pf->vf_qp_offset = pf->lan_qp_offset + pf->lan_nb_qps;
if (hw->func_caps.sr_iov_1_1 && pci_dev->max_vfs) {
pf->flags |= I40E_FLAG_SRIOV;
- pf->vf_nb_qps = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF;
+
Re: [dpdk-dev] [PATCH] debug: update assertion macro
> On Nov 19, 2017, at 12:18 PM, Ilya Matveychikov
> wrote:
>
> Update RTE_VERIFY macro to make it possible to use complex expressions
> in RTE_ASSERT.
>
> Signed-off-by: Ilya V. Matveychikov
>
> Fixes: 148f963fb532 ("xen: core library changes")
> Cc: bruce.richard...@intel.com
>
> ---
> Now it's incorrect to use complex expressions for assertion
> like RTE_ASSERT((1 + 2) == 3). This patch makes it possible.
Update.
Now it’s possible to have % char inside the expression, for example:
RTE_ASSERT((sizeof(some_struct) % 64) == 0)
Before the patch, “%" sign acts like a conversion specification beginning
character.
>
> lib/librte_eal/common/include/rte_debug.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/common/include/rte_debug.h
> b/lib/librte_eal/common/include/rte_debug.h
> index 79b67b3ec..fbb3bb5e5 100644
> --- a/lib/librte_eal/common/include/rte_debug.h
> +++ b/lib/librte_eal/common/include/rte_debug.h
> @@ -86,7 +86,7 @@ void rte_dump_registers(void);
> #endif
> #define RTE_VERIFY(exp) do {
> \
> if (unlikely(!(exp)))
> \
> - rte_panic("line %d\tassert \"" #exp "\" failed\n", __LINE__); \
> + rte_panic("line %d\tassert \"%s\" failed\n", __LINE__, #exp); \
> } while (0)
>
> /*
> --
> 2.15.0
Re: [dpdk-dev] [PATCH 3/4] doc: Add documents for AMD XGBE Ethernet
HI Shippen, DPDK is a BSD licensed projects unlike Linux kernel. BSD is very permissive license. I am not a lawyer, I am just afraid that including a proprietary license should not have any implications on DPDK project. We are planning to move to SPDX based license identifiers to clearly mark file license instead of putting the whole license text in the source files. 1. We will need an statement from Synopsys that they agree to include this code as "BSD-3 clause" license. 2. In near future, you will be asked to remove the Complete License statement and the files will be identified under SPDK tag for BSD-3 Clause license (or Dual BSD-3/GPLv2). Note - your copyrights will remain intact. If you don't agree to any of the above, we have to go to Gov Board for exception approval and may be to LF Legal for advice. It is going to take time. Regards, Hemant > -Original Message- > From: Shippen, Greg [mailto:greg.ship...@amd.com] > Sent: Friday, November 17, 2017 11:48 AM > To: Hemant Agrawal ; Kumar, Ravi1 > ; Thomas Monjalon > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 3/4] doc: Add documents for AMD XGBE > Ethernet > > Hemant: > > I am working the changes we are asking for on the BSD license. With > respect to the Synopsys license text. They are telling me that similar header > concerns were raised from linux .org and they were OK keeping the header if > an author signoff-off text was included. Would that be sufficient for > dpdk.org with respect to the Synopsys text? > > Greg > > -Original Message- > From: Hemant Agrawal [mailto:hemant.agra...@nxp.com] > Sent: Tuesday, November 14, 2017 6:08 PM > To: Shippen, Greg ; Kumar, Ravi1 > ; Thomas Monjalon > Cc: dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH 3/4] doc: Add documents for AMD XGBE > Ethernet > > HI Greg, > There is no restriction on sending the code to DPDK for public > review and it is up to the respective maintainers to provide comments. > > However, your patches can not be merged to DPDK and it's next trees till > the Licensing issues are sorted out. > > Regards, > Hemant > > > > -Original Message- > > From: Shippen, Greg [mailto:greg.ship...@amd.com] > > Sent: Tuesday, November 14, 2017 3:16 PM > > To: Kumar, Ravi1 ; Thomas Monjalon > > > > Cc: dev@dpdk.org; Hemant Agrawal > > Subject: RE: [dpdk-dev] [PATCH 3/4] doc: Add documents for AMD XGBE > > Ethernet > > > > Hement: > > > > I'd like to understand whether we can get dpdk.org some early code for > > review in parallel with our efforts to resolve the licensing issue. > > To answer this question, I need to understand what happens if we sent > > you v2 before the end of the month? Is the code visible to all > > dpdk.org and the public or just to internal reviewers? > > > > Greg > > > > -Original Message- > > From: Kumar, Ravi1 > > Sent: Tuesday, November 14, 2017 12:36 AM > > To: Thomas Monjalon > > Cc: dev@dpdk.org; Hemant Agrawal ; > Shippen, > > Greg > > Subject: RE: [dpdk-dev] [PATCH 3/4] doc: Add documents for AMD XGBE > > Ethernet > > > > >15/09/2017 14:26, Kumar, Ravi1: > > > > > >> >1. As a non-written convention, we are adding following statement > > >> >in the top of such dual licensed files : " This file is provided > > >> >under a dual > > >> >BSD/GPLv2 license. When using or redistributing this file, you may > > >> >do > > so under either license.". And license header as "BSD LICENSE" or "GPL .." > > >> > > > >> >2. you are using a modified version of BSD. Typical license in > > >> >DPDK files > > are BSD-3 or BSD-2. If you intend to use your specific version of BSD > > license, it will require TechBoard, Gov Board and legal approval. > > >> > > > >> >3. Additionally your BSD license is including a proprietary > > >> >license text of > > Synopsys. This will also need approval before it get included in DPDK. > > >> > > > >> >4. It seems you have copy pasted the same license text in all the files. > > >> >e.g. do you intend to keep dual license option + Synopsys text for > > >> >your > > documentation and the files, which you have created originally for > > dpdk only. > > >> > > > >> > > >> Hi Hemant, > > >> > > >> Thank you very much for the detailed explanation. We have to work > > >> with > > our Legal team on this. We will get back to you. > > > > > >Please keep us posted about your legal issues. > > >Maybe there is something we can help. > > > > > >If you target 18.02, I suggest to send a v2 before the end of the > > >month, in > > order to give us time to review what else must be reworked. > > > > > >Thanks > > > > Thanks for following up on this. > > > > The AMD legal team is working with Synopsys legal team on this as both > > the companies licenses are involved. Thats why it is taking longer > > than expected. > > We are working hard to meet the month end deadline and want to target > > 18.02. > > > > Regards, > > Ravi
[dpdk-dev] [PATCH] eal/common: better likely() and unlikely()
A warning is issued when using an argument to likely() or unlikely() builtins which is evaluated to a pointer value, as __builtin_expect() expects a 'long int' type for its first argument. With this fix a pointer value is converted to an integer with the value of 0 or 1. Signed-off-by: Aleksey Baulin --- lib/librte_eal/common/include/rte_branch_prediction.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/common/include/rte_branch_prediction.h b/lib/librte_eal/common/include/rte_branch_prediction.h index a6a56d1..2e7dc69 100644 --- a/lib/librte_eal/common/include/rte_branch_prediction.h +++ b/lib/librte_eal/common/include/rte_branch_prediction.h @@ -50,7 +50,7 @@ * */ #ifndef likely -#define likely(x) __builtin_expect((x),1) +#define likely(x) __builtin_expect(!!(x), 1) #endif /* likely */ /** @@ -64,7 +64,7 @@ * */ #ifndef unlikely -#define unlikely(x) __builtin_expect((x),0) +#define unlikely(x)__builtin_expect(!!(x), 0) #endif /* unlikely */ #endif /* _RTE_BRANCH_PREDICTION_H_ */ -- 2.7.4
[dpdk-dev] [PATCH v2] net/ixgbe: fix l3fwd start failed on PF
L3fwd start failed on PF, for tx_q check failed. That occured when the SRIOV is active and tx_q > rx_q. The tx_q is equal to nb_q_per_pool. The number of nb_q_per_pool should equeal to max number of queues supported by HW not nb_rx_q. Fixes: 27b609cbd1c6 (ethdev: move the multi-queue mode check to specific drivers) Signed-off-by: Yanglong Wu --- drivers/net/ixgbe/ixgbe_ethdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c index ae9c44421..0f0641da1 100644 --- a/drivers/net/ixgbe/ixgbe_ethdev.c +++ b/drivers/net/ixgbe/ixgbe_ethdev.c @@ -2180,7 +2180,7 @@ ixgbe_check_vf_rss_rxq_num(struct rte_eth_dev *dev, uint16_t nb_rx_q) return -EINVAL; } - RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = nb_rx_q; + RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = 128 / RTE_ETH_DEV_SRIOV(dev).active; RTE_ETH_DEV_SRIOV(dev).def_pool_q_idx = pci_dev->max_vfs * nb_rx_q; return 0; -- 2.11.0
[dpdk-dev] [PATCH v2] net/ixgbe: fix l3fwd start failed on VF
VF can't run in multi queue mode, if nb_q_per_pool was set as 1. The value of nb_q_per_pool is passed through to max_rx_q and max_tx_q in VF. So if nb_q_per_pool is equal to 1, max_rx_q and max_tx_q can't be more than 1 and VF multi queue mode will fail. Fixes: 27b609cbd1c6 (ethdev: move the multi-queue mode check to specific drivers) Signed-off-by: Yanglong Wu --- drivers/net/ixgbe/ixgbe_ethdev.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c index 14b9c5303..ae9c44421 100644 --- a/drivers/net/ixgbe/ixgbe_ethdev.c +++ b/drivers/net/ixgbe/ixgbe_ethdev.c @@ -,8 +,6 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev) case ETH_MQ_RX_NONE: /* if nothing mq mode configure, use default scheme */ dev->data->dev_conf.rxmode.mq_mode = ETH_MQ_RX_VMDQ_ONLY; - if (RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool > 1) - RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = 1; break; default: /* ETH_MQ_RX_DCB, ETH_MQ_RX_DCB_RSS or ETH_MQ_TX_DCB*/ /* SRIOV only works in VMDq enable mode */ -- 2.11.0
[dpdk-dev] [PATCH v3] net/ixgbe: fix l3fwd start failed on VF
VF can't run in multi queue mode, if nb_q_per_pool was set as 1. Nb_q_per_pool is passed through to max_rx_q and max_tx_q in VF. So if nb_q_per_pool is equal to 1, max_rx_q and max_tx_q can't be more than 1 and VF multi queue mode will fail. Fixes: 27b609cbd1c6 (ethdev: move the multi-queue mode check) Signed-off-by: Yanglong Wu --- drivers/net/ixgbe/ixgbe_ethdev.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c index 14b9c5303..ae9c44421 100644 --- a/drivers/net/ixgbe/ixgbe_ethdev.c +++ b/drivers/net/ixgbe/ixgbe_ethdev.c @@ -,8 +,6 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev) case ETH_MQ_RX_NONE: /* if nothing mq mode configure, use default scheme */ dev->data->dev_conf.rxmode.mq_mode = ETH_MQ_RX_VMDQ_ONLY; - if (RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool > 1) - RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = 1; break; default: /* ETH_MQ_RX_DCB, ETH_MQ_RX_DCB_RSS or ETH_MQ_TX_DCB*/ /* SRIOV only works in VMDq enable mode */ -- 2.11.0
[dpdk-dev] [PATCH v3] net/ixgbe: fix l3fwd start failed on PF
L3fwd start failed on PF, for tx_q check failed. That occurred when the SRIOV is active and tx_q > rx_q. The tx_q is equal to nb_q_per_pool. The number of nb_q_per_pool should equeal to max number of queues supported by HW not nb_rx_q. Fixes: 27b609cbd1c6 (ethdev: move the multi-queue mode check to specific drivers) Signed-off-by: Yanglong Wu --- drivers/net/ixgbe/ixgbe_ethdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c index ae9c44421..0f0641da1 100644 --- a/drivers/net/ixgbe/ixgbe_ethdev.c +++ b/drivers/net/ixgbe/ixgbe_ethdev.c @@ -2180,7 +2180,7 @@ ixgbe_check_vf_rss_rxq_num(struct rte_eth_dev *dev, uint16_t nb_rx_q) return -EINVAL; } - RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = nb_rx_q; + RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = 128/RTE_ETH_DEV_SRIOV(dev).active; RTE_ETH_DEV_SRIOV(dev).def_pool_q_idx = pci_dev->max_vfs * nb_rx_q; return 0; -- 2.11.0
Re: [dpdk-dev] [PATCH v3] net/ixgbe: fix l3fwd start failed on VF
Hi Yanglong, You should write something after SoB, which makes reviewer easier to know What changes are since last version. Thanks Zhiyong > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu > Sent: Monday, November 20, 2017 10:26 AM > To: dev@dpdk.org > Cc: Wu, Yanglong > Subject: [dpdk-dev] [PATCH v3] net/ixgbe: fix l3fwd start failed on VF > > VF can't run in multi queue mode, if nb_q_per_pool was set as 1. > Nb_q_per_pool is passed through to max_rx_q and max_tx_q in VF. > So if nb_q_per_pool is equal to 1, max_rx_q and max_tx_q can't be more than 1 > and VF multi queue mode will fail. > > Fixes: 27b609cbd1c6 (ethdev: move the multi-queue mode check) > > Signed-off-by: Yanglong Wu > --- Changes in V3:
[dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on PF
L3fwd start failed on PF, for tx_q check failed. That occurred when the SRIOV is active and tx_q > rx_q. The tx_q is equal to nb_q_per_pool. The number of nb_q_per_pool should equeal to max number of queues supported by HW not nb_rx_q. Fixes: 27b609cbd1c6 (ethdev: move the multi-queue mode check to specific drivers) Signed-off-by: Yanglong Wu --- drivers/net/ixgbe/ixgbe_ethdev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c index ae9c44421..0f0641da1 100644 --- a/drivers/net/ixgbe/ixgbe_ethdev.c +++ b/drivers/net/ixgbe/ixgbe_ethdev.c @@ -2180,7 +2180,7 @@ ixgbe_check_vf_rss_rxq_num(struct rte_eth_dev *dev, uint16_t nb_rx_q) return -EINVAL; } - RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = nb_rx_q; + RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool = 128 / RTE_ETH_DEV_SRIOV(dev).active; RTE_ETH_DEV_SRIOV(dev).def_pool_q_idx = pci_dev->max_vfs * nb_rx_q; return 0; -- 2.11.0
[dpdk-dev] [PATCH] net/ixgbe: fix VF RX hang
The datasheet says, if using MSI-X mode, the PBA support
bit of the GPIE register must be set to 1.
DPDK uses polling mode, we cannot hit this issue in the
scenario DPDK PF + DPDK VF. If we use DPDK PF + kernel VF,
as the kernel driver uses interrpt mode, VF may hit RX hang
after running hours.
Fixes: 00e30184daa0 ("ixgbe: add PF support")
Cc: sta...@dpdk.org
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/ixgbe_pf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/ixgbe_pf.c b/drivers/net/ixgbe/ixgbe_pf.c
index 676e92c..0114694 100644
--- a/drivers/net/ixgbe/ixgbe_pf.c
+++ b/drivers/net/ixgbe/ixgbe_pf.c
@@ -273,7 +273,7 @@ int ixgbe_pf_host_configure(struct rte_eth_dev *eth_dev)
gpie = IXGBE_READ_REG(hw, IXGBE_GPIE);
gpie &= ~IXGBE_GPIE_VTMODE_MASK;
- gpie |= IXGBE_GPIE_MSIX_MODE;
+ gpie |= IXGBE_GPIE_MSIX_MODE | IXGBE_GPIE_PBA_SUPPORT;
switch (RTE_ETH_DEV_SRIOV(eth_dev).active) {
case ETH_64_POOLS:
--
1.9.3
[dpdk-dev] [PATCH] net/i40e: i40e support mac loopback
According to loopback mode, setup loopback link or not.
If loopback link is setted, packets will be sent to
rx_q from tx_q directly.Loopback mode can be used to
support testing task.
Signed-off-by: Yanglong Wu
---
drivers/net/i40e/base/i40e_adminq_cmd.h | 1 +
drivers/net/i40e/i40e_ethdev.c | 12 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/net/i40e/base/i40e_adminq_cmd.h
b/drivers/net/i40e/base/i40e_adminq_cmd.h
index c36da2a32..8171f877b 100644
--- a/drivers/net/i40e/base/i40e_adminq_cmd.h
+++ b/drivers/net/i40e/base/i40e_adminq_cmd.h
@@ -2128,6 +2128,7 @@ I40E_CHECK_CMD_LENGTH(i40e_aqc_an_advt_reg);
/* Set Loopback mode (0x0618) */
struct i40e_aqc_set_lb_mode {
__le16 lb_mode;
+#define I40E_AQ_LB_MODE_NONE 0x0
#define I40E_AQ_LB_PHY_LOCAL 0x01
#define I40E_AQ_LB_PHY_REMOTE 0x02
#define I40E_AQ_LB_MAC_LOCAL 0x04
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index f40c463aa..2e6aa9d0d 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -2048,6 +2048,17 @@ i40e_dev_start(struct rte_eth_dev *dev)
}
}
+ /* Enable mac loopback mode */
+ if (hw->mac.type == I40E_MAC_XL710 &&
+ (dev->data->dev_conf.lpbk_mode == I40E_AQ_LB_MODE_NONE ||
+ dev->data->dev_conf.lpbk_mode == I40E_AQ_LB_PHY_LOCAL)) {
+ ret = i40e_aq_set_lb_modes(hw,
+ dev->data->dev_conf.lpbk_mode, NULL);
+ if (ret != I40E_SUCCESS) {
+ PMD_DRV_LOG(INFO, "fail to set loopback link");
+ goto err_up;
+ }
+ }
+
/* Apply link configure */
if (dev->data->dev_conf.link_speeds & ~(ETH_LINK_SPEED_100M |
ETH_LINK_SPEED_1G | ETH_LINK_SPEED_10G |
--
2.11.0
Re: [dpdk-dev] [RFC v1] doc compression API for DPDK
Ping. Awaiting feedback/comments. Thanks Shally > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Verma, Shally > Sent: 31 October 2017 17:09 > To: dev@dpdk.org; Trahe, Fiona ; Athreya, > Narayana Prasad ; Challa, Mahipal > > Subject: [dpdk-dev] [RFC v1] doc compression API for DPDK > > [This sender failed our fraud detection checks and may not be who they > appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] > > HI Fiona > > This is an RFC document to brief our understanding and requirements on > compression API proposal in DPDK. It is based on "[RFC] Compression API in > DPDK http://dpdk.org/ml/archives/dev/2017-October/079377.html";. > Intention of this document is to align on concepts built into compression API, > its usage and identify further requirements. > > Going further it could be a base to Compression Module Programmer Guide. > > Current scope is limited to > - definition of the terminology which makes up foundation of compression > API > - typical API flow expected to use by applications > > Overview > > A. Notion of a session in compression API > == > A Session is per device logical entity which is setup with chained-xforms to > be > performed on burst operations where individual entry contains operation > type (decompress/compress) and related parameter. > A typical Session parameter includes: > - compress / decompress > - dev_id > - compression algorithm and other related parameters > - mempool - for use by session for runtime requirement > - and any other associated private data maintained by session > > Application can setup multiple sessions on a device as dictated by > dev_info.nb_sessions or nb_session_per_qp. > > B. Notion of burst operations in compression API > === > struct rte_comp_op defines compression/decompression operational > parameter and makes up one single element of burst. This is both an > input/output parameter. > PMD gets source, destination and checksum information at input and > updated it with bytes consumed and produced at output. > Once enqueued for processing, rte_comp_op *cannot be reused* until its > status is set to RTE_COMP_OP_FAILURE or > RTE_COMP_OP_STATUS_SUCCESS. > > C. Session and rte_comp_op > === > Every operation in a burst is tied to a Session. More to cover on this under > Stateless Vs Stateful section. > > D. Stateless Vs Stateful > === > Compression API provide RTE_COMP_FF_STATEFUL feature flag for PMD to > reflect its support for Stateful operation. > > D.1 Compression API Stateless operation > -- > A Stateless operation means all enqueued packets are independent of each > other i.e. Each packet has > - Their flush value is set to RTE_FLUSH_FULL or RTE_FLUSH_FINAL > (required only on compression side), > - All-of the required input and sufficient large buffer size to > store > output i.e. OUT_OF_SPACE can never occur (required during both > compression and decompression) > > In such case, PMD initiates stateless processing and releases acquired > resources after processing of current operation is complete i.e. full input > consumed and full output written. > Application can attach same or different session to each packet and can make > consecutive enque_burst() calls i.e. Following is relevant usage: > > enqueued = rte_comp_enque_burst (dev_id, qp_id, ops1, nb_ops); > enqueued = rte_comp_enque_burst(dev_id, qp_id, ops2, nb_ops); > enqueued = rte_comp_enque_burst(dev_id, qp_id, ops3, nb_ops); > > *Note – Every call has different ops array i.e. same rte_comp_op array > *cannot be reused* to queue next batch of data until previous ones are > completely processed. > > Also if multiple threads calls enqueue_burst() on same queue pair then it’s > application onus to use proper locking mechanism to ensure serialized > enqueuing of operations. > > Please note any time output buffer ran out of space during write then > operation will turn “Stateful”. See more on Stateful under respective > section. > > Typical API(flow-wise) to setup for stateless operation: > 1. rte_comp_session *sess = rte_comp_session_create(rte_mempool > *pool); > 2. rte_comp_session_init (int dev_id, rte_comp_session *sess, > rte_comp_xform *xform, rte_mempool *sess_pool); > 3. rte_comp_op_pool_create(rte_mempool ..) > 4. rte_comp_op_bulk_alloc (struct rte_mempool *mempool, struct > rte_comp_op **ops, uint16_t nb_ops); > 5. for every rte_comp_op in ops[], > 5.1 rte_comp_op_attach_session(rte_comp_op *op, rte_comp_session > *sess); > 5.2 set up with src/dst buffer > 6. enq = rte_compdev_enqueue_burst(uint8_t dev_id, uint16_t qp_id, > struct rte_comp_op **ops, uint16_t nb_ops); > 7. dqu = rte_compdev_dequeue_burst(dev_id, qp_id, ops, enq); > 8. repeat 7 while (dqu < enq) // Wait till all of enqueued are dequeue
Re: [dpdk-dev] [RFC] Compression API in DPDK
Hi Fiona Could you give some expected timeframe for next comp API spec patch? Thanks Shally > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Verma, Shally > Sent: 10 November 2017 17:35 > To: Trahe, Fiona ; dev@dpdk.org > Cc: Athreya, Narayana Prasad ; > Challa, Mahipal > Subject: Re: [dpdk-dev] [RFC] Compression API in DPDK > > [This sender failed our fraud detection checks and may not be who they > appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] > > > -Original Message- > > From: Trahe, Fiona [mailto:fiona.tr...@intel.com] > > Sent: 07 November 2017 16:54 > > To: Verma, Shally ; dev@dpdk.org > > Cc: Athreya, Narayana Prasad ; > > Challa, Mahipal ; Trahe, Fiona > > > > Subject: RE: [dpdk-dev] [RFC] Compression API in DPDK > > > > Hi Shally, > > > > ///snip/// > > > [Shally] Ok. Then, just to confirm my understanding here. You mean PMD > > can figure out amount of > > > available space in dst mbuf by calling rte_pktmbuf_data_len() on each of > its > > segment? > > [Fiona] exactly. > > > > ///snip/// > > > > > > > > + * This indicates the buffer size and should be > > > > > > > > + * set a little larger than the expected max source buffer > size. > > > > > > > > + * if the output of static compression doesn't fit in the > > > > > > > > + * intermediate buffer dynamic compression may not be > > possible, > > > > > > > > + * in this case the accelerator may revert back to static > > > > compression. > > > [Shally] > > > > + * in this case the accelerator may revert back to > > > static > > compression.> > > > > + */ > > > Can you elaborate more on this? This looks to me as decision made during > > enqueue_burst() processing. > > > If yes and If application has chosen specific Huffman code i.e. > > RTE_COMP_DYNAMIC or > > > RTE_COMP_FIXED in rte_comp_compress_xform, then how this would > > work? > > [Fiona] yes, it would have to revert back on the enqueue. The compressed > > data would still conform to deflate standard, so any decompressor would > be > > able to inflate it. The ratio would not be as good as hoped for but it would > be > > the best the compression engine could do with the resources it has. > > > [Shally] Ok. However, I'm not sure how to use Intermediate bufs here as it is > not requirement for us for this purpose. > So, it looks like It is very device specific requirement where some may not > need it. So, I would suggest that API should propose a way to indicate if > it's a > requirement for specific device so that app can input it at config time. May > be > feature flag or capability. > > Thanks > Shally > > > ///snip/// > > > [Shally] Sure. So just to align here. Except few questions posted above on > > this RFC (such as Dynamic Vs > > > Static or dst mbuf parsing), following (and any other) will further be > > covered as part of 'RFC doc' > > > discussion > > > - Hash support > > > - RTE_COMPDEV_FF_MULTI_PKT_CHECKSUM > > [Fiona] Agreed.
[dpdk-dev] [PATCH] vhost user: unlink sockaddr when poll sched fails
From: Jan Wickbom
Issue:
Vhost user socket addresses left in /var/run/openvswitch.
This will lead to failure to add vhost user ports with names that
already exist in this directory.
When there is a failure to add a vhost user socket file descriptor to
the file descriptor set using fdset_add() in
rte_vhost_driver_register() the address bound to the socket is not
released.
Solution:
Add unlink of the file path corresponding to the socket address.
Signed-off-by: Jan Wickbom
Signed-off-by: Gellert Babel
---
lib/librte_vhost/socket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c
index 41aa3f9..eb9dae2 100644
--- a/lib/librte_vhost/socket.c
+++ b/lib/librte_vhost/socket.c
@@ -352,6 +352,7 @@ struct vhost_user {
err:
close(fd);
+ unlink(path);
return -1;
}
--
1.9.1
[dpdk-dev] [PATCH] net/bonding: fix bond 8023ad mode enable using wrong index
Hi all, In the function bond_mode_8023ad_enable(), the var i is to used to as the second parameter to pass the slave dev's dpdk port id to the function bond_mode_8023ad_activate_slave(). I think this variable is only a index for array internals->active_slaves. So its need to be fixed and change i to internals->active_slaves[i]. [Patch] net/bonding: fix bond 8023ad mode enable using wrong index. Signed-off-by: Lilijun diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c b/drivers/net/bonding/rte_eth_bond_8023ad.c index a2313b3..20a08dc 100644 --- a/drivers/net/bonding/rte_eth_bond_8023ad.c +++ b/drivers/net/bonding/rte_eth_bond_8023ad.c @@ -1159,7 +1159,7 @@ uint8_t i; for (i = 0; i < internals->active_slave_count; i++) - bond_mode_8023ad_activate_slave(bond_dev, i); + bond_mode_8023ad_activate_slave(bond_dev, internals->active_slaves[i]); return 0; }
Re: [dpdk-dev] [PATCH v2 4/6] net/representor: Implement port representor PMD
On 11/17/2017 6:42 AM, Mohammad Abdul Awal wrote: > V2: > Update rte_bus_vdev.h header file instead of rte_vdev.h file. > > V1: > Representor PMD is a virtual PMD which provides a logical representation > in DPDK for ports of a multi port device. This supports configuration, > management, and monitoring of VFs of a physical function bound to a > userspace control plane application. Why we need this PMD? It looks like this has been used only for parameter parsing. Can it be possible to rte_representor_broker_init() will allocate ethdevs and fill brokers with this information? > > Change-Id: I5a7834bbc05bc9037e3218f69f10c1bd1e787236 > Signed-off-by: Mohammad Abdul Awal > Signed-off-by: Remy Horton > Signed-off-by: Declan Doherty <...>
Re: [dpdk-dev] [PATCH v2 5/6] net/i40e: Enable port representor PMD and broker for fortville PMD driver
On 11/17/2017 6:42 AM, Mohammad Abdul Awal wrote:
> +struct eth_dev_ops i40e_representor_dev_ops = {
> + .link_update = i40e_representor_link_update,
> + .dev_infos_get= i40e_representor_dev_infos_get,
> +
> + .stats_get= i40e_representor_stats_get,
> + .stats_reset = i40e_representor_stats_reset,
> +
> + .promiscuous_enable = i40e_representor_promiscuous_enable,
> + .promiscuous_disable = i40e_representor_promiscuous_disable,
> +
> + .allmulticast_enable = i40e_representor_allmulticast_enable,
> + .allmulticast_disable = i40e_representor_allmulticast_disable,
> +
> + .mac_addr_remove = i40e_representor_mac_addr_remove,
> + .mac_addr_set = i40e_representor_mac_addr_set,
> +
> + .vlan_filter_set = i40e_representor_vlan_filter_set,
> + .vlan_offload_set = i40e_representor_vlan_offload_set,
> + .vlan_strip_queue_set = i40e_representor_vlan_strip_queue_set,
> + .vlan_pvid_set= i40e_representor_vlan_pvid_set
> +};
Will we able to get rid of VF control related PMD specific APIs when port
representation enabled?
