* Re: [PATCH 1/2] net/i40e: fix link status change interrupt
From: Ferruh Yigit @ 2016-10-19 10:56 UTC (permalink / raw)
To: Qiming Yang, dev; +Cc: Jingjing Wu
In-Reply-To: <1476338840-50003-1-git-send-email-qiming.yang@intel.com>
Hi Qiming,
On 10/13/2016 7:07 AM, Qiming Yang wrote:
> Previously, link status interrupt in i40e is achieved by checking
> LINK_STAT_CHANGE_MASK in PFINT_ICR0 register which is provided only
> for diagnostic use. Instead, drivers need to get the link status
> change notification by using LSE (Link Status Event).
>
> This patch enables LSE and calls LSC callback when the event is
> received. This patch also removes the processing on
> LINK_STAT_CHANGE_MASK.
>
> Fixes: 5c9222058df7 ("i40e: move to drivers/net/")
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
CC: Jingjing Wu <jingjing.wu@intel.com>
Can you please add maintainer(s) to CC when sending a patch, mail
traffic in dpdk.org is keep increasing and it is hard to follow. Adding
maintainer to the CC helps a lot to the maintainer.
I guess everybody knows, but just as a reminder, maintainer list kept in
file: http://dpdk.org/browse/dpdk/tree/MAINTAINERS
Thanks,
ferruh
^ permalink raw reply
* Re: [PATCH] net/ixgbe: fix vlan insert parameter type and its use
From: Iremonger, Bernard @ 2016-10-19 10:55 UTC (permalink / raw)
To: Lu, Wenzhuo, E. Scott Daniels, Zhang, Helin; +Cc: dev@dpdk.org, az5157@att.com
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093933CE36@shsmsx102.ccr.corp.intel.com>
Hi Wenzhuo, Scott,
<snip>
> > Subject: [dpdk-dev] [PATCH] net/ixgbe: fix vlan insert parameter type
> > and its use
> >
> > The final parameter to rte_pmd_ixgbe_set_vf_vlan_insert is uint8_t and
> > treated as a binary flag when it needs to be a uint16_t and treated as
> > a VLAN id. The data sheet (sect 8.2.3.27.13) describes the right most
> > 16 bits as the VLAN id that is to be inserted; the
> > 16.11 code is accepting only a 1 or 0 thus effectively only allowing
> > the VLAN id 1 to be inserted (0 disables the insertion setting).
> >
> > This patch changes the final parm name to represent the data that is
> > being accepted (vlan_id), changes the type to permit all valid VLAN
> > ids, and validates the parameter based on the range of 0 to 4095.
> > Corresponding changes to prototype and documentation in the .h file.
> >
> > Fixes: 49e248223e9f71 ("net/ixgbe: add API for VF management")
> >
> > Signed-off-by: E. Scott Daniels <daniels@research.att.com>
> > ---
> > drivers/net/ixgbe/ixgbe_ethdev.c | 8 ++++----
> > drivers/net/ixgbe/rte_pmd_ixgbe.h | 9 +++++----
> > 2 files changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 4ca5747..316af73 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -4727,7 +4727,7 @@ rte_pmd_ixgbe_set_vf_mac_anti_spoof(uint8_t
> > port, uint16_t vf, uint8_t on) }
> >
> > int
> > -rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf, uint8_t
> > on)
> > +rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf, uint16_t
> > +vlan_id)
> > {
> > struct ixgbe_hw *hw;
> > uint32_t ctrl;
> > @@ -4742,13 +4742,13 @@ rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t
> port,
> > uint16_t vf, uint8_t on)
> > if (vf >= dev_info.max_vfs)
> > return -EINVAL;
> >
> > - if (on > 1)
> > + if (vlan_id > 4095)
> > return -EINVAL;
> >
> > hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > ctrl = IXGBE_READ_REG(hw, IXGBE_VMVIR(vf));
> > - if (on) {
> > - ctrl = on;
> > + if (vlan_id) {
> > + ctrl = vlan_id;
> I believe this patch is a good idea of an enhancement. But you cannot
> leverage the existing code like this.
> The register IXGBE_VMVIR is only for enable/disable. We cannot write the
> VLAN ID into it.
> If you want to merge the 2 things, enabling/disabling and setting VLAN ID
> together. I think we need a totally new implementation. So NACK.
Reading the 82599 data sheet (sect 8.2.3.27.13), the change from Scott is correct.
The NACK is not correct.
However changing the API means that where it is called needs to be changed too.
It is called at present from app/testpmd/cmdline.c line 4731.
> > ctrl |= IXGBE_VMVIR_VLANA_DEFAULT;
> > } else {
> > ctrl = 0;
> > diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.h
> > b/drivers/net/ixgbe/rte_pmd_ixgbe.h
> > index 2fdf530..c2fb826 100644
> > --- a/drivers/net/ixgbe/rte_pmd_ixgbe.h
> > +++ b/drivers/net/ixgbe/rte_pmd_ixgbe.h
> > @@ -99,16 +99,17 @@ int rte_pmd_ixgbe_set_vf_mac_anti_spoof(uint8_t
> > port, uint16_t vf, uint8_t on);
> > * The port identifier of the Ethernet device.
> > * @param vf
> > * ID specifying VF.
> > - * @param on
> > - * 1 - Enable VF's vlan insert.
> > - * 0 - Disable VF's vlan insert
> > + * @param vlan_id
> > + * 0 - Disable VF's vlan insert.
> > + * n - Enable; n is inserted as the vlan id.
> > *
> > * @return
> > * - (0) if successful.
> > * - (-ENODEV) if *port* invalid.
> > * - (-EINVAL) if bad parameter.
> > */
> > -int rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf,
> > uint8_t on);
> > +int rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf,
> > + uint16_t vlan_id);
> >
> > /**
> > * Enable/Disable tx loopback
> > --
> > 1.9.1
Regards,
Bernard.
^ permalink raw reply
* [PATCH v5 2/2] app/test_pmd: fix DCB configuration
From: Bernard Iremonger @ 2016-10-19 10:21 UTC (permalink / raw)
To: dev, rahul.r.shah, wenzhuo.lu; +Cc: Bernard Iremonger
In-Reply-To: <1476723683-9601-1-git-send-email-bernard.iremonger@intel.com>
when dcb mode is DCB_VT_ENABLED set nb_rxq and nb_txq to 1.
Fixes: 2a977b891f99 ("app/testpmd: fix DCB configuration")
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
app/test-pmd/testpmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 6185be6..ee567c3 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -2002,8 +2002,8 @@ init_port_dcb_config(portid_t pid,
* and has the same number of rxq and txq in dcb mode
*/
if (dcb_mode == DCB_VT_ENABLED) {
- nb_rxq = rte_port->dev_info.max_rx_queues;
- nb_txq = rte_port->dev_info.max_tx_queues;
+ nb_rxq = 1;
+ nb_txq = 1;
} else {
/*if vt is disabled, use all pf queues */
if (rte_port->dev_info.vmdq_pool_base == 0) {
--
2.10.1
^ permalink raw reply related
* [PATCH v5 1/2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
From: Bernard Iremonger @ 2016-10-19 10:21 UTC (permalink / raw)
To: dev, rahul.r.shah, wenzhuo.lu; +Cc: Bernard Iremonger
In-Reply-To: <1476723683-9601-1-git-send-email-bernard.iremonger@intel.com>
Modify ixgbe_check_mq_mode function,
when SRIOV is enabled, enable mq_mode
ETH_MQ_RX_VMDQ_DCB and ETH_MQ_TX_VMDQ_DCB.
Modify ixgbe_dcb_tx_hw_config function,
replace the struct ixgbe_hw parameter with a
struct rte_eth_dev parameter and handle SRIOV enabled.
Modify ixgbe_dev_mq_rx_configure function,
when SRIOV is enabled, enable mq_mode ETH_MQ_RX_VMDQ_DCB.
Modify ixgbe_configure_dcb function,
drop check on dev->data->nb_rx_queues.
Signed-off-by: Rahul R Shah <rahul.r.shah@intel.com>
Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
---
drivers/net/ixgbe/ixgbe_ethdev.c | 11 ++++++-----
drivers/net/ixgbe/ixgbe_rxtx.c | 35 ++++++++++++++++++++++-------------
2 files changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 4ca5747..4d5ce83 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1977,6 +1977,9 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
/* check multi-queue mode */
switch (dev_conf->rxmode.mq_mode) {
case ETH_MQ_RX_VMDQ_DCB:
+ PMD_INIT_LOG(INFO, "ETH_MQ_RX_VMDQ_DCB mode supported in SRIOV");
+ dev->data->dev_conf.rxmode.mq_mode = ETH_MQ_RX_VMDQ_DCB;
+ break;
case ETH_MQ_RX_VMDQ_DCB_RSS:
/* DCB/RSS VMDQ in SRIOV mode, not implement yet */
PMD_INIT_LOG(ERR, "SRIOV active,"
@@ -2012,11 +2015,9 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
switch (dev_conf->txmode.mq_mode) {
case ETH_MQ_TX_VMDQ_DCB:
- /* DCB VMDQ in SRIOV mode, not implement yet */
- PMD_INIT_LOG(ERR, "SRIOV is active,"
- " unsupported VMDQ mq_mode tx %d.",
- dev_conf->txmode.mq_mode);
- return -EINVAL;
+ PMD_INIT_LOG(INFO, "ETH_MQ_TX_VMDQ_DCB mode supported in SRIOV");
+ dev->data->dev_conf.txmode.mq_mode = ETH_MQ_TX_VMDQ_DCB;
+ break;
default: /* ETH_MQ_TX_VMDQ_ONLY or ETH_MQ_TX_NONE */
dev->data->dev_conf.txmode.mq_mode = ETH_MQ_TX_VMDQ_ONLY;
break;
diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 2ce8234..b2d9f45 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2015 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
* Copyright 2014 6WIND S.A.
* All rights reserved.
*
@@ -3313,15 +3313,16 @@ ixgbe_vmdq_dcb_configure(struct rte_eth_dev *dev)
/**
* ixgbe_dcb_config_tx_hw_config - Configure general DCB TX parameters
- * @hw: pointer to hardware structure
+ * @dev: pointer to eth_dev structure
* @dcb_config: pointer to ixgbe_dcb_config structure
*/
static void
-ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
+ixgbe_dcb_tx_hw_config(struct rte_eth_dev *dev,
struct ixgbe_dcb_config *dcb_config)
{
uint32_t reg;
uint32_t q;
+ struct ixgbe_hw *hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
PMD_INIT_FUNC_TRACE();
if (hw->mac.type != ixgbe_mac_82598EB) {
@@ -3340,10 +3341,17 @@ ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
reg |= IXGBE_MTQC_VT_ENA;
IXGBE_WRITE_REG(hw, IXGBE_MTQC, reg);
- /* Disable drop for all queues */
- for (q = 0; q < 128; q++)
- IXGBE_WRITE_REG(hw, IXGBE_QDE,
- (IXGBE_QDE_WRITE | (q << IXGBE_QDE_IDX_SHIFT)));
+ if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
+ /* Disable drop for all queues in VMDQ mode*/
+ for (q = 0; q < 128; q++)
+ IXGBE_WRITE_REG(hw, IXGBE_QDE,
+ (IXGBE_QDE_WRITE | (q << IXGBE_QDE_IDX_SHIFT)));
+ } else {
+ /* Enable drop for all queues in SRIOV mode */
+ for (q = 0; q < 128; q++)
+ IXGBE_WRITE_REG(hw, IXGBE_QDE,
+ (IXGBE_QDE_WRITE | (q << IXGBE_QDE_IDX_SHIFT) | IXGBE_QDE_ENABLE));
+ }
/* Enable the Tx desc arbiter */
reg = IXGBE_READ_REG(hw, IXGBE_RTTDCS);
@@ -3378,7 +3386,7 @@ ixgbe_vmdq_dcb_hw_tx_config(struct rte_eth_dev *dev,
vmdq_tx_conf->nb_queue_pools == ETH_16_POOLS ? 0xFFFF : 0xFFFFFFFF);
/*Configure general DCB TX parameters*/
- ixgbe_dcb_tx_hw_config(hw, dcb_config);
+ ixgbe_dcb_tx_hw_config(dev, dcb_config);
}
static void
@@ -3661,7 +3669,7 @@ ixgbe_dcb_hw_configure(struct rte_eth_dev *dev,
/*get DCB TX configuration parameters from rte_eth_conf*/
ixgbe_dcb_tx_config(dev, dcb_config);
/*Configure general DCB TX parameters*/
- ixgbe_dcb_tx_hw_config(hw, dcb_config);
+ ixgbe_dcb_tx_hw_config(dev, dcb_config);
break;
default:
PMD_INIT_LOG(ERR, "Incorrect DCB TX mode configuration");
@@ -3810,7 +3818,7 @@ void ixgbe_configure_dcb(struct rte_eth_dev *dev)
(dev_conf->rxmode.mq_mode != ETH_MQ_RX_DCB_RSS))
return;
- if (dev->data->nb_rx_queues != ETH_DCB_NUM_QUEUES)
+ if (dev->data->nb_rx_queues > ETH_DCB_NUM_QUEUES)
return;
/** Configure DCB hardware **/
@@ -4082,12 +4090,13 @@ ixgbe_dev_mq_rx_configure(struct rte_eth_dev *dev)
case ETH_MQ_RX_VMDQ_RSS:
ixgbe_config_vf_rss(dev);
break;
-
- /* FIXME if support DCB/RSS together with VMDq & SRIOV */
case ETH_MQ_RX_VMDQ_DCB:
+ ixgbe_vmdq_dcb_configure(dev);
+ break;
+ /* FIXME if support DCB/RSS together with VMDq & SRIOV */
case ETH_MQ_RX_VMDQ_DCB_RSS:
PMD_INIT_LOG(ERR,
- "Could not support DCB with VMDq & SRIOV");
+ "Could not support DCB/RSS with VMDq & SRIOV");
return -1;
default:
ixgbe_config_vf_default(dev);
--
2.10.1
^ permalink raw reply related
* [PATCH v5 0/2] net/ixgbe: VMDq DCB with SRIOV
From: Bernard Iremonger @ 2016-10-19 10:21 UTC (permalink / raw)
To: dev, rahul.r.shah, wenzhuo.lu; +Cc: Bernard Iremonger
In-Reply-To: <1476723683-9601-1-git-send-email-bernard.iremonger@intel.com>
Changes in v5:
fix enable/disable of the QDE bit in the PFQDE register.
Changes in v4:
changes to ixgbe patch following comments.
Changes in v3:
rebase to latest master.
update commit message for ixgbe patch
add testpmd patch.
Changes in v2:
rebase to latest master.
Bernard Iremonger (2):
net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
app/test_pmd: fix DCB configuration
app/test-pmd/testpmd.c | 4 ++--
drivers/net/ixgbe/ixgbe_ethdev.c | 11 ++++++-----
drivers/net/ixgbe/ixgbe_rxtx.c | 35 ++++++++++++++++++++++-------------
3 files changed, 30 insertions(+), 20 deletions(-)
--
2.10.1
^ permalink raw reply
* Re: [PATCH v2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
From: Iremonger, Bernard @ 2016-10-19 10:16 UTC (permalink / raw)
To: Lu, Wenzhuo, dev@dpdk.org, Shah, Rahul R
In-Reply-To: <6A0DE07E22DDAD4C9103DF62FEBC09093933CC27@shsmsx102.ccr.corp.intel.com>
Hi Wenzhuo,
<snip>
> > > > Subject: RE: [PATCH v2] net/ixgbe: support multiqueue mode VMDq
> > > > DCB with SRIOV
> > > >
> > > > Hi Wenzhuo,
> > > >
> > > > > > if (hw->mac.type != ixgbe_mac_82598EB) { @@ -3339,11
> > > > > > +3340,17
> > > > > @@
> > > > > > ixgbe_dcb_tx_hw_config(struct ixgbe_hw *hw,
> > > > > > if (dcb_config->vt_mode)
> > > > > > reg |= IXGBE_MTQC_VT_ENA;
> > > > > > IXGBE_WRITE_REG(hw, IXGBE_MTQC, reg);
> > > > > > -
> > > > > > - /* Disable drop for all queues */
> > > > > > - for (q = 0; q < 128; q++)
> > > > > > - IXGBE_WRITE_REG(hw, IXGBE_QDE,
> > > > > > - (IXGBE_QDE_WRITE | (q <<
> > > > > > IXGBE_QDE_IDX_SHIFT)));
> > > > > > + if (RTE_ETH_DEV_SRIOV(dev).active == 0) {
> > > > > > + /* Disable drop for all queues in VMDQ
> mode*/
> > > > > > + for (q = 0; q < 128; q++)
> > > > > > + IXGBE_WRITE_REG(hw, IXGBE_QDE,
> > > > > > + (IXGBE_QDE_WRITE |
> > (q <<
> > > > > > IXGBE_QDE_IDX_SHIFT) | IXGBE_QDE_ENABLE));
> This code is used to enable drop, but the comments say 'disable drop'.
The comment is correct but the code is not.
> > > > > > + } else {
> > > > > > + /* Enable drop for all queues in SRIOV mode
> */
> > > > > > + for (q = 0; q < 128; q++)
> > > > > > + IXGBE_WRITE_REG(hw, IXGBE_QDE,
> > > > > > + (IXGBE_QDE_WRITE |
> > (q <<
> > > > > > IXGBE_QDE_IDX_SHIFT)));
> This code is used to disable drop, but the comments say 'enable drop'.
The comment is correct but the code is not.
> I've checked the V4, the same problem too. I think the problem is the
> comments, right?
No, the comments are correct but the code is reversed.
I will send a v5.
> > > > > > + }
> > > > > I think it has nothing to do with mq mode. Do I miss something?
> > > >
> > > > Behavior is different when SRIOV is enabled.
> > > I don't understand why the behavior is different. To my opinion, the
> > > drop has nothing to do with the mode. We can enable or disable it.
> > > The old behavior is disabling it by default. Now you change it to
> > > disabling it by default in NO-SRIOV mode, but enabling it in SRIOV mode.
> > > What I don't get is the reason.
> >
> > Please refer to section 4.6.11.3.1 page 180 of the
> > 82599-10-gbe-controller- datasheet.pdf The last paragraph on page 180
> > states:
> >
> > "Queue Drop Enable (PFQDE) - In SR-IO the QDE bit should be set to 1b
> > in the PFQDE register for all queues.
> > In VMDq mode, the QDE bit should be set to 0b for all queues."
> Got it, thanks a lot :)
>
> >
> >
> > > > > > /* Enable the Tx desc arbiter */
> > > > > > reg = IXGBE_READ_REG(hw, IXGBE_RTTDCS); @@ -
> 3378,7
> > > > > > +3385,7 @@ ixgbe_vmdq_dcb_hw_tx_config(struct rte_eth_dev
> > > > > > +*dev,
> > > > > > vmdq_tx_conf->nb_queue_pools ==
> ETH_16_POOLS
> > > > > ?
> > > > > > 0xFFFF : 0xFFFFFFFF);
> > > > > >
> > > > > > /*Configure general DCB TX parameters*/
> > > > > > - ixgbe_dcb_tx_hw_config(hw, dcb_config);
> > > > > > + ixgbe_dcb_tx_hw_config(dev, dcb_config);
> > > > > > }
> > > > > >
> > > > > > static void
> > > > > > @@ -3661,7 +3668,7 @@ ixgbe_dcb_hw_configure(struct
> > > > > > rte_eth_dev
> > > > > *dev,
> > > > > > /*get DCB TX configuration parameters from
> rte_eth_conf*/
> > > > > > ixgbe_dcb_tx_config(dev, dcb_config);
> > > > > > /*Configure general DCB TX parameters*/
> > > > > > - ixgbe_dcb_tx_hw_config(hw, dcb_config);
> > > > > > + ixgbe_dcb_tx_hw_config(dev, dcb_config);
> > > > > > break;
> > > > > > default:
> > > > > > PMD_INIT_LOG(ERR, "Incorrect DCB TX mode
> > > > > configuration"); @@
> > > > > > -3810,9 +3817,6 @@ void ixgbe_configure_dcb(struct rte_eth_dev
> > > *dev)
> > > > > > (dev_conf->rxmode.mq_mode != ETH_MQ_RX_DCB_RSS))
> > > > > > return;
> > > > > >
> > > > > > - if (dev->data->nb_rx_queues != ETH_DCB_NUM_QUEUES)
> > > > > > - return;
> > > > > I remember it's a limitation of implementation. The reason is
> > > > > the resource allocation. Why could we remove it now?
> > > >
> > > > ETH_DCB_NUM_QUEUES is 128, nb_rx_queues may not be 128.
> > > I think it's a limitation to force the queue number to be
> > > ETH_DCB_NUM_QUEUES.
> > > Just to confirm it, have you try to set rx queue number to something
> > > different from 128, like 64, 32...
> >
> > In my test scenario the nb_rx_queues is 1.
> Glad to know that, thanks :)
>
Regards,
Bernard
^ permalink raw reply
* Re: [PATCH 1/3] mbuf: embedding timestamp into the packet
From: Pattan, Reshma @ 2016-10-19 10:14 UTC (permalink / raw)
To: Olivier Matz, Oleg Kuporosov
Cc: Richardson, Bruce, Ananyev, Konstantin, dev@dpdk.org
In-Reply-To: <efb55b81-339b-6706-12ef-d67bae6e6c5f@6wind.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
> Sent: Tuesday, October 18, 2016 4:44 PM
> To: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 1/3] mbuf: embedding timestamp into the
> packet
>
>
>
> On 10/13/2016 04:35 PM, Oleg Kuporosov wrote:
> > The hard requirement of financial services industry is accurate
> > timestamping aligned with the packet itself. This patch is to satisfy
> > this requirement:
> >
> > - include uint64_t timestamp field into rte_mbuf with minimal impact to
> > throughput/latency. Keep it just simple uint64_t in ns (more than 580
> > years) would be enough for immediate needs while using full
> > struct timespec with twice bigger size would have much stronger
> > performance impact as missed cacheline0.
> >
> > - it is possible as there is 6-bytes gap in 1st cacheline (fast path)
> > and moving uint16_t vlan_tci_outer field to 2nd cacheline.
> >
> > - such move will only impact for pretty rare usable VLAN RX stripping
> > mode for outer TCI (it used only for one NIC i40e from the whole set and
> > allows to keep minimal performance impact for RX/TX timestamps.
>
> This argument is difficult to accept. One can say you are adding a field for a
> pretty rare case used by only one NIC :)
>
> Honestly, I'm not able to judge whether timestamp is more important than
> vlan_tci_outer. As room is tight in the first cache line, your patch submission is
> the occasion to raise the question: how to decide what should be in the first part
> of the mbuf? There are also some other candidates for moving: m->seqn is only
> used in librte_reorder and it is not set in the RX part of a driver.
>
> About the timestamp, it would be valuable to have other opinions, not only
> about the placement of the field in the structure, but also to check that this API
> is also usable for other NICs.
>
> Have you measured the impact of having the timestamp in the second part of
> the mbuf?
>
> Changing the mbuf structure should happen as rarely as possible, and we have to
> make sure we take the correct decisions. I think we will discuss this at dpdk
> userland 2016.
>
>
I just read this mail chain, to make every one aware again, I am emphasizing on the point that I am also adding new "time_arraived" field
to mbuf struct as part of below 17.02 Road map item.
" Extended Stats (Latency and Bit Rate Statistics): Enhance the Extended NIC Stats (Xstats) implementation to support the collection and reporting of latency and bit rate measurements. Latency statistics will include min, max and average latency, and jitter. Bit rate statistics will include peak and average bit rate aggregated over a user-defined time period. This will be implemented for IXGBE and I40E."
Adding new field " time_arrived" to the 2nd cache line of rte_mbuf struct to mark the packet arrival time for latency measurements.
Adding this new filed to second cache line will not break the ABI. I implemented a new library to mark the time as part of rte_eth_rx callbacks
and use that time stamp inside rte_eth_tx callback for measuring the latency. Below is the latest v3 RFC patch for reference.
http://dpdk.org/dev/patchwork/patch/16655/
Comments are welcome.
Thanks,
Reshma
^ permalink raw reply
* Re: [PATCH] net/fm10k: fix SGLORT of VF Tx queues
From: Bruce Richardson @ 2016-10-19 10:10 UTC (permalink / raw)
To: Xiao Wang; +Cc: jing.d.chen, dev
In-Reply-To: <1476840614-1478-1-git-send-email-xiao.w.wang@intel.com>
On Wed, Oct 19, 2016 at 09:30:14AM +0800, Xiao Wang wrote:
> The SGLORT (Source Global Resource Tag) of the VF queues should be
> assigned by PF driver, VF driver should not set these registers.
>
> Fixes: 3b845bf6bcd9 ("fm10k: fix switch manager high CPU usage")
>
> Signed-off-by: Xiao Wang <xiao.w.wang@intel.com>
> Reported-by: Sarathx Somasekharan <sarathx.somasekharan@intel.com>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH v2] net/mlx5: fix init on secondary process
From: Adrien Mazarguil @ 2016-10-19 10:05 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Ferruh Yigit, Olivier Gournet, dev, Nelio Laranjeiro
In-Reply-To: <20161019093147.GD27816@bricha3-MOBL3.ger.corp.intel.com>
On Wed, Oct 19, 2016 at 10:31:48AM +0100, Bruce Richardson wrote:
> On Mon, Oct 17, 2016 at 04:18:59PM +0200, Adrien Mazarguil wrote:
> > On Mon, Oct 17, 2016 at 02:52:39PM +0100, Ferruh Yigit wrote:
> > > Hi Adrien,
> > >
> > > On 10/17/2016 1:56 PM, Olivier Gournet wrote:
> > > > Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
> > > > Fixes: 21c8bb4928c9 ("net/mlx5: split Tx queue structure")
> > > >
> > > > Signed-off-by: Olivier Gournet <ogournet@corp.free.fr>
> > >
> > > According your comment on previous version of it, I think you have your
> > > Ack on this patch, but can you please confirm?
> >
> > Yes it's fine, thanks.
> >
> > Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> >
> > --
> While this patch is acked, I'd still like a bit of detail in the commit
> message describing what the problem is and how the patch fixes it. The
> Chuck Norris approach of trying to stare down the code until it tells
> me just isn't working for me today! :-)
>
> Adrien or Olivier, if you can supply a brief description of what this
> patch is doing and why I'll add it to the commit log on apply.
*cough* this patch restores the original behavior of not causing a secondary
process to segfault during init.
Seriously, one needs to look at mlx5_secondary_data_setup() in both commits
to really understand what happened, my suggestion for a commit log:
The changes introduced by these commits made secondaries attempt to
reinitialize the TX queue structures of the primary instead of their own,
for which they also do not allocate enough memory, leading to crashes.
--
Adrien Mazarguil
6WIND
^ permalink raw reply
* Re: [PATCH] drivers: make driver names consistent
From: Yuanhan Liu @ 2016-10-19 10:05 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: Jan Blunck, De Lara Guarch, Pablo, dev, Mcnamara, John
In-Reply-To: <7993435.bReMuqSN60@xps13>
On Tue, Oct 18, 2016 at 06:46:40PM +0200, Thomas Monjalon wrote:
> 2016-10-18 22:18, Yuanhan Liu:
> > On Tue, Oct 18, 2016 at 03:42:54PM +0200, Thomas Monjalon wrote:
> > > 2016-10-18 21:06, Yuanhan Liu:
> > > > On Tue, Oct 18, 2016 at 02:50:16PM +0200, Jan Blunck wrote:
> > > > > >From my understanding this is a massive API breakage. This forces all
> > > > > existing users of the virtual PMDs to change with zero benefit. Even
> > > > > if that isn't enough it also makes it impossible to switch between
> > > > > releases by recompiling.
> > > > >
> > > > > Can we please revert these changes and work on some aliasing support
> > > > > for the PMDs to fix it long term?
> > > >
> > > > +1. Aliasing is also something I would suggest before making such renames.
> > >
> > > It is a brutal change, yes.
> > > It was announced in 16.07 release notes though.
> >
> > Yes, but it still took me a while (by running git bisect) to figure out
> > what went wrong: I wasn't aware of such note, that I was thinking maybe
> > something is broken.
> >
> > Later I also got quite few same complains. It may also took them a while
> > to know what's happened.
> >
> > Anyway, my point is, for this kind of change, we should have added the
> > alias support firstly.
>
> Yes.
>
> > If that's been done, then the announcement is not
> > needed at all?
>
> The announcement would be needed to remove the aliases, later.
Why do you have to remove an aliase? What's wrong if they stay there
forever. I think the naming will be switched (maybe slowly) when we
haved updated the doc (whereas it states "net_vhost" but not "eth_vhost"
only).
After few releases, the name should have been switched fluently. And
we should not care about those alias.
--yliu
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix link status report
From: Bruce Richardson @ 2016-10-19 9:58 UTC (permalink / raw)
To: Nelio Laranjeiro; +Cc: dev, Olga Shern, Adrien Mazarguil
In-Reply-To: <ec7fb7f370b7215a4fa374182e3ebc9914b00f13.1476688229.git.nelio.laranjeiro@6wind.com>
On Mon, Oct 17, 2016 at 01:10:48PM +0200, Nelio Laranjeiro wrote:
> From: Olga Shern <olgas@mellanox.com>
>
> This commit fixes link status report on device start up when
> lcs callback is configured.
>
> Fixes: 62072098b54e ("mlx5: support setting link up or down")
>
> Signed-off-by: Olga Shern <olgas@mellanox.com>
> ---
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: Project Governance and Linux Foundation
From: Thomas Monjalon @ 2016-10-19 9:56 UTC (permalink / raw)
To: Dave Neary, O'Driscoll, Tim, Jerin Jacob; +Cc: dev, users
In-Reply-To: <58073195.60409@redhat.com>
2016-10-19 09:40, Dave Neary:
> On 10/19/2016 09:04 AM, O'Driscoll, Tim wrote:
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> > > On Tue, Oct 18, 2016 at 03:27:27PM +0200, Thomas Monjalon wrote:
> > > > How can we solve issues if you don't give more details than
> > > > "hear concerns" or "heard anecdotal evidence of issues"?
> > >
> > > Honestly, I don't see any issue in the current DPDK project execution.
> > > The concern was more towards the fact that multi-vendor infrastructure
> > > project like DPDK owned and controlled by the single company.
> > >
> > > We believe, Moving to LF will fix that issue/perception and it will
> > > enable more users to use/consume/invest DPDK in their products.
> >
> > +1. This is in danger of becoming a never-ending argument. We said in
> > the original post that one of the goals of moving to LF is to "Remove any
> > remaining perception that DPDK is not truly open". I believe that's an
> > important goal for the project and one that we should all agree on.
Yes, being truly open and welcome all contributors is important.
> > Whether you choose the accept it or not, it's a fact that concerns exist
> > in the community over the fact that one single company controls the
> > infrastructure for the project. Moving the project to an independent
> > body like the LF would fix that.
Sure I accept that one have concerns even if I don't understand them.
I was just asking questions to try understanding the concerns.
But unfortunately, we have no answer on these (see also how ZTE and
China Mobile do not answer).
> > > Having said that, Does anyone see any issue in moving to LF?
> > > If yes, Then we should enumerate the issues and discuss further.
> >
> > This is a great point. Can you explain what you see as the benefits
> > of maintaining the current model? As far as I can see, the LF model
> > provides everything that we currently have, plus it makes DPDK
> > independent of any single company, and it also gives us the option
> > of availing of other LF services if we choose to do so, including
> > the ability to host lab infrastructure for the project, legal
> > support for trademarks if we need that, event planning etc.
Tim, are you asking me to argue in favor of the current model?
I said multiple times that having an infrastructure with legals may be
interesting, and that resources for event planning sounds great.
See also this answer: http://dpdk.org/ml/archives/dev/2016-October/049098.html
> The one issue I am aware of is that the Linux Foundation, in our
> previous discussions, requested that they take ownership of the dpdk.org
> domain name and management of the DNS, to ensure that the website and
> community infrastructure were not beholden to a single project member -
> is that still an issue?
Sorry to not be able to answer, I do not manage this adminitrative question.
I think the discussion must continue during the summit.
My conclusion on this thread:
I was very active in the creation of dpdk.org with the goal of gathering and
welcoming every contributors. That's why I want to understand the feedbacks.
Then I will embrace the collective decision with the joy to see this
successful project satisfying its community.
^ permalink raw reply
* Re: [PATCH] Revert "bonding: use existing enslaved device queues"
From: Bruce Richardson @ 2016-10-19 9:55 UTC (permalink / raw)
To: Declan Doherty
Cc: Ilya Maximets, dev, Heetae Ahn, Yuanhan Liu, Eric Kinzie,
Bernard Iremonger, stable
In-Reply-To: <a785b1de-5b8e-1847-8e67-2e86a67aecf9@intel.com>
On Thu, Oct 06, 2016 at 03:32:36PM +0100, Declan Doherty wrote:
> On 07/09/16 13:28, Ilya Maximets wrote:
> > This reverts commit 5b7bb2bda5519b7800f814df64d4e015282140e5.
> >
> > It is necessary to reconfigure all queues every time because configuration
> > can be changed.
> >
>
> Hey Ilya, this makes sense. I guess this was my original intention but I
> missed this case in my review of the change.
>
> > For example, if we're reconfiguring bonding device with new memory pool,
> > already configured queues will still use the old one. And if the old
> > mempool be freed, application likely will panic in attempt to use
> > freed mempool.
> >
> > This happens when we use the bonding device with OVS 2.6 while MTU
> > reconfiguration:
> >
> > PANIC in rte_mempool_get_ops():
> > assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed
> >
> > Cc: <stable@dpdk.org>
> > Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
> > ---
>
> Acked-by: Declan Doherty <declan.doherty@intel.com>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH v2 0/3] net: fix out of order Rx read issue
From: Bruce Richardson @ 2016-10-19 9:52 UTC (permalink / raw)
To: Ananyev, Konstantin; +Cc: Zhang, Qi Z, Wu, Jingjing, Zhang, Helin, dev@dpdk.org
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0C2B37@irsmsx105.ger.corp.intel.com>
On Tue, Oct 18, 2016 at 11:33:43AM +0000, Ananyev, Konstantin wrote:
>
>
> >
> > In vPMD, when load Rx desc with _mm_loadu_si128,
> > volatile point will be cast into non-volatile point.
> > So GCC is allowed to reorder the load instructions,
> > while Rx read's correctness is reply on these load
> > instructions to follow a backward sequence strictly,
> > so we add compile barrier to prevent compiler reorder.
> > We already met this issue on i40e with GCC6 and we
> > fixed this on ixgbe and fm10k also.
> >
> > v2:
> > - fix check-git-log.sh warning.
> > - add more detail commit message.
> >
> > Qi Zhang (3):
> > net/i40e: fix out of order Rx read issue
> > net/ixgbe: fix out of order Rx read issue
> > net/fm10k: fix out of ofder Rx read issue
> >
> > drivers/net/fm10k/fm10k_rxtx_vec.c | 3 +++
> > drivers/net/i40e/i40e_rxtx_vec.c | 3 +++
> > drivers/net/ixgbe/ixgbe_rxtx_vec_sse.c | 3 +++
> > 3 files changed, 9 insertions(+)
> >
> > --
>
> Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
>
Applied to dpdk-next_net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH] Revert "bonding: use existing enslaved device queues"
From: Ilya Maximets @ 2016-10-19 9:47 UTC (permalink / raw)
To: Jan Blunck
Cc: dev, Declan Doherty, Heetae Ahn, Yuanhan Liu, Eric Kinzie,
Bernard Iremonger, stable, Dyasly Sergey
In-Reply-To: <CALe+Z03rF9Fh-u17kWHhfTJkRzYM==juQMR8ucOLCrgmp9FCug@mail.gmail.com>
On 18.10.2016 18:19, Jan Blunck wrote:
> On Tue, Oct 18, 2016 at 2:49 PM, Ilya Maximets <i.maximets@samsung.com> wrote:
>> On 18.10.2016 15:28, Jan Blunck wrote:
>>> If the application already configured queues the PMD should not
>>> silently claim ownership and reset them.
>>>
>>> What exactly is the problem when changing MTU? This works fine from
>>> what I can tell.
>>
>> Following scenario leads to APP PANIC:
>>
>> 1. mempool_1 = rte_mempool_create()
>> 2. rte_eth_rx_queue_setup(bond0, ..., mempool_1);
>> 3. rte_eth_dev_start(bond0);
>> 4. mempool_2 = rte_mempool_create();
>> 5. rte_eth_dev_stop(bond0);
>> 6. rte_eth_rx_queue_setup(bond0, ..., mempool_2);
>> 7. rte_eth_dev_start(bond0);
>> * RX queues still use 'mempool_1' because reconfiguration doesn't affect them. *
>> 8. rte_mempool_free(mempool_1);
>> 9. On any rx operation we'll get PANIC because of using freed 'mempool_1':
>> PANIC in rte_mempool_get_ops():
>> assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed
>>
>> You may just start OVS 2.6 with DPDK bonding device and attempt to change MTU via 'mtu_request'.
>> Bug is easily reproducible.
>>
>
> I see. I'm not 100% that this is expected to work without leaking the
> driver's queues though. The driver is allowed to do allocations in
> its rx_queue_setup() function that are being freed via
> rx_queue_release() later. But rx_queue_release() is only called if you
> reconfigure the
> device with 0 queues. From what I understand there is no other way to
> reconfigure a device to use another mempool.
>
> But ... even that wouldn't work with the bonding driver right now: the
> bonding master only configures the slaves during startup. I can put
> that on my todo list.
>
> Coming back to your original problem: changing the MTU for the bond
> does work through rte_eth_dev_set_mtu() for slaves supporting that. In
> any other case you could (re-)configure rxmode.max_rx_pkt_len (and
> jumbo_frame / enable_scatter accordingly). This does work without a
> call to rte_eth_rx_queue_setup().
Thanks for suggestion, but using of rte_eth_dev_set_mtu() without
reconfiguration will require to have mempools with huge mbufs (9KB)
for all ports from the start. This is unacceptable because leads to
significant performance regressions because of fast cache exhausting.
Also this will require big work to rewrite OVS reconfiguration code
this way.
Anyway, it isn't the MTU only problem. Number of rx/tx descriptors
also can't be changed in runtime.
I'm not fully understand what is the use case for this 'reusing' code.
Could you, please, describe situation where this behaviour is necessary?
Best regards, Ilya Maximets.
>>
>>>
>>> On Wed, Sep 7, 2016 at 2:28 PM, Ilya Maximets <i.maximets@samsung.com> wrote:
>>>> This reverts commit 5b7bb2bda5519b7800f814df64d4e015282140e5.
>>>>
>>>> It is necessary to reconfigure all queues every time because configuration
>>>> can be changed.
>>>>
>>>> For example, if we're reconfiguring bonding device with new memory pool,
>>>> already configured queues will still use the old one. And if the old
>>>> mempool be freed, application likely will panic in attempt to use
>>>> freed mempool.
>>>>
>>>> This happens when we use the bonding device with OVS 2.6 while MTU
>>>> reconfiguration:
>>>>
>>>> PANIC in rte_mempool_get_ops():
>>>> assert "(ops_index >= 0) && (ops_index < RTE_MEMPOOL_MAX_OPS_IDX)" failed
>>>>
>>>> Cc: <stable@dpdk.org>
>>>> Signed-off-by: Ilya Maximets <i.maximets@samsung.com>
>>>> ---
>>>> drivers/net/bonding/rte_eth_bond_pmd.c | 10 ++--------
>>>> 1 file changed, 2 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c b/drivers/net/bonding/rte_eth_bond_pmd.c
>>>> index b20a272..eb5b6d1 100644
>>>> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
>>>> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
>>>> @@ -1305,8 +1305,6 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
>>>> struct bond_rx_queue *bd_rx_q;
>>>> struct bond_tx_queue *bd_tx_q;
>>>>
>>>> - uint16_t old_nb_tx_queues = slave_eth_dev->data->nb_tx_queues;
>>>> - uint16_t old_nb_rx_queues = slave_eth_dev->data->nb_rx_queues;
>>>> int errval;
>>>> uint16_t q_id;
>>>>
>>>> @@ -1347,9 +1345,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
>>>> }
>>>>
>>>> /* Setup Rx Queues */
>>>> - /* Use existing queues, if any */
>>>> - for (q_id = old_nb_rx_queues;
>>>> - q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
>>>> + for (q_id = 0; q_id < bonded_eth_dev->data->nb_rx_queues; q_id++) {
>>>> bd_rx_q = (struct bond_rx_queue *)bonded_eth_dev->data->rx_queues[q_id];
>>>>
>>>> errval = rte_eth_rx_queue_setup(slave_eth_dev->data->port_id, q_id,
>>>> @@ -1365,9 +1361,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
>>>> }
>>>>
>>>> /* Setup Tx Queues */
>>>> - /* Use existing queues, if any */
>>>> - for (q_id = old_nb_tx_queues;
>>>> - q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
>>>> + for (q_id = 0; q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
>>>> bd_tx_q = (struct bond_tx_queue *)bonded_eth_dev->data->tx_queues[q_id];
>>>>
>>>> errval = rte_eth_tx_queue_setup(slave_eth_dev->data->port_id, q_id,
>>>> --
>>>> 2.7.4
>>>>
>>>
>>>
>>>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] net/enic: fix error in init of RQ when not using Rx scatter
From: Bruce Richardson @ 2016-10-19 9:43 UTC (permalink / raw)
To: John Daley; +Cc: dev, Nelson Escobar
In-Reply-To: <20161012201129.31611-1-johndale@cisco.com>
On Wed, Oct 12, 2016 at 01:11:28PM -0700, John Daley wrote:
> From: Nelson Escobar <neescoba@cisco.com>
>
> The Rx scatter patch was accidentally setting the index of the
> secondary receive queue in the primary receive queue's initialization
> when the secondary receive queue wasn't needed and was disabled. This
> caused some misleading hardware counters in some situations.
>
> Fixes: 856d7ba7ed22 ("net/enic: support scattered Rx")
>
> Signed-off-by: Nelson Escobar <neescoba@cisco.com>
> Reviewed-by: John Daley <johndale@cisco.com>
Patchset applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH 1/2] net/enic: fix crash on MTU update or rxq reconfigure
From: Bruce Richardson @ 2016-10-19 9:42 UTC (permalink / raw)
To: John Daley; +Cc: dev
In-Reply-To: <20161012211203.23250-1-johndale@cisco.com>
On Wed, Oct 12, 2016 at 02:12:02PM -0700, John Daley wrote:
> The incorrect completion queue corresponding to an RQ would be
> freed if multiple Rx queues are in use and the MTU is changed,
> or an Rx queue is released. This could lead to a segmentation fault
> when the device is disabled or even in the Rx or Tx paths.
>
> The index of the completion queue corresponding to a RQ needed
> to be adjusted after Rx scatter was introduced.
>
> Fixes: 856d7ba7ed22 ("net/enic: support scattered Rx")
>
> Signed-off-by: John Daley <johndale@cisco.com>
> Reviewed-by: Nelson Escobar <neescoba@cisco.com>
> ---
Patchset applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH] net/enic: fix poor multi-queue Rx performance
From: Bruce Richardson @ 2016-10-19 9:41 UTC (permalink / raw)
To: John Daley; +Cc: dev
In-Reply-To: <20161012212229.6603-1-johndale@cisco.com>
On Wed, Oct 12, 2016 at 02:22:29PM -0700, John Daley wrote:
> The rx_free_thresh was not being initialized and left at 0
> on 1/2 of the RQs which could lead to poor multi-queue
> performanace.
>
> Fixes: 856d7ba7ed22 ("net/enic: support scattered Rx")
>
> Signed-off-by: John Daley <johndale@cisco.com>
> Reviewed-by: Nelson Escobar <neescoba@cisco.com>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH] net/enic: fix fdir UDP v4 source port mask
From: Bruce Richardson @ 2016-10-19 9:40 UTC (permalink / raw)
To: John Daley; +Cc: dev
In-Reply-To: <20161018051708.25218-1-johndale@cisco.com>
On Mon, Oct 17, 2016 at 10:17:08PM -0700, John Daley wrote:
> This fixes issue found by Coverity where a typo caused the flow director
> UDP IPv4 source port mask to be assigned the destination port mask
> supplied by the caller.
>
> Coverity issue: 137860
>
> Fixes: dfbd6a9cb504 ("net/enic: extend flow director support for 1300 series")
>
> Signed-off-by: John Daley <johndale@cisco.com>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH v3 0/3] fix flow director mask issues
From: Bruce Richardson @ 2016-10-19 9:35 UTC (permalink / raw)
To: Wenzhuo Lu; +Cc: dev
In-Reply-To: <1476840180-1350-1-git-send-email-wenzhuo.lu@intel.com>
On Wed, Oct 19, 2016 at 09:22:57AM +0800, Wenzhuo Lu wrote:
> There're 2 issues about flow director mask.
> 1, MAC address mask is not supported in mac-vlan mode.
> 2, All the parameter are defined as big endian, but
> they're not treated approriately.
> This patch set is used to fix these 2 issues.
>
> v2:
> - Re-split the patches and reword commit log. No code change.
>
> v3:
> - Reword the commit log.
>
> Wenzhuo Lu (3):
> ixgbe: fix wrong flow director mask
> app/testpmd: fix wrong flow director mask
> app/testpmd: fix flow director endian issue
>
Patchset applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH v2] net/mlx5: fix init on secondary process
From: Bruce Richardson @ 2016-10-19 9:31 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: Ferruh Yigit, Olivier Gournet, dev, Nelio Laranjeiro
In-Reply-To: <20161017141859.GB5733@6wind.com>
On Mon, Oct 17, 2016 at 04:18:59PM +0200, Adrien Mazarguil wrote:
> On Mon, Oct 17, 2016 at 02:52:39PM +0100, Ferruh Yigit wrote:
> > Hi Adrien,
> >
> > On 10/17/2016 1:56 PM, Olivier Gournet wrote:
> > > Fixes: 1d88ba171942 ("net/mlx5: refactor Tx data path")
> > > Fixes: 21c8bb4928c9 ("net/mlx5: split Tx queue structure")
> > >
> > > Signed-off-by: Olivier Gournet <ogournet@corp.free.fr>
> >
> > According your comment on previous version of it, I think you have your
> > Ack on this patch, but can you please confirm?
>
> Yes it's fine, thanks.
>
> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>
> --
While this patch is acked, I'd still like a bit of detail in the commit
message describing what the problem is and how the patch fixes it. The
Chuck Norris approach of trying to stare down the code until it tells
me just isn't working for me today! :-)
Adrien or Olivier, if you can supply a brief description of what this
patch is doing and why I'll add it to the commit log on apply.
Thanks,
/Bruce
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix hash key size retrieval
From: Bruce Richardson @ 2016-10-19 9:26 UTC (permalink / raw)
To: Adrien Mazarguil; +Cc: Nelio Laranjeiro, dev
In-Reply-To: <20161014082032.GD17252@6wind.com>
On Fri, Oct 14, 2016 at 10:20:32AM +0200, Adrien Mazarguil wrote:
> On Fri, Oct 14, 2016 at 09:30:14AM +0200, Nelio Laranjeiro wrote:
> > Return RSS key size in struct rte_eth_dev_info.
> >
> > Fixes: 0f6f219e7919 ("app/testpmd: fix RSS hash key size")
> >
> > Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
>
> Acked-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH] net/bnx2x: fix icc build error
From: Bruce Richardson @ 2016-10-19 9:24 UTC (permalink / raw)
To: Mody, Rasesh
Cc: Ferruh Yigit, dev@dpdk.org, Sony Chacko, Harish Patil,
Rasesh Mody
In-Reply-To: <BLUPR0701MB1572EACD26B20F755DF81D009FD00@BLUPR0701MB1572.namprd07.prod.outlook.com>
On Mon, Oct 17, 2016 at 06:04:32PM +0000, Mody, Rasesh wrote:
> > From: Ferruh Yigit [mailto:ferruh.yigit@intel.com]
> > Sent: Monday, October 17, 2016 5:12 AM
> >
> > On 9/30/2016 3:45 PM, Ferruh Yigit wrote:
> > > When bnx2x debug config enabled, icc (ICC) 17.0.0 20160721 gives the
> > > following compilation error:
> > >
> > > .../drivers/net/bnx2x/elink.c(6682):
> > > error #3656: variable "fw_ver1" may be used before its value is set
> > > PMD_DRV_LOG(DEBUG,
> > > ^
> > >
> > > According logic in the code, this error is a false positive, but since
> > > this is not in the fast path, fixing compiler error by assigning
> > > initial value to variable.
> > >
> > > Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
<snip>
>
> > Since this is an compilation fix, I believe it is good to have this in the release,
> > can you please review the patch?
>
> Thanks!
>
> Acked-by: Rasesh Mody <rasesh.mody@qlogic.com>
>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: [PATCH v2 0/5] i40e: vector poll-mode driver on ARM64
From: Bruce Richardson @ 2016-10-19 9:20 UTC (permalink / raw)
To: Jianbo Liu; +Cc: helin.zhang, jingjing.wu, jerin.jacob, dev, qi.z.zhang
In-Reply-To: <20161017144434.GA228948@bricha3-MOBL3.ger.corp.intel.com>
On Mon, Oct 17, 2016 at 03:44:34PM +0100, Bruce Richardson wrote:
> On Fri, Oct 14, 2016 at 09:29:59AM +0530, Jianbo Liu wrote:
> > This patch set is to implement i40e vector PMD on ARM64.
> > For x86, vPMD is only reorganized, there should be no performance loss.
> >
> > v1 -> v2
> > - rebase to dpdk-next-net/rel_16_11
> >
> > Jianbo Liu (5):
> > i40e: extract non-x86 specific code from vector driver
> > i40e: implement vector PMD for ARM architecture
> > i40e: enable i40e vector PMD on ARMv8a platform
> > i40e: make vector driver filenames consistent
> > maintainers: claim i40e vector PMD on ARM
> >
> While I haven't reviewed the ARM code, I have run a very quick sanity
> check on an IA platform and saw no performance regression there.
>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Applied to dpdk-next-net/rel_16_11
/Bruce
^ permalink raw reply
* Re: Project Governance and Linux Foundation
From: Jerin Jacob @ 2016-10-19 9:09 UTC (permalink / raw)
To: O'Driscoll, Tim
Cc: Thomas Monjalon, Dave Neary, dev@dpdk.org, users@dpdk.org
In-Reply-To: <26FA93C7ED1EAA44AB77D62FBE1D27BA675F83B2@IRSMSX108.ger.corp.intel.com>
On Wed, Oct 19, 2016 at 08:04:19AM +0000, O'Driscoll, Tim wrote:
> > From: Jerin Jacob [mailto:jerin.jacob@caviumnetworks.com]
> >
> > On Tue, Oct 18, 2016 at 03:27:27PM +0200, Thomas Monjalon wrote:
> > > 2016-10-18 17:04, Jerin Jacob:
> > > > On Mon, Oct 17, 2016 at 05:23:42PM -0400, Dave Neary wrote:
> > > > > > I still hear concerns on this, and based on discussions with
> > others who put their names to the post below, they do too. I think it's
> > a perception that we need to address.
> > > > >
> > > > > I would say that there is still a perception issue, for companies
> > who
> > > > > look at the active developers, the owners of the project's
> > resources
> > > > > (infra, domain name), and who have heard anecdotal evidence of
> > issues in
> > > > > the past. I think the project has made a lot of progress since I
> > have
> > > > > been following it, and I do not believe there are any major issues
> > with
> > > > > the independence of the project. However, there are still
> > concerned
> > > > > parties on this front, and the concerns can be easily addressed by
> > a
> > > > > move to the LF.
> > > >
> > > > +1
> > >
> > > How can we solve issues if you don't give more details than
> > > "hear concerns" or "heard anecdotal evidence of issues"?
> >
> > Honestly, I don't see any issue in the current DPDK project execution.
> > The concern was more towards the fact that multi-vendor infrastructure
> > project
> > like DPDK owned and controlled by the single company.
> >
> > We believe, Moving to LF will fix that issue/perception and it will
> > enable more users to use/consume/invest DPDK in their products.
>
> +1. This is in danger of becoming a never-ending argument. We said in the original post that one of the goals of moving to LF is to "Remove any remaining perception that DPDK is not truly open". I believe that's an important goal for the project and one that we should all agree on.
>
> Whether you choose the accept it or not, it's a fact that concerns exist in the community over the fact that one single company controls the infrastructure for the project. Moving the project to an independent body like the LF would fix that.
>
> > Having said that, Does anyone see any issue in moving to LF?
> > If yes, Then we should enumerate the issues and discuss further.
>
> This is a great point. Can you explain what you see as the benefits of maintaining the current model?
We don't see any additional benefits of maintaining the current model(when we
compare with LF model)
> As far as I can see, the LF model provides everything that we currently have, plus it makes DPDK independent of any single company, and it also gives us the option of availing of other LF services if we choose to do so, including the ability to host lab infrastructure for the project, legal support for trademarks if we need that, event planning etc.
>
> >
> > Jerin
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox