Re: [dpdk-dev] [PATCH 1/7] net/ixgbe/base: support Broadwell-DE XFI backplane
> -Original Message- > From: Yigit, Ferruh > Sent: Wednesday, January 11, 2017 11:38 PM > To: Dai, Wei ; dev@dpdk.org > Cc: Zhang, Helin ; Ananyev, Konstantin > > Subject: Re: [dpdk-dev] [PATCH 1/7] net/ixgbe/base: support Broadwell-DE XFI > backplane > > On 1/10/2017 3:45 PM, Wei Dai wrote: > > This patch adds initial support for a Braodwell-DE XFI backplane > > interface. The XFI backplane requires a custom tuned link. > > Hardware/Firmware owns the link config for XF backplane and software > > must not interfere with it. > > Does it make sense to announce this support in release notes? This is just an initial support and need to be further completed and optimized, So I don't think it is suitable to announce in this release note. Maybe we can do that in next release 17.05 . > > > > > Signed-off-by: Wei Dai > <...>
Re: [dpdk-dev] [PATCH 2/7] net/ixgbe/base: remove a compiler warning
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, January 11, 2017 11:38 PM
> To: Dai, Wei ; dev@dpdk.org
> Cc: Zhang, Helin ; Ananyev, Konstantin
>
> Subject: Re: [dpdk-dev] [PATCH 2/7] net/ixgbe/base: remove a compiler warning
>
> On 1/10/2017 3:45 PM, Wei Dai wrote:
> > This patch fixes a compiler warning.
>
> I guess compiler warning is because of "mac->led_link_act = i;", since
> led_link_act is 8bits..
>
> But can you please add the compile warning here, to make it more clear to
> understand what is the issue.
I have compared the generated ixgbe_common.o both from "u16 i" and "u8 I" .
Two .o files are identical.
Whether the variable i is defined as u8 or u16, there is no compile warning.
The version of gcc version is 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC).
If i is u16, mac->led_link_act = i; should generate a warning, but there is no.
It is a bit weird .
As you know, this code is provided by another Intel team.
I think that it will generate a warning when they build it with their C
compiler.
Anyway, to define i as u8 is better than u16 and we had better keep aligned
with them.
>
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/ixgbe/base/ixgbe_common.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ixgbe/base/ixgbe_common.c
> > b/drivers/net/ixgbe/base/ixgbe_common.c
> > index 18bb18c..0dd33b8 100644
> > --- a/drivers/net/ixgbe/base/ixgbe_common.c
> > +++ b/drivers/net/ixgbe/base/ixgbe_common.c
> > @@ -1150,7 +1150,7 @@ s32 ixgbe_init_led_link_act_generic(struct
> > ixgbe_hw *hw) {
> > struct ixgbe_mac_info *mac = &hw->mac;
> > u32 led_reg, led_mode;
> > - u16 i;
> > + u8 i;
> >
> > led_reg = IXGBE_READ_REG(hw, IXGBE_LEDCTL);
> >
> >
Re: [dpdk-dev] [PATCH 6/7] net/ixgbe/base: add some debug traces
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, January 11, 2017 11:39 PM
> To: Dai, Wei ; dev@dpdk.org
> Cc: Zhang, Helin ; Ananyev, Konstantin
>
> Subject: Re: [dpdk-dev] [PATCH 6/7] net/ixgbe/base: add some debug traces
>
> On 1/10/2017 3:45 PM, Wei Dai wrote:
> > This patch adds some traces in the reset_hw logic and semaphore
> > acquisition logic to help debugging.
>
> Is verbosity of the PMD changes with this update?
>
> Is something required in PMD to disable DEBUGOUT1(), DEBUGOUT2(),
> DEBUGOUT() by default?
In drivers/net/ixgbe/ixgbe_logs.h, there are
#ifdef RTE_LIBRTE_IXGBE_DEBUG_DRIVER
#define PMD_DRV_LOG_RAW(level, fmt, args...) \
RTE_LOG(level, PMD, "%s(): " fmt, __func__, ## args)
#else
#define PMD_DRV_LOG_RAW(level, fmt, args...) do { } while (0)
#endif
And in drivers/net/ixgbe/base/ixgbe_osdep.h, there are
#include "../ixgbe_logs.h"
#define DEBUGOUT(S, args...)PMD_DRV_LOG_RAW(DEBUG, S, ##args)
#define DEBUGOUT1(S, args...) DEBUGOUT(S, ##args)
#define DEBUGOUT2(S, args...) DEBUGOUT(S, ##args)
#define DEBUGOUT3(S, args...) DEBUGOUT(S, ##args)
#define DEBUGOUT6(S, args...) DEBUGOUT(S, ##args)
#define DEBUGOUT7(S, args...) DEBUGOUT(S, ##args)
In config/common_base, there is
CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n
So according above codes, the macro RTE_LIBRTE_IXGBE_DEBUG_DRIVER in
drivers/net/ixgbe/ixgbe_logs.h is not defined
and PMD_DRV_LOG_RAW(level, fmt, args...) do { } while (0) will be valid,
then DEBUGOUT() is just a null definition by default.
>
> >
> > Signed-off-by: Wei Dai
> > ---
>
> <...>
Re: [dpdk-dev] [PATCH v5 00/18] net/ixgbe: Consistent filter API
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Xing, Beilei > Sent: Thursday, January 12, 2017 7:39 PM > To: Zhao1, Wei ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v5 00/18] net/ixgbe: Consistent filter API > > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao > > Sent: Thursday, January 12, 2017 5:17 PM > > To: dev@dpdk.org > > Subject: [dpdk-dev] [PATCH v5 00/18] net/ixgbe: Consistent filter API > > > > The patches mainly finish following functions: > > 1) Store and restore all kinds of filters. > > 2) Parse all kinds of filters. > > 3) Add flow validate function. > > 4) Add flow create function. > > 5) Add flow destroy function. > > 6) Add flow flush function. > > > > v2 changes: > > fix git log error > > Modify some function call relationship Change return value type of > > all parse flow functions Update error info for all flow ops Add > > ixgbe_filterlist_flush to flush flows and rules created > > > > v3 change: > > add new file ixgbe_flow.c to store generic API parser related > > functions add more comment about pattern and action rules add attr > > check in parser functions change struct name ixgbe_flow to rte_flow > > change SYN to TCP SYN change to use memset initizlize struct > > ixgbe_filter_info break down filter uninit process to 3 indepedent > > functions in eth_ixgbe_dev_uninit() change struct rte_flow_item_nvgre > > definition change struct rte_flow_item_e_tag definition fix one bug > > in function ixgbe_dev_filter_ctrl add goto in function > > ixgbe_flow_create delete some useless initialization eliminate some > > git log check warning > > > > v4 change: > > fix some check patch warning > > > > v5 change: > > fix some git log warning > > > > zhao wei (18): > > net/ixgbe: store TCP SYN filter > > net/ixgbe: store flow director filter > > net/ixgbe: store L2 tunnel filter > > net/ixgbe: restore n-tuple filter > > net/ixgbe: restore ether type filter > > net/ixgbe: restore TCP SYN filter > > net/ixgbe: restore flow director filter > > net/ixgbe: restore L2 tunnel filter > > net/ixgbe: store and restore L2 tunnel configuration > > net/ixgbe: flush all the filters > > net/ixgbe: parse n-tuple filter > > net/ixgbe: parse ethertype filter > > net/ixgbe: parse TCP SYN filter > > net/ixgbe: parse L2 tunnel filter > > net/ixgbe: parse flow director filter > > net/ixgbe: create consistent filter > > net/ixgbe: destroy consistent filter > > net/ixgbe: flush all the filter list > > > > drivers/net/ixgbe/Makefile |2 + > > drivers/net/ixgbe/ixgbe_ethdev.c | 667 +++-- > > drivers/net/ixgbe/ixgbe_ethdev.h | 203 ++- > > drivers/net/ixgbe/ixgbe_fdir.c | 407 -- > > drivers/net/ixgbe/ixgbe_flow.c | 2808 > > ++ > > drivers/net/ixgbe/ixgbe_pf.c | 26 +- > > lib/librte_ether/rte_flow.h | 48 + > > 7 files changed, 3950 insertions(+), 211 deletions(-) create mode > > 100644 drivers/net/ixgbe/ixgbe_flow.c > > > Acked-by: Beilei Xing Acked-by: Wei Dai
Re: [dpdk-dev] [PATCH v3] net/ixgbe:fix max packet length in ixgbevf
I think your patch does fix an error in ixgbevf and I can acknowledge it after I have checked with 82599 and x540 and x550 datasheet. In 82599 datasheet, there is an annotation in the chapter 1.3 Features Summary (page 29) The 82599 supports full-size 15.5 KB (15872-byte) jumbo packets while in a basic mode of operation. When DCB mode is enabled, or security engines enabled or virtualization is enabled, the 82599 supports 9.5 KB (9728-byte) jumbo packets In x540 datasheet, there is also an annotation in the chapter 1.3 Features Summary (page 13) The X540 and 82599 support full-size 15.5 KB jumbo packets while in a basic mode of operation. When DCB mode is enabled, or security engines enabled, or virtualization is enabled, or OS2BMC is enabled, then the X540 supports 9.5 KB jumbo packets. Packets to/from MC longer than 2KB are filtered out. In x550 datasheet, there is still also an annotation in the chapter 1.4 Feature Summary (page 23) All the products support full-size 15.5 KB jumbo packets while in a basic mode of operation. When DCB mode is enabled, or security engines enabled, or virtualization is enabled, or OS2BMC is enabled, then only 9.5 KB jumbo packets are supported. Packets to/ from the MC longer than 2 KB are filtered out. > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yuanhan Liu > Sent: Wednesday, December 14, 2016 3:06 PM > To: Yi Zhang > Cc: Zhang, Helin ; Ananyev, Konstantin > ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3] net/ixgbe:fix max packet length in ixgbevf > > On Thu, Dec 15, 2016 at 02:50:19AM +0800, Yi Zhang wrote: > > Current ixgbevf driver get max_rx_pktlen = 15872, but in fact PF > > supports 15872-byte jumbo frame and VF only supports 9728-byte jumbo > > frame. If VF is running DPDK driver and set frame_size > 9728 ,PF > > running kernel ixgbe driver will report an error and set VF failed. > > This patch fixs DPDK ixgbevf driver to get correct jumbo frame size of > > VF. > > > > Signed-off-by: Yi Zhang > > Hi, > > I saw you have sent this patch 3 times; are you looking for review? > If so, you should not resend it many times, instead, you could reply to your > patch if it hasn't got any comments after one week, with something like "some > one can help review this?", or even a simple "ping ..." might just work. > > Besides that, you should Cc the corresponding maintainers, but not > "maintai...@some.org", which is just an example: I doubt such email exists. > > You could get the maintainers from the MAINTAINERS. Take ixgbe as example, > it's: > > Intel ixgbe > M: Helin Zhang > M: Konstantin Ananyev > F: drivers/net/ixgbe/ > F: doc/guides/nics/ixgbe.rst > F: doc/guides/nics/intel_vf.rst > > So for this patch, you should at least Cc (or To) Helin and Konstantin. > I have done that for you this time. > > --yliu > > --- > > 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 edc9b22..573252c 100644 > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > > @@ -3168,7 +3168,7 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev, > > dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues; > > dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues; > > dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL reg */ > > - dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS reg */ > > + dev_info->max_rx_pktlen = 9728; /* includes CRC, cf MAXFRS reg */ > > dev_info->max_mac_addrs = hw->mac.num_rar_entries; > > dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC; > > dev_info->max_vfs = dev->pci_dev->max_vfs; > > -- > > 2.9.3 > >
Re: [dpdk-dev] [PATCH v3] net/ixgbe:fix max packet length in ixgbevf
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dai, Wei > Sent: Wednesday, January 25, 2017 9:40 AM > To: Yuanhan Liu ; Yi Zhang > > Cc: Zhang, Helin ; Ananyev, Konstantin > ; dev@dpdk.org; Lu, Wenzhuo > > Subject: Re: [dpdk-dev] [PATCH v3] net/ixgbe:fix max packet length in ixgbevf > > I think your patch does fix an error in ixgbevf and I can acknowledge it > after I > have checked with 82599 and x540 and x550 datasheet. > > In 82599 datasheet, there is an annotation in the chapter 1.3 Features > Summary (page 29) The 82599 supports full-size 15.5 KB (15872-byte) jumbo > packets while in a basic mode of operation. When DCB mode is enabled, or > security engines enabled or virtualization is enabled, the 82599 supports 9.5 > KB > (9728-byte) jumbo packets > > In x540 datasheet, there is also an annotation in the chapter 1.3 Features > Summary (page 13) The X540 and 82599 support full-size 15.5 KB jumbo > packets while in a basic mode of operation. When DCB mode is enabled, or > security engines enabled, or virtualization is enabled, or OS2BMC is enabled, > then the X540 supports 9.5 KB jumbo packets. > Packets to/from MC longer than 2KB are filtered out. > > In x550 datasheet, there is still also an annotation in the chapter 1.4 > Feature > Summary (page 23) All the products support full-size 15.5 KB jumbo packets > while in a basic mode of operation. When DCB mode is enabled, or security > engines enabled, or virtualization is enabled, or OS2BMC is enabled, then only > 9.5 KB jumbo packets are supported. Packets to/ from the MC longer than 2 KB > are filtered out. > > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yuanhan Liu > > Sent: Wednesday, December 14, 2016 3:06 PM > > To: Yi Zhang > > Cc: Zhang, Helin ; Ananyev, Konstantin > > ; dev@dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v3] net/ixgbe:fix max packet length in > > ixgbevf > > > > On Thu, Dec 15, 2016 at 02:50:19AM +0800, Yi Zhang wrote: > > > Current ixgbevf driver get max_rx_pktlen = 15872, but in fact PF > > > supports 15872-byte jumbo frame and VF only supports 9728-byte jumbo > > > frame. If VF is running DPDK driver and set frame_size > 9728 ,PF > > > running kernel ixgbe driver will report an error and set VF failed. > > > This patch fixs DPDK ixgbevf driver to get correct jumbo frame size > > > of VF. > > > > > > Signed-off-by: Yi Zhang Acked-by: Wei Dai > > > > Hi, > > > > I saw you have sent this patch 3 times; are you looking for review? > > If so, you should not resend it many times, instead, you could reply > > to your patch if it hasn't got any comments after one week, with > > something like "some one can help review this?", or even a simple "ping ..." > might just work. > > > > Besides that, you should Cc the corresponding maintainers, but not > > "maintai...@some.org", which is just an example: I doubt such email exists. > > > > You could get the maintainers from the MAINTAINERS. Take ixgbe as > > example, > > it's: > > > > Intel ixgbe > > M: Helin Zhang > > M: Konstantin Ananyev > > F: drivers/net/ixgbe/ > > F: doc/guides/nics/ixgbe.rst > > F: doc/guides/nics/intel_vf.rst > > > > So for this patch, you should at least Cc (or To) Helin and Konstantin. > > I have done that for you this time. > > > > --yliu > > > --- > > > 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 edc9b22..573252c 100644 > > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c > > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > > > @@ -3168,7 +3168,7 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev, > > > dev_info->max_rx_queues = (uint16_t)hw->mac.max_rx_queues; > > > dev_info->max_tx_queues = (uint16_t)hw->mac.max_tx_queues; > > > dev_info->min_rx_bufsize = 1024; /* cf BSIZEPACKET in SRRCTL reg */ > > > - dev_info->max_rx_pktlen = 15872; /* includes CRC, cf MAXFRS reg */ > > > + dev_info->max_rx_pktlen = 9728; /* includes CRC, cf MAXFRS reg */ > > > dev_info->max_mac_addrs = hw->mac.num_rar_entries; > > > dev_info->max_hash_mac_addrs = IXGBE_VMDQ_NUM_UC_MAC; > > > dev_info->max_vfs = dev->pci_dev->max_vfs; > > > -- > > > 2.9.3 > > >
Re: [dpdk-dev] [PATCH 6/7] ixgbe: remove useless return
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev, Konstantin
> Sent: Thursday, February 2, 2017 12:41 AM
> To: Stephen Hemminger ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 6/7] ixgbe: remove useless return
Subject line had better be net/ixgbe: remove useless return
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Stephen Hemminger
> > Sent: Monday, January 9, 2017 11:30 PM
> > To: dev@dpdk.org
> > Cc: Stephen Hemminger
> > Subject: [dpdk-dev] [PATCH 6/7] ixgbe: remove useless return
> >
> > If all goto's lead to a return, then better to get rid of goto.
> >
> > Signed-off-by: Stephen Hemminger
> > ---
> > drivers/net/ixgbe/ixgbe_82599_bypass.c | 10 --
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_82599_bypass.c
> > b/drivers/net/ixgbe/ixgbe_82599_bypass.c
> > index de9fa5a7..af55cc0a 100644
> > --- a/drivers/net/ixgbe/ixgbe_82599_bypass.c
> > +++ b/drivers/net/ixgbe/ixgbe_82599_bypass.c
> > @@ -73,7 +73,7 @@ ixgbe_set_fiber_fixed_speed(struct ixgbe_hw *hw,
> ixgbe_link_speed speed)
> >&eeprom_data);
> > if (status) {
> > PMD_DRV_LOG(ERR, "Failed to read Rx Rate Select RS0");
> > - goto out;
> > + return;
> > }
> >
> > eeprom_data = (eeprom_data & ~IXGBE_SFF_SOFT_RS_SELECT_MASK) &
> rs;
> > @@ -83,7 +83,7 @@ ixgbe_set_fiber_fixed_speed(struct ixgbe_hw *hw,
> ixgbe_link_speed speed)
> > eeprom_data);
> > if (status) {
> > PMD_DRV_LOG(ERR, "Failed to write Rx Rate Select RS0");
> > - goto out;
> > + return;
> > }
> >
> > /* Set RS1 */
> > @@ -92,7 +92,7 @@ ixgbe_set_fiber_fixed_speed(struct ixgbe_hw *hw,
> ixgbe_link_speed speed)
> >&eeprom_data);
> > if (status) {
> > PMD_DRV_LOG(ERR, "Failed to read Rx Rate Select RS1");
> > - goto out;
> > + return;
> > }
> >
> > eeprom_data = (eeprom_data & ~IXGBE_SFF_SOFT_RS_SELECT_MASK) &
> rs;
> > @@ -102,10 +102,8 @@ ixgbe_set_fiber_fixed_speed(struct ixgbe_hw *hw,
> ixgbe_link_speed speed)
> > eeprom_data);
> > if (status) {
> > PMD_DRV_LOG(ERR, "Failed to write Rx Rate Select RS1");
> > - goto out;
> > + return;
This return is also not needed. :-)
> > }
> > -out:
> > - return;
> > }
> >
> > /**
> > --
>
> Acked-by: Konstantin Ananyev
Acked-by: Wei Dai
>
> > 2.11.0
Re: [dpdk-dev] [PATCH] net/ixgbe: ensure link status is updated
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Laurent Hardy
> Sent: Friday, November 18, 2016 1:30 AM
> To: Zhang, Helin ; Ananyev, Konstantin
>
> Cc: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH] net/ixgbe: ensure link status is updated
>
> In case of link speed set to 1Gb at peer side (with autoneg or with defined
> speed) and cable not plugged-in when device is configured and started, then
> link status is not updated properly with new speed as no link setup is
> triggered.
>
> To avoid this issue, IXGBE_FLAG_NEED_LINK_CONFIG is set to try a link setup
> each time link_update() is triggered and current link status is down. When
> cable is plugged-in, link setup will be performed via ixgbe_setup_link().
>
> Signed-off-by: Laurent Hardy
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 20
> drivers/net/ixgbe/ixgbe_ethdev.h |1 +
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 52ebbe4..513d1d5 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -2095,6 +2095,7 @@ ixgbe_dev_configure(struct rte_eth_dev *dev)
>
> /* set flag to update link status after init */
> intr->flags |= IXGBE_FLAG_NEED_LINK_UPDATE;
> + intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;
>
> /*
>* Initialize to TRUE. If any of Rx queues doesn't meet the bulk @@
> -3117,8 +3118,12 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int
> wait_to_complete)
> struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> struct rte_eth_link link, old;
> ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
> + struct ixgbe_interrupt *intr =
> + IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
> int link_up;
> int diag;
> + u32 speed = 0;
> + bool autoneg = false;
>
> link.link_status = ETH_LINK_DOWN;
> link.link_speed = 0;
> @@ -3128,6 +3133,19 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev,
> int wait_to_complete)
>
> hw->mac.get_link_status = true;
>
> + if (intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) {
> + speed = hw->phy.autoneg_advertised;
> + if (!speed) {
> + ixgbe_get_link_capabilities(hw, &speed, &autoneg);
> + /* setup the highest link when no autoneg */
> + if (!autoneg) {
> + if (speed & IXGBE_LINK_SPEED_10GB_FULL)
> + speed = IXGBE_LINK_SPEED_10GB_FULL;
> + }
> + }
> + ixgbe_setup_link(hw, speed, true);
> + }
> +
> /* check if it needs to wait to complete, if lsc interrupt is enabled */
> if (wait_to_complete == 0 || dev->data->dev_conf.intr_conf.lsc != 0)
> diag = ixgbe_check_link(hw, &link_speed, &link_up, 0); @@
> -3145,10
> +3163,12 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int
> wait_to_complete)
>
> if (link_up == 0) {
> rte_ixgbe_dev_atomic_write_link_status(dev, &link);
> + intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;
> if (link.link_status == old.link_status)
> return -1;
> return 0;
> }
> + intr->flags &= ~IXGBE_FLAG_NEED_LINK_CONFIG;
> link.link_status = ETH_LINK_UP;
> link.link_duplex = ETH_LINK_FULL_DUPLEX;
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h
> b/drivers/net/ixgbe/ixgbe_ethdev.h
> index e060c3d..9d335ba 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.h
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.h
> @@ -43,6 +43,7 @@
> #define IXGBE_FLAG_NEED_LINK_UPDATE (uint32_t)(1 << 0)
> #define IXGBE_FLAG_MAILBOX (uint32_t)(1 << 1)
> #define IXGBE_FLAG_PHY_INTERRUPT(uint32_t)(1 << 2)
> +#define IXGBE_FLAG_NEED_LINK_CONFIG (uint32_t)(1 << 3)
Now there is following macro in DPDK 17.02-rc2.
#define IXGBE_FLAG_MACSEC (uint32_t)(1 << 3)
You can redefine it as #define IXGBE_FLAG_NEED_LINK_CONFIG (uint32_t)(1 << 4)
>
> /*
> * Defines that were not part of ixgbe_type.h as they are not used by the
> --
> 1.7.10.4
Re: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a PF reset
The stats register can rewind to zero when the port is running for a long
period.
So I am afraid that this check is not always correct.
Why not introduce a variable to directly indicate whether the resulted stats
should be updated or not.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz
> Sent: Monday, February 6, 2017 9:59 PM
> To: dev@dpdk.org; Zhang, Helin ; Ananyev,
> Konstantin
> Cc: Guo Fengtian ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a PF reset
>
> Hi,
>
> On Wed, 11 Jan 2017 18:04:14 +0100, Olivier Matz
> wrote:
> > From: Guo Fengtian
> >
> > When PF is set down, in VF, the value of stats register is zero.
> > So only increase stats when it's non zero.
> >
> > Fixes: af75078fece3 ("first public release")
> >
> > CC: sta...@dpdk.org
> > Signed-off-by: Guo Fengtian
> > Signed-off-by: Olivier Matz
>
> Ping
>
>
> Thanks,
> Olivier
Re: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a PF reset
Another way is to clear
hw_stats->last_vfgprc/last_vfgorc/last_vfgptc/last_vfmprc
at the same time PF is set down.
> -Original Message-
> From: Dai, Wei
> Sent: Thursday, February 9, 2017 10:38 PM
> To: 'Olivier Matz' ; dev@dpdk.org; Zhang, Helin
> ; Ananyev, Konstantin
>
> Cc: Guo Fengtian ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a PF reset
>
> The stats register can rewind to zero when the port is running for a long
> period.
> So I am afraid that this check is not always correct.
> Why not introduce a variable to directly indicate whether the resulted stats
> should be updated or not.
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Olivier Matz
> > Sent: Monday, February 6, 2017 9:59 PM
> > To: dev@dpdk.org; Zhang, Helin ; Ananyev,
> > Konstantin
> > Cc: Guo Fengtian ; sta...@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a
> > PF reset
> >
> > Hi,
> >
> > On Wed, 11 Jan 2017 18:04:14 +0100, Olivier Matz
> >
> > wrote:
> > > From: Guo Fengtian
> > >
> > > When PF is set down, in VF, the value of stats register is zero.
> > > So only increase stats when it's non zero.
> > >
> > > Fixes: af75078fece3 ("first public release")
> > >
> > > CC: sta...@dpdk.org
> > > Signed-off-by: Guo Fengtian
> > > Signed-off-by: Olivier Matz
> >
> > Ping
> >
> >
> > Thanks,
> > Olivier
Re: [dpdk-dev] [PATCH 29/29] net/ixgbe/base: update version of basical codes in README
Thanks to Yigit Ferruh. > -Original Message- > From: Yigit, Ferruh > Sent: Tuesday, December 6, 2016 3:41 AM > To: Dai, Wei ; Zhang, Helin ; > Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 29/29] net/ixgbe/base: update version of > basical > codes in README > > On 12/4/2016 6:31 AM, Wei Dai wrote: > > update the version of shared codes to cid-ixgbe.2016.11.21.tar.gz, all > > files in net/ixgbe/base are developped by another team and DPDK PMD > > uses them accordingly. > > > > Signed-off-by: Wei Dai > > --- > > drivers/net/ixgbe/base/README | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/ixgbe/base/README > > b/drivers/net/ixgbe/base/README index 6b54c31..84773ff 100644 > > --- a/drivers/net/ixgbe/base/README > > +++ b/drivers/net/ixgbe/base/README > > @@ -34,7 +34,8 @@ Intel® IXGBE driver > > === > > > > This directory contains source code of FreeBSD ixgbe driver of > > version > > -cid-10g-shared-code.2016.08.15 released by ND. The sub-directory of > > base/ > > +cid-10g-shared-code.2016.08.15 released by the team which develop > > I guess version needs to be updated to 2016.11.21 ? Yes, it should be updated to 2016.11.21 . > > > +basical drivers for any ixgbe NIC. The sub-directory of base/ > > contains the original source package. > > This driver is valid for the product(s) listed below > > > >
Re: [dpdk-dev] [PATCH 24/29] net/ixgbe/base: add EEE support for DNL-controlled PHYs
> -Original Message-
> From: Yigit, Ferruh
> Sent: Tuesday, December 6, 2016 3:41 AM
> To: Dai, Wei ; Zhang, Helin ;
> Ananyev, Konstantin
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 24/29] net/ixgbe/base: add EEE support for
> DNL-controlled PHYs
>
> On 12/4/2016 6:31 AM, Wei Dai wrote:
> > This patch adds EEE support for DNL-controlled PHYs. Because DNL
>
> What is DNL?
DNL is short for name of some method to control Marvel PHY.
This git log message will be revised in v2 patch set.
>
> > does not indicate EEE capability or status, this patch simply assumes
> > that it is supported. As soon as there is a DNL-supported PHY that
> > does not support EEE, there will be defects in this area because the
> > driver will not report the EEE status correctly.
> > This also deletes some now-unused definitions from an earlier Marvell
> > PHY implementation and combines a device ID check into a switch
> > statement.
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/ixgbe/base/ixgbe_type.h | 8
> > drivers/net/ixgbe/base/ixgbe_x550.c | 15 +++
> > 2 files changed, 7 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/net/ixgbe/base/ixgbe_type.h
> > b/drivers/net/ixgbe/base/ixgbe_type.h
> > index 9ec17a9..f1761a3 100644
> > --- a/drivers/net/ixgbe/base/ixgbe_type.h
> > +++ b/drivers/net/ixgbe/base/ixgbe_type.h
> > @@ -3720,14 +3720,6 @@ enum ixgbe_fc_mode {
> > ixgbe_fc_default
> > };
> >
> > -/* Master/slave control */
> > -enum ixgbe_ms_type {
> > - ixgbe_ms_hw_default = 0,
> > - ixgbe_ms_force_master,
> > - ixgbe_ms_force_slave,
> > - ixgbe_ms_auto
> > -};
> > -
>
> This seems not related to this patchset, also patch 15/29 has [1] again seems
> unrelated to that patch, does it make sense to make these a separate patch?
Yes, in v2 patch set, removing of above enum type will be in a separate one.
>
> [1]
> "
> @@ -4046,8 +4112,8 @@ struct ixgbe_phy_info {
> bool reset_disable;
> ixgbe_autoneg_advertised autoneg_advertised;
> ixgbe_link_speed speeds_supported;
> - enum ixgbe_ms_type ms_type;
> - enum ixgbe_ms_type original_ms_type;
>
>
Re: [dpdk-dev] [PATCH 27/29] net/ixgbe/base: add write flush required by Inphi
> -Original Message- > From: Yigit, Ferruh > Sent: Tuesday, December 6, 2016 3:41 AM > To: Dai, Wei ; Zhang, Helin ; > Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 27/29] net/ixgbe/base: add write flush required > by Inphi > > On 12/4/2016 6:31 AM, Wei Dai wrote: > > This patch updates Inphi configuration to flush the register write > > with > > Do we really need to mention from Inphi here? If so, can you please explain > what it is? Inphi (www.inphi.com) is a company which provides PHYs. So I will use "Inphi PHY" instead of "Inphi" in v2 patch set. > > > a reg read. Inphi is configured in ixgbe_setup_mac_link_sfp_x550a. > > The Inphy setup flow has been updated to read configuration reg, write > > only linear/non-linear, and then read (write flush). > > Also patch does [1] seems not mentioned in the commit log, can you please add > information for it? Yes, following statement is redundant, but in order to simplify the process to keep up with the shared code provided by another team (Intel Network Division), I'd like to keep it here. Anyway it is harmless. > > [1] > > + reg_phy_ext &= ~((IXGBE_CS4227_EDC_MODE_CX1 << 1) | > > +(IXGBE_CS4227_EDC_MODE_SR << 1)); > > > > > Signed-off-by: Wei Dai > > --- > > drivers/net/ixgbe/base/ixgbe_x550.c | 14 ++ > > 1 file changed, 14 insertions(+) > > > > diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c > > b/drivers/net/ixgbe/base/ixgbe_x550.c > > index 4a98530..a57ba74 100644 > > --- a/drivers/net/ixgbe/base/ixgbe_x550.c > > +++ b/drivers/net/ixgbe/base/ixgbe_x550.c > > @@ -2834,12 +2834,26 @@ s32 ixgbe_setup_mac_link_sfp_x550a(struct > > ixgbe_hw *hw, > > > > /* Configure CS4227/CS4223 LINE side to proper mode. */ > > reg_slice = IXGBE_CS4227_LINE_SPARE24_LSB + slice_offset; > > + > > + ret_val = hw->phy.ops.read_reg(hw, reg_slice, > > + IXGBE_MDIO_ZERO_DEV_TYPE, ®_phy_ext); > > + > > + if (ret_val != IXGBE_SUCCESS) > > + return ret_val; > > + > > + reg_phy_ext &= ~((IXGBE_CS4227_EDC_MODE_CX1 << 1) | > > +(IXGBE_CS4227_EDC_MODE_SR << 1)); > > + > > if (setup_linear) > > reg_phy_ext = (IXGBE_CS4227_EDC_MODE_CX1 << 1) | 0x1; > > else > > reg_phy_ext = (IXGBE_CS4227_EDC_MODE_SR << 1) | 0x1; > > ret_val = hw->phy.ops.write_reg(hw, reg_slice, > > IXGBE_MDIO_ZERO_DEV_TYPE, reg_phy_ext); > > + > > + /* Flush previous write with a read */ > > + ret_val = hw->phy.ops.read_reg(hw, reg_slice, > > + IXGBE_MDIO_ZERO_DEV_TYPE, ®_phy_ext); > > } > > return ret_val; > > } > >
Re: [dpdk-dev] [PATCH 29/29] net/ixgbe/base: update version of basical codes in README
Thanks for your correcting. > -Original Message- > From: Yigit, Ferruh > Sent: Tuesday, December 6, 2016 3:41 AM > To: Dai, Wei ; Zhang, Helin ; > Ananyev, Konstantin > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 29/29] net/ixgbe/base: update version of > basical > codes in README > > On 12/4/2016 6:31 AM, Wei Dai wrote: > > update the version of shared codes to cid-ixgbe.2016.11.21.tar.gz, all > > files in net/ixgbe/base are developped by another team and DPDK PMD > > uses them accordingly. > > > > Signed-off-by: Wei Dai > > --- > > drivers/net/ixgbe/base/README | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/net/ixgbe/base/README > > b/drivers/net/ixgbe/base/README index 6b54c31..84773ff 100644 > > --- a/drivers/net/ixgbe/base/README > > +++ b/drivers/net/ixgbe/base/README > > @@ -34,7 +34,8 @@ Intel® IXGBE driver > > === > > > > This directory contains source code of FreeBSD ixgbe driver of > > version > > -cid-10g-shared-code.2016.08.15 released by ND. The sub-directory of > > base/ > > +cid-10g-shared-code.2016.08.15 released by the team which develop > > I guess version needs to be updated to 2016.11.21 ? Yes, it should be 2016.11.21. It will be corrected in v2 patch. > > > +basical drivers for any ixgbe NIC. The sub-directory of base/ > > contains the original source package. > > This driver is valid for the product(s) listed below > > > >
Re: [dpdk-dev] [PATCH v2 00/30] update ixgbe shared code to version 16.11.21
Many thanks to you for your taking time to review this patch set. Thanks -Wei > -Original Message- > From: Yigit, Ferruh > Sent: Thursday, December 22, 2016 1:20 AM > To: Dai, Wei ; dev@dpdk.org > Cc: Zhang, Helin ; Ananyev, Konstantin > > Subject: Re: [dpdk-dev] [PATCH v2 00/30] update ixgbe shared code to version > 16.11.21 > > On 12/21/2016 9:47 AM, Wei Dai wrote: > > update ixgbe shared code to version 16.11.21 . > > v2 changes: > > modify subject line and message body of git log according to > > feedbacks from communtiy. > > > > split the 24th patch into 2 separate ones. > > the 24th of v1 is net/ixgbe/base: add EEE support for DNL-controlled PHYs > > the 24th of v2 is net/ixgbe/base: add EEE support for some PHYs > > the 25th of v2 is net/ixgbe/base: remove unused enum type > > > > correct RAEDME > > > > Wei Dai (30): > > net/ixgbe/base: fix PHY reset check for x550em-ext > > net/ixgbe/base: fix clearing SAN MAC address > > net/ixgbe/base: use fast MDIO for non-10G devices > > net/ixgbe/base: fix PHY identification for x550a > > net/ixgbe/base: clean up X557 link status check > > net/ixgbe/base: add driver version to firmware > > net/ixgbe/base: store link active LED > > net/ixgbe/base: cleanup X540 checksum calculation > > net/ixgbe/base: enable LASI only for X552 devices > > net/ixgbe/base: limit iXFI setup to X552 devices > > net/ixgbe/base: fix getting PHY type for some x550 devices > > net/ixgbe/base: fix SGMII link setup for M88 PHYs > > net/ixgbe/base: cleanup dead EEE code > > net/ixgbe/base: fix setting unsupported autoneg speeds > > net/ixgbe/base: support FW commands to control some PHYs > > net/ixgbe/base: use FW commands to control some PHYs > > net/ixgbe/base: support busy SGMII register reads > > net/ixgbe/base: include new speeds in VFLINK interpretation > > net/ixgbe/base: limit 5Gb support to X550 devices > > net/ixgbe/base: add physical layer options for FW PHY type > > net/ixgbe/base: remove unneeded MAC type check > > net/ixgbe/base: remove unused PHY ID > > net/ixgbe/base: update FW PHY flow control > > net/ixgbe/base: add EEE support for some PHYs > > net/ixgbe/base: remove unused enum type > > net/ixgbe/base: fix IXGBE LSWFW register > > net/ixgbe/base: remove unused EEE code > > net/ixgbe/base: add write flush required by Inphi PHY > > net/ixgbe/base: report physical layer for SGMII PHY type > > net/ixgbe/base: update shared code version to 2016.11.21 > <...> > > Series applied to dpdk-next-net/master, thanks. >
Re: [dpdk-dev] [PATCH v2 02/18] net/ixgbe: store flow director filter
Hi, Wei Zhao
Would you please do git rebase master for this patch set?
When I do git pull and then git apply this patch, following errors are reported:
[root@dpdk4 dpdk-org]# git am
../patches/bundle-488-zhaowei-ixgbe-filter-api-v2.mbox
Applying: net/ixgbe: store SYN filter
Applying: net/ixgbe: store flow director filter
error: patch failed: drivers/net/ixgbe/ixgbe_ethdev.c:1284
error: drivers/net/ixgbe/ixgbe_ethdev.c: patch does not apply
Patch failed at 0002 net/ixgbe: store flow director filter
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Friday, December 30, 2016 3:53 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; Zhao1, Wei
> Subject: [dpdk-dev] [PATCH v2 02/18] net/ixgbe: store flow director filter
>
> Add support for storing flow director filter in SW.
>
> Signed-off-by: Wenzhuo Lu
> Signed-off-by: Wei Zhao
> ---
>
> v2:
> --add a fdir initialization function in device start process
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 55
> drivers/net/ixgbe/ixgbe_ethdev.h | 19 ++-
> drivers/net/ixgbe/ixgbe_fdir.c | 105
> ++-
> 3 files changed, 176 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 316e560..de27a73 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -60,6 +60,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ixgbe_logs.h"
> #include "base/ixgbe_api.h"
> @@ -165,6 +166,7 @@ enum ixgbevf_xcast_modes {
>
> static int eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev); static int
> eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev);
> +static int ixgbe_fdir_filter_init(struct rte_eth_dev *eth_dev);
> static int ixgbe_dev_configure(struct rte_eth_dev *dev); static int
> ixgbe_dev_start(struct rte_eth_dev *dev); static void ixgbe_dev_stop(struct
> rte_eth_dev *dev); @@ -1276,6 +1278,9 @@ eth_ixgbe_dev_init(struct
> rte_eth_dev *eth_dev)
>
> /* initialize SYN filter */
> filter_info->syn_info = 0;
> + /* initialize flow director filter list & hash */
> + ixgbe_fdir_filter_init(eth_dev);
> +
> return 0;
> }
>
> @@ -1284,6 +1289,9 @@ eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev)
> {
> struct rte_pci_device *pci_dev;
> struct ixgbe_hw *hw;
> + struct ixgbe_hw_fdir_info *fdir_info =
> + IXGBE_DEV_PRIVATE_TO_FDIR_INFO(eth_dev->data->dev_private);
> + struct ixgbe_fdir_filter *fdir_filter;
>
> PMD_INIT_FUNC_TRACE();
>
> @@ -1317,9 +1325,56 @@ eth_ixgbe_dev_uninit(struct rte_eth_dev
> *eth_dev)
> rte_free(eth_dev->data->hash_mac_addrs);
> eth_dev->data->hash_mac_addrs = NULL;
>
> + /* remove all the fdir filters & hash */
> + if (fdir_info->hash_map)
> + rte_free(fdir_info->hash_map);
> + if (fdir_info->hash_handle)
> + rte_hash_free(fdir_info->hash_handle);
> +
> + while ((fdir_filter = TAILQ_FIRST(&fdir_info->fdir_list))) {
> + TAILQ_REMOVE(&fdir_info->fdir_list,
> + fdir_filter,
> + entries);
> + rte_free(fdir_filter);
> + }
> +
> return 0;
> }
>
> +static int ixgbe_fdir_filter_init(struct rte_eth_dev *eth_dev) {
> + struct ixgbe_hw_fdir_info *fdir_info =
> + IXGBE_DEV_PRIVATE_TO_FDIR_INFO(eth_dev->data->dev_private);
> + char fdir_hash_name[RTE_HASH_NAMESIZE];
> + struct rte_hash_parameters fdir_hash_params = {
> + .name = fdir_hash_name,
> + .entries = IXGBE_MAX_FDIR_FILTER_NUM,
> + .key_len = sizeof(union ixgbe_atr_input),
> + .hash_func = rte_hash_crc,
> + .hash_func_init_val = 0,
> + .socket_id = rte_socket_id(),
> + };
> +
> + TAILQ_INIT(&fdir_info->fdir_list);
> + snprintf(fdir_hash_name, RTE_HASH_NAMESIZE,
> + "fdir_%s", eth_dev->data->name);
> + fdir_info->hash_handle = rte_hash_create(&fdir_hash_params);
> + if (!fdir_info->hash_handle) {
> + PMD_INIT_LOG(ERR, "Failed to create fdir hash table!");
> + return -EINVAL;
> + }
> + fdir_info->hash_map = rte_zmalloc("ixgbe",
> + sizeof(struct ixgbe_fdir_filter *) *
> + IXGBE_MAX_FDIR_FILTER_NUM,
> + 0);
> + if (!fdir_info->hash_map) {
> + PMD_INIT_LOG(ERR,
> + "Failed to allocate memory for fdir hash map!");
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> /*
> * Negotiate mail
Re: [dpdk-dev] [PATCH v2 01/18] net/ixgbe: store SYN filter
Hi, Wei Zhao
I think that you had better give a cover letter for such a series of patches.
You can give the changes between v2 and v1 in cover letter
and maybe no need describe it in each one.
Thanks &Best Regards
-Wei
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Zhao
> Sent: Friday, December 30, 2016 3:53 PM
> To: dev@dpdk.org
> Cc: Lu, Wenzhuo ; Zhao1, Wei
> Subject: [dpdk-dev] [PATCH v2 01/18] net/ixgbe: store SYN filter
>
> Add support for storing SYN filter in SW.
>
> Signed-off-by: Wenzhuo Lu
> Signed-off-by: Wei Zhao
> ---
>
> v2:
> --synqf assignment location change
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 14 +++---
> drivers/net/ixgbe/ixgbe_ethdev.h | 2 ++
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index a25bac8..316e560 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -1274,6 +1274,8 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
> memset(filter_info->fivetuple_mask, 0,
> sizeof(uint32_t) * IXGBE_5TUPLE_ARRAY_SIZE);
>
> + /* initialize SYN filter */
> + filter_info->syn_info = 0;
> return 0;
> }
>
> @@ -5580,15 +5582,18 @@ ixgbe_syn_filter_set(struct rte_eth_dev *dev,
> bool add)
> {
> struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + struct ixgbe_filter_info *filter_info =
> + IXGBE_DEV_PRIVATE_TO_FILTER_INFO(dev->data->dev_private);
> + uint32_t syn_info;
> uint32_t synqf;
>
> if (filter->queue >= IXGBE_MAX_RX_QUEUE_NUM)
> return -EINVAL;
>
> - synqf = IXGBE_READ_REG(hw, IXGBE_SYNQF);
> + syn_info = filter_info->syn_info;
>
> if (add) {
> - if (synqf & IXGBE_SYN_FILTER_ENABLE)
> + if (syn_info & IXGBE_SYN_FILTER_ENABLE)
> return -EINVAL;
> synqf = (uint32_t)(((filter->queue <<
> IXGBE_SYN_FILTER_QUEUE_SHIFT) &
> IXGBE_SYN_FILTER_QUEUE) | IXGBE_SYN_FILTER_ENABLE);
> @@ -5598,10 +5603,13 @@ ixgbe_syn_filter_set(struct rte_eth_dev *dev,
> else
> synqf &= ~IXGBE_SYN_FILTER_SYNQFP;
> } else {
> - if (!(synqf & IXGBE_SYN_FILTER_ENABLE))
> + synqf = IXGBE_READ_REG(hw, IXGBE_SYNQF);
> + if (!(syn_info & IXGBE_SYN_FILTER_ENABLE))
> return -ENOENT;
> synqf &= ~(IXGBE_SYN_FILTER_QUEUE |
> IXGBE_SYN_FILTER_ENABLE);
> }
> +
> + filter_info->syn_info = synqf;
> IXGBE_WRITE_REG(hw, IXGBE_SYNQF, synqf);
> IXGBE_WRITE_FLUSH(hw);
> return 0;
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h
> b/drivers/net/ixgbe/ixgbe_ethdev.h
> index 4ff6338..827026c 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.h
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.h
> @@ -262,6 +262,8 @@ struct ixgbe_filter_info {
> /* Bit mask for every used 5tuple filter */
> uint32_t fivetuple_mask[IXGBE_5TUPLE_ARRAY_SIZE];
> struct ixgbe_5tuple_filter_list fivetuple_list;
> + /* store the SYN filter info */
> + uint32_t syn_info;
> };
>
> /*
> --
> 2.5.5
Re: [dpdk-dev] [PATCH v4 5/5] app/testpmd: enhance command to test NIC reset
Adding PCI address info here is to let user confirm mapping between PCI address
and port id is kept after reset.
As this is only for test purpose, are you OK for other part except these PCI
address printf ?
> -Original Message-
> From: Wu, Jingjing
> Sent: Friday, June 30, 2017 5:10 PM
> To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Zhang, Helin ;
> Peng, Yuan
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v4 5/5] app/testpmd: enhance command to test NIC reset
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Thursday, June 29, 2017 10:58 PM
> > To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev,
> > Konstantin ; Zhang, Helin
> > ; Wu, Jingjing ;
> > yuan.pntel.com
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v4 5/5] app/testpmd: enhance command to test NIC reset
> >
> > When PF is reset, a message will show it and all its VF need to be
> > reset.
> > User can run the command "port reset port_id"
> > to reset the VF port and to keep same port id without any
> > configuration. Then user can run "port stop port_id"
> > and "port start port_id" to reconfigure its forwarding mode and
> > parmaters as previous ones.
> > To avoid crash, current forwarding should be stopped before running
> > "port reset port_id".
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 10 ++--- app/test-pmd/testpmd.c | 61
> > +++---
> > app/test-pmd/testpmd.h | 1 +
> > 3 files changed, 66 insertions(+), 6 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > ff8ffd2..58ba6e4 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -950,6 +950,8 @@ static void cmd_operate_port_parsed(void
> *parsed_result,
> > stop_port(RTE_PORT_ALL);
> > else if (!strcmp(res->name, "close"))
> > close_port(RTE_PORT_ALL);
> > + else if (!strcmp(res->name, "reset"))
> > + reset_port(RTE_PORT_ALL);
> > else
> > printf("Unknown parameter\n");
> > }
> > @@ -959,7 +961,7 @@ cmdline_parse_token_string_t
> cmd_operate_port_all_cmd =
> > "port");
> > cmdline_parse_token_string_t cmd_operate_port_all_port =
> > TOKEN_STRING_INITIALIZER(struct cmd_operate_port_result, name,
> > - "start#stop#close");
> > + "start#stop#close#reset");
> > cmdline_parse_token_string_t cmd_operate_port_all_all =
> > TOKEN_STRING_INITIALIZER(struct cmd_operate_port_result, value,
> > "all");
> >
> > @@ -994,6 +996,8 @@ static void cmd_operate_specific_port_parsed(void
> *parsed_result,
> > stop_port(res->value);
> > else if (!strcmp(res->name, "close"))
> > close_port(res->value);
> > + else if (!strcmp(res->name, "reset"))
> > + reset_port(res->value);
> > else
> > printf("Unknown parameter\n");
> > }
> > @@ -1003,7 +1007,7 @@ cmdline_parse_token_string_t
> cmd_operate_specific_port_cmd =
> > keyword, "port");
> > cmdline_parse_token_string_t cmd_operate_specific_port_port =
> > TOKEN_STRING_INITIALIZER(struct cmd_operate_specific_port_result,
> > - name, "start#stop#close");
> > + name, "start#stop#close#reset");
> > cmdline_parse_token_num_t cmd_operate_specific_port_id =
> > TOKEN_NUM_INITIALIZER(struct cmd_operate_specific_port_result,
> > value, UINT8);
> > @@ -1011,7 +1015,7 @@ cmdline_parse_token_num_t
> > cmd_operate_specific_port_id = cmdline_parse_inst_t
> cmd_operate_specific_port = {
> > .f = cmd_operate_specific_port_parsed,
> > .data = NULL,
> > - .help_str = "port start|stop|close : Start/Stop/Close port_id",
> > + .help_str = "port start|stop|close|reset :
> > +Start/Stop/Close/Reset port_id",
> > .tokens = {
> > (void *)&cmd_operate_specific_port_cmd,
> > (void *)&cmd_operate_specific_port_port,
> > diff --git a/app/test-pmd/testpmd.c b/app/te
Re: [dpdk-dev] [PATCH v4 3/5] net/i40e: add support of reset
> -Original Message-
> From: Wu, Jingjing
> Sent: Friday, June 30, 2017 4:54 PM
> To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Zhang, Helin ;
> Peng, Yuan
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v4 3/5] net/i40e: add support of reset
>
> > }
> >
> > +static int
> > +i40e_dev_reset(struct rte_eth_dev *dev) {
> > + int ret;
> > +
> > + ret = eth_i40e_dev_uninit(dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = eth_i40e_dev_init(dev);
> > +
> > + return ret;
> Have you thought about if DPDK is working as host driver, and there Are VFs
> rely on it? If it doesn't support, at least a check should be added.
> Or you can add those check in Rte level.
If there is any VF, PF reset need sync with VF, but sync method may be much
different with different NIC type.
So, we'd like first reject PF reset if its VF exist.
I'll update it in v5 patch set.
>
> Thanks
> Jingjing
Re: [dpdk-dev] [PATCH v5 0/4] Support NIC reset and keep same port id
Hi, Thomas Would you please have a look at this patch set ? If any question, please let me know . Thanks -Wei -Original Message- From: Wu, Jingjing Sent: Friday, June 30, 2017 6:50 PM To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo ; Ananyev, Konstantin ; Zhang, Helin ; Peng, Yuan Cc: dev@dpdk.org Subject: RE: [PATCH v5 0/4] Support NIC reset and keep same port id > -Original Message- > From: Dai, Wei > Sent: Friday, June 30, 2017 6:13 PM > To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev, > Konstantin ; Wu, Jingjing > ; Zhang, Helin ; Peng, > Yuan > Cc: dev@dpdk.org; Dai, Wei > Subject: [PATCH v5 0/4] Support NIC reset and keep same port id > > Sometimes a port have to be reset. For example PF is reset, all its VF > should also be reset. After reset, if the port goes through PCI > remove() and then PCI probe() for restoration, its port id may be > changed and this is not expected by some customer DPDK application. > Normally, PCI probe() includes two parts: one is in rte_ethdev layer > and the other is calling PMD dev_init(). PCI remove( ) release all > resource allocated from rte_ethdev layer in PCI probe( ) and calls PMD > dev_unit( ). > To keep same port id and reset the port, only dev_uninit() and > dev_init( ) in PMD can be called and keep all resources allocated from > rte_ethdev layer poart in PCI probe( ). > > New rte_eth_dev_reset( ) calls rte_eth_dev_stop( ), PMD dev_uninit( ) > and then PMD dev_init( ) to reset a port and keep same port id. > And then application can go through rte_eth_dev_configure( ), > rte_eth_rx_queue_setup( ), rte_eth_tx_queue_setup( ) and > rte_eth_dev_start( ) again to restore its previous settings or to > reconfigure itself with different settings. > > To test this new feature, a testpmd command "port reset port_id" is added. > The mapping between port number and its PCI address can be monitored > to confirm its port number is kept. > And following test case can also be used to confirm the port can work > again after reset. > > A typical test steps are listed as follows: > For example, run "ifconfig PF-name down" will trigger a reset to VF. > 1. run testpmd with 2 ixgbe VF ports belonging to same PF 2. testpmd > > set verbose 1 //to observe VF working 3. testpmd > show port info > all //show port number and MAC addr 4. testpmd > start 5. let all > ports forwarding work for a while 6. testpmd > show port stats all 7. > ifconfig name-of-PF down 8. A message is shown in testmd to indicate > PF reset 9. ifconfig name-of-PF up 10. testpmd > stop // stop > forwarding to avoid crash during reset 11. testpmd > port reset all > 12. testpmd > port stop all 13. testpmd > port start all //recofnig > all ports 14. testpmd > show port info all > //get mapping of port id and MAC addr for forwarding 15. testpmd > > start // restore forwarding 14. let all ports forwarding work for a > while 15. testpmd > show port stats all //confirm all port can work > again 16. repeat above step 7 - 15 > > chagnes: > v5: > remove PCI address output to align with other modification which > will output it in other way > disable PF reset when its VF is ative to avoid unexpected VF > behavior > v4: > add PCI address to confirm its port number keep same > correct test method in cover letter > v3: > update testpmd command > v2: > only reset PMD layer resource and keep same port id, but > not restore settings > > Signed-off-by: Wei Dai > Tested-by: Yuan Peng Acked-by: Jingjing Wu
Re: [dpdk-dev] [PATCH v5 2/4] net/ixgbe: add support of reset
Thanks, Thomas
I have just sent out my v6 patch set which includes more details to explain
why/what/when.
-Original Message-
From: Thomas Monjalon [mailto:tho...@monjalon.net]
Sent: Friday, July 7, 2017 4:36 PM
To: Dai, Wei ; Yigit, Ferruh
Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, Konstantin
; Wu, Jingjing ; Zhang,
Helin ; Peng, Yuan
Subject: Re: [dpdk-dev] [PATCH v5 2/4] net/ixgbe: add support of reset
07/07/2017 10:25, Thomas Monjalon:
> Hi,
>
> 30/06/2017 12:12, Wei Dai:
> > +/*
> > + * Reest PF device.
> > + */
> > +static int
> > +ixgbe_dev_reset(struct rte_eth_dev *dev) {
> > + int ret;
> > +
> > + /* To avoid unexpected behavior in VF, disable PF reset */
> > + if (dev->data->sriov.active)
> > + return -ENOTSUP;
> > +
> > + ret = eth_ixgbe_dev_uninit(dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = eth_ixgbe_dev_init(dev);
> > +
> > + return ret;
> > +}
>
> rte_eth_dev_reset() just do
> + rte_eth_dev_stop(port_id);
> + ret = dev->dev_ops->dev_reset(dev);
>
> and dev_reset() just do
> + ret = eth_ixgbe_dev_uninit(dev);
> + ret = eth_ixgbe_dev_init(dev);
>
> It is doing one more thing, the check of SR-IOV.
> Unfortunately, this restriction is not documented.
>
> This is the documentation of the new API:
>
> /**
> + * Reset a Ethernet device.
> + *
> + * @param port_id
> + * The port identifier of the Ethernet device.
> + */
> +int rte_eth_dev_reset(uint8_t port_id);
>
> It is really really too short.
> From the beginning of this proposal we are asking you to better
> explain why this API is needed. It still does not appear in the doc.
> Are you adding it to offer a new service to DPDK application developpers?
> Or is it just a secret sauce that you will explain only to your customers?
>
> This is what is expected to be documented:
> - why/when this API must be used
> - what the API will do
> - what is needed to do after
I would like to add that the description of the API must also help other PMD
maintainers to implement it.
Adding a new op means more work for PMD maintainers, that's why they should
understand the benefit and acknowledge it.
Ferruh, as the maintainer of next-net, please could you ask for feedbacks from
other PMD maintainers?
Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset
-Original Message- From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] Sent: Monday, July 10, 2017 7:35 PM To: Dai, Wei Cc: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev, Konstantin ; Wu, Jingjing ; Xing, Beilei ; dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset -Original Message- > Date: Mon, 10 Jul 2017 18:05:41 +0800 > From: Wei Dai > To: tho...@monjalon.net, wenzhuo...@intel.com, > konstantin.anan...@intel.com, jingjing...@intel.com, > beilei.x...@intel.com > CC: dev@dpdk.org, Wei Dai > Subject: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset > X-Mailer: git-send-email 2.7.5 > > This patch adds a new eth_dev layer API function rte_eth_dev_reset(). > A DPDK application can call this function to reset a NIC and keep its > port id afterwards. > It means that all SW resources allocated in ethdev layer should be > kept and SW and HW resources of the NIC in PMD need to be reset in > similar way that it runs PCI dev_uninit() and then dev_init(). > The sequence of dev_uninit() and dev_init() can be packed into a > single interface API rte_eth_dev_reset(). > Please See the comments before the declaration of rte_eht_dev_reset() > in lib/librte_ether/rte_ethdev.h to get more details on why this > function is needed, what this function does and what an application > should do after calling this function. > > Signed-off-by: Wei Dai > --- > /** > + * Reset a Ethernet device and keep its port id. > + * > + * A DPDK application calls this function to do an initiative or > + passive > + * reset of a port. > + * > + * Sometimes a port have to be reset passively. For example a PF is > + reset, > + * all its VFs should also be reset by application itself to align > + with the > + * PF. May be I didn't understood this use case properly,But, PF can always send mailbox message to VF on PF reset. Right? [Wei: As to ixgbe, PF kernel driver always send mailbox message to VF when PF is reset. For other NICs, there are maybe other mechanism to notify VF of PF reset.] On such message from PF, VF can transparently reset without application knowledge(i.e rx and/or tx burst return zero) [Wei: VF reset is handling many HW registers which may have effect on working Rx/Tx path and may cause some unexpected behavior like crash. So application should make some operations like stopping Rx/Tx path before it begin VF reset. This is why application should handle VF reset itself.] > + * A DPDK application also can call this function to trigger an > + initative > + * port reset. When apart from the above use case? Even if it is above case, we should have some event to notify application to initiate the reset.Right? Without the event, When or on what basics application needs to initiate reset? [Wei: Indeed, until now we didn't see any use case which DPDK application initiative port reset itself. The most usual case is that PF is working with kernel driver and VFs are working with DPDK PMD. Some operations on kernel PF lead to a PF reset which causes its VF reset. Anyway this new function provides a possibility for application to trigger an initiative port reset.] > + *
Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset
> -Original Message- > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > Sent: Tuesday, July 11, 2017 1:17 PM > To: Dai, Wei > Cc: tho...@monjalon.net; Lu, Wenzhuo ; > Ananyev, Konstantin ; Wu, Jingjing > ; Xing, Beilei ; > dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset > > -Original Message- > > Date: Tue, 11 Jul 2017 01:57:15 + > > From: "Dai, Wei" > > To: Jerin Jacob > > CC: "tho...@monjalon.net" , "Lu, Wenzhuo" > > , "Ananyev, Konstantin" > > , "Wu, Jingjing" > > , "Xing, Beilei" , > > "dev@dpdk.org" > > Subject: RE: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC > > reset > > > > > > > + * A DPDK application also can call this function to trigger an > > > + initative > > > + * port reset. > > > > When apart from the above use case? Even if it is above case, we should > have some event to notify application to initiate the reset.Right? Without > the event, When or on what basics application needs to initiate reset? > > [Wei: Indeed, until now we didn't see any use case which DPDK application > initiative port reset itself. > > The most usual case is that PF is working with kernel driver and VFs are > working with DPDK PMD. > > Some operations on kernel PF lead to a PF reset which causes its VF reset. > > Anyway this new function provides a possibility for application to > > trigger an initiative port reset.] > > That's fine. The only concern part is when to call reset API from application. > Can we say on RTE_ETH_EVENT_INTR_RESET event, application needs to > call the reset API? I think, it is important to specify when application need > to > call this API, otherwise this api behavior will be tightly coupled with > underneath PMD. Side effect is, a new, non portable PMD specific API. > If a PMD wishes to fixup some overflow case(as an example), by invoking the > reset API from the application BUT same case may not valid for another > PMD hence it will create unexpected behavior from application based on the > underneath PMD. It is duty of PMD to trigger RTE_ETH_EVENT_INTR_RESET event and application should also register some callback function to handle this event. When PMD wants to trigger a reset, it can trigger RTE_ETH_EVENT_INTR_RESET. On the received event of RTE_ETH_EVENT_INTR_RESET, application can begin to handle it: stop working queues, make rx and tx function not be called and then call rte_eth_dev_reset( ). For thread safety, all these controlling operations had better be made in same thread. For example, when ixgbe PF is reset, PF send a message to notify VF this event and also trigger an interrupt to VF. And then in the interrupt service routine DPDK VF detect this notification message and calls _rte_eth_dev_callback_process(dev, RTE_ETH_EVENT_INTR_RESET, NULL, NULL). So it means that PF reset trigger RTE_ETH_EVENT_INTR_RESET event in VF. The function _rte_eth_dev_callback_process( ) will call the registered callback function. The callback function can trigger application to handle all operations of VF reset including something like stopping working Rx/Tx queues and call this rte_eth_dev_reset(). The rte_eth_dev_reset( ) itself is generic function which only does some HW reset operations through calling dev_unint() and dev_init(). And itself doesn't handle above synchronization which is handled by application. PMD itself should not call rte_eth_dev_reset( ). PMD can trigger application to handle reset event. It is duty of application to handle all synchronization befort it calls rte_eth_dev_reset( ). > > if RTE_ETH_EVENT_INTR_RESET event is not expected event to call the reset > API then create a new event or if it needs to be called in > RTE_ETH_EVENT_INTR_RESET then update the API documentation. > Of course, when PMD wants to trigger a reset event, it can trigger other event other than RTE_ETH_EVENT_INTR_RESET. So the application should know which the alternate event is. This make application more complex. So it is suggested that only RTE_ETH_EVENT_INTR_RESET can be used to trigger a port reset. > > > > > + *
Re: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC reset
> > Subject: RE: [dpdk-dev] [PATCH v6 1/4] ethdev: add support of NIC > > reset > > > > > > > + * A DPDK application also can call this function to trigger an > > > + initative > > > + * port reset. > > > > When apart from the above use case? Even if it is above case, we should > have some event to notify application to initiate the reset.Right? Without > the event, When or on what basics application needs to initiate reset? > > [Wei: Indeed, until now we didn't see any use case which DPDK application > initiative port reset itself. > > The most usual case is that PF is working with kernel driver and VFs are > working with DPDK PMD. > > Some operations on kernel PF lead to a PF reset which causes its VF reset. > > Anyway this new function provides a possibility for application to > > trigger an initiative port reset.] > > That's fine. The only concern part is when to call reset API from application. > Can we say on RTE_ETH_EVENT_INTR_RESET event, application needs to > call the reset API? I think, it is important to specify when application need > to > call this API, otherwise this api behavior will be tightly coupled with > underneath PMD. Side effect is, a new, non portable PMD specific API. > If a PMD wishes to fixup some overflow case(as an example), by invoking the > reset API from the application BUT same case may not valid for another > PMD hence it will create unexpected behavior from application based on the > underneath PMD. > > if RTE_ETH_EVENT_INTR_RESET event is not expected event to call the reset > API then create a new event or if it needs to be called in > RTE_ETH_EVENT_INTR_RESET then update the API documentation. Thanks for your feedback. I'll add description of this function in API doc in my v7 patch set. > > > > > > + *
Re: [dpdk-dev] [PATCH v7 0/5] Support NIC reset and keep same port id
Hi, Thomas Thanks for your expert guidance. I'll rework out v8 patch set to follow your guide and rebase to master brach. > -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Monday, July 17, 2017 3:26 AM > To: Dai, Wei > Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, > Konstantin ; Wu, Jingjing > ; Xing, Beilei ; Mcnamara, > John > Subject: Re: [dpdk-dev] [PATCH v7 0/5] Support NIC reset and keep same > port id > > 13/07/2017 17:53, Wei Dai: > > chagnes: > > v7: > > add description of NIC reset in doc/poll_mode_drv.rst > > Thanks for bringing more explanations. > The texts have to be reviewed by a native english speaker. > > About the organization of the doc, it is good to explain the VF use case in > the > prog guide as you do. But you should not add it to the doxygen. > The doxygen must be concise enough and explains only the API: > - when it can be called > - what a driver is doing when calling reset > - what is the expected state of the device after reset
Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
HI, Srini Sorry for late response. As I have pointed out that Ixgbe_reset_hw_82599( ) calls hw->phy.ops.init(hw) unconditionally, I think it is no need to call hw->phy.ops.init(hw) after ixgbe_pf_reset_hw(hw) at least for 82599. I also think that only moving "hw->phy.type = ixgbe_phy_unknown" just before ixgbe_pf_reset_hw(hw) is OK. What's more, how about X540 and X550 ? I have just got a X540 and a X550 NIC with copper interface, so I only can plug in/out the RJ45 line to help test it. Is your patch designed for plugging out original SFP and then plugging in another different type of SFP ? By the way, I'd like you provide more details on how to test your patch? With testpmd ? Or other app ? Thanks -Wei > -Original Message- > From: Yigit, Ferruh > Sent: Thursday, June 29, 2017 9:00 PM > To: Srinivasan J ; Dai, Wei > Cc: Thomas Monjalon ; dev@dpdk.org; Lu, > Wenzhuo ; Ananyev, Konstantin > > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot > swapped SFP/SFP+ > > On 5/19/2017 11:04 AM, Srinivasan J wrote: > > Hi Wei, > > Yes the changes are in ixgbe_dev_start( ), the patch shows > > the function as eth_ixgbevf_pci_remove() probably due to the way diff > > recognizes the change. I have tested the change using Intel > > Corporation 82599ES. > > Hi Srinivasan, Wei, > > What is the latest status of the patch? Are all issues pointed by Wie > addressed in the patch, or are we waiting for a new version? > > Thanks, > ferruh > > > > > Thanks, > > Srini > > > > On Tue, May 16, 2017 at 9:04 AM, Dai, Wei wrote: > >> Hi, Srini > >> > >> There is a bit confusion. Your patch shows that your code is added into > the function eth_ixgbevf_pci_remove( ). > >> But it is not. It is added into the fucntion ixgbe_dev_start( ), right ? > >> So would you please rebase it to R 17.05 ? > >> > >> Which type of ixgbe device id did you tested ? > >> > >> There are many MAC types with different device id. > >> > >> The function ixgbe_pf_reset_hw(hw) is called before your adding code. > >> ixgbe_pf_reset_hw() calls hw->mac.ops.reset_hw( ) which may points to > following different function for different MAC type. > >> Ixgbe_reset_hw_82598( ) calls hw->phy.ops.init(hw) if > hw->phy.reset_disable == false . > >> Ixgbe_reset_hw_82599( ) calls hw->phy.ops.init(hw) unconditionally. > >> ixgbe_reset_hw_X540( ) doesn't' call pw->phy.ops.init(hw). For X540, > hw->phy.ops.init points to ixgbe_init_phy_ops_generic() which only initialize > some function pointers. > >> Ixgbe_rest_hw_x550em() calls hw->phy.ops.init(hw) unconditionally. > >> > >> And for VF, ixgbe_reset_hw_vf( ) and ixgbevf_hv_reset_hw_vf( ) don't > call hw->phy.ops.init(hw) anywhere. > >> > >> Thanks & Best Regards > >> -Wei > >> > >>> -Original Message- > >>> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas > Monjalon > >>> Sent: Sunday, May 7, 2017 6:36 AM > >>> To: Srinivasan J > >>> Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, > >>> Konstantin > >>> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot > >>> swapped SFP/SFP+ > >>> > >>> 06/05/2017 15:51, Srinivasan J: > >>>> Hi, > >>>>Do we need an explicit "Acked-by" keyword for > >>>> this patch to be accepted and applied? > >>> > >>> Yes, given it is not a trivial patch, an ack from the maintainer is > >>> required. > >>> Anyway, it has been submitted too late for 17.05 testing.
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix Rx/Tx queue interrupt for x550 devices
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Qiming Yang
> Sent: Tuesday, July 18, 2017 10:29 AM
> To: dev@dpdk.org
> Cc: sta...@dpdk.org; Lu, Wenzhuo ; Yang, Qiming
>
> Subject: [dpdk-dev] [PATCH v2] net/ixgbe: fix Rx/Tx queue interrupt for x550
> devices
>
> x550 devices not do interrupt vector mapping before enable Rx/Tx queue
> interrupt, makes interrupt mode can't work neither with igb_uio or VFIO.
>
> Fixes: d2e72774e58c ("ixgbe/base: support X550")
>
> Signed-off-by: Qiming Yang
Have looked through datasheet of 82599, X540 and X550.
Acked-by: Wei Dai
> ---
> v2 changes:
> * fixed other cause interrupt vector map and typo issue
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 9b06ac1..0caafd5 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -5611,7 +5611,8 @@ ixgbe_set_ivar_map(struct ixgbe_hw *hw, int8_t
> direction,
> tmp |= (msix_vector << (8 * (queue & 0x3)));
> IXGBE_WRITE_REG(hw, IXGBE_IVAR(idx), tmp);
> } else if ((hw->mac.type == ixgbe_mac_82599EB) ||
> - (hw->mac.type == ixgbe_mac_X540)) {
> + (hw->mac.type == ixgbe_mac_X540) ||
> + (hw->mac.type == ixgbe_mac_X550)) {
> if (direction == -1) {
> /* other causes */
> idx = ((queue & 1) * 8);
> @@ -5719,6 +5720,7 @@ ixgbe_configure_msix(struct rte_eth_dev *dev)
> break;
> case ixgbe_mac_82599EB:
> case ixgbe_mac_X540:
> + case ixgbe_mac_X550:
> ixgbe_set_ivar_map(hw, -1, 1, IXGBE_MISC_VEC_ID);
> break;
> default:
> --
> 2.7.4
Re: [dpdk-dev] [PATCH v7 0/5] Support NIC reset and keep same port id
Remy is a Native English speaker. He will help me review my v8 patch set. Thank you, Remy. > -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Monday, July 17, 2017 3:26 AM > To: Dai, Wei > Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, > Konstantin ; Wu, Jingjing > ; Xing, Beilei ; Mcnamara, > John > Subject: Re: [dpdk-dev] [PATCH v7 0/5] Support NIC reset and keep same > port id > > 13/07/2017 17:53, Wei Dai: > > chagnes: > > v7: > > add description of NIC reset in doc/poll_mode_drv.rst > > Thanks for bringing more explanations. > The texts have to be reviewed by a native english speaker. > > About the organization of the doc, it is good to explain the VF use case in > the > prog guide as you do. But you should not add it to the doxygen. > The doxygen must be concise enough and explains only the API: > - when it can be called > - what a driver is doing when calling reset > - what is the expected state of the device after reset
Re: [dpdk-dev] [PATCH v8 1/5] ethdev: add support of NIC reset
Many thanks, Remy. My v9 patch set has followed your guidance. > -Original Message- > From: Horton, Remy > Sent: Thursday, July 20, 2017 9:22 PM > To: Dai, Wei ; dev@dpdk.org > Cc: tho...@monjalon.net; Lu, Wenzhuo ; > Ananyev, Konstantin ; Xing, Beilei > ; Wu, Jingjing ; Mcnamara, > John > Subject: Re: [dpdk-dev] [PATCH v8 1/5] ethdev: add support of NIC reset > > See suggested wording inline > > On 17/07/2017 16:14, Wei Dai wrote: > > This patch adds a new eth_dev layer API function rte_eth_dev_reset(). > > A DPDK application can call this function to reset a NIC and keep > > its port id afterwards. > > It means that all SW resources allocated in ethdev layer should be > > kept and SW and HW resources of the NIC in PMD need to be reset in > > similar way that it runs PCI dev_uninit() and then dev_init(). > > The sequence of dev_uninit() and dev_init() can be packed into a > > single interface API rte_eth_dev_reset(). > > Please See the comments before the declaration of rte_eht_dev_reset() > > in lib/librte_ether/rte_ethdev.h to get more details on why this > > function is needed, what it does, when it should be called > > and what an application should do after calling this function. > > This patch adds a new eth_dev layer API function rte_eth_dev_reset(), > which a DPDK application can call to reset a NIC and keep its port id > afterwards. It means that all software resources allocated in the ethdev > layer are kept, and software & hardware resources of the NIC within the > NIC's PMD are reset to a state simular to that obtained by calling the > PCI dev_uninit() and then dev_init(). This effective sequence of > dev_uninit() and dev_init() is packed into a single API function > rte_eth_dev_reset(). > > Please see the comments before the declaration of rte_eht_dev_reset() > in lib/librte_ether/rte_ethdev.h to get more details on why this > function is needed, what it does, when it should be called > and what an application should do after calling this function. > > > > Signed-off-by: Wei Dai > > --- > > lib/librte_ether/rte_ethdev.c | 17 + > > lib/librte_ether/rte_ethdev.h | 33 > + > > lib/librte_ether/rte_ether_version.map | 1 + > > 3 files changed, 51 insertions(+) > > Reviewed-by: Remy Horton > > > > > /** > > + * Reset a Ethernet device and keep its port id. > > + * > > + * When a port has to be reset passively, the DPDK application can invoke > this > > + * function. For example a PF is reset, all its VFs should also be reset. > > + * Normally, a DPDK application can invoke this function when > > + * RTE_ETH_EVENT_INTR_RESET event is detected. A DPDK application > can also call > > + * this function to start an initiative port reset. > > When a port has to be reset passively, the DPDK application can invoke > this function. For example when a PF is reset, all its VFs should also > be reset. Normally a DPDK application can invoke this function when > RTE_ETH_EVENT_INTR_RESET event is detected, but can also use it to start > a port reset in other circumstances. > > > + * When this function is called, it first stops the port and then call PMD > > + * specific dev_uninit( ) and dev_init( ) to makes the port return to > > initial > > + * status in which no any Tx queue and no Rx queue are setup and the port > has > > + * just be reset and not started. And the port keeps its port id after > > calling > > + * this function. > > 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 go through > > + * rte_eth_dev_configure( ), rte_eth_rx_queue_setup( ), > > + * rte_eth_tx_queue_setup( ) and rte_eth_dev_start( ) again to restore > > + * its previous settings or to reconfigure itself with different settings. > > 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 behaviour, the application should stop > calling Rx > > + * and Rx function before calling rte_eth_dev_reset( ).For thread > safety, > > + * all these controlling operations had better be made in same > thread. > > 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. >
Re: [dpdk-dev] [PATCH v2] net/ixgbe: add support of 2.5G and 5G on X550
Hi, Wenzhuo
> > speed = 0x0;
> > if (*link_speeds == ETH_LINK_SPEED_AUTONEG) {
> > - speed = (hw->mac.type != ixgbe_mac_82598EB) ?
> > - IXGBE_LINK_SPEED_82599_AUTONEG :
> > - IXGBE_LINK_SPEED_82598_AUTONEG;
> > + switch (hw->mac.type) {
> > + case ixgbe_mac_82598EB:
> > + speed = IXGBE_LINK_SPEED_82598_AUTONEG;
> > + break;
> > +
> > + case ixgbe_mac_82599EB:
> > + case ixgbe_mac_X540:
> > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > + break;
> > +
> > + case ixgbe_mac_X550:
> > + case ixgbe_mac_X550EM_x:
> > + case ixgbe_mac_X550EM_a:
> > + speed = IXGBE_LINK_SPEED_100_FULL |
> > + IXGBE_LINK_SPEED_1GB_FULL |
> > + IXGBE_LINK_SPEED_10GB_FULL |
> > + IXGBE_LINK_SPEED_2_5GB_FULL |
> > + IXGBE_LINK_SPEED_5GB_FULL;
> Thanks for the patch. It looks good to me. A suggestion, why not define a
> macro like IXGBE_LINK_SPEED_82599_AUTONEG for x550?
IXGBE_LINK_SPEED_82599_AUTONEG is defined in
drivers/net/ixgbe/base/ixgbe_type.h .
Normally, the base driver code in this file is provided and maintained by
another team.
I will ask them to add similar macro in it.
Currently, I'd like do this way. And I will replace it till a similar macro is
introduced.
>
> > + break;
> > + default:
> > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > + }
> > } else {
> > if (*link_speeds & ETH_LINK_SPEED_10G)
> > speed |= IXGBE_LINK_SPEED_10GB_FULL; @@ -
> > 3972,6 +3991,14 @@ ixgbe_dev_link_update_share(struct rte_eth_dev
> *dev,
> > link.link_speed = ETH_SPEED_NUM_1G;
> > break;
> >
> > + case IXGBE_LINK_SPEED_2_5GB_FULL:
> > + link.link_speed = ETH_SPEED_NUM_2_5G;
> > + break;
> > +
> > + case IXGBE_LINK_SPEED_5GB_FULL:
> > + link.link_speed = ETH_SPEED_NUM_5G;
> > + break;
> > +
> > case IXGBE_LINK_SPEED_10GB_FULL:
> > link.link_speed = ETH_SPEED_NUM_10G;
> > break;
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v2] net/ixgbe: add support of 2.5G and 5G on X550
> -Original Message-
> From: Lu, Wenzhuo
> Sent: Wednesday, July 26, 2017 10:14 PM
> To: Dai, Wei ; Ananyev, Konstantin
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v2] net/ixgbe: add support of 2.5G and 5G on X550
>
> Hi Wei,
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, July 26, 2017 10:10 AM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> >
> > Cc: dev@dpdk.org
> > Subject: RE: [PATCH v2] net/ixgbe: add support of 2.5G and 5G on X550
> >
> > Hi, Wenzhuo
> > > > speed = 0x0;
> > > > if (*link_speeds == ETH_LINK_SPEED_AUTONEG) {
> > > > - speed = (hw->mac.type != ixgbe_mac_82598EB) ?
> > > > - IXGBE_LINK_SPEED_82599_AUTONEG :
> > > > - IXGBE_LINK_SPEED_82598_AUTONEG;
> > > > + switch (hw->mac.type) {
> > > > + case ixgbe_mac_82598EB:
> > > > + speed = IXGBE_LINK_SPEED_82598_AUTONEG;
> > > > + break;
> > > > +
> > > > + case ixgbe_mac_82599EB:
> > > > + case ixgbe_mac_X540:
> > > > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > > > + break;
> > > > +
> > > > + case ixgbe_mac_X550:
> > > > + case ixgbe_mac_X550EM_x:
> > > > + case ixgbe_mac_X550EM_a:
> > > > + speed = IXGBE_LINK_SPEED_100_FULL |
> > > > + IXGBE_LINK_SPEED_1GB_FULL |
> > > > + IXGBE_LINK_SPEED_10GB_FULL |
> > > > + IXGBE_LINK_SPEED_2_5GB_FULL |
> > > > + IXGBE_LINK_SPEED_5GB_FULL;
> > > Thanks for the patch. It looks good to me. A suggestion, why not
> > > define a macro like IXGBE_LINK_SPEED_82599_AUTONEG for x550?
> >
> > IXGBE_LINK_SPEED_82599_AUTONEG is defined in
> > drivers/net/ixgbe/base/ixgbe_type.h .
> > Normally, the base driver code in this file is provided and maintained
> > by another team.
> > I will ask them to add similar macro in it.
> > Currently, I'd like do this way. And I will replace it till a similar
> > macro is introduced.
> No. I'm talking about changing the base code. You can add a macro in any .h
> or even .c file you like.
> Then when there's a macro in base code, it's easier to replace a macro by
> another macro.
I'll follow your guidance in my v3 patch.
>
> >
> > >
> > > > + break;
> > > > + default:
> > > > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > > > + }
> > > > } else {
> > > > if (*link_speeds & ETH_LINK_SPEED_10G)
> > > > speed |= IXGBE_LINK_SPEED_10GB_FULL; @@ -
> > > > 3972,6 +3991,14 @@ ixgbe_dev_link_update_share(struct rte_eth_dev
> > > *dev,
> > > > link.link_speed = ETH_SPEED_NUM_1G;
> > > > break;
> > > >
> > > > + case IXGBE_LINK_SPEED_2_5GB_FULL:
> > > > + link.link_speed = ETH_SPEED_NUM_2_5G;
> > > > + break;
> > > > +
> > > > + case IXGBE_LINK_SPEED_5GB_FULL:
> > > > + link.link_speed = ETH_SPEED_NUM_5G;
> > > > + break;
> > > > +
> > > > case IXGBE_LINK_SPEED_10GB_FULL:
> > > > link.link_speed = ETH_SPEED_NUM_10G;
> > > > break;
> > > > --
> > > > 2.7.5
Re: [dpdk-dev] [PATCH v3] net/ixgbe: add support of 2.5G and 5G on X550
> -Original Message-
> From: Lu, Wenzhuo
> Sent: Wednesday, July 26, 2017 11:02 PM
> To: Dai, Wei ; Ananyev, Konstantin
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v3] net/ixgbe: add support of 2.5G and 5G on X550
>
> Hi Wei,
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, July 26, 2017 10:43 AM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> >
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v3] net/ixgbe: add support of 2.5G and 5G on X550
> >
> > This patch adds support of 2.5G and 5G ethernet interface on X550.
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/ixgbe/base/ixgbe_type.h | 5 +
> > drivers/net/ixgbe/ixgbe_ethdev.c| 24
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/net/ixgbe/base/ixgbe_type.h
> > b/drivers/net/ixgbe/base/ixgbe_type.h
> > index bda8558..3fd5425 100644
> > --- a/drivers/net/ixgbe/base/ixgbe_type.h
> > +++ b/drivers/net/ixgbe/base/ixgbe_type.h
> > @@ -3408,6 +3408,11 @@ typedef u32 ixgbe_link_speed; #define
> > IXGBE_LINK_SPEED_82599_AUTONEG
> > (IXGBE_LINK_SPEED_100_FULL | \
> > IXGBE_LINK_SPEED_1GB_FULL | \
> > IXGBE_LINK_SPEED_10GB_FULL)
> > +#define IXGBE_LINK_SPEED_X550_AUTONEG
> > (IXGBE_LINK_SPEED_100_FULL | \
> > + IXGBE_LINK_SPEED_1GB_FULL | \
> > + IXGBE_LINK_SPEED_2_5GB_FULL | \
> > + IXGBE_LINK_SPEED_5GB_FULL | \
> > + IXGBE_LINK_SPEED_10GB_FULL)
> >
> > /* Physical layer type */
> > typedef u64 ixgbe_physical_layer;
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 194058f..bafe7f4 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -2650,6 +2650,22 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
> > speed = (hw->mac.type != ixgbe_mac_82598EB) ?
> > IXGBE_LINK_SPEED_82599_AUTONEG :
> > IXGBE_LINK_SPEED_82598_AUTONEG;
> A little confused here. I saw you erased these 3 lines of code in the previous
> version. Suppose it's better to remove them, right?
Sorry, I forgot to remove them.
I will rework on v4 patch.
Thanks
>
> > + switch (hw->mac.type) {
> > + case ixgbe_mac_82598EB:
> > + speed = IXGBE_LINK_SPEED_82598_AUTONEG;
> > + break;
> > + case ixgbe_mac_82599EB:
> > + case ixgbe_mac_X540:
> > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > + break;
> > + case ixgbe_mac_X550:
> > + case ixgbe_mac_X550EM_x:
> > + case ixgbe_mac_X550EM_a:
> > + speed = IXGBE_LINK_SPEED_X550_AUTONEG;
> > + break;
> > + default:
> > + speed = IXGBE_LINK_SPEED_82599_AUTONEG;
> > + }
> > } else {
> > if (*link_speeds & ETH_LINK_SPEED_10G)
> > speed |= IXGBE_LINK_SPEED_10GB_FULL; @@ -
> > 3972,6 +3988,14 @@ ixgbe_dev_link_update_share(struct rte_eth_dev
> *dev,
> > link.link_speed = ETH_SPEED_NUM_1G;
> > break;
> >
> > + case IXGBE_LINK_SPEED_2_5GB_FULL:
> > + link.link_speed = ETH_SPEED_NUM_2_5G;
> > + break;
> > +
> > + case IXGBE_LINK_SPEED_5GB_FULL:
> > + link.link_speed = ETH_SPEED_NUM_5G;
> > + break;
> > +
> > case IXGBE_LINK_SPEED_10GB_FULL:
> > link.link_speed = ETH_SPEED_NUM_10G;
> > break;
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v4] net/ixgbe: add support of 2.5G and 5G on X550
> -Original Message- > From: Lu, Wenzhuo > Sent: Thursday, July 27, 2017 12:59 AM > To: Dai, Wei ; Ananyev, Konstantin > > Cc: dev@dpdk.org > Subject: RE: [PATCH v4] net/ixgbe: add support of 2.5G and 5G on X550 > > Hi Wei, > > > -----Original Message- > > From: Dai, Wei > > Sent: Wednesday, July 26, 2017 11:30 AM > > To: Lu, Wenzhuo ; Ananyev, Konstantin > > > > Cc: dev@dpdk.org; Dai, Wei > > Subject: [PATCH v4] net/ixgbe: add support of 2.5G and 5G on X550 > > > > This patch adds support of 2.5G and 5G ethernet interface on X550. > > > > Signed-off-by: Wei Dai > > --- > > drivers/net/ixgbe/base/ixgbe_type.h | 5 + > > drivers/net/ixgbe/ixgbe_ethdev.c| 27 > --- > > 2 files changed, 29 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/net/ixgbe/base/ixgbe_type.h > > b/drivers/net/ixgbe/base/ixgbe_type.h > > index bda8558..3fd5425 100644 > > --- a/drivers/net/ixgbe/base/ixgbe_type.h > > +++ b/drivers/net/ixgbe/base/ixgbe_type.h > > @@ -3408,6 +3408,11 @@ typedef u32 ixgbe_link_speed; #define > > IXGBE_LINK_SPEED_82599_AUTONEG > > (IXGBE_LINK_SPEED_100_FULL | \ > > IXGBE_LINK_SPEED_1GB_FULL | \ > > IXGBE_LINK_SPEED_10GB_FULL) > > +#define IXGBE_LINK_SPEED_X550_AUTONEG > > (IXGBE_LINK_SPEED_100_FULL | \ > > + IXGBE_LINK_SPEED_1GB_FULL | \ > > + IXGBE_LINK_SPEED_2_5GB_FULL | \ > > + IXGBE_LINK_SPEED_5GB_FULL | \ > > + IXGBE_LINK_SPEED_10GB_FULL) > Just noticed you changed base code. As we discussed before, I don't mean > that. Actually, I suggest to put it in, for example, ixgbe_ethdev.h Yes, you are right. Your method is better. I will follow it in my v5 patch.
Re: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a PF reset
First of all, I don't agree the method in this patch because the register can also rewind to 0 in normal mode except reset/PF down. In the function void ixgbe_down(struct ixgbe_adapter *adapter) of ixgbe_main.c in the ixgbe kernel PF driver (version 5.0.4), the PF in kernel driver will ping all the active vfs to let them know PF is going down by mailbox messages. On other side, ixgbe VF in DPDK PMD will handle the ping mailbox message in ixgbevf_dev_interrupt_handler( ) which is registered interrupt routine. And ixgbevf_dev_interrupt_handler( ) will call ixgbevf_mbx_process( ) to process mailbox message from PF. So it is in ixgbevf_mbx_process( ) where the SW stats registers of VF can be fixed. There is more than one line to send ping message to VF in kernel PF drvier codes. I am studying it to make it clear how to identify the ping message due to PF down. So can we defer this patch first. And another patch in above way should be submitted. Thanks > -Original Message- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Tuesday, March 28, 2017 11:23 PM > To: Zhang, Helin ; Ananyev, Konstantin > > Cc: dev@dpdk.org; Olivier Matz ; Dai, Wei > ; Guo Fengtian ; Yigit, Ferruh > > Subject: Re: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a PF reset > > Please ixgbe maintainers, what can be done for this fix? > > 2017-03-24 15:11, Olivier Matz: > > Hi, > > > > (remove sta...@dpdk.org) > > > > On Tue, 14 Mar 2017 10:46:40 +0100, Olivier Matz > wrote: > > > Hi Wei, > > > > > > On Thu, 16 Feb 2017 17:49:22 +0100, Olivier Matz > wrote: > > > > Hi Wei, > > > > > > > > On Thu, 9 Feb 2017 14:50:05 +, "Dai, Wei" > wrote: > > > > > > -Original Message- > > > > > > From: Dai, Wei > > > > > > Sent: Thursday, February 9, 2017 10:38 PM > > > > > > To: 'Olivier Matz' ; dev@dpdk.org; > > > > > > Zhang, Helin ; Ananyev, Konstantin > > > > > > > > > > > > Cc: Guo Fengtian ; sta...@dpdk.org > > > > > > Subject: RE: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update > > > > > > after a PF reset > > > > > > > > > > > > The stats register can rewind to zero when the port is running > > > > > > for a long period. So I am afraid that this check is not always > > > > > > correct. > > > > > > Why not introduce a variable to directly indicate whether the > > > > > > resulted stats should be updated or not. > > > > > > > > > > Another way is to clear > > > > > hw_stats->last_vfgprc/last_vfgorc/last_vfgptc/last_vfmprc at the > > > > > same time PF is set down. > > > > > > > > > > > > > Can we know easily in VF if the PF was set down? > > > > > > Any guideline for this? Or is it something we cannot fix? > > > > > > > Is any maintainer available to help to fix that? > > > > Unfortunately I don't have enough knowledge on this driver to do the > > fix by myself. It would be helpful to have some guidelines by a > > maintainer so I can understand what is the proper way to fix the issue. > > > > Thanks, > > Olivier >
Re: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a PF reset
First of all, I don't agree the method in this patch because the register can also rewind to 0 in normal mode except reset/PF down. In the function void ixgbe_down(struct ixgbe_adapter *adapter) of ixgbe_main.c in the ixgbe kernel PF driver (version 5.0.4), the PF in kernel driver will ping all the active vfs to let them know PF is going down by mailbox messages. On other side, ixgbe VF in DPDK PMD will handle the ping mailbox message in ixgbevf_dev_interrupt_handler( ) which is registered interrupt routine. And ixgbevf_dev_interrupt_handler( ) will call ixgbevf_mbx_process( ) to process mailbox message from PF. So it is in ixgbevf_mbx_process( ) where the SW stats registers of VF can be fixed. There is more than one line to send ping message to VF in kernel PF drvier codes. I am studying it to make it clear how to identify the ping message due to PF down. So can we defer this patch first. And another patch in above way should be submitted. Thanks > -Original Message- > From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] > Sent: Tuesday, March 28, 2017 11:23 PM > To: Zhang, Helin ; Ananyev, Konstantin > > Cc: dev@dpdk.org; Olivier Matz ; Dai, Wei > ; Guo Fengtian ; Yigit, Ferruh > > Subject: Re: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a PF reset > > Please ixgbe maintainers, what can be done for this fix? > > 2017-03-24 15:11, Olivier Matz: > > Hi, > > > > (remove sta...@dpdk.org) > > > > On Tue, 14 Mar 2017 10:46:40 +0100, Olivier Matz > wrote: > > > Hi Wei, > > > > > > On Thu, 16 Feb 2017 17:49:22 +0100, Olivier Matz > wrote: > > > > Hi Wei, > > > > > > > > On Thu, 9 Feb 2017 14:50:05 +, "Dai, Wei" > wrote: > > > > > > -Original Message- > > > > > > From: Dai, Wei > > > > > > Sent: Thursday, February 9, 2017 10:38 PM > > > > > > To: 'Olivier Matz' ; dev@dpdk.org; > > > > > > Zhang, Helin ; Ananyev, Konstantin > > > > > > > > > > > > Cc: Guo Fengtian ; sta...@dpdk.org > > > > > > Subject: RE: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update > > > > > > after a PF reset > > > > > > > > > > > > The stats register can rewind to zero when the port is running > > > > > > for a long period. So I am afraid that this check is not always > > > > > > correct. > > > > > > Why not introduce a variable to directly indicate whether the > > > > > > resulted stats should be updated or not. > > > > > > > > > > Another way is to clear > > > > > hw_stats->last_vfgprc/last_vfgorc/last_vfgptc/last_vfmprc at the > > > > > same time PF is set down. > > > > > > > > > > > > > Can we know easily in VF if the PF was set down? > > > > > > Any guideline for this? Or is it something we cannot fix? > > > > > > > Is any maintainer available to help to fix that? > > > > Unfortunately I don't have enough knowledge on this driver to do the > > fix by myself. It would be helpful to have some guidelines by a > > maintainer so I can understand what is the proper way to fix the issue. > > > > Thanks, > > Olivier >
Re: [dpdk-dev] [PATCH] net/ixgbevf: fix stats update after a PF reset
HI, Olivier > > Hi Wei, > > On Wed, 29 Mar 2017 09:22:55 +0000, "Dai, Wei" wrote: > > First of all, I don't agree the method in this patch because the > > register can also rewind to 0 in normal mode except reset/PF down. > > > > In the function void ixgbe_down(struct ixgbe_adapter *adapter) of > > ixgbe_main.c in the ixgbe kernel PF driver (version 5.0.4), the PF in kernel > driver will ping all the active vfs to let them know PF is going down by > mailbox > messages. > > > > On other side, ixgbe VF in DPDK PMD will handle the ping mailbox > > message in ixgbevf_dev_interrupt_handler( ) which is registered interrupt > routine. > > And ixgbevf_dev_interrupt_handler( ) will call ixgbevf_mbx_process( ) to > process mailbox message from PF. > > > > So it is in ixgbevf_mbx_process( ) where the SW stats registers of VF can be > fixed. > > There is more than one line to send ping message to VF in kernel PF drvier > codes. > > Thank you for the explanation. > > Just to be sure I correctly understand: > 1- the ping message is properly sent by ixgbe pf linux driver Yes, I think so. > 2- the ping message is not yet sent by ixgbe pf dpdk driver I have not find any codes in DPDK PF to send them. > 3- the ping message is properly received by ixgbe vf dpdk driver, but >it is not used yet to stop wrong stats accumulation Yes, need register some callback function on to handle it. > > > I am studying it to make it clear how to identify the ping message due to PF > down. > > Are you saying that you are currently working on a fix for 2 and 3 (that > would be > great!) or are you expecting that I work on it? In any case, I can help, at > least > to test the patches. I am working on it now. Need check both ixgbe kernel driver and DPDK driver and also need look up some pages in datasheet including 82599, X540 and X550. So it is not an easy task. By the way, not only statistics function but also other configurations should be restored. Anyway, I always appreciate your help. Of course, you can help me test my upcoming patches. Thanks -Wei > > > > So can we defer this patch first. > > And another patch in above way should be submitted. > > > I'm of course ok to defer the initial patch, I agree it's more a workaround > than a > proper solution. I was stuck because I did not know how the VF is notified by > the PF when it is reset. > > > Thanks > Olivier
Re: [dpdk-dev] [PATCH] net/ixgbe: keep interrupt throttling disabled
Hi, David The code to be removed set the minimum interrupt interval of queue 0 to 0x79E. According to datasheet, this value has something wrong because it wirte the least reserved 3 bits to 110. Anyway, it intends to set a non-zero minimum interrupt interval. ixgbe_configure_msix( ) is only called by ixgbe_dev_start( ). After it is called, ixgbe_dev_rx_ini( ) is called. And ixgbe_set_rsc( ) is called in ixgbe_dev_rx_init( ). In ixgbe_set_rsc( ), if RSC is enabled, the ITR (interrupt interval) is set to 500us again. So I think enabling immediate interrupt response by removing these codes is not suitable. It should be done in other code where interrupt mode Rx is configured. > Subject: [dpdk-dev] [PATCH] net/ixgbe: keep interrupt throttling disabled > > The code being removed would enable time-based interrupt throttling for the > first MSI-X interrupt vector. This would throttle link status change > interrupts > for NICs bound to vfio_pci driver; but for igb_uio driver, rx queue 0 > interrupts > would be throttled. This resulted in inconsistent latencies in a DPDK > interrupt > mode packet forwarding application between the 2 drivers. > > We'd like DPDK interrupt mode applications to be awaken by inbound packet > interrupts as soon as they are received regardless of interrupt interval, > interrupt throttling should be kept disabled. > > Signed-off-by: David Su > --- > drivers/net/ixgbe/ixgbe_ethdev.c |2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c > b/drivers/net/ixgbe/ixgbe_ethdev.c > index bdf4e2b..fdfb7a6 100644 > --- a/drivers/net/ixgbe/ixgbe_ethdev.c > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > @@ -5815,8 +5815,6 @@ ixgbe_configure_msix(struct rte_eth_dev *dev) > default: > break; > } > - IXGBE_WRITE_REG(hw, IXGBE_EITR(IXGBE_MISC_VEC_ID), > - IXGBE_MIN_INTER_INTERRUPT_INTERVAL_DEFAULT & 0xFFF); > > /* set up to autoclear timer, and the vectors */ > mask = IXGBE_EIMS_ENABLE_MASK; > -- > 1.7.0.4
Re: [dpdk-dev] [PATCH v2] net/ixgbe: ensure link status is updated
Hi, Olivier
Has anyone already tested this patch ?
Can you present some useful info on how to test it ?
Can I use ethtool with some argument to downgrade or upgrade the rate of peer
port ?
I have just run testpmd with 82599, the hw->phy. autoneg_advertised is 0 after
rte_eal_init() and rte_eth_dev_start().
So I think the codes in if (!speed) { ... } is likely to be run.
I agree with most of your codes.
But why to limit speed of NIC to 10Gbps if autoneg is false and 10Gbps is
supported ?
In this case, how about setting multiple speed ?
Thanks
-Wei
> -Original Message-
> From: Olivier Matz [mailto:olivier.m...@6wind.com]
> Sent: Thursday, March 30, 2017 5:20 PM
> To: dev@dpdk.org; Zhang, Helin ; Ananyev,
> Konstantin ; Dai, Wei
> Cc: laurent.ha...@6wind.com
> Subject: Re: [dpdk-dev] [PATCH v2] net/ixgbe: ensure link status is updated
>
> Hi,
>
> Can this patch be applied?
>
> Thanks,
> Olivier
>
>
> On Thu, 16 Feb 2017 17:32:01 +0100, Olivier Matz
> wrote:
> > From: Laurent Hardy
> >
> > In case of fiber and link speed set to 1Gb at peer side (with autoneg
> > or with defined speed), link status could be not properly updated at
> > time cable is plugged-in.
> > Indeed if cable was not plugged when device has been configured and
> > started then link status will not be updated properly with new speed
> > as no link setup will be triggered.
> >
> > To avoid this issue, IXGBE_FLAG_NEED_LINK_CONFIG is set to try a link
> > setup each time link_update() is triggered and current link status is
> > down. When cable is plugged-in, link setup will be performed via
> > ixgbe_setup_link().
> >
> > Signed-off-by: Laurent Hardy
> > ---
> >
> > v1 -> v2:
> > - rebase on top of head (change flag to 1<<4)
> > - fix regression with copper links: only update link for fiber links
> >
> > drivers/net/ixgbe/ixgbe_ethdev.c | 21 +
> > drivers/net/ixgbe/ixgbe_ethdev.h | 1 +
> > 2 files changed, 22 insertions(+)
> >
> > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > index 0b89598..1114106 100644
> > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > @@ -2357,6 +2357,7 @@ ixgbe_dev_configure(struct rte_eth_dev *dev)
> >
> > /* set flag to update link status after init */
> > intr->flags |= IXGBE_FLAG_NEED_LINK_UPDATE;
> > + intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;
> >
> > /*
> > * Initialize to TRUE. If any of Rx queues doesn't meet the bulk @@
> > -3515,8 +3516,12 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int
> wait_to_complete)
> > struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > struct rte_eth_link link, old;
> > ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
> > + struct ixgbe_interrupt *intr =
> > + IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
> > int link_up;
> > int diag;
> > + u32 speed = 0;
> > + bool autoneg = false;
> >
> > link.link_status = ETH_LINK_DOWN;
> > link.link_speed = 0;
> > @@ -3526,6 +3531,20 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev,
> > int wait_to_complete)
> >
> > hw->mac.get_link_status = true;
> >
> > + if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> > + hw->mac.ops.get_media_type(hw) == ixgbe_media_type_fiber) {
> > + speed = hw->phy.autoneg_advertised;
> > + if (!speed) {
> > + ixgbe_get_link_capabilities(hw, &speed, &autoneg);
> > + /* setup the highest link when no autoneg */
> > + if (!autoneg) {
> > + if (speed & IXGBE_LINK_SPEED_10GB_FULL)
> > + speed = IXGBE_LINK_SPEED_10GB_FULL;
> > + }
> > + }
> > + ixgbe_setup_link(hw, speed, true);
> > + }
> > +
> > /* check if it needs to wait to complete, if lsc interrupt is enabled */
> > if (wait_to_complete == 0 || dev->data->dev_conf.intr_conf.lsc != 0)
> > diag = ixgbe_check_link(hw, &link_speed, &link_up, 0); @@
> > -3543,10
> > +3562,12 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int
> > wait_to_complete)
> >
> > if (link_up == 0) {
> > rte_ixgbe_dev_atomic_write_link_status(dev, &link);
> > + intr->flags |= IXGBE_FLAG_NEED_LINK
Re: [dpdk-dev] [PATCH v3] net/ixgbe: ping VF when PF status changes
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Lu, Wenzhuo > Sent: Thursday, March 30, 2017 9:10 PM > To: al...@att.com; dev@dpdk.org > Cc: Ananyev, Konstantin ; Zhang, Helin > ; Iremonger, Bernard > Subject: Re: [dpdk-dev] [PATCH v3] net/ixgbe: ping VF when PF status changes > > Hi, > > > -Original Message- > > Subject: [PATCH v3] net/ixgbe: ping VF when PF status changes > > > > From: Alex Zelezniak > > > > * added 17.05 block to rte_pmd_ixgbe_version.map file > > > > Signed-off-by: Alex Zelezniak > Acked-by: Wenzhuo Lu Except the commit log should > describe what's implemented and for what. Acked-by: Wei Dai The second "hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);" can be removed. :-) And is there any other patch to use this new function ?
Re: [dpdk-dev] [PATCH v4] net/ixgbe: ping VF when PF status changes
Hi, Alexz
Thanks for your quick reponse.
Hi, Wenzhuo
Would you please review it again and add your acknowledgement if it is OK for
you.
> Subject: [PATCH v4] net/ixgbe: ping VF when PF status changes
>
> From: Alex Zelezniak
>
> v4:
> * Removed duplicate line
>
> v3:
> * Added 17.05 block to rte_pmd_ixgbe_version.map file
>
> v2:
> * Removed trailing spaces
>
> v1:
> * Implements function used by application managing PF to inform VF when link
> status changes
>
> Signed-off-by: Alex Zelezniak
Acked-by: Wei Dai
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c| 31
> +
> drivers/net/ixgbe/rte_pmd_ixgbe.h | 14 +
> drivers/net/ixgbe/rte_pmd_ixgbe_version.map | 6 ++
> 3 files changed, 51 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 34bd681..a427a3d 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -4898,6 +4898,37 @@ static void ixgbevf_set_vfta_all(struct rte_eth_dev
> *dev, bool on)
> return new_val;
> }
>
> +int
> +rte_pmd_ixgbe_ping_vf(uint8_t port, uint16_t vf) {
> + struct ixgbe_hw *hw;
> + struct ixgbe_vf_info *vfinfo;
> + struct rte_eth_dev *dev;
> + struct rte_pci_device *pci_dev;
> + uint32_t ctrl;
> +
> + RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
> +
> + dev = &rte_eth_devices[port];
> + pci_dev = IXGBE_DEV_TO_PCI(dev);
> +
> + if (!is_device_supported(dev, &rte_ixgbe_pmd))
> + return -ENOTSUP;
> +
> + if (vf >= pci_dev->max_vfs)
> + return -EINVAL;
> +
> + hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> + vfinfo = *(IXGBE_DEV_PRIVATE_TO_P_VFDATA(dev->data->dev_private));
> +
> + ctrl = IXGBE_PF_CONTROL_MSG;
> + if (vfinfo[vf].clear_to_send)
> + ctrl |= IXGBE_VT_MSGTYPE_CTS;
> +
> + ixgbe_write_mbx(hw, &ctrl, 1, vf);
> +
> + return 0;
> +}
>
> int
> rte_pmd_ixgbe_set_vf_vlan_anti_spoof(uint8_t port, uint16_t vf, uint8_t on)
> diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.h
> b/drivers/net/ixgbe/rte_pmd_ixgbe.h
> index 4d7b507..cdb747e 100644
> --- a/drivers/net/ixgbe/rte_pmd_ixgbe.h
> +++ b/drivers/net/ixgbe/rte_pmd_ixgbe.h
> @@ -42,6 +42,20 @@
> #include
>
> /**
> + * Notify VF when PF link status changes.
> + *
> + * @param port
> + * The port identifier of the Ethernet device.
> + * @param vf
> + * VF id.
> + * @return
> + * - (0) if successful.
> + * - (-ENODEV) if *port* invalid.
> + * - (-EINVAL) if *vf* invalid.
> + */
> +int rte_pmd_ixgbe_ping_vf(uint8_t port, uint16_t vf);
> +
> +/**
> * Set the VF MAC address.
> *
> * @param port
> diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
> b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
> index a992dfd..2c7512d 100644
> --- a/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
> +++ b/drivers/net/ixgbe/rte_pmd_ixgbe_version.map
> @@ -31,3 +31,9 @@ DPDK_17.02 {
> rte_pmd_ixgbe_set_vf_tx;
> rte_pmd_ixgbe_set_vf_vlan_filter;
> } DPDK_16.11;
> +
> +DPDK_17.05 {
> + global:
> +
> + rte_pmd_ixgbe_ping_vf;
> +} DPDK_17.02;
> --
> 1.9.1
Re: [dpdk-dev] [PATCH] net/ixgbe: ensure link status is updated
> -Original Message-
> From: Olivier MATZ [mailto:olivier.m...@6wind.com]
> Sent: Thursday, February 9, 2017 1:03 AM
> To: Dai, Wei
> Cc: Laurent Hardy ; Zhang, Helin
> ; Ananyev, Konstantin
> ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: ensure link status is updated
>
> Hi Wei,
>
> On Wed, 8 Feb 2017 15:51:42 +, "Dai, Wei" wrote:
> > > -Original Message-
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Laurent Hardy
> > > Sent: Friday, November 18, 2016 1:30 AM
> > > To: Zhang, Helin ; Ananyev, Konstantin
> > >
> > > Cc: dev@dpdk.org
> > > Subject: [dpdk-dev] [PATCH] net/ixgbe: ensure link status is updated
> > >
> > > In case of link speed set to 1Gb at peer side (with autoneg or with
> > > defined speed) and cable not plugged-in when device is configured
> > > and started, then link status is not updated properly with new speed
> > > as no link setup is triggered.
> > >
> > > To avoid this issue, IXGBE_FLAG_NEED_LINK_CONFIG is set to try a
> > > link setup each time link_update() is triggered and current link
> > > status is down. When cable is plugged-in, link setup will be
> > > performed via ixgbe_setup_link().
> > >
> > > Signed-off-by: Laurent Hardy
> > > ---
> > > drivers/net/ixgbe/ixgbe_ethdev.c | 20
> > > drivers/net/ixgbe/ixgbe_ethdev.h |1 +
> > > 2 files changed, 21 insertions(+)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > index 52ebbe4..513d1d5 100644
> > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > @@ -2095,6 +2095,7 @@ ixgbe_dev_configure(struct rte_eth_dev *dev)
> > >
> > > /* set flag to update link status after init */
> > > intr->flags |= IXGBE_FLAG_NEED_LINK_UPDATE;
> > > + intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;
> > >
> > > /*
> > >* Initialize to TRUE. If any of Rx queues doesn't meet the bulk
> > > @@ -3117,8 +3118,12 @@ ixgbe_dev_link_update(struct rte_eth_dev
> > > *dev, int wait_to_complete)
> > > struct ixgbe_hw *hw =
> > > IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > > struct rte_eth_link link, old;
> > > ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
> > > + struct ixgbe_interrupt *intr =
> > > + IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
> > > int link_up;
> > > int diag;
> > > + u32 speed = 0;
> > > + bool autoneg = false;
> > >
> > > link.link_status = ETH_LINK_DOWN;
> > > link.link_speed = 0;
> > > @@ -3128,6 +3133,19 @@ ixgbe_dev_link_update(struct rte_eth_dev
> > > *dev, int wait_to_complete)
> > >
> > > hw->mac.get_link_status = true;
> > >
> > > + if (intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) {
> > > + speed = hw->phy.autoneg_advertised;
> > > + if (!speed) {
> > > + ixgbe_get_link_capabilities(hw, &speed,
> > > &autoneg);
> > > + /* setup the highest link when no autoneg
> > > */
> > > + if (!autoneg) {
> > > + if (speed &
> > > IXGBE_LINK_SPEED_10GB_FULL)
> > > + speed =
> > > IXGBE_LINK_SPEED_10GB_FULL;
> > > + }
> > > + }
> > > + ixgbe_setup_link(hw, speed, true);
> > > + }
> > > +
> > > /* check if it needs to wait to complete, if lsc interrupt is
> > > enabled */ if (wait_to_complete == 0 ||
> > > dev->data->dev_conf.intr_conf.lsc != 0) diag = ixgbe_check_link(hw,
> > > &link_speed, &link_up, 0); @@ -3145,10 +3163,12 @@
> > > ixgbe_dev_link_update(struct rte_eth_dev *dev, int wait_to_complete)
> > >
> > > if (link_up == 0) {
> > > rte_ixgbe_dev_atomic_write_link_status(dev, &link);
> > > + intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;
> > > if (link.link_status == old.link_status)
> > > return -1;
> > > return 0;
> > > }
> > > + intr->flags &= ~IXGBE_FLAG_NEED_LINK_CONFIG;
> > > link.link_status = ETH_LINK_UP;
> > > link.link_duplex = ETH_LINK_FULL_DUPLEX;
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h
> > > b/drivers/net/ixgbe/ixgbe_ethdev.h
> > > index e060c3d..9d335ba 100644
> > > --- a/drivers/net/ixgbe/ixgbe_ethdev.h
> > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.h
> > > @@ -43,6 +43,7 @@
> > > #define IXGBE_FLAG_NEED_LINK_UPDATE (uint32_t)(1 << 0)
> > > #define IXGBE_FLAG_MAILBOX (uint32_t)(1 << 1)
> > > #define IXGBE_FLAG_PHY_INTERRUPT(uint32_t)(1 << 2)
> > > +#define IXGBE_FLAG_NEED_LINK_CONFIG (uint32_t)(1 << 3)
> >
> > Now there is following macro in DPDK 17.02-rc2.
> > #define IXGBE_FLAG_MACSEC (uint32_t)(1 << 3)
> > You can redefine it as #define IXGBE_FLAG_NEED_LINK_CONFIG
> > (uint32_t)(1 << 4)
>
> Thanks, I'll send a v2.
>
> Do you agree with the rest of the patch?
So far I have no disagree opinions about the reset of this patch.
>
>
> Regards,
> Olivier
Re: [dpdk-dev] [PATCH] examples/ip_fragmentation: fix check of packet type
Sorry, correct the name of Tester
> -Original Message-
> From: Dai, Wei
> Sent: Friday, March 10, 2017 11:28 AM
> To: dev@dpdk.org; Ananyev, Konstantin
> Cc: Dai, Wei ; sta...@dpdk.org
> Subject: [PATCH] examples/ip_fragmentation: fix check of packet type
>
> The packet_type in mbuf is not correctly filled by ixgbe 82599 NIC.
> To use the ether_type in ethernet header to check packet type is more
> reliaber.
>
> Fixes: 3c0184cc0c60 ("examples: replace some offload flags with packet type")
> Fixes: ab351fe1c95c ("mbuf: remove packet type from offload flags")
>
> Cc: sta...@dpdk.org
>
> Reported-by: Fangfang Wei
> Signed-off-by: Wei Dai
Tested-by: Fangfang Wei
> ---
> examples/ip_fragmentation/main.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/examples/ip_fragmentation/main.c
> b/examples/ip_fragmentation/main.c
> index e1e32c6..8612984 100644
> --- a/examples/ip_fragmentation/main.c
> +++ b/examples/ip_fragmentation/main.c
> @@ -268,6 +268,7 @@ l3fwd_simple_forward(struct rte_mbuf *m, struct
> lcore_queue_conf *qconf,
> uint32_t i, len, next_hop_ipv4;
> uint8_t next_hop_ipv6, port_out, ipv6;
> int32_t len2;
> + struct ether_hdr *eth_hdr;
>
> ipv6 = 0;
> rxq = &qconf->rx_queue_list[queueid];
> @@ -276,13 +277,14 @@ l3fwd_simple_forward(struct rte_mbuf *m, struct
> lcore_queue_conf *qconf,
> port_out = port_in;
>
> /* Remove the Ethernet header and trailer from the input packet */
> + eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
> rte_pktmbuf_adj(m, (uint16_t)sizeof(struct ether_hdr));
>
> /* Build transmission burst */
> len = qconf->tx_mbufs[port_out].len;
>
> /* if this is an IPv4 packet */
> - if (RTE_ETH_IS_IPV4_HDR(m->packet_type)) {
> + if (eth_hdr->ether_type == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
> struct ipv4_hdr *ip_hdr;
> uint32_t ip_dst;
> /* Read the lookup key (i.e. ip_dst) from the input packet */ @@
> -316,7 +318,7 @@ l3fwd_simple_forward(struct rte_mbuf *m, struct
> lcore_queue_conf *qconf,
> if (unlikely (len2 < 0))
> return;
> }
> - } else if (RTE_ETH_IS_IPV6_HDR(m->packet_type)) {
> + } else if (eth_hdr->ether_type == rte_be_to_cpu_16(ETHER_TYPE_IPv6)) {
> /* if this is an IPv6 packet */
> struct ipv6_hdr *ip_hdr;
>
> @@ -363,8 +365,8 @@ l3fwd_simple_forward(struct rte_mbuf *m, struct
> lcore_queue_conf *qconf,
> void *d_addr_bytes;
>
> m = qconf->tx_mbufs[port_out].m_table[i];
> - struct ether_hdr *eth_hdr = (struct ether_hdr *)
> - rte_pktmbuf_prepend(m, (uint16_t)sizeof(struct
> ether_hdr));
> + eth_hdr = (struct ether_hdr *)rte_pktmbuf_prepend(m,
> + (uint16_t)sizeof(struct ether_hdr));
> if (eth_hdr == NULL) {
> rte_panic("No headroom in mbuf.\n");
> }
> --
> 2.7.4
Re: [dpdk-dev] [PATCH] examples/ip_fragmentation: fix check of packet type
Hi, Konstantin
I see your point.
I think your method can work.
But I think your method is a bit complex. As you method need to add more codes.
Anyway this is a simple bug.
How do you think now ?
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Friday, March 10, 2017 8:21 PM
> To: Dai, Wei ; dev@dpdk.org
> Cc: sta...@dpdk.org
> Subject: RE: [PATCH] examples/ip_fragmentation: fix check of packet type
>
> Hi Wei,
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Friday, March 10, 2017 3:28 AM
> > To: dev@dpdk.org; Ananyev, Konstantin
> > Cc: Dai, Wei ; sta...@dpdk.org
> > Subject: [PATCH] examples/ip_fragmentation: fix check of packet type
> >
> > The packet_type in mbuf is not correctly filled by ixgbe 82599 NIC.
> > To use the ether_type in ethernet header to check packet type is more
> > reliaber.
> >
> > Fixes: 3c0184cc0c60 ("examples: replace some offload flags with packet
> > type")
> > Fixes: ab351fe1c95c ("mbuf: remove packet type from offload flags")
> >
> > Cc: sta...@dpdk.org
> >
> > Reported-by: Fangfang Wei
> > Signed-off-by: Wei Dai
> > Tested-by: Fagnfang Wei
> > ---
> > examples/ip_fragmentation/main.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/examples/ip_fragmentation/main.c
> > b/examples/ip_fragmentation/main.c
> > index e1e32c6..8612984 100644
> > --- a/examples/ip_fragmentation/main.c
> > +++ b/examples/ip_fragmentation/main.c
> > @@ -268,6 +268,7 @@ l3fwd_simple_forward(struct rte_mbuf *m, struct
> lcore_queue_conf *qconf,
> > uint32_t i, len, next_hop_ipv4;
> > uint8_t next_hop_ipv6, port_out, ipv6;
> > int32_t len2;
> > + struct ether_hdr *eth_hdr;
> >
> > ipv6 = 0;
> > rxq = &qconf->rx_queue_list[queueid]; @@ -276,13 +277,14 @@
> > l3fwd_simple_forward(struct rte_mbuf *m, struct lcore_queue_conf *qconf,
> > port_out = port_in;
> >
> > /* Remove the Ethernet header and trailer from the input packet */
> > + eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
> > rte_pktmbuf_adj(m, (uint16_t)sizeof(struct ether_hdr));
> >
> > /* Build transmission burst */
> > len = qconf->tx_mbufs[port_out].len;
> >
> > /* if this is an IPv4 packet */
> > - if (RTE_ETH_IS_IPV4_HDR(m->packet_type)) {
> > + if (eth_hdr->ether_type == rte_cpu_to_be_16(ETHER_TYPE_IPv4)) {
> > struct ipv4_hdr *ip_hdr;
> > uint32_t ip_dst;
> > /* Read the lookup key (i.e. ip_dst) from the input packet */ @@
> > -316,7 +318,7 @@ l3fwd_simple_forward(struct rte_mbuf *m, struct
> lcore_queue_conf *qconf,
> > if (unlikely (len2 < 0))
> > return;
> > }
> > - } else if (RTE_ETH_IS_IPV6_HDR(m->packet_type)) {
> > + } else if (eth_hdr->ether_type == rte_be_to_cpu_16(ETHER_TYPE_IPv6))
> > +{
> > /* if this is an IPv6 packet */
> > struct ipv6_hdr *ip_hdr;
> >
> > @@ -363,8 +365,8 @@ l3fwd_simple_forward(struct rte_mbuf *m, struct
> lcore_queue_conf *qconf,
> > void *d_addr_bytes;
> >
> > m = qconf->tx_mbufs[port_out].m_table[i];
> > - struct ether_hdr *eth_hdr = (struct ether_hdr *)
> > - rte_pktmbuf_prepend(m, (uint16_t)sizeof(struct
> > ether_hdr));
> > + eth_hdr = (struct ether_hdr *)rte_pktmbuf_prepend(m,
> > + (uint16_t)sizeof(struct ether_hdr));
> > if (eth_hdr == NULL) {
> > rte_panic("No headroom in mbuf.\n");
> > }
>
> Thanks for the fix.
> Would it be more convenient to do what l3fwd does:
> Check what ptype capabilities are provided by HW, if no ptype support
> detected,
> then install an RX callback?
> Konstantin
>
> > --
> > 2.7.4
Re: [dpdk-dev] [PATCH] examples/ip_fragmentation: fix check of packet type
> -Original Message- > From: Ananyev, Konstantin > Sent: Monday, March 13, 2017 3:02 PM > To: Dai, Wei ; dev@dpdk.org > Cc: sta...@dpdk.org > Subject: RE: [PATCH] examples/ip_fragmentation: fix check of packet type > > Hi Wei, > > > > > Hi, Konstantin > > I see your point. > > I think your method can work. > > But I think your method is a bit complex. As you method need to add more > codes. > > Anyway this is a simple bug. > > How do you think now ? > > I still think it is better for all apps to handle this issue in a uniform way. > Again in that case for NICs that do support PTYPE offloads the performance > should be unaffected. > Konstantin > I have just had a quick look through the l3fwd and didn't find any codes to check what ptypes capabilities ae provided by stuff below DPDK PMD & its base driver. L3fwd only check an input argument "--parse-ptype" to enable ptype check implemented in a Rx callback function. In this l3fwd rx callback function, it has done the same thing as my code. Anyway, I'd like to provide a v2 patch to deal with this issue in a uniform way. Thanks & Best Regards -Wei
Re: [dpdk-dev] [PATCH 3/3] eal: remove references to execinfo.h for musl
> -Original Message-
> From: jblu...@gmail.com [mailto:jblu...@gmail.com] On Behalf Of Jan Blunck
> Sent: Friday, March 10, 2017 10:50 PM
> To: Thomas Monjalon
> Cc: Dai, Wei ; dev ; Mcnamara, John
> ; david.march...@intel.com
> Subject: Re: [dpdk-dev] [PATCH 3/3] eal: remove references to execinfo.h for
> musl
>
> On Fri, Mar 10, 2017 at 1:40 PM, Thomas Monjalon
> wrote:
> > 2017-03-10 19:58, Wei Dai:
> >> @@ -47,6 +50,7 @@
> >> /* dump the stack of the calling core */ void rte_dump_stack(void)
> >> {
> >> +#ifndef RTE_LIBC_MUSL
> >> void *func[BACKTRACE_SIZE];
> >> char **symb = NULL;
> >> int size;
> >> @@ -64,6 +68,7 @@ void rte_dump_stack(void)
> >> }
> >>
> >> free(symb);
> >> +#endif
> >> }
> >
> > There are probably other libc implementations not supporting this feature.
> > Instead of calling it "RTE_LIBC_MUSL", it should something like
> > "ENABLE_BACKTRACE".
> > Then you can add a musl section in the Linux quick start guide.
>
> Also I would improve the code readability by removing the preprocessor junk
> from it by moving the rte_dump_stack() function into eal_backtrace.c and make
> that conditionally compile based on CONFIG_ENABLE_BACKTRACE.
I'd like to change CONFIG_RTE_LIBC_MUSL to CONFIG_RTE_EAL_ENABLE_BACKTRACE and
Will send a v2 patch soon.
Anyway, you also still can move rte_dump_stack() to another file when my change
is accepted.
Re: [dpdk-dev] [PATCH] examples/ip_fragmentation: fix check of packet type
> -Original Message- > From: Ananyev, Konstantin > Sent: Tuesday, March 14, 2017 6:13 AM > To: Dai, Wei ; dev@dpdk.org > Cc: sta...@dpdk.org > Subject: RE: [PATCH] examples/ip_fragmentation: fix check of packet type > > > > > > Hi Wei, > > > > > > > > > > > Hi, Konstantin > > > > I see your point. > > > > I think your method can work. > > > > But I think your method is a bit complex. As you method need to > > > > add more > > > codes. > > > > Anyway this is a simple bug. > > > > How do you think now ? > > > > > > I still think it is better for all apps to handle this issue in a uniform > > > way. > > > Again in that case for NICs that do support PTYPE offloads the > > > performance should be unaffected. > > > Konstantin > > > > > > > I have just had a quick look through the l3fwd and didn't find any > > codes to check what ptypes capabilities ae provided by stuff below DPDK > PMD & its base driver. > > L3fwd only check an input argument "--parse-ptype" to enable ptype > > check implemented in a Rx callback function. > > As an example for lpm: > http://dpdk.org/browse/dpdk/tree/examples/l3fwd/l3fwd_lpm.c#n279 > Konstantin Thanks for your guide. I will use rte_eth_dev_get_supported_ptypes( ) in my v2 patch. > > > > In this l3fwd rx callback function, it has done the same thing as my code. > > Anyway, I'd like to provide a v2 patch to deal with this issue in a uniform > > way. > > > > Thanks & Best Regards > > -Wei
[dpdk-dev] [PATCH] app/test: remove large lpm test head file
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, September 26, 2016 5:56 PM > To: Dai, Wei > Cc: dev at dpdk.org; Richardson, Bruce > Subject: Re: [dpdk-dev] [PATCH] app/test: remove large lpm test head file > > 2016-09-26 17:37, Wei Dai: > > remove the large file app/test/test_lpm_routes.h and add codes to > > auto-generate similar large route rule talbe which keeps same depth > > and IP class distribution as previous one in test_lpm_routes.h . > > With the rule table auto-generated at run time, the performance of > > looking up keep similar to that from pervious constant talbe. > > > > Signed-off-by: Wei Dai > > --- > > app/test/test_lpm.c| 2 +- > > app/test/test_lpm_perf.c | 268 +- > > app/test/test_lpm_routes.h | 1076861 > > - > > 3 files changed, 266 insertions(+), 1076865 deletions(-) delete mode > > 100644 app/test/test_lpm_routes.h > > Whaouh! Good news :) > This file is 21 MB. It should help to reduce the size of a tarball. > Are you working also on the IPv6 flavour? (7 MB to save) Yes, I am designing an algorithm to auto-generate LPM IPv6 test route rule and test input data. As the number of next table to be checked during a looking-up varies much more and depends on the pre-injected rule sets, to keep the similar performance for looking-up is more difficult than IPv4. Regards /Wei
[dpdk-dev] [PATCH] app/test: remove large lpm test head file
Hi, Bruce
How about your test result for this patch ?
Especially on performance of rule looking-up ?
There are also some replies for your comments as below.
Thanks
/ Wei
> -Original Message-
> From: Richardson, Bruce
> Sent: Monday, September 26, 2016 6:07 PM
> To: Dai, Wei
> Cc: dev at dpdk.org
> Subject: Re: [PATCH] app/test: remove large lpm test head file
>
> On Mon, Sep 26, 2016 at 05:37:05PM +0800, Wei Dai wrote:
> > remove the large file app/test/test_lpm_routes.h and add codes to
> > auto-generate similar large route rule talbe which keeps same depth
> > and IP class distribution as previous one in test_lpm_routes.h .
> > With the rule table auto-generated at run time, the performance of
> > looking up keep similar to that from pervious constant talbe.
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test/test_lpm.c| 2 +-
> > app/test/test_lpm_perf.c | 268 +-
> > app/test/test_lpm_routes.h | 1076861
> > -
> > 3 files changed, 266 insertions(+), 1076865 deletions(-) delete mode
> > 100644 app/test/test_lpm_routes.h
> >
> > diff --git a/app/test/test_lpm.c b/app/test/test_lpm.c index
> > b6ad2eb..0952f52 100644
> > --- a/app/test/test_lpm.c
> > +++ b/app/test/test_lpm.c
> > @@ -35,10 +35,10 @@
> > #include
> > #include
> >
> > +#include
> > #include
> >
> > #include "test.h"
> > -#include "test_lpm_routes.h"
> > #include "test_xmmt_ops.h"
> >
> > #define TEST_LPM_ASSERT(cond) do
> {\
> > diff --git a/app/test/test_lpm_perf.c b/app/test/test_lpm_perf.c index
> > 58eb415..5582ef4 100644
> > --- a/app/test/test_lpm_perf.c
> > +++ b/app/test/test_lpm_perf.c
> > @@ -34,14 +34,15 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> > #include
> > #include
> > #include
> > +#include
> >
> > #include "test.h"
> > -#include "test_lpm_routes.h"
> > #include "test_xmmt_ops.h"
> >
> > #define TEST_LPM_ASSERT(cond) do
> {\
> > @@ -55,6 +56,265 @@
> > #define BATCH_SIZE (1 << 12)
> > #define BULK_SIZE 32
> >
> > +#define MAX_RULE_NUM (120)
> > +
> > +struct route_rule {
> > + uint32_t ip;
> > + uint8_t depth;
> > +};
> > +
> > +struct route_rule large_route_table[MAX_RULE_NUM];
> > +
> > +static uint32_t num_route_entries; /* NUM_ROUTE_ENTRIES */ #define
> > +NUM_ROUTE_ENTRIES num_route_entries
> > +
> > +struct route_rule_count {
> > + uint32_t total;
> > + uint32_t a[RTE_LPM_MAX_DEPTH];
> > + uint32_t b[RTE_LPM_MAX_DEPTH];
> > + uint32_t c[RTE_LPM_MAX_DEPTH];
> > + uint32_t left;
> > + uint32_t abc[3*RTE_LPM_MAX_DEPTH];
>
> Can you provide some comments explaining how you are generating the rules
> to test with. For example, explain why have you split the sets of rules into
> three,
> a, b, and c, and how you use each of those three sets. Perhaps also provide a
> comment alongside each member of the structure above.
a/b/c means IP address class. These class doesn't count IP address for local
network.
Because the previous large route rule table was just dumped from a real router
and
as to match similar performance, I design to keep similar depth and IP address
coverage
as previous constant table. All the numbers of each depth of each IP class are
just
got from previous constant table.
>
>
> > +static void init_rule_count(void)
> > +{
> > + uint32_t depth;
> > + uint32_t count;
> > +
> > + rule_count.left = 0;
> > + count = 0;
> > +
> > + for (depth = 1; depth <= RTE_LPM_MAX_DEPTH; depth++) {
> > + count += rule_count.a[depth-1];
> > + if (rule_count.a[depth-1])
> > + rule_count.abc[rule_count.left++] = depth;
> > + }
> > +
> > + for (depth = 1; depth <= RTE_LPM_MAX_DEPTH; depth++) {
> > + count += rule_count.b[depth-1];
> > + if (rule_count.b[depth-1])
> > + rule_count.abc[rule_count.left++] = 256 + depth;
> > + }
> > +
> > + for (depth = 1; depth <= RTE_LPM_MAX_DEPTH; depth++) {
> > + count += rule_count.c[depth-1];
> > + if (rule_count.c[depth-1])
> > + rule_count.abc[rule_count.left++] = 512 + depth;
> >
[dpdk-dev] [PATCH v2] app/test: remove large lpm test head file
> -Original Message- > From: Richardson, Bruce > Sent: Wednesday, September 28, 2016 4:42 PM > To: Dai, Wei > Cc: dev at dpdk.org > Subject: Re: [PATCH v2] app/test: remove large lpm test head file > > On Wed, Sep 28, 2016 at 01:38:27AM +0800, Wei Dai wrote: > > remove the large file app/test/test_lpm_routes.h and add codes to > > auto-generate similar large route rule talbe which keeps same depth > > and IP class distribution as previous one in test_lpm_routes.h . > > With the rule table auto-generated at run time, the performance of > > looking up keep similar to that from pervious constant talbe. > > > > Signed-off-by: Wei Dai > > --- > > Can you perhaps indicate what has changed between v1 and v2, it helps those > of us looking to review the patch. [The best way to do so is to place details > of > diffs in each version underneath the cut line "---".] --- Changes between v2 and v1 include: 1. add more annotations to explain why and how the data structures and algorithm are designed. 2. simplify the implementation of same algorithm by removing fields total, left, abc[ ] in struct route_rule_count. > > Regards, > /Bruce
Re: [dpdk-dev] [PATCH v2] ethdev: moved bypass functions to ixgbe pmd
No other NIC has bypass functions except ixgbe,
so I agree moving them from ethdev to ixgbe pmd.
As these functions are exported to external upper layer application,
it is necessary to use is_ixgbe_supported() to avoid be called by
other type of NIC.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Lu, Wenzhuo
> Sent: Wednesday, May 31, 2017 11:30 AM
> To: Nicolau, Radu ; dev@dpdk.org
> Cc: Yigit, Ferruh ; Iremonger, Bernard
> ; Nicolau, Radu
> Subject: Re: [dpdk-dev] [PATCH v2] ethdev: moved bypass functions to ixgbe
> pmd
>
> Hi Radu,
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Radu Nicolau
> > Sent: Monday, May 29, 2017 11:23 PM
> > To: dev@dpdk.org
> > Cc: Yigit, Ferruh; Iremonger, Bernard; Nicolau, Radu
> > Subject: [dpdk-dev] [PATCH v2] ethdev: moved bypass functions to ixgbe
> > pmd
> >
> > Moved all bypass functions to ixgbe pmd and removed function pointers
> > from the eth_dev_ops struct.
> >
> > Changes in v2:
> > CONFIG_RTE_NIC_BYPASS removed, new option in the IXGBE section added,
> > CONFIG_RTE_LIBRTE_IXGBE_BYPASS.
> > Updated test-pmd to always include the bypass commands.
> >
> > Signed-off-by: Radu Nicolau
>
>
> > diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.c
> > b/drivers/net/ixgbe/rte_pmd_ixgbe.c
> > index e8fc9a6..efcaf68 100644
> > --- a/drivers/net/ixgbe/rte_pmd_ixgbe.c
> > +++ b/drivers/net/ixgbe/rte_pmd_ixgbe.c
> > @@ -908,3 +908,109 @@ rte_pmd_ixgbe_set_tc_bw_alloc(uint8_t port,
> >
> > return 0;
> > }
> > +
> > +#ifdef RTE_LIBRTE_IXGBE_BYPASS
> > +int
> > +rte_pmd_ixgbe_bypass_init(uint8_t port_id) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> Please reference the existing code to check "is_ixgbe_supported" here.
> Because this API may be called by APP directly.
> The same comments for all the other APIs below.
>
> > +
> > + dev = &rte_eth_devices[port_id];
> > + ixgbe_bypass_init(dev);
> > + return 0;
> > +}
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_state_show(uint8_t port_id, uint32_t *state) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_state_show(dev, state); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_state_set(uint8_t port_id, uint32_t *new_state) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_state_store(dev, new_state); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_event_show(uint8_t port_id,
> > + uint32_t event,
> > + uint32_t *state)
> > +{
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_event_show(dev, event, state); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_event_store(uint8_t port_id,
> > +uint32_t event,
> > +uint32_t state)
> > +{
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_event_store(dev, event, state); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_wd_timeout_store(uint8_t port_id, uint32_t
> > +timeout) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_wd_timeout_store(dev, timeout); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_ver_show(uint8_t port_id, uint32_t *ver) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_ver_show(dev, ver); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_wd_timeout_show(uint8_t port_id, uint32_t
> > +*wd_timeout) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_wd_timeout_show(dev, wd_timeout); }
> > +
> > +int
> > +rte_pmd_ixgbe_bypass_wd_reset(uint8_t port_id) {
> > + struct rte_eth_dev *dev;
> > +
> > + RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> > +
> > + dev = &rte_eth_devices[port_id];
> > + return ixgbe_bypass_wd_reset(dev);
> > +}
>
Re: [dpdk-dev] [PATCH v4 05/19] net/ixgbe: properly reference PCI header
Why to introduce this change ? Even without this patch, all files can be built successfully. Each.*.o.d files in x86_64-native-linuxapp-gcc keeps same in both with and without this patch. So there is no need to add the line at least in the config of x86_64-native-linuxapp-gcc. > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Gaetan Rivet > Sent: Thursday, June 8, 2017 7:57 AM > To: dev@dpdk.org > Cc: Gaetan Rivet > Subject: [dpdk-dev] [PATCH v4 05/19] net/ixgbe: properly reference PCI header > > Signed-off-by: Gaetan Rivet > --- > drivers/net/ixgbe/ixgbe_ethdev.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h > b/drivers/net/ixgbe/ixgbe_ethdev.h > index e2d0139..bb5ecd5 100644 > --- a/drivers/net/ixgbe/ixgbe_ethdev.h > +++ b/drivers/net/ixgbe/ixgbe_ethdev.h > @@ -39,6 +39,7 @@ > #include "ixgbe_bypass.h" > #include > #include > +#include > > /* need update link, bit flag */ > #define IXGBE_FLAG_NEED_LINK_UPDATE (uint32_t)(1 << 0) > -- > 2.1.4
Re: [dpdk-dev] [PATCH 7/7] net/i40e: add support of restoration
> -Original Message-
> From: Wu, Jingjing
> Sent: Wednesday, June 7, 2017 3:50 PM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Ananyev, Konstantin ; Zhang, Helin
>
> Cc: dev@dpdk.org
> Subject: RE: [PATCH 7/7] net/i40e: add support of restoration
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Saturday, May 27, 2017 4:22 PM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> > ; Zhang, Helin ;
> > Wu, Jingjing
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH 7/7] net/i40e: add support of restoration
> >
> > export dev_uninit and dev_init for restoration to reset port but keep
> > same port id.
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/i40e/i40e_ethdev.c| 2 ++
> > drivers/net/i40e/i40e_ethdev_vf.c | 5 +
> > 2 files changed, 7 insertions(+)
> >
> > diff --git a/drivers/net/i40e/i40e_ethdev.c
> > b/drivers/net/i40e/i40e_ethdev.c index 4c49673..9512ca4 100644
> > --- a/drivers/net/i40e/i40e_ethdev.c
> > +++ b/drivers/net/i40e/i40e_ethdev.c
> > @@ -449,6 +449,8 @@ static const struct eth_dev_ops i40e_eth_dev_ops =
> {
> > .dev_start= i40e_dev_start,
> > .dev_stop = i40e_dev_stop,
> > .dev_close= i40e_dev_close,
> > + .dev_init = eth_i40e_dev_init,
> > + .dev_uninit = eth_i40e_dev_uninit,
> > .promiscuous_enable = i40e_dev_promiscuous_enable,
> > .promiscuous_disable = i40e_dev_promiscuous_disable,
> > .allmulticast_enable = i40e_dev_allmulticast_enable,
>
>
> you can just get int and unint func point by eth_dev->driver.eth_dev_init and
> eth_dev->driver.eth_dev_init
>
> No need to define ops here.
I'm sorry that struct rte_eth_dev doesn't have member driver.
The struct rte_eth_dev_data, struct rte_pci_device and struct rte_pci_device
don't have
Any member to refer dev_init() and dev_uninit.
Re: [dpdk-dev] [PATCH v2 0/5] Support NIC reset and keep same port id
Many thanks to Yuan for your test support.
Your test show the code changes for rte_ether and driver/net can work as
expected.
I'll update a v3 patch set according to feedback from Wu Jingjing and your test.
In v3 patch, only code in testpmd will be changed but with similar test method.
> -Original Message-
> From: Peng, Yuan
> Sent: Thursday, June 29, 2017 11:52 AM
> To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Zhang, Helin ; Wu,
> Jingjing
> Cc: dev@dpdk.org; Dai, Wei
> Subject: RE: [dpdk-dev] [PATCH v2 0/5] Support NIC reset and keep same port id
>
> Tested-by: Peng, Yuan
>
> - Tested commit c1923afc0999b5b6f109190bc5b69b6c3d334635+the 5
> patches.
> - OS: 4.5.5-300.fc24.x86_64
> - GCC: gcc version 6.1.1 20160510 (Red Hat 6.1.1-2) (GCC)
> - CPU: Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz
> - NIC: Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit
> SFI/SFP+
> Network Connection [8086:10fb] (rev 01)
> - Default x86_64-native-linuxapp-gcc configuration
> - Prerequisites:
> - Total 1cases, 1 passed, 0 failed
>
> Steps:
> DUT:
> 1. run testpmd with ixgbe VF
> echo 1 >/sys/bus/pci/devices/:07:00.0/sriov_numvfs
> ip link set ens786f0 vf 0 mac 00:11:22:33:44:11 ./usertools/dpdk-devbind.py -b
> vfio-pci 07:10.0 ./x86_64-native-linuxapp-gcc/app/testpmd -c 0x3 -n 4 -- -i
>
> 2. testpmd > set verbose 1
> testpmd> set fwd rxonly
> testpmd> start
> tester:
> scapy
> >>> pkt1 = Ether(dst="00:11:22:33:44:11")/IP()/UDP()/Raw('x' * 20)
> >>> sendp(pkt1, iface="ens786f1", count=1)
> Vf can receive the packet correctly.
>
> 3. ifconfig ens786f0 down
> A message is shown in testmd to indicate PF reset:
> Port 0: Interrupt reset event
>
> 4. ifconfig ens786f0 up
>
> 5. testpmd > stop
>
> 6. testpmd > reset_port 0
>
> 7. testpmd> reconfig_port 0
> PMD: ixgbevf_dev_configure(): VF can't disable HW CRC Strip Port 0 MAC: 00
> 11 22 33 44 11 Begin to forward at least 100 packets to test reconfiguration
>
> 8. tester:
> >>> sendp(pkt1, iface="ens786f1", count=100)
>
> 9. Finish forwarding 100 packets to test reconfiguration
> testpmd> show port stats all
>
> NIC statistics for port 0
>
> RX-packets: 100RX-missed: 0 RX-bytes: 6200
> RX-errors: 0
> RX-nombuf: 0
> TX-packets: 0 TX-errors: 0 TX-bytes: 0
>
> Throughput (since last show)
> Rx-pps:0
> Tx-pps:0
>
>
> ########
>
> The vf can be reconfigured successfully after pf reset.
>
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> Sent: Tuesday, June 27, 2017 10:07 PM
> To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev,
> Konstantin ; Zhang, Helin
> ; Wu, Jingjing
> Cc: dev@dpdk.org; Dai, Wei
> Subject: [dpdk-dev] [PATCH v2 0/5] Support NIC reset and keep same port id
>
> Sometimes a port have to be reset. After reset, if the port goes through PCI
> remove() and then PCI probe() for restoration, its port id may be changed and
> this is not expected by some customer DPDK application.
> Normally, PCI probe() includes two parts: one is in rte_ethdev layer and the
> other is calling PMD dev_init(). PCI remove( ) release all resource allocated
> from rte_ethdev layer in PCI probe( ) and calls PMD dev_unit( ).
> To keep same port id and reset the port, only dev_uninit() and dev_init( ) in
> PMD can be called and keep all resources allocated from rte_ethdev layer poart
> in PCI probe( ).
>
> New rte_eth_dev_reset( ) calls rte_eth_dev_stop( ), PMD dev_uninit( ) and
> then PMD dev_init( ) to reset a port and keep same port id.
> And then application can go through rte_eth_dev_configure( ),
> rte_eth_rx_queue_setup( ), rte_eth_tx_queue_setup( ) and
> rte_eth_dev_start( ) again to restore its previous settings or to reconfigure
> itself with different settings.
>
> To test this new feature, 2 testpmd commands are introduced.
> The first command "reset_port port_id" calls rte_eth_dev_reset( ).
> The second command "reconfig_port port_id" is used to test if the port can be
> reconfigured successfully. This command configure the port with the simplest
> settings include only 1 Rx queue, only 1 Tx queue, Rx mode = None and Tx mode
> = None. It check port by receving at least
> 100 packets and then forward these packets from itself.
>
> A typical test steps are listed as follows:
> For example, run "ifconfig
Re: [dpdk-dev] [PATCH v2 5/5] app/testpmd: add command to test NIC restoration
Thanks for your feedback. V3 patch set will follow your guide. > -Original Message- > From: Wu, Jingjing > Sent: Wednesday, June 28, 2017 5:05 PM > To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo > ; Ananyev, Konstantin > ; Zhang, Helin > Cc: dev@dpdk.org > Subject: RE: [PATCH v2 5/5] app/testpmd: add command to test NIC restoration > > > > > -----Original Message- > > From: Dai, Wei > > Sent: Tuesday, June 27, 2017 10:07 PM > > To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev, > > Konstantin ; Zhang, Helin > > ; Wu, Jingjing > > Cc: dev@dpdk.org; Dai, Wei > > Subject: [PATCH v2 5/5] app/testpmd: add command to test NIC > > restoration > > > > When a NIC is reset, a message will show it. > > And then user can run the command "reset_port port_id" > > to reset the port and to keep same port id without any without any > > configuration. > > This patch adds a testpmd command "reconfig_port port_id" > > to test whether the port can be reconfigured to have success Rx and Tx > function. > > The new command will configure the port with the simplest setting > > which includes only 1 Rx queue, only 1 Tx queue, Rx mode = None and Tx > > mode = None. > > It check if the port can receive and forward some packets. > > For example 100 packets in this new command. > > Before testing with "reset_port port_id" and then "reconfig_port > > port_id", current forwarding should be stopped first to avoid crash. > > > > Testpmd has mechanism to support reconfigure, you can check the > need_reconfig Field in port struct. > No need to define a new command. > > > Thanks > Jingjing
Re: [dpdk-dev] [PATCH v2 4/5] app/testpmd: add command to test NIC reset
> -Original Message-
> From: Wu, Jingjing
> Sent: Wednesday, June 28, 2017 5:11 PM
> To: Dai, Wei ; tho...@monjalon.net; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Zhang, Helin
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v2 4/5] app/testpmd: add command to test NIC reset
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Tuesday, June 27, 2017 10:07 PM
> > To: tho...@monjalon.net; Lu, Wenzhuo ; Ananyev,
> > Konstantin ; Zhang, Helin
> > ; Wu, Jingjing
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v2 4/5] app/testpmd: add command to test NIC reset
> >
> > When a NIC is reset, a message will show it.
> > And then user can run the command "reset_port port_id"
> > to process it.
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 31 +++
> > app/test- pmd/config.c | 13 + app/test-pmd/testpmd.h |
> > 1 +
> > 3 files changed, 45 insertions(+)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > ff8ffd2..90f6bde 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -2588,6 +2588,36 @@ cmdline_parse_inst_t cmd_stop = {
> > },
> > };
> >
> > +/* *** reset a port *** */
> > +struct cmd_reset_port_result {
> > + cmdline_fixed_string_t command;
> > + uint8_t port_id;
> > +};
> > +
> > +static void cmd_reset_port_parsed(__attribute__((unused)) void
> > *parsed_result,
> > + __attribute__((unused)) struct cmdline *cl,
> > + __attribute__((unused)) void *data) {
> > + struct cmd_reset_port_result *res = parsed_result;
> > + reset_port(res->port_id);
> > +}
> > +
> > +cmdline_parse_token_string_t cmd_reset_port_cmd =
> > + TOKEN_STRING_INITIALIZER(struct cmd_reset_port_result, command,
> > +"reset_port"); cmdline_parse_token_num_t cmd_reset_port_id =
> > + TOKEN_NUM_INITIALIZER(struct cmd_reset_port_result, port_id,
> > UINT8);
> > +
> > +cmdline_parse_inst_t cmd_reset_port = {
> > + .f = cmd_reset_port_parsed,
> > + .data = NULL,
> > + .help_str = "reset_port ",
>
> You can just add one more option in the commands "port start|stop|close
> " and " port start|stop|close all"
> To "port start|stop|close|reset " and " port start|stop|close|reset
> all" instead of defining a new one.
Thanks for your feedback.
V3 patch set will follow your guide.
Re: [dpdk-dev] [PATCH 1/2] ethdev: fix adding invalid MAC addr
Hi, Nélio Laranjeiro
Thanks for your feedback.
I will change them in my next version of patch set.
-Wei
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Monday, April 3, 2017 5:18 PM
> To: Dai, Wei
> Cc: dev@dpdk.org; thomas.monja...@6wind.com; harish.pa...@cavium.com;
> rasesh.m...@cavium.com; stephen.h...@broadcom.com;
> ajit.khapa...@broadcom.com; Lu, Wenzhuo ; Zhang,
> Helin ; Ananyev, Konstantin
> ; Wu, Jingjing ; Chen,
> Jing D ; adrien.mazarg...@6wind.com; Richardson,
> Bruce ; yuanhan@linux.intel.com;
> maxime.coque...@redhat.com; sta...@dpdk.org
> Subject: Re: [PATCH 1/2] ethdev: fix adding invalid MAC addr
>
> Hi,
>
> Please see below some comments,
>
> On Sat, Apr 01, 2017 at 04:03:16PM +0800, Wei Dai wrote:
> >[...]
> > diff --git a/drivers/net/mlx4/mlx4.c b/drivers/net/mlx4/mlx4.c index
> >79efaaa..d61bb27 100644
> > --- a/drivers/net/mlx4/mlx4.c
> > +++ b/drivers/net/mlx4/mlx4.c
> > @@ -4630,26 +4630,30 @@ mlx4_mac_addr_remove(struct rte_eth_dev
> *dev, uint32_t index)
> > * @param vmdq
> > * VMDq pool index to associate address with (ignored).
> > */
> > -static void
> > +static int
>
> Please keep function documentation up to date.
>
> > mlx4_mac_addr_add(struct rte_eth_dev *dev, struct ether_addr
> *mac_addr,
> > uint32_t index, uint32_t vmdq)
> > {
> > struct priv *priv = dev->data->dev_private;
> > + int re;
> >
> > if (mlx4_is_secondary())
> > - return;
> > + return -1;
>
> Should not it return ENOSUP instead?
>
> > (void)vmdq;
> > priv_lock(priv);
> > DEBUG("%p: adding MAC address at index %" PRIu32,
> > (void *)dev, index);
> > /* Last array entry is reserved for broadcast. */
> > - if (index >= (elemof(priv->mac) - 1))
> > - goto end;
> > - priv_mac_addr_add(priv, index,
> > + if (index >= (elemof(priv->mac) - 1)) {
> > + priv_unlock(priv);
> > + return -2;
> > + }
> > + re = priv_mac_addr_add(priv, index,
> > (const uint8_t (*)[ETHER_ADDR_LEN])
> > mac_addr->addr_bytes);
>
> You have an issue here, internal function of mlx drivers return positives
> errno
> (as described in their functions documentation).
> It should be negated before returning.
>
> > end:
> > priv_unlock(priv);
> > + return re;
> > }
> >
> > /**
> > diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h index
> > 879da5e..cca7a36 100644
> > --- a/drivers/net/mlx5/mlx5.h
> > +++ b/drivers/net/mlx5/mlx5.h
> > @@ -229,8 +229,8 @@ int hash_rxq_mac_addrs_add(struct hash_rxq *);
> > int priv_mac_addr_add(struct priv *, unsigned int,
> > const uint8_t (*)[ETHER_ADDR_LEN]); int
> > priv_mac_addrs_enable(struct priv *); -void mlx5_mac_addr_add(struct
> > rte_eth_dev *, struct ether_addr *, uint32_t,
> > - uint32_t);
> > +int mlx5_mac_addr_add(struct rte_eth_dev *dev, struct ether_addr
> *mac_addr,
> > + uint32_t index, uint32_t vmdq);
> > void mlx5_mac_addr_set(struct rte_eth_dev *, struct ether_addr *);
> >
> > /* mlx5_rss.c */
> > diff --git a/drivers/net/mlx5/mlx5_mac.c b/drivers/net/mlx5/mlx5_mac.c
> > index 4fcfd3b..db93f4e 100644
> > --- a/drivers/net/mlx5/mlx5_mac.c
> > +++ b/drivers/net/mlx5/mlx5_mac.c
> > @@ -470,26 +470,30 @@ priv_mac_addrs_enable(struct priv *priv)
> > * @param vmdq
> > * VMDq pool index to associate address with (ignored).
> > */
> > -void
> > +int
> > mlx5_mac_addr_add(struct rte_eth_dev *dev, struct ether_addr
> *mac_addr,
> > uint32_t index, uint32_t vmdq)
> > {
> > struct priv *priv = dev->data->dev_private;
> > + int re;
> >
> > if (mlx5_is_secondary())
> > - return;
> > + return -1;
> >
> > (void)vmdq;
> > priv_lock(priv);
> > DEBUG("%p: adding MAC address at index %" PRIu32,
> > (void *)dev, index);
> > - if (index >= RTE_DIM(priv->mac))
> > + if (index >= RTE_DIM(priv->mac)) {
> > + re = -2;
> > goto end;
> > - priv_mac_addr_add(priv, index,
> > + }
> > + re = priv_mac_addr_add(priv, index,
> > (const uint8_t (*)[ETHER_ADDR_LEN])
> > mac_addr->addr_bytes);
> > end:
> > priv_unlock(priv);
> > + return re;
> > }
> >[...]
>
> Same remarks here,
>
> Thanks,
>
> --
> Nélio Laranjeiro
> 6WIND
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: fix adding invalid MAC addr
Thanks, Nelio Laranjeiro.
What about other parts, dear maintainers ?
> -Original Message-
> From: Nélio Laranjeiro [mailto:nelio.laranje...@6wind.com]
> Sent: Thursday, April 13, 2017 4:45 PM
> To: Dai, Wei
> Cc: thomas.monja...@6wind.com; harish.pa...@cavium.com;
> rasesh.m...@cavium.com; stephen.h...@broadcom.com;
> ajit.khapa...@broadcom.com; Lu, Wenzhuo ; Zhang,
> Helin ; Ananyev, Konstantin
> ; Wu, Jingjing ; Chen,
> Jing D ; adrien.mazarg...@6wind.com; Richardson,
> Bruce ; yuanhan@linux.intel.com;
> maxime.coque...@redhat.com; dev@dpdk.org; sta...@dpdk.org
> Subject: Re: [PATCH v4 1/3] ethdev: fix adding invalid MAC addr
>
> On Thu, Apr 13, 2017 at 04:21:04PM +0800, Wei Dai wrote:
> > some customers find adding mac addr to VF sometimes can fail, but it
> > is still stored in dev->data->mac_addrs[ ]. So this can lead to some
> > errors that assumes the non-zero entry in
> > dev->data->mac_addrs[ ] is valid.
> >
> > Fixes: af75078fece3 ("first public release")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > drivers/net/bnx2x/bnx2x_ethdev.c | 7 +--
> > drivers/net/bnxt/bnxt_ethdev.c | 12 ++--
> > drivers/net/e1000/base/e1000_api.c | 2 +-
> > drivers/net/e1000/em_ethdev.c | 6 +++---
> > drivers/net/e1000/igb_ethdev.c | 5 +++--
> > drivers/net/enic/enic.h| 2 +-
> > drivers/net/enic/enic_ethdev.c | 4 ++--
> > drivers/net/enic/enic_main.c | 6 +++---
> > drivers/net/fm10k/fm10k_ethdev.c | 3 ++-
> > drivers/net/i40e/i40e_ethdev.c | 11 ++-
> > drivers/net/i40e/i40e_ethdev_vf.c | 8
> > drivers/net/ixgbe/ixgbe_ethdev.c | 27 ++-
> > drivers/net/mlx4/mlx4.c| 18 +++---
> > drivers/net/mlx5/mlx5.h| 4 ++--
> > drivers/net/mlx5/mlx5_mac.c| 16 ++--
> > drivers/net/qede/qede_ethdev.c | 6 --
> > drivers/net/ring/rte_eth_ring.c| 3 ++-
> > drivers/net/virtio/virtio_ethdev.c | 13 +++--
> > lib/librte_ether/rte_ethdev.c | 15 +--
> > lib/librte_ether/rte_ethdev.h | 2 +-
> > 20 files changed, 100 insertions(+), 70 deletions(-)
> >
>
>
> For mlx changes,
>
> Acked-by: Nelio Laranjeiro
>
> --
> Nélio Laranjeiro
> 6WIND
Re: [dpdk-dev] [PATCH] net/ixgbe: ensure link status is updated
First of all, I agree usage of IXGBE_FLAG_NEED_LINK_CONFIG to trigger link
setup when link is up again.
Both ixgbe_get_link_capabilities( ) and ixgbe_setup_link( ) calls different
sub-function for different ixgbe MAC type including 82598, 82599, X540 and X550
and so on.
I think ixgbe_setup_link( ) can process all speeds returned from
ixgbe_get_link_capabilities( ) no matter what autoneg is.
It is no need to check autoneg and set speed to 10G if autoneg is false.
And sometimes if autoneg is false, the speed can't be 10G, maybe should be 5G
or 2.5G or others in case of multi-speed fiber.
So I suggest that you can remove following 3 lines in your patch and test it
again.
+/* setup the highest link when no autoneg */
+ if (!autoneg)
+ speed = IXGBE_LINK_SPEED_10GB_FULL;
> -Original Message-
> From: Laurent Hardy [mailto:laurent.ha...@6wind.com]
> Sent: Wednesday, April 12, 2017 4:22 PM
> To: dev@dpdk.org; Yigit, Ferruh ; Dai, Wei
> ; olivier.m...@6wind.com
> Cc: Zhang, Helin ; Ananyev, Konstantin
>
> Subject: [PATCH] net/ixgbe: ensure link status is updated
>
> In case of fiber and link speed set to 1Gb at peer side (with autoneg or with
> defined speed), link status could be not properly updated at time cable is
> plugged-in.
> Indeed if cable was not plugged when device has been configured and started
> then link status will not be updated properly with new speed as no link setup
> will be triggered.
>
> To avoid this issue, IXGBE_FLAG_NEED_LINK_CONFIG is set to try a link setup
> each time link_update() is triggered and current link status is down. When
> cable is plugged-in, link setup will be performed via ixgbe_setup_link().
>
> Signed-off-by: Laurent Hardy
> ---
>
> v1 -> v2:
> - rebase on top of head (change flag to 1<<4)
> - fix regression with copper links: only update link for fiber links
>
> v2 -> v3:
> - remove unnescessary check on speed mask if autoneg is false
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 18 ++
> drivers/net/ixgbe/ixgbe_ethdev.h | 1 +
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 1462324..bd03e60 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -3516,8 +3516,12 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev,
> int wait_to_complete)
> struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> struct rte_eth_link link, old;
> ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
> + struct ixgbe_interrupt *intr =
> + IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
> int link_up;
> int diag;
> + u32 speed = 0;
> + bool autoneg = false;
>
> link.link_status = ETH_LINK_DOWN;
> link.link_speed = 0;
> @@ -3527,6 +3531,18 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev,
> int wait_to_complete)
>
> hw->mac.get_link_status = true;
>
> + if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> + hw->mac.ops.get_media_type(hw) == ixgbe_media_type_fiber) {
> + speed = hw->phy.autoneg_advertised;
> + if (!speed) {
> + ixgbe_get_link_capabilities(hw, &speed, &autoneg);
> + /* setup the highest link when no autoneg */
> + if (!autoneg)
> + speed = IXGBE_LINK_SPEED_10GB_FULL;
> + }
> + ixgbe_setup_link(hw, speed, true);
> + }
> +
> /* check if it needs to wait to complete, if lsc interrupt is enabled */
> if (wait_to_complete == 0 || dev->data->dev_conf.intr_conf.lsc != 0)
> diag = ixgbe_check_link(hw, &link_speed, &link_up, 0); @@
> -3544,10
> +3560,12 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev, int
> wait_to_complete)
>
> if (link_up == 0) {
> rte_ixgbe_dev_atomic_write_link_status(dev, &link);
> + intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;
> if (link.link_status == old.link_status)
> return -1;
> return 0;
> }
> + intr->flags &= ~IXGBE_FLAG_NEED_LINK_CONFIG;
> link.link_status = ETH_LINK_UP;
> link.link_duplex = ETH_LINK_FULL_DUPLEX;
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h
> b/drivers/net/ixgbe/ixgbe_ethdev.h
> index a32ba4d..a6e8c8a 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.h
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.h
> @@ -45,6 +45,7 @@
> #define IXGBE_FLAG_MAILBOX (uint32_t)(1 << 1)
> #define IXGBE_FLAG_PHY_INTERRUPT(uint32_t)(1 << 2)
> #define IXGBE_FLAG_MACSEC (uint32_t)(1 << 3)
> +#define IXGBE_FLAG_NEED_LINK_CONFIG (uint32_t)(1 << 4)
>
> /*
> * Defines that were not part of ixgbe_type.h as they are not used by the
> --
> 2.1.4
Re: [dpdk-dev] [PATCH 0/4] update ixgbe base driver to version 2017-03-29
Hi, Ferruh The first patch is to align a fix in firmware. The second is to fix the miss of support of 2.5G PHY which is also needed by some customers. The third is to fix LED support on MAC X550em/X557. We have just verified them with fixed firmware. So if it is accepted, some customers can get these support. Thanks & Best Regards -Wei > -Original Message- > From: Yigit, Ferruh > Sent: Wednesday, April 19, 2017 9:22 PM > To: Dai, Wei > Cc: Zhang, Helin ; Ananyev, Konstantin > ; Lu, Wenzhuo ; > dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/4] update ixgbe base driver to version > 2017-03-29 > > On 4/18/2017 7:56 AM, Wei Dai wrote: > > This patch set has following 4 patches. > > No any new device id is added. > > > > net/ixgbe/base: acquire PHY semaphore before device reset > > net/ixgbe/base: add support for 2.5G KX physical layer > > net/ixgbe/base: add MAC X550em/X557 LED on/off support > > net/ixgbe/base: update base driver version to 2017.03.29 > > Hi Wei, > > This base code update received very close to RC2. I am postponing to next > release. > > If this set has a critical fix for release, please shout for RC3 inclusion. > > Thanks, > ferruh
Re: [dpdk-dev] [PATCH v4] net/ixgbe: ensure link status is updated
> -Original Message-
> From: Laurent Hardy [mailto:laurent.ha...@6wind.com]
> Sent: Thursday, April 27, 2017 11:04 PM
> To: dev@dpdk.org; Dai, Wei
> Cc: Yigit, Ferruh ; Zhang, Helin
> ; Ananyev, Konstantin
> ; olivier.m...@6wind.com
> Subject: [PATCH v4] net/ixgbe: ensure link status is updated
>
> In case of fiber and link speed set to 1Gb at peer side (with autoneg
> or with defined speed), link status could be not properly updated at
> time cable is plugged-in.
> Indeed if cable was not plugged when device has been configured and
> started then link status will not be updated properly with new speed
> as no link setup will be triggered.
>
> To avoid this issue, IXGBE_FLAG_NEED_LINK_CONFIG is set to try a link
> setup each time link_update() is triggered and current link status is
> down. When cable is plugged-in, link setup will be performed via
> ixgbe_setup_link().
>
> Signed-off-by: Laurent Hardy
Acked-by: Wei Dai
> ---
> Hi Wei, please find enclosed patch v4, tested using testpmd.
>
> v1 -> v2:
> - rebase on top of head (change flag to 1<<4)
> - fix regression with copper links: only update link for fiber links
>
> v2 -> v3:
> - remove unnescessary check on speed mask if autoneg is false
>
> v3 -> v4:
> - remove default speed set to 10Gb if autoneg is false, rely on
> ixgbe_get_link_capabilities( ) instead.
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 14 ++
> drivers/net/ixgbe/ixgbe_ethdev.h | 1 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 7b856bb..8a0c0a7 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -3782,8 +3782,12 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev,
> int wait_to_complete)
> struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> struct rte_eth_link link, old;
> ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
> + struct ixgbe_interrupt *intr =
> + IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
> int link_up;
> int diag;
> + u32 speed = 0;
> + bool autoneg = false;
>
> link.link_status = ETH_LINK_DOWN;
> link.link_speed = 0;
> @@ -3793,6 +3797,14 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev,
> int wait_to_complete)
>
> hw->mac.get_link_status = true;
>
> + if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> + hw->mac.ops.get_media_type(hw) == ixgbe_media_type_fiber) {
> + speed = hw->phy.autoneg_advertised;
> + if (!speed)
> + ixgbe_get_link_capabilities(hw, &speed, &autoneg);
> + ixgbe_setup_link(hw, speed, true);
> + }
> +
> /* check if it needs to wait to complete, if lsc interrupt is enabled */
> if (wait_to_complete == 0 || dev->data->dev_conf.intr_conf.lsc != 0)
> diag = ixgbe_check_link(hw, &link_speed, &link_up, 0);
> @@ -3810,10 +3822,12 @@ ixgbe_dev_link_update(struct rte_eth_dev *dev,
> int wait_to_complete)
>
> if (link_up == 0) {
> rte_ixgbe_dev_atomic_write_link_status(dev, &link);
> + intr->flags |= IXGBE_FLAG_NEED_LINK_CONFIG;
> if (link.link_status == old.link_status)
> return -1;
> return 0;
> }
> + intr->flags &= ~IXGBE_FLAG_NEED_LINK_CONFIG;
> link.link_status = ETH_LINK_UP;
> link.link_duplex = ETH_LINK_FULL_DUPLEX;
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h
> b/drivers/net/ixgbe/ixgbe_ethdev.h
> index 5176b02..b576a6f 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.h
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.h
> @@ -45,6 +45,7 @@
> #define IXGBE_FLAG_MAILBOX (uint32_t)(1 << 1)
> #define IXGBE_FLAG_PHY_INTERRUPT(uint32_t)(1 << 2)
> #define IXGBE_FLAG_MACSEC (uint32_t)(1 << 3)
> +#define IXGBE_FLAG_NEED_LINK_CONFIG (uint32_t)(1 << 4)
>
> /*
> * Defines that were not part of ixgbe_type.h as they are not used by the
> --
> 2.1.4
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: fix adding invalid MAC addr
HI, Wenzhuo > > > > int bnxt_link_update_op(struct rte_eth_dev *eth_dev, int > > wait_to_complete) diff --git a/drivers/net/e1000/base/e1000_api.c > > b/drivers/net/e1000/base/e1000_api.c > > index f7cf83b..dcb53f7 100644 > > --- a/drivers/net/e1000/base/e1000_api.c > > +++ b/drivers/net/e1000/base/e1000_api.c > > @@ -855,7 +855,7 @@ int e1000_rar_set(struct e1000_hw *hw, u8 *addr, > > u32 index) > > if (hw->mac.ops.rar_set) > > return hw->mac.ops.rar_set(hw, addr, index); > > > > - return E1000_SUCCESS; > > + return E1000_ERR_NO_SPACE; > > } > NACK here. Normally we try to avoid changing base code. And I don't think the > change is necessary. If this code is not changed, the code in ethdev may get wrong return value and assume the failed MAC addr is added. Anyway, we can ask the base code to be revised by the associated team.
Re: [dpdk-dev] [PATCH v4 1/3] ethdev: fix adding invalid MAC addr
> > > > > > > > int bnxt_link_update_op(struct rte_eth_dev *eth_dev, int > > > > wait_to_complete) diff --git a/drivers/net/e1000/base/e1000_api.c > > > > b/drivers/net/e1000/base/e1000_api.c > > > > index f7cf83b..dcb53f7 100644 > > > > --- a/drivers/net/e1000/base/e1000_api.c > > > > +++ b/drivers/net/e1000/base/e1000_api.c > > > > @@ -855,7 +855,7 @@ int e1000_rar_set(struct e1000_hw *hw, u8 > > > > *addr, > > > > u32 index) > > > > if (hw->mac.ops.rar_set) > > > > return hw->mac.ops.rar_set(hw, addr, index); > > > > > > > > - return E1000_SUCCESS; > > > > + return E1000_ERR_NO_SPACE; > > > > } > > > NACK here. Normally we try to avoid changing base code. And I don't > > > think the change is necessary. > > > > If this code is not changed, the code in ethdev may get wrong return > > value and assume the failed MAC addr is added. > > Anyway, we can ask the base code to be revised by the associated team. > ' hw->mac.ops.rar_set ' cannot be NULL. That's why I think this change is not > necessary. OK, I will follow your advice in my v6 patch set. Thanks
Re: [dpdk-dev] [PATCH v6 1/3] ethdev: fix adding invalid MAC addr
> Subject: Re: [PATCH v6 1/3] ethdev: fix adding invalid MAC addr
>
> On Tue, May 02, 2017 at 08:44:23PM +0800, Wei Dai wrote:
> > Some customers find adding MAC addr to VF sometimes can fail, but it
> > is still stored in dev->data->mac_addrs[ ]. So this can lead to some
> > errors that assumes the non-zero entry in
> > dev->data->mac_addrs[ ] is valid.
> > Following acknowledgements are from specific NIC PMD maintainer for
> > their managing part.
> >
> > Fixes: af75078fece3 ("first public release")
>
>
> > Cc: sta...@dpdk.org
>
> Just a note, this patch changes API. It should not be backported to a
> stable/LTS
> release, even though it fixes something.
>
> --yliu
Thank you, Yuanhan. I will drop the "Cc: sta...@dpdk.org" in my v7 patch set.
Re: [dpdk-dev] [PATCH v2 0/3] add a macro to enable support of backtrace
Hi, Thomas I noticed that my following patch set has been superseded. It address the compile errors when DPDK is built with musl. I know some customer products like Yocto Linux and that from Roph are using DPDK with musl and they have to manually change something to build it. Roph also referenced to use DPDK with musl in his mail titled " [dpdk-dev] Compiling DPDK 17.02 using musl instead of glibc " sent on 2017-03-14 Thanks & Best Regards -Wei > -Original Message----- > From: Dai, Wei > Sent: Monday, March 13, 2017 4:59 PM > To: dev@dpdk.org > Cc: thomas.monja...@6wind.com; Mcnamara, John > ; david.march...@6wind.com; Tan, Raymond > ; Dai, Wei > Subject: [PATCH v2 0/3] add a macro to enable support of backtrace > > Some LIBC implementation like musl doesn't support backtrace( ) and > backtrace_symbols declared in execinfo.h. > Currently some DPDK customers fail to build PDDK with musl. > In order to build DPDK with musl, there is a need to reomve references > toexecinfo.h. > > Add a configuration parameter in config/common_linuxapp which equals to y by > default. It also generate a macro named as RTE_EAL_ENABLE_BACKTRACE > when this configuration paramter equals to y or no above macro when it is n. > > --- > changes: > v2 -- change configuration parameter name > > > Wei Dai (3): > examples/performance-thread: remove reference to execinfo.h > config: add a marco to enable backtrace or not > eal: remove references to execinfo.h for musl > > config/common_linuxapp | 1 + > examples/performance-thread/common/lthread_tls.c | 1 - > lib/librte_eal/linuxapp/eal/eal_debug.c | 4 > 3 files changed, 5 insertions(+), 1 deletion(-) > > -- > 2.7.4
Re: [dpdk-dev] bug in net/ixgbe/ixgbe_ethdev.c:ixgbe_dev_link_update beginning in 17.05-rc3?
Yes, it is a bug.
The hw->mac.ops.get_media_type of ixgbe VF is NULL.
I have just submitted a patch to fix it.
http://dpdk.org/dev/patchwork/patch/24188/
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Roger B Melton
> Sent: Wednesday, May 10, 2017 1:53 AM
> To: dev@dpdk.org; laurent.ha...@6wind.com
> Subject: [dpdk-dev] bug in net/ixgbe/ixgbe_ethdev.c:ixgbe_dev_link_update
> beginning in 17.05-rc3?
>
> After updating to 17.05-rc4 I hit a crash in
> drivers/net/ixgbe/ixgbe_ethdev.c:ixgbe_dev_link_update(). The issue was
> a NULL get_media_type FV for the VF driver.
>
> Looking at recent commits, I see the following added the
> get_media_type() check:
>
> commit c12d22f65b132c56db7b4fdbfd5ddce27d1e9572
> Author: Laurent Hardy
> Date: Thu Apr 27 17:03:42 2017 +0200
>
> @@ -3793,6 +3797,14 @@ ixgbe_dev_link_update(struct
> rte_eth_dev
> *dev, int wait_to_complete)
>
> hw->mac.get_link_status = true;
>
> + if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> + hw->mac.ops.get_media_type(hw) ==
> ixgbe_media_type_fiber) {
> + speed = hw->phy.autoneg_advertised;
> + if (!speed)
> + ixgbe_get_link_capabilities(hw,
> &speed,
> &autoneg);
> + ixgbe_setup_link(hw, speed, true);
> + }
> +
>
> This is fine for the PF driver, but we shouldn't invoke get_media_type
> for the VF.
>
>
> Laurent,
>
> Is this a bug, or am I missing something? If it is a bug, what's the
> proper fix?
>
> Regards,
> Roger
>
>
>
>
> --
>
>
>
> |Roger B. Melton| | Cisco Systems
> |
> |CPP Software :|::|: 7100 Kit Creek Rd |
> |+1.919.476.2332 phone:|||: :|||:RTP, NC 27709-4987 |
> |+1.919.392.1094 fax .:|||:..:|||:. rmel...@cisco.com |
> |
> |
> | This email may contain confidential and privileged material for the|
> | sole use of the intended recipient. Any review, use, distribution |
> | or disclosure by others is strictly prohibited. If you are not the |
> | intended recipient (or authorized to receive for the recipient), |
> | please contact the sender by reply email and delete all copies of |
> | this message.
> |
> |
> |
> | For corporate legal information go to: |
> | http://www.cisco.com/web/about/doing_business/legal/cri/index.html |
> |__ http://www.cisco.com
> |
Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
Hi, Srini There is a bit confusion. Your patch shows that your code is added into the function eth_ixgbevf_pci_remove( ). But it is not. It is added into the fucntion ixgbe_dev_start( ), right ? So would you please rebase it to R 17.05 ? Which type of ixgbe device id did you tested ? There are many MAC types with different device id. The function ixgbe_pf_reset_hw(hw) is called before your adding code. ixgbe_pf_reset_hw() calls hw->mac.ops.reset_hw( ) which may points to following different function for different MAC type. Ixgbe_reset_hw_82598( ) calls hw->phy.ops.init(hw) if hw->phy.reset_disable == false . Ixgbe_reset_hw_82599( ) calls hw->phy.ops.init(hw) unconditionally. ixgbe_reset_hw_X540( ) doesn't' call pw->phy.ops.init(hw). For X540, hw->phy.ops.init points to ixgbe_init_phy_ops_generic() which only initialize some function pointers. Ixgbe_rest_hw_x550em() calls hw->phy.ops.init(hw) unconditionally. And for VF, ixgbe_reset_hw_vf( ) and ixgbevf_hv_reset_hw_vf( ) don't call hw->phy.ops.init(hw) anywhere. Thanks & Best Regards -Wei > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Thomas Monjalon > Sent: Sunday, May 7, 2017 6:36 AM > To: Srinivasan J > Cc: dev@dpdk.org; Lu, Wenzhuo ; Ananyev, > Konstantin > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped > SFP/SFP+ > > 06/05/2017 15:51, Srinivasan J: > > Hi, > >Do we need an explicit "Acked-by" keyword for this > > patch to be accepted and applied? > > Yes, given it is not a trivial patch, an ack from the maintainer is required. > Anyway, it has been submitted too late for 17.05 testing.
Re: [dpdk-dev] [PATCH] examples/helloworld: add output of core id and socket id
> -Original Message-
> From: Yigit, Ferruh
> Sent: Wednesday, May 17, 2017 10:16 PM
> To: Dai, Wei ; Richardson, Bruce
> ; Mcnamara, John
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] examples/helloworld: add output of core id and
> socket id
>
> On 5/17/2017 2:49 PM, Wei Dai wrote:
> > Adding output of core id and socket id of each lcore/pthread can help
> > to understand their relationship.
> > And this can also help to examine the usage of the EAL lcore settings
> > like -c, -l and --lcore .
> >
> > Signed-off-by: Wei Dai
> > ---
> > examples/helloworld/main.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/examples/helloworld/main.c b/examples/helloworld/main.c
> > index 8b7a2de..fdd8818 100644
> > --- a/examples/helloworld/main.c
> > +++ b/examples/helloworld/main.c
> > @@ -50,7 +50,9 @@ lcore_hello(__attribute__((unused)) void *arg) {
> > unsigned lcore_id;
> > lcore_id = rte_lcore_id();
> > - printf("hello from core %u\n", lcore_id);
> > + printf("hello from core %2u at core_id = %2u on socket_id = %2u\n",
>
> It is hard to understand difference from "core" and "core_id", what do you
> think using "lcore" and "core" respectively in the message?
Yes, it is still a bit confused.
I should change it to printf("hello from lcore_id = %2u at core_id = %2u on
socket_id = %2u\n",
>
> > + lcore_id, lcore_config[lcore_id].core_id,
> > + lcore_config[lcore_id].socket_id);
> > return 0;
> > }
> >
> >
Re: [dpdk-dev] 2nd try: problem with ixgbe_dev_link_update() for multi-speed fiber [was] Re: [PATCH v4] net/ixgbe: ensure link status is updated
Hi, Roger
Sorry for late response as we are busy with other higher priority task.
ixgbe_setup_mac_link_multispeed_fiber( ) in ixgbe_common.c calls
ixgbe_setup_mac_link( ) which some functions defined in ixgbe/base .
Would you please give us more info to narrow down this issue ?
What device id did you use to trigger this issue ?
To get more info, would you please change
"CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n" to "
CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=y" in config/common_base
And run your application with EAL parameter --log-level=7 to get trace path of
ixgbe functions for us.
Thanks & Best Regards
-Wei
> -Original Message-
> From: Roger B. Melton [mailto:rmel...@cisco.com]
> Sent: Tuesday, May 23, 2017 2:54 AM
> To: Laurent Hardy ; dev@dpdk.org; Dai, Wei
>
> Cc: Yigit, Ferruh ; Zhang, Helin
> ; Ananyev, Konstantin
> ; olivier.m...@6wind.com
> Subject: 2nd try: problem with ixgbe_dev_link_update() for multi-speed fiber
> [was] Re: [dpdk-dev] [PATCH v4] net/ixgbe: ensure link status is updated
>
> Hi Laurent/Wei,
>
> Any thoughts?
>
> Regards,
> Roger
>
>
> On 5/17/17 9:31 AM, Roger B Melton wrote:
> > Hi Laurent/Wei,
> >
> > As I continue to integrate DPDK 17.05 into my application, I have hit
> > another issue with this patch while testing in a VM with multispeed
> > fiber ixgbe PCI passthrough. My application periodically invokes
> > rte_eth_link_get_nowait() to detect link state changes. If the link
> > is down (no cable or far end disabled), ixgbe_setup_link() will not
> > return for ~1.3seconds due to the link setup algorithm in
> > ixgbe_common.c:ixgbe_multispeed_fiber():
> >
> > +if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> > +hw->mac.ops.get_media_type(hw) == ixgbe_media_type_fiber) {
> > +speed = hw->phy.autoneg_advertised;
> > +if (!speed)
> > +ixgbe_get_link_capabilities(hw, &speed, &autoneg);
> > +ixgbe_setup_link(hw, speed, true); +}
> > +
> >
> > I have two questions:
> >
> > * Shouldn't we avoid the link setup cost if the caller has specified
> >not to wait_to_complete?
> > * If the concern is speed may not be properly configured, shouldn't
> >the link setup be deferred until state changes link up thus
> >minimizing the delays enforced in ixgbe_multispeed_fiber()?
> >
> >
> > Regards,
> > -Roger
> >
> >
> >
> >
> > On 4/27/17 11:03 AM, Laurent Hardy wrote:
> >> In case of fiber and link speed set to 1Gb at peer side (with autoneg
> >> or with defined speed), link status could be not properly updated at
> >> time cable is plugged-in.
> >> Indeed if cable was not plugged when device has been configured and
> >> started then link status will not be updated properly with new speed
> >> as no link setup will be triggered.
> >>
> >> To avoid this issue, IXGBE_FLAG_NEED_LINK_CONFIG is set to try a link
> >> setup each time link_update() is triggered and current link status is
> >> down. When cable is plugged-in, link setup will be performed via
> >> ixgbe_setup_link().
> >>
> >> Signed-off-by: Laurent Hardy
> >> ---
> >> Hi Wei, please find enclosed patch v4, tested using testpmd.
> >>
> >> v1 -> v2:
> >> - rebase on top of head (change flag to 1<<4)
> >> - fix regression with copper links: only update link for fiber links
> >>
> >> v2 -> v3:
> >> - remove unnescessary check on speed mask if autoneg is false
> >>
> >> v3 -> v4:
> >> - remove default speed set to 10Gb if autoneg is false, rely on
> >> ixgbe_get_link_capabilities( ) instead.
> >> ---
> >> drivers/net/ixgbe/ixgbe_ethdev.c | 14 ++
> >> drivers/net/ixgbe/ixgbe_ethdev.h | 1 +
> >> 2 files changed, 15 insertions(+)
> >>
> >> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> >> b/drivers/net/ixgbe/ixgbe_ethdev.c
> >> index 7b856bb..8a0c0a7 100644
> >> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> >> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> >> @@ -3782,8 +3782,12 @@ ixgbe_dev_link_update(struct rte_eth_dev
> *dev,
> >> int wait_to_complete)
> >> struct ixgbe_hw *hw =
> >> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> >> struct rte_eth_link link, old;
> >> ixgbe_link_speed link_speed = IXGBE_LINK_SPEED_UNKNOWN;
> >> +struct ixgbe_interrupt *intr =
> >> + IXGBE_DEV_PRIVA
Re: [dpdk-dev] 2nd try: problem with ixgbe_dev_link_update() for multi-speed fiber [was] Re: [PATCH v4] net/ixgbe: ensure link status is updated
Hi, Roger
Sorry for typo error. You should set --log-level=8
Regards
-Wei
> -Original Message-
> From: Dai, Wei
> Sent: Tuesday, May 23, 2017 3:24 PM
> To: 'Roger B. Melton' ; Laurent Hardy
> ; dev@dpdk.org
> Cc: Yigit, Ferruh ; Zhang, Helin
> ; Ananyev, Konstantin
> ; olivier.m...@6wind.com
> Subject: RE: 2nd try: problem with ixgbe_dev_link_update() for multi-speed
> fiber [was] Re: [dpdk-dev] [PATCH v4] net/ixgbe: ensure link status is updated
>
> Hi, Roger
> Sorry for late response as we are busy with other higher priority task.
> ixgbe_setup_mac_link_multispeed_fiber( ) in ixgbe_common.c calls
> ixgbe_setup_mac_link( ) which some functions defined in ixgbe/base .
> Would you please give us more info to narrow down this issue ?
>
> What device id did you use to trigger this issue ?
>
> To get more info, would you please change
> "CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=n" to "
> CONFIG_RTE_LIBRTE_IXGBE_DEBUG_DRIVER=y" in config/common_base And
> run your application with EAL parameter --log-level=7 to get trace path of
> ixgbe functions for us.
>
> Thanks & Best Regards
> -Wei
>
>
> > -Original Message-
> > From: Roger B. Melton [mailto:rmel...@cisco.com]
> > Sent: Tuesday, May 23, 2017 2:54 AM
> > To: Laurent Hardy ; dev@dpdk.org; Dai, Wei
> >
> > Cc: Yigit, Ferruh ; Zhang, Helin
> > ; Ananyev, Konstantin
> > ; olivier.m...@6wind.com
> > Subject: 2nd try: problem with ixgbe_dev_link_update() for multi-speed
> > fiber [was] Re: [dpdk-dev] [PATCH v4] net/ixgbe: ensure link status is
> > updated
> >
> > Hi Laurent/Wei,
> >
> > Any thoughts?
> >
> > Regards,
> > Roger
> >
> >
> > On 5/17/17 9:31 AM, Roger B Melton wrote:
> > > Hi Laurent/Wei,
> > >
> > > As I continue to integrate DPDK 17.05 into my application, I have
> > > hit another issue with this patch while testing in a VM with
> > > multispeed fiber ixgbe PCI passthrough. My application periodically
> > > invokes
> > > rte_eth_link_get_nowait() to detect link state changes. If the link
> > > is down (no cable or far end disabled), ixgbe_setup_link() will not
> > > return for ~1.3seconds due to the link setup algorithm in
> > > ixgbe_common.c:ixgbe_multispeed_fiber():
> > >
> > > +if ((intr->flags & IXGBE_FLAG_NEED_LINK_CONFIG) &&
> > > +hw->mac.ops.get_media_type(hw) == ixgbe_media_type_fiber) {
> > > +speed = hw->phy.autoneg_advertised;
> > > +if (!speed)
> > > +ixgbe_get_link_capabilities(hw, &speed, &autoneg);
> > > +ixgbe_setup_link(hw, speed, true); +}
> > > +
> > >
> > > I have two questions:
> > >
> > > * Shouldn't we avoid the link setup cost if the caller has specified
> > >not to wait_to_complete?
> > > * If the concern is speed may not be properly configured, shouldn't
> > >the link setup be deferred until state changes link up thus
> > >minimizing the delays enforced in ixgbe_multispeed_fiber()?
> > >
> > >
> > > Regards,
> > > -Roger
> > >
> > >
> > >
> > >
> > > On 4/27/17 11:03 AM, Laurent Hardy wrote:
> > >> In case of fiber and link speed set to 1Gb at peer side (with
> > >> autoneg or with defined speed), link status could be not properly
> > >> updated at time cable is plugged-in.
> > >> Indeed if cable was not plugged when device has been configured and
> > >> started then link status will not be updated properly with new
> > >> speed as no link setup will be triggered.
> > >>
> > >> To avoid this issue, IXGBE_FLAG_NEED_LINK_CONFIG is set to try a
> > >> link setup each time link_update() is triggered and current link
> > >> status is down. When cable is plugged-in, link setup will be
> > >> performed via ixgbe_setup_link().
> > >>
> > >> Signed-off-by: Laurent Hardy
> > >> ---
> > >> Hi Wei, please find enclosed patch v4, tested using testpmd.
> > >>
> > >> v1 -> v2:
> > >> - rebase on top of head (change flag to 1<<4)
> > >> - fix regression with copper links: only update link for fiber
> > >> links
> > >>
> > >> v2 -> v3:
> > >> - remove unnescessary check on speed mask if autoneg is false
> > >>
> > >> v3 -> v4:
> > &g
Re: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some offload
Hi, Yuan
How about your test result ?
Thanks a lot!
> -Original Message-
> From: Dai, Wei
> Sent: Thursday, July 19, 2018 8:21 PM
> To: Wu, Jingjing ; yuan.p...@intle.com
> Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> Subject: [PATCH] app/testpmd: fix commands to config some offload
>
> Without this patch, testpmd command to config Rx offload keep_crc would
> fail and report "Bad argument".
> This patch aslo fix the command to config the Tx offload mbuf_fast_free.
>
> Fixes: 70815c9ecadd ("ethdev: add new offload flag to keep CRC")
> Fixes: c73a9071877a ("app/testpmd: add commands to test new offload
> API")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> app/test-pmd/cmdline.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> 5885289..a0ed3a0 100644
> --- a/app/test-pmd/cmdline.c
> +++ b/app/test-pmd/cmdline.c
> @@ -16665,7 +16665,7 @@ struct cmd_config_per_port_rx_offload_result
> {
>offload,
> "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
> "qinq_strip#outer_ipv4_cksum#macsec_strip#"
> "header_split#vlan_filter#vlan_extend#jumbo_frame#"
> -"crc_strip#scatter#timestamp#security");
> +"crc_strip#scatter#timestamp#security#keep_crc");
> cmdline_parse_token_string_t
> cmd_config_per_port_rx_offload_result_on_off =
> TOKEN_STRING_INITIALIZER
> (struct cmd_config_per_port_rx_offload_result,
> @@ -16744,7 +16744,7 @@ struct cmd_config_per_port_rx_offload_result
> {
> .help_str = "port config rx_offload vlan_strip|ipv4_cksum|"
>
> "udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
> "macsec_strip|header_split|vlan_filter|vlan_extend|"
> - "jumbo_frame|crc_strip|scatter|timestamp|security "
> +
> "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
> "on|off",
> .tokens = {
> (void *)&cmd_config_per_port_rx_offload_result_port,
> @@ -16794,7 +16794,7 @@ struct
> cmd_config_per_queue_rx_offload_result {
>offload,
> "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
> "qinq_strip#outer_ipv4_cksum#macsec_strip#"
> "header_split#vlan_filter#vlan_extend#jumbo_frame#"
> -"crc_strip#scatter#timestamp#security");
> +"crc_strip#scatter#timestamp#security#keep_crc");
> cmdline_parse_token_string_t
> cmd_config_per_queue_rx_offload_result_on_off =
> TOKEN_STRING_INITIALIZER
> (struct cmd_config_per_queue_rx_offload_result,
> @@ -16846,7 +16846,7 @@ struct
> cmd_config_per_queue_rx_offload_result {
> "vlan_strip|ipv4_cksum|"
>
> "udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
> "macsec_strip|header_split|vlan_filter|vlan_extend|"
> - "jumbo_frame|crc_strip|scatter|timestamp|security "
> +
> "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
> "on|off",
> .tokens = {
> (void *)&cmd_config_per_queue_rx_offload_result_port,
> @@ -17063,7 +17063,7 @@ struct cmd_config_per_port_tx_offload_result
> {
> "sctp_cksum#tcp_tso#udp_tso#outer_ipv4_cksum#"
> "qinq_insert#vxlan_tnl_tso#gre_tnl_tso#"
> "ipip_tnl_tso#geneve_tnl_tso#macsec_insert#"
> - "mt_lockfree#multi_segs#fast_free#security");
> + "mt_lockfree#multi_segs#mbuf_fast_free#security");
> cmdline_parse_token_string_t
> cmd_config_per_port_tx_offload_result_on_off =
> TOKEN_STRING_INITIALIZER
> (struct cmd_config_per_port_tx_offload_result,
> @@ -17144,7 +17144,7 @@ struct cmd_config_per_port_tx_offload_result
> {
> "sctp_cksum|tcp_tso|udp_tso|outer_ipv4_cksum|"
> "qinq_insert|vxlan_tnl_tso|gre_tnl_tso|"
> "ipip_tnl_tso|geneve_tnl_tso|macsec_insert|"
> - "mt_lockfree|multi_segs|fast_free|security "
> + "mt_lockfree|multi_segs|mbuf_fast_free|security "
> "on|off",
> .tokens
Re: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some offload
Hi, Bernard
Thanks for your feedback and guidance.
I have just submitted a v2 patch to include modification on document.
Thanks & Best Regrards
-Wei
> -Original Message-
> From: Iremonger, Bernard
> Sent: Tuesday, July 24, 2018 10:22 PM
> To: Dai, Wei ; Wu, Jingjing ; Lu,
> Wenzhuo ; dev@dpdk.org
> Cc: Dai, Wei ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some
> offload
>
> Hi Wei,
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Tuesday, July 24, 2018 4:45 AM
> > To: Wu, Jingjing ; Lu, Wenzhuo
> > ; dev@dpdk.org
> > Cc: Dai, Wei ; sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some
> > offload
> >
> > Without this patch, testpmd command to config Rx offload keep_crc
> > would fail and report "Bad argument".
> > This patch aslo fix the command to config the Tx offload mbuf_fast_free.
> >
> > Fixes: 70815c9ecadd ("ethdev: add new offload flag to keep CRC")
> > Fixes: c73a9071877a ("app/testpmd: add commands to test new offload
> > API")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 16
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > 5885289..a0ed3a0 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -16665,7 +16665,7 @@ struct
> cmd_config_per_port_rx_offload_result {
> > offload,
> > "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
> >"qinq_strip#outer_ipv4_cksum#macsec_strip#"
> >
> > "header_split#vlan_filter#vlan_extend#jumbo_frame#"
> > - "crc_strip#scatter#timestamp#security");
> > + "crc_strip#scatter#timestamp#security#keep_crc");
> > cmdline_parse_token_string_t
> > cmd_config_per_port_rx_offload_result_on_off =
> > TOKEN_STRING_INITIALIZER
> > (struct cmd_config_per_port_rx_offload_result,
> > @@ -16744,7 +16744,7 @@ struct
> cmd_config_per_port_rx_offload_result {
> > .help_str = "port config rx_offload
> > vlan_strip|ipv4_cksum|"
> >
> > "udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
> > "macsec_strip|header_split|vlan_filter|vlan_extend|"
> > - "jumbo_frame|crc_strip|scatter|timestamp|security "
> > +
> > "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
> > "on|off",
> > .tokens = {
> > (void *)&cmd_config_per_port_rx_offload_result_port,
> > @@ -16794,7 +16794,7 @@ struct
> cmd_config_per_queue_rx_offload_result
> > {
> > offload,
> > "vlan_strip#ipv4_cksum#udp_cksum#tcp_cksum#tcp_lro#"
> >"qinq_strip#outer_ipv4_cksum#macsec_strip#"
> >
> > "header_split#vlan_filter#vlan_extend#jumbo_frame#"
> > - "crc_strip#scatter#timestamp#security");
> > + "crc_strip#scatter#timestamp#security#keep_crc");
> > cmdline_parse_token_string_t
> > cmd_config_per_queue_rx_offload_result_on_off =
> > TOKEN_STRING_INITIALIZER
> > (struct cmd_config_per_queue_rx_offload_result,
> > @@ -16846,7 +16846,7 @@ struct
> cmd_config_per_queue_rx_offload_result
> > {
> > "vlan_strip|ipv4_cksum|"
> >
> > "udp_cksum|tcp_cksum|tcp_lro|qinq_strip|outer_ipv4_cksum|"
> > "macsec_strip|header_split|vlan_filter|vlan_extend|"
> > - "jumbo_frame|crc_strip|scatter|timestamp|security "
> > +
> > "jumbo_frame|crc_strip|scatter|timestamp|security|keep_crc "
> > "on|off",
> > .tokens = {
> > (void *)&cmd_config_per_queue_rx_offload_result_port,
> > @@ -17063,7 +17063,7 @@ struct
> cmd_config_per_port_tx_offload_result {
> >
> > "sctp_cksum#tcp_tso#udp_tso#outer_ipv4_cksum#"
> > "qinq_insert#vxlan_tnl_tso#gre_tnl_tso#"
> > "ipip_tnl_tso#geneve_tnl_tso#macsec_insert#"
> > - "mt_lockfree#multi_segs#fast_free#security");
> > +
> > "mt_lockfree#m
Re: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some offload
Thanks, Iremonger.
I will reply this patch with a v3 patch.
> -Original Message-
> From: Iremonger, Bernard
> Sent: Thursday, August 2, 2018 5:12 PM
> To: Dai, Wei ; Wu, Jingjing ; Lu,
> Wenzhuo
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some
> offload
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Thursday, August 2, 2018 2:32 AM
> > To: Wu, Jingjing ; Lu, Wenzhuo
> >
> > Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> > Subject: [dpdk-dev] [PATCH] app/testpmd: fix commands to config some
> > offload
> >
> > Without this patch, testpmd command to config Rx offload keep_crc
> > would fail and report "Bad argument".
> > This patch aslo fix the command to config the Tx offload mbuf_fast_free.
> >
> > Fixes: 70815c9ecadd ("ethdev: add new offload flag to keep CRC")
> > Fixes: c73a9071877a ("app/testpmd: add commands to test new offload
> > API")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > Tested-by: Yuan Peng
>
> Should have been [PATCH v2] otherwise fine.
>
> Acked-by: Bernard Iremonger
>
Re: [dpdk-dev] [PATCH v4] ethdev: check Rx/Tx offloads
Thanks to Thomas, Ferruh and Zhang Qi for your feedback.
I will rework v5 patch to follow your guidance.
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, April 26, 2018 4:51 PM
> To: Thomas Monjalon
> Cc: Yigit, Ferruh ; Dai, Wei ;
> dev@dpdk.org
> Subject: RE: [PATCH v4] ethdev: check Rx/Tx offloads
>
>
>
> > -Original Message-
> > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > Sent: Thursday, April 26, 2018 4:19 PM
> > To: Zhang, Qi Z
> > Cc: Yigit, Ferruh ; Dai, Wei
> > ; dev@dpdk.org
> > Subject: Re: [PATCH v4] ethdev: check Rx/Tx offloads
> >
> > 26/04/2018 09:59, Zhang, Qi Z:
> > >
> > > > -Original Message-
> > > > From: Yigit, Ferruh
> > > > Sent: Thursday, April 26, 2018 1:05 AM
> > > > To: Dai, Wei ; tho...@monjalon.net; Zhang, Qi Z
> > > >
> > > > Cc: dev@dpdk.org
> > > > Subject: Re: [PATCH v4] ethdev: check Rx/Tx offloads
> > > >
> > > > On 4/25/2018 12:50 PM, Wei Dai wrote:
> > > > > This patch check if a requested offloading is supported in the
> > > > > device capability.
> > > > > Any offloading is disabled by default if it is not set in
> > > > > rte_eth_dev_configure( ) and rte_eth_[rt]x_queue_setup().
> > > > > A per port offloading can only be enabled in rte_eth_dev_configure().
> > > > > If a per port offloading is sent to rte_eth_[rt]x_queue_setup(
> > > > > ), return error.
> > > > > Only per queue offloading can be sent to
> rte_eth_[rt]x_queue_setup( ).
> > > > > A per queue offloading is enabled only if it is enabled in
> > > > > rte_eth_dev_configure( ) OR if it is enabled in
> > > > > rte_eth_[rt]x_queue_setup( ).
> > > > > If a per queue offloading is enabled in rte_eth_dev_configure(),
> > > > > it can't be disabled in rte_eth_[rt]x_queue_setup( ).
> > > > > If a per queue offloading is disabled in rte_eth_dev_configure(
> > > > > ), it can be enabled or disabled( ) in rte_eth_[rt]x_queue_setup( ).
> > > > >
> > > > > This patch can make such checking in a common way in rte_ethdev
> > > > > layer to avoid same checking in underlying PMD.
> > > >
> > > > Hi Wei,
> > > >
> > > > For clarification, there is existing API for rc1, and there is a
> > > > suggested update in API for rc2. I guess this patch is for
> > > > suggested update
> > in rc2?
> > > >
> > > > > Signed-off-by: Wei Dai
> > > > >
> > > > > ---
> > > > > v4: fix a wrong description in git log message.
> > > > >
> > > > > v3: rework according to dicision of offloading API in community
> > > > >
> > > > > v2: add offloads checking in rte_eth_dev_configure( ).
> > > > > check if a requested offloading is supported.
> > > > > ---
> > > > > lib/librte_ether/rte_ethdev.c | 76
> > > > > +++
> > > > > 1 file changed, 76 insertions(+)
> > > > >
> > > > > diff --git a/lib/librte_ether/rte_ethdev.c
> > > > > b/lib/librte_ether/rte_ethdev.c index f0f53d4..70a7904 100644
> > > > > --- a/lib/librte_ether/rte_ethdev.c
> > > > > +++ b/lib/librte_ether/rte_ethdev.c
> > > > > @@ -1196,6 +1196,28 @@ rte_eth_dev_configure(uint16_t port_id,
> > > > uint16_t nb_rx_q, uint16_t nb_tx_q,
> > > > > ETHER_MAX_LEN;
> > > > > }
> > > > >
> > > > > + /* Any requested offload must be within its device capability */
> > > > > + if ((local_conf.rxmode.offloads & dev_info.rx_offload_capa) !=
> > > > > + local_conf.rxmode.offloads) {
> > > > > + RTE_PMD_DEBUG_TRACE("ethdev port_id=%d requested Rx
> > > > offloads "
> > > > > + "0x%" PRIx64 " doesn't match Rx
> > > > > offloads "
> > > > > + "capability 0x%" PRIx64 "\n",
> > > > > + port_id,
> > > > > + local_conf.rxmode.offloads,
> > > > > +
Re: [dpdk-dev] [PATCH v7] ethdev: check Rx/Tx offloads
Thanks to Shuler and Ferruh for your feedback and guidance.
PMD at least has these 2 options with this patch:
a). If PMD doesn't want to make much more changes, it still can do
"[rt]x_conf->offloads |= dev->data->dev_conf.rxmode.offloads;"
in the beginning of its specific queue_setup( ) and just remove offload
checking (although the checking always pass now) and all
others keep same. In this way, PMDs still comply with the offload APIs
defined in 17.11.
b). PMD also can use the info that only new added queue-level offloads in the
input argument [rt]x_conf->offloads to make some
optimization or other code changes. It may be more efficient than a).
As Ferruh said, only this patch and without relevant change in PMD will cause
application broken,
I will submit v8 patch which will include this patch for ethdev and code
changes in PMDs with above option a and document update.
I'd like include all these changes in only one patch to avoid application
failure if some patches are not applied and some are applied.
PMD maintainers call go on with option b)
Shuler's suggestion to simplify the new added offloads in queue_setup( ) is
better.
I will adopt it in my v8 patch.
> -Original Message-
> From: Shahaf Shuler [mailto:shah...@mellanox.com]
> Sent: Sunday, May 6, 2018 3:00 AM
> To: Dai, Wei ; Thomas Monjalon
> ; Yigit, Ferruh
> Cc: dev@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v7] ethdev: check Rx/Tx offloads
>
> Hi Ferruh, Dai,
> > Subject: [dpdk-dev] [PATCH v7] ethdev: check Rx/Tx offloads
> >
> > This patch check if a input requested offloading is valid or not.
> > Any reuqested offloading must be supported in the device capabilities.
> > Any offloading is disabled by default if it is not set in the
> > parameter dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and
> > [rt]x_conf-
> > >offloads to rte_eth_[rt]x_queue_setup( ).
> > From application, a pure per-port offloading can't be enabled on any
> > queue if it hasn't been enabled in rte_eth_dev_configure( ).
> > If any offloading is enabled in rte_eth_dev_configure( ) by
> > application, it is enabled on all queues no matter whether it is
> > per-queue or per-port type and no matter whether it is set or cleared
> > in [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
> > The underlying PMD must be aware that the requested offloadings to PMD
> > specific queue_setup( ) function only carries those offloadings only
> > enabled for the queue but not enabled in rte_eth_dev_configure( ) and
> > they are certain per-queue type.
> >
> > This patch can make above such checking in a common way in rte_ethdev
> > layer to avoid same checking in underlying PMD.
> >
> > Signed-off-by: Wei Dai
> > Signed-off-by: Ferruh Yigit
> >
> > ---
> > v7:
> > Give the maximum freedom for upper application, only minimal checking
> > is performed in ethdev layer.
> > Only requested specific pure per-queue offloadings are input to
> > underlying PMD.
> >
> > v6:
> > No need enable an offload in queue_setup( ) if it has already been
> > enabled in dev_configure( )
> >
> > v5:
> > keep offload settings sent to PMD same as those from application
> >
> > v4:
> > fix a wrong description in git log message.
> >
> > v3:
> > rework according to dicision of offloading API in community
> >
> > v2:
> > add offloads checking in rte_eth_dev_configure( ).
> > check if a requested offloading is supported.
> > ---
> > lib/librte_ethdev/rte_ethdev.c | 150
> > +
> > 1 file changed, 150 insertions(+)
> >
> > diff --git a/lib/librte_ethdev/rte_ethdev.c
> > b/lib/librte_ethdev/rte_ethdev.c index e560524..0ad05eb 100644
> > --- a/lib/librte_ethdev/rte_ethdev.c
> > +++ b/lib/librte_ethdev/rte_ethdev.c
> > @@ -1139,6 +1139,28 @@ rte_eth_dev_configure(uint16_t port_id,
> > uint16_t nb_rx_q, uint16_t nb_tx_q,
> > ETHER_MAX_LEN;
> > }
> >
> > + /* Any requested offloading must be within its device capabilities */
> > + if ((local_conf.rxmode.offloads & dev_info.rx_offload_capa) !=
> > +local_conf.rxmode.offloads) {
> > + RTE_PMD_DEBUG_TRACE("ethdev port_id=%d requested Rx
> > offloads "
> > + "0x%" PRIx64 " doesn't match Rx offloads "
> > + "capabilities 0x%" PRIx64 "\n",
> > + port_id,
> > +
Re: [dpdk-dev] [PATCH v7 0/2] app/testpmd: add new commands to test new Tx/Rx offloads
Hi, Ferruh Thanks for your feedback. I lost your mail but I can found it in http://dpdk.org/ml/archives/dev/2018-April/096900.html I will update new version of this patch for new offload API in my v8 big patch for ethdev: check offloads. As my command to get offload capablites and configuration return all results on port level and all queues, I'd like to adopt your suggestion to use 'show port ...' I search '.help_str' in app/test-pmd/cmdline.c and find all existed 'port config ...' is for port level configuration. So if it is used to add new commands to enable/disable per-queue offloading, the style will be broken. I'd like to use 'port config on|off ' to enable/disable offloading on all queues. I also would like to use 'port rxq|txq on|off' to enable/disable offloading on a queue. All above my plan want to keep the style of current command and avoid to introduce more commands. Can you agree it ? Thanks & Best Regards -Wei > -Original Message- > From: Dai, Wei > Sent: Tuesday, April 3, 2018 4:58 PM > To: Lu, Wenzhuo ; Wu, Jingjing > > Cc: dev@dpdk.org; Dai, Wei > Subject: [PATCH v7 0/2] app/testpmd: add new commands to test new Tx/Rx > offloads > > Existed testpmd commands can't support per queue offload configuration. > And there are different commands to enable or disable different offloading. > This patch set add following commands to support new Tx/Rx offloading API > test. > > To get Rx offload capability of a port, please run: > testpmd > rx_offload get capability > > To get current Rx offload per queue and per port configuration of a port, > run: > tesstpmd > rx_offload get configuration > > To enable or disable a Rx per port offloading, please run: > testpmd > rx_offload enable|disable per_port vlan_strip|ipv4_cksum|... > > This command will set|clear the associated bit in > dev->dev_conf.rxmode.offloads > for rte_eth_dev_configure and tx_conf->offloads of all Rx queues for > rte_eth_rx_queue_setup( ). > > To enable or disable a Tx per port offloading, please run: > testpmd > rx_offload enable|disable per_queue vlan_strip|ipv4_cksum|... > > > Same commands like "tx_offload ..." are also added to support new Tx > offload API test. > > Signed-off-by: Wei Dai > Acked-by: Jingjing Wu > > --- > v7: >update testpmd document > v6: >reconfig port and queues if offloading is enabled or disabled > v5: >don't depend on enum types defined in rte_ethdev. > v4: >improve testpmd command per port offload to set or clear the port > configuration >and the queue configuration of all queues. > v3: >add enum rte_eth_rx_offload_type and enum rte_eth_tx_offload_type >free memory of port->rx_offloads and port->tx_offloads when testpmd > is existed > v2: >use rte_eth_dev_rx_offload_name() and > rte_eth_dev_tx_offload_name(). >remove static const strings of Rx/Tx offload names. > > > Wei Dai (2): > app/testpmd: add commands to test new Rx offload API > app/testpmd: add commands to test new Tx offload API > > app/test-pmd/cmdline.c | 759 > > app/test-pmd/testpmd.c | 34 +- > app/test-pmd/testpmd.h | 2 + > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 87 > 4 files changed, 878 insertions(+), 4 deletions(-) > > -- > 2.9.5
Re: [dpdk-dev] [PATCH v8] ethdev: check Rx/Tx offloads
> -Original Message-
> From: Andrew Rybchenko [mailto:arybche...@solarflare.com]
> Sent: Wednesday, May 9, 2018 1:52 AM
> To: Dai, Wei ; Yigit, Ferruh ;
> tho...@monjalon.net; shah...@mellanox.com; Zhang, Qi Z
>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v8] ethdev: check Rx/Tx offloads
>
> On 05/08/2018 01:10 PM, Wei Dai wrote:
> > This patch check if a input requested offloading is valid or not.
> > Any reuqested offloading must be supported in the device capabilities.
> > Any offloading is disabled by default if it is not set in the
> > parameter dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and
> > [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
> > If any offloading is enabled in rte_eth_dev_configure( ) by
> > application, it is enabled on all queues no matter whether it is
> > per-queue or per-port type and no matter whether it is set or cleared
> > in [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
> > If a per-queue offloading hasn't be enabled in rte_eth_dev_configure(
> > ), it can be enabled or disabled for individual queue in
> > ret_eth_[rt]x_queue_setup( ).
> > A new added offloading is the one which hasn't been enabled in
> > rte_eth_dev_configure( ) and is reuqested to be enabled in
> > rte_eth_[rt]x_queue_setup( ), it must be per-queue type, otherwise
> > return error.
> > The underlying PMD must be aware that the requested offloadings to PMD
> > specific queue_setup( ) function only carries those new added
> > offloadings of per-queue type.
> >
> > This patch can make above such checking in a common way in rte_ethdev
> > layer to avoid same checking in underlying PMD.
> >
> > This patch assumes that all PMDs in 18.05-rc2 have already converted
> > to offload API defined in 17.11 . It also assumes that all PMDs can
> > return correct offloading capabilities in rte_eth_dev_infos_get( ).
> >
> > In the beginning of [rt]x_queue_setup( ) of underlying PMD, add
> > offloads = [rt]xconf->offloads |
> > dev->data->dev_conf.[rt]xmode.offloads; to keep same as offload API
> > defined in 17.11 to avoid upper application broken due to offload API
> > change.
> > PMD can use the info that input [rt]xconf->offloads only carry the new
> > added per-queue offloads to do some optimization or some code change
> > on base of this patch.
> >
> > Signed-off-by: Wei Dai
> > Signed-off-by: Ferruh Yigit
> > Signed-off-by: Qi Zhang
>
> [...]
>
> > diff --git a/lib/librte_ethdev/rte_ethdev.c
> > b/lib/librte_ethdev/rte_ethdev.c index e560524..523a07b 100644
> > --- a/lib/librte_ethdev/rte_ethdev.c
> > +++ b/lib/librte_ethdev/rte_ethdev.c
> > @@ -1139,6 +1139,28 @@ rte_eth_dev_configure(uint16_t port_id,
> uint16_t nb_rx_q, uint16_t nb_tx_q,
> > ETHER_MAX_LEN;
> > }
> >
> > + /* Any requested offloading must be within its device capabilities */
> > + if ((local_conf.rxmode.offloads & dev_info.rx_offload_capa) !=
> > +local_conf.rxmode.offloads) {
> > + RTE_PMD_DEBUG_TRACE("ethdev port_id=%d requested Rx
> offloads "
> > + "0x%" PRIx64 " doesn't match Rx offloads "
> > + "capabilities 0x%" PRIx64 "\n",
> > + port_id,
> > + local_conf.rxmode.offloads,
> > + dev_info.rx_offload_capa);
> > + return -EINVAL;
> > + }
> > + if ((local_conf.txmode.offloads & dev_info.tx_offload_capa) !=
> > +local_conf.txmode.offloads) {
> > + RTE_PMD_DEBUG_TRACE("ethdev port_id=%d requested Tx
> offloads "
> > + "0x%" PRIx64 " doesn't match Tx offloads "
> > + "capabilities 0x%" PRIx64 "\n",
> > + port_id,
> > + local_conf.txmode.offloads,
> > + dev_info.tx_offload_capa);
> > + return -EINVAL;
> > + }
> > +
> > /* Check that device supports requested rss hash functions. */
> > if ((dev_info.flow_type_rss_offloads |
> > dev_conf->rx_adv_conf.rss_conf.rss_hf) != @@ -1504,6
> +1526,39
> > @@ rte_eth_rx_queue_setup(uint16_t port_id, uint16_t rx_queue_id,
> > &local_conf
Re: [dpdk-dev] [PATCH v8] ethdev: check Rx/Tx offloads
Hi, Andrew
See my in-line comments as below.
From: Andrew Rybchenko [mailto:arybche...@solarflare.com]
Sent: Tuesday, May 8, 2018 7:37 PM
To: Dai, Wei ; Yigit, Ferruh ;
tho...@monjalon.net; Doherty, Declan ;
linvi...@tuxdriver.com; m...@semihalf.com; m...@semihalf.com;
gtza...@amazon.com; evge...@amazon.com; ravi1.ku...@amd.com;
shepard.sie...@atomicrules.com; ed.cz...@atomicrules.com;
john.mil...@atomicrules.com; ajit.khapa...@broadcom.com;
somnath.ko...@broadcom.com; jerin.ja...@caviumnetworks.com;
maciej.cze...@caviumnetworks.com; shijith.thot...@cavium.com;
ssriniva...@cavium.com; santosh.shu...@caviumnetworks.com;
rahul.lakkire...@chelsio.com; ohnd...@cisco.com; hyon...@cisco.com; Lu, Wenzhuo
; Ananyev, Konstantin ;
Xing, Beilei ; Zhang, Qi Z ; Wang,
Xiao W ; Wu, Jingjing ;
t...@semihalf.com; d...@marvell.com; nsams...@marvell.com; jianbo@arm.com;
adrien.mazarg...@6wind.com; nelio.laranje...@6wind.com; ys...@mellanox.com;
ma...@mellanox.com; v...@cesnet.cz; alejandro.luc...@netronome.com;
emant.agra...@nxp.com; shreyansh.j...@nxp.com; hemant.agra...@nxp.com;
harish.pa...@cavium.com; rasesh.m...@cavium.com; asesh.m...@cavium.com;
shahed.sha...@cavium.com; yongw...@vmware.com; maxime.coque...@redhat.com;
mtetsu...@gmail.com; Bie, Tiwei ; Legacy, Allain (Wind
River) ; Peters, Matt (Wind River)
; pascal.ma...@6wind.com; Richardson, Bruce
; gaetan.ri...@6wind.com; Singh, Jasvinder
; Dumitrescu, Cristian
Cc: dev@dpdk.org; Ivan Malov
Subject: Re: [PATCH v8] ethdev: check Rx/Tx offloads
On 05/08/2018 01:05 PM, Wei Dai wrote:
This patch check if a input requested offloading is valid or not.
Any reuqested offloading must be supported in the device capabilities.
Any offloading is disabled by default if it is not set in the parameter
dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and
[rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
If any offloading is enabled in rte_eth_dev_configure( ) by application,
it is enabled on all queues no matter whether it is per-queue or
per-port type and no matter whether it is set or cleared in
[rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ).
If a per-queue offloading hasn't be enabled in rte_eth_dev_configure( ),
it can be enabled or disabled for individual queue in
ret_eth_[rt]x_queue_setup( ).
A new added offloading is the one which hasn't been enabled in
rte_eth_dev_configure( ) and is reuqested to be enabled in
rte_eth_[rt]x_queue_setup( ), it must be per-queue type,
otherwise return error.
The underlying PMD must be aware that the requested offloadings
to PMD specific queue_setup( ) function only carries those
new added offloadings of per-queue type.
This patch can make above such checking in a common way in rte_ethdev
layer to avoid same checking in underlying PMD.
This patch assumes that all PMDs in 18.05-rc2 have already
converted to offload API defined in 17.11 . It also assumes
that all PMDs can return correct offloading capabilities
in rte_eth_dev_infos_get( ).
In the beginning of [rt]x_queue_setup( ) of underlying PMD,
add offloads = [rt]xconf->offloads |
dev->data->dev_conf.[rt]xmode.offloads; to keep same as offload API
defined in 17.11 to avoid upper application broken due to offload
API change.
PMD can use the info that input [rt]xconf->offloads only carry
the new added per-queue offloads to do some optimization or some
code change on base of this patch.
Signed-off-by: Wei Dai
Signed-off-by: Ferruh Yigit
Signed-off-by: Qi Zhang
[...]
diff --git a/drivers/net/sfc/sfc_ethdev.c b/drivers/net/sfc/sfc_ethdev.c
index e42d553..fc2b254 100644
--- a/drivers/net/sfc/sfc_ethdev.c
+++ b/drivers/net/sfc/sfc_ethdev.c
@@ -413,14 +413,16 @@ sfc_rx_queue_setup(struct rte_eth_dev *dev, uint16_t
rx_queue_id,
{
struct sfc_adapter *sa = dev->data->dev_private;
int rc;
+ uint64_t offloads;
sfc_log_init(sa, "RxQ=%u nb_rx_desc=%u socket_id=%u",
rx_queue_id, nb_rx_desc, socket_id);
sfc_adapter_lock(sa);
+ offloads = rx_conf->offloads | dev->data->dev_conf.rxmode.offloads;
I'd prefer to see it inside sfc_rx_qinit() function. It would allow to avoid
sfc_rx_qinit() function prototype changes.
[Wei: As rx_conf is a const argument in sfc_rx_queue_setup( ),
rx_conf->offloads can't be updated.
If sfc_rx_qinit( ) function prototype keep unchanged, the dev->data can be
deduced from the
1st argument sa . Andrew, if my code works well, can it be kept here, you
can change it later
in your separate patch, OK ? ]
rc = sfc_rx_qinit(sa, rx_queue_id, nb_rx_desc, socket_id,
- rx_conf, mb_pool);
+ rx_conf, mb_pool, offloads);
if (rc != 0)
goto fail_rx_qinit;
@@ -469,13 +471,16 @@ sfc_tx_queue_setup(struct rte_eth_dev *dev, uint16_t
tx_queue_id,
{
struct sfc_adapter *sa = dev->data->dev_priva
Re: [dpdk-dev] [PATCH v8] ethdev: check Rx/Tx offloads
> -Original Message- > From: Yigit, Ferruh > Sent: Tuesday, May 8, 2018 8:13 PM > To: Dai, Wei ; tho...@monjalon.net; Doherty, Declan > ; linvi...@tuxdriver.com; m...@semihalf.com; > m...@semihalf.com; gtza...@amazon.com; evge...@amazon.com; > ravi1.ku...@amd.com; shepard.sie...@atomicrules.com; > ed.cz...@atomicrules.com; john.mil...@atomicrules.com; > ajit.khapa...@broadcom.com; somnath.ko...@broadcom.com; > jerin.ja...@caviumnetworks.com; maciej.cze...@caviumnetworks.com; > shijith.thot...@cavium.com; ssriniva...@cavium.com; > santosh.shu...@caviumnetworks.com; rahul.lakkire...@chelsio.com; > ohnd...@cisco.com; hyon...@cisco.com; Lu, Wenzhuo > ; Ananyev, Konstantin > ; Xing, Beilei ; > Zhang, Qi Z ; Wang, Xiao W > ; Wu, Jingjing ; > t...@semihalf.com; d...@marvell.com; nsams...@marvell.com; > jianbo@arm.com; adrien.mazarg...@6wind.com; > nelio.laranje...@6wind.com; ys...@mellanox.com; ma...@mellanox.com; > v...@cesnet.cz; alejandro.luc...@netronome.com; > emant.agra...@nxp.com; shreyansh.j...@nxp.com; > hemant.agra...@nxp.com; harish.pa...@cavium.com; > rasesh.m...@cavium.com; asesh.m...@cavium.com; > shahed.sha...@cavium.com; arybche...@solarflare.com; > yongw...@vmware.com; maxime.coque...@redhat.com; > mtetsu...@gmail.com; Bie, Tiwei ; Legacy, Allain > (Wind River) ; Peters, Matt (Wind River) > ; pascal.ma...@6wind.com; Richardson, > Bruce ; gaetan.ri...@6wind.com; Singh, > Jasvinder ; Dumitrescu, Cristian > > Cc: dev@dpdk.org > Subject: Re: [PATCH v8] ethdev: check Rx/Tx offloads > > On 5/8/2018 11:05 AM, Wei Dai wrote: > > This patch check if a input requested offloading is valid or not. > > Any reuqested offloading must be supported in the device capabilities. > > Any offloading is disabled by default if it is not set in the > > parameter dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and > > [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ). > > If any offloading is enabled in rte_eth_dev_configure( ) by > > application, it is enabled on all queues no matter whether it is > > per-queue or per-port type and no matter whether it is set or cleared > > in [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ). > > If a per-queue offloading hasn't be enabled in rte_eth_dev_configure( > > ), it can be enabled or disabled for individual queue in > > ret_eth_[rt]x_queue_setup( ). > > A new added offloading is the one which hasn't been enabled in > > rte_eth_dev_configure( ) and is reuqested to be enabled in > > rte_eth_[rt]x_queue_setup( ), it must be per-queue type, otherwise > > return error. > > The underlying PMD must be aware that the requested offloadings to PMD > > specific queue_setup( ) function only carries those new added > > offloadings of per-queue type. > > > > This patch can make above such checking in a common way in rte_ethdev > > layer to avoid same checking in underlying PMD. > > > > This patch assumes that all PMDs in 18.05-rc2 have already converted > > to offload API defined in 17.11 . It also assumes that all PMDs can > > return correct offloading capabilities in rte_eth_dev_infos_get( ). > > > > In the beginning of [rt]x_queue_setup( ) of underlying PMD, add > > offloads = [rt]xconf->offloads | > > dev->data->dev_conf.[rt]xmode.offloads; to keep same as offload API > > defined in 17.11 to avoid upper application broken due to offload API > > change. > > PMD can use the info that input [rt]xconf->offloads only carry the new > > added per-queue offloads to do some optimization or some code change > > on base of this patch. > > > > Signed-off-by: Wei Dai > > Signed-off-by: Ferruh Yigit > > Signed-off-by: Qi Zhang > > > > --- > > v8: > > Revise PMD codes to comply with offload API in v7 update document > > > > v7: > > Give the maximum freedom for upper application, only minimal checking > > is performed in ethdev layer. > > Only requested specific pure per-queue offloadings are input to > > underlying PMD. > > > > v6: > > No need enable an offload in queue_setup( ) if it has already been > > enabled in dev_configure( ) > > > > v5: > > keep offload settings sent to PMD same as those from application > > > > v4: > > fix a wrong description in git log message. > > > > v3: > > rework according to dicision of offloading API in community > > > > v2: > > add offloads checking in rte_eth_dev_configure( ). > > check if a requested offloading is supported. > > --- > > doc/guides/prog_guide/poll_mode_drv.rst | 26 +++
Re: [dpdk-dev] [PATCH v10] ethdev: new Rx/Tx offloads API
Hi, Thomas Thanks for your feedback and guidance. > -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Thursday, May 10, 2018 10:36 AM > To: Dai, Wei > Cc: dev@dpdk.org; Yigit, Ferruh ; Zhang, Qi Z > > Subject: Re: [dpdk-dev] [PATCH v10] ethdev: new Rx/Tx offloads API > > Hi, > > I am checking if this patch comply with goals discussed in the survey: > http://dpdk.org/ml/archives/dev/2018-March/094459.html > > - Allow "forgetting" port offloads in queue offloads setup. > > - An offload enabled at port level, cannot be disabled at queue level. > > - Every queue capabilities must be reported as port capabilities. > > - A capability should be reported at queue level > only if it can be enabled on queue when it is disabled on port level. > > I think some items must be updated in doxygen comments of rte_ethdev.h. > Please could you try to do a v11 for doxygen? I will review it quickly. > > Examples: > > - in queue offloads: > "No need to repeat flags already enabled at port level. >A flag enabled at port level, cannot be disabled at queue > level." > > - in port capabilities: "(include per-queue capabilities)" > > More comments below, thanks. > > > 10/05/2018 02:56, Wei Dai: > > This patch check if a input requested offloading is valid or not. > > Any reuqested offloading must be supported in the device capabilities. > > Any offloading is disabled by default if it is not set in the > > parameter dev_conf->[rt]xmode.offloads to rte_eth_dev_configure( ) and > > [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ). > > If any offloading is enabled in rte_eth_dev_configure( ) by > > application, it is enabled on all queues no matter whether it is > > per-queue or per-port type and no matter whether it is set or cleared > > in [rt]x_conf->offloads to rte_eth_[rt]x_queue_setup( ). > > If a per-queue offloading hasn't be enabled in rte_eth_dev_configure( > > ), it can be enabled or disabled for individual queue in > > ret_eth_[rt]x_queue_setup( ). > > A new added offloading is the one which hasn't been enabled in > > rte_eth_dev_configure( ) and is reuqested to be enabled in > > rte_eth_[rt]x_queue_setup( ), it must be per-queue type, otherwise > > triger an error log. > > The underlying PMD must be aware that the requested offloadings to PMD > > specific queue_setup( ) function only carries those new added > > offloadings of per-queue type. > > Good summary. > Please forget the whitespace inside the parens. I will remove whitespaces inside the parens. > > > This patch can make above such checking in a common way in rte_ethdev > > layer to avoid same checking in underlying PMD. > > Good > > > --- a/doc/guides/prog_guide/poll_mode_drv.rst > > +++ b/doc/guides/prog_guide/poll_mode_drv.rst > > @@ -297,16 +297,30 @@ Per-Port and Per-Queue Offloads > > ^^^ > > > > In the DPDK offload API, offloads are divided into per-port and per-queue > offloads. > > +A per-queue offloading can be enabled on a queue and disabled on > another queue at the same time. > > +A pure per-port offloading can't be enabled on a queue and disabled on > another queue at the same time. > > +A pure per-port offloading must be enabled or disabled on all queues at > the same time. > > +A per-port offloading can be enabled or disabled on all queues at the > same time. > > What is the difference between pure per-port and per-port here? > Can I add following words to explain more: A pure per-port offloads are those supported by device but not per-queue type. A supported offload can be per-queue or pure per-port, but can't be both types at same device. Any offloadings are per-port type as it can be enabled or disabled on all queues at the same time. > > +It is certain that both per-queue and pure per-port offloading are per-port > type. > > I don't understand this sentence. > Explained above, I just want to divide all offloading into two distinct types: Per-queue and pure per-port. And per-queue + pure per-port = per-port. > > The different offloads capabilities can be queried using > ``rte_eth_dev_info_get()``. > > +The dev_info->[rt]x_queue_offload_capa returned from > ``rte_eth_dev_info_get()`` includes all per-queue offloading capabilities. > > +The dev_info->[rt]x_offload_capa returned from > ``rte_eth_dev_info_get()`` includes all per-port and per-queue offloading > capabilities. > > Yes > > > +Any requested offloading by applicatio
Re: [dpdk-dev] [PATCH v12] ethdev: new Rx/Tx offloads API
Hi, Thomas & Ferruh
Thanks for your feedback.
I agree with your comments and I am working on the latest commit of the repo
dpdk-next-net.
I will submit a new patch to adopt your suggestion.
Please wait for a while ...
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, May 14, 2018 4:37 PM
> To: Dai, Wei
> Cc: dev@dpdk.org; Yigit, Ferruh ; Zhang, Qi Z
>
> Subject: Re: [dpdk-dev] [PATCH v12] ethdev: new Rx/Tx offloads API
>
> Wei Dai,
> Do you agree with my comments?
> Could we have a wording patch to squash in RC3?
>
>
> 10/05/2018 23:39, Thomas Monjalon:
> > Hi,
> >
> > A first general comment: a lot of spaces are still inside parens.
> > You can grep '( )'.
> >
> > 10/05/2018 13:56, Wei Dai:
> > > --- a/doc/guides/prog_guide/poll_mode_drv.rst
> > > +++ b/doc/guides/prog_guide/poll_mode_drv.rst
> > > +A per-queue offloading can be enabled on a queue and disabled on
> another queue at the same time.
> > > +A pure per-port offload is the one supported by device but not
> per-queue type.
> >
> > Another way to say it: pure per-port offloads are not directly
> > advertised but are the port offloads capabilities minus the queue
> capabilities.
> > port capabilities = pure per-port capabilities + queue capabilities
> >
> > > +A pure per-port offloading can't be enabled on a queue and disabled on
> another queue at the same time.
> > > +A pure per-port offloading must be enabled or disabled on all queues at
> the same time.
> > > +Any offloading is per-queue or pure per-port type, but can't be both
> types at same devices.
> > > +A per-port offloading can be enabled or disabled on all queues at the
> same time.
> >
> > This sentence is useless: it says any offload can be setup for the whole
> port.
> >
> > > +It is certain that both per-queue and pure per-port offloading are
> per-port type.
> >
> > This sentence is confusing. I cannot understand it.
> >
> >
> > > The different offloads capabilities can be queried using
> ``rte_eth_dev_info_get()``.
> > > +The dev_info->[rt]x_queue_offload_capa returned from
> ``rte_eth_dev_info_get()`` includes all per-queue offloading capabilities.
> > > +The dev_info->[rt]x_offload_capa returned from
> ``rte_eth_dev_info_get()`` includes all per-port and per-queue offloading
> capabilities.
> >
> > If you want to stick with pure per-port wording, you should say
> > [rt]x_offload_capa is the port capabilities (including pure per-port and
> per-queue).
> >
> >
> > > --- a/lib/librte_ethdev/rte_ethdev.c
> > > +++ b/lib/librte_ethdev/rte_ethdev.c
> > > + /* Any requested offloading must be within its device capabilities
> */
> > > + if ((local_conf.rxmode.offloads & dev_info.rx_offload_capa) !=
> > > + local_conf.rxmode.offloads) {
> > > + ethdev_log(ERR, "ethdev port_id=%d requested Rx offloads "
> > > + "0x%" PRIx64 " doesn't match Rx offloads "
> > > + "capabilities 0x%" PRIx64 " in %s( )\n",
> > > + port_id,
> > > + local_conf.rxmode.offloads,
> > > + dev_info.rx_offload_capa,
> > > + __func__);
> >
> > We could have a comment saying that an error will be returned in next
> version.
> >
> > > + }
> > > + if ((local_conf.txmode.offloads & dev_info.tx_offload_capa) !=
> > > + local_conf.txmode.offloads) {
> > > + ethdev_log(ERR, "ethdev port_id=%d requested Tx offloads "
> > > + "0x%" PRIx64 " doesn't match Tx offloads "
> > > + "capabilities 0x%" PRIx64 " in %s( )\n",
> > > + port_id,
> > > + local_conf.txmode.offloads,
> > > + dev_info.tx_offload_capa,
> > > + __func__);
> >
> > idem
> >
> > > + }
> >
> >
> > > + /*
> > > + * If an offloading has already been enabled in
> > > + * rte_eth_dev_configure(), it has been enabled on all queues,
> > > + * so there is no need to enable it in this queue again.
> > > + * The local_conf.offloads input to underlying PMD only carries
> > > + * those offloadings which are onl
Re: [dpdk-dev] [PATCH v13] ethdev: new Rx/Tx offloads API
Hi, Thomas
Thanks for your quick feedback.
> -Original Message-
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Monday, May 14, 2018 8:54 PM
> To: Dai, Wei
> Cc: dev@dpdk.org; Yigit, Ferruh ; Zhang, Qi Z
>
> Subject: Re: [dpdk-dev] [PATCH v13] ethdev: new Rx/Tx offloads API
>
> 14/05/2018 14:00, Wei Dai:
> > --- a/doc/guides/prog_guide/poll_mode_drv.rst
> > +++ b/doc/guides/prog_guide/poll_mode_drv.rst
> > @@ -303,12 +303,12 @@ In the DPDK offload API, offloads are divided
> > into per-port and per-queue offloa
> > * A pure per-port offloading can't be enabled on a queue and disabled on
> another queue at the same time.
> > * A pure per-port offloading must be enabled or disabled on all queues at
> the same time.
> > * Any offloading is per-queue or pure per-port type, but can't be both
> types at same devices.
> > -* A per-port offloading can be enabled or disabled on all queues at the
> same time.
> > -* It is certain that both per-queue and pure per-port offloading are
> per-port type.
> > +* Port capabilities = pre-queue capabilities + pure per-port capabilities.
>
> s/pre/per/
Sorry for the typo error.
>
> > +* Any supported offloading can be enabled on all queues.
> >
> > The different offloads capabilities can be queried using
> ``rte_eth_dev_info_get()``.
> > The ``dev_info->[rt]x_queue_offload_capa`` returned from
> ``rte_eth_dev_info_get()`` includes all per-queue offloading capabilities.
> > -The ``dev_info->[rt]x_offload_capa`` returned from
> ``rte_eth_dev_info_get()`` includes all per-port and per-queue offloading
> capabilities.
> > +The ``dev_info->[rt]x_offload_capa`` returned from
> ``rte_eth_dev_info_get()`` includes all pure per-port and per-queue
> offloading capabilities.
>
> OK
>
>
> > @@ -1556,29 +1558,29 @@ rte_eth_rx_queue_setup(uint16_t port_id,
> uint16_t rx_queue_id,
> > * The local_conf.offloads input to underlying PMD only carries
> > * those offloadings which are only enabled on this queue and
> > * not enabled on all queues.
> > -* The underlying PMD must be aware of this point.
> > */
>
> OK
>
>
> > --- a/lib/librte_ethdev/rte_ethdev.h
> > +++ b/lib/librte_ethdev/rte_ethdev.h
> > @@ -1067,13 +1067,18 @@ struct rte_eth_dev_info {
> > uint16_t max_vfs; /**< Maximum number of VFs. */
> > uint16_t max_vmdq_pools; /**< Maximum number of VMDq pools. */
> > uint64_t rx_offload_capa;
> > - /**< All RX offload capabilities including all per queue ones */
> > + /**<
> > +* All RX offload capabilities including all per-queue ones.
> > +* Any flag in [rt]x_offload_capa and [rt]x_queue_offload_capa
> > +* of this structure needn't be repeated in rte_eth_[rt]x_queue_setup().
>
> It is confusing. Better to remove this sentence about queue_setup in port
> capa comment.
>
> > +* A flag enabled at port level can't be disabled at queue level.
>
> This one too: it is a comment about port capa, not queue setup.
>
Sorry, I think I have a mistake about your feedback on v12.
Will remove above 2 sentences.
>
> > @@ -1554,9 +1559,7 @@ const char * __rte_experimental
> rte_eth_dev_tx_offload_name(uint64_t offload);
> > *the [rt]x_offload_capa returned from
> rte_eth_dev_infos_get().
> > *Any type of device supported offloading set in the input
> argument
> > *eth_conf->[rt]xmode.offloads to rte_eth_dev_configure() is
> enabled
> > - *on all [RT]x queues and it can't be disabled no matter whether
> > - *it is cleared or set in the input argument [rt]x_conf->offloads
> > - *to rte_eth_[rt]x_queue_setup().
> > + *on all queues and it can't be disabled in
> rte_eth_[rt]x_queue_setup().
>
> OK
>
>
> Missing: we must explain the "no repeat need" and "no disable port offload
> on queue" constraint.
> In the last review, I was suggesting such sentences:
> No need to repeat flags already enabled at port level.
> A flag enabled at port level, cannot be disabled at queue level.
> I think it should go in queue setup comments.
>
> Opinion?
>
Will add this in the comments of queue_setup( ) in rte_ethdev.h
Re: [dpdk-dev] [PATCH] bus/pci: fix error in parsing vfio driver
Give up this patch as there is already a patch
in http://dpdk.org/dev/patchwork/patch/40030/ bus/pci: correct the earlier
strlcpy conversion
> -Original Message-
> From: Dai, Wei
> Sent: Tuesday, May 15, 2018 10:41 PM
> To: Yigit, Ferruh ; Burakov, Anatoly
>
> Cc: dev@dpdk.org; Dai, Wei ; sta...@dpdk.org
> Subject: [PATCH] bus/pci: fix error in parsing vfio driver
>
> In pci_get_kernel_driver_by_path(), the available memory size of dri_name
> should be strlen(name + 1) + 1, not the size of the pointer (8 bytes), so
> "vfio-pci" is truncated to "vfio-pc"
> ended with number 0.
> This patch fixes it.
>
> Fixes: fe5f777b5383 ("bus/pci: replace strncpy by strlcpy")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> ---
> drivers/bus/pci/linux/pci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bus/pci/linux/pci.c b/drivers/bus/pci/linux/pci.c index
> a73ee49..cc6b383 100644
> --- a/drivers/bus/pci/linux/pci.c
> +++ b/drivers/bus/pci/linux/pci.c
> @@ -54,7 +54,7 @@ pci_get_kernel_driver_by_path(const char *filename,
> char *dri_name)
>
> name = strrchr(path, '/');
> if (name) {
> - strlcpy(dri_name, name + 1, sizeof(dri_name));
> + strlcpy(dri_name, name + 1, strlen(name + 1) + 1);
> return 0;
> }
>
> --
> 2.5.5
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
> -Original Message-
> From: Zhang, Qi Z
> Sent: Friday, May 18, 2018 3:46 PM
> To: Wu, Yanglong ; dev@dpdk.org
> Cc: Dai, Wei
> Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
>
> > -Original Message-
> > From: Wu, Yanglong
> > Sent: Friday, May 18, 2018 3:24 PM
> > To: dev@dpdk.org
> > Cc: Zhang, Qi Z ; Dai, Wei ;
> > Wu, Yanglong
> > Subject: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per
> > port
> >
> > rxq->offload should synchronize with dev_conf
> >
> > Fixes: 860a94d3c692 ("net/ixgbe: support VLAN strip per queue
> > offloading in
> > VF")
> > Signed-off-by: Yanglong Wu
>
> Acked-by: Qi Zhang
The release date is coming soon.
Sorry, I have to NACK it.
VLAN strip is per-queue feature,
If it is disabled on port level, it still can be enabled on queue level.
So the else branches still should be removed.
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
> -Original Message-
> From: Zhang, Qi Z
> Sent: Friday, May 18, 2018 8:37 PM
> To: Dai, Wei ; Wu, Yanglong
> ; dev@dpdk.org
> Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
>
> Hi Daiwei:
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Friday, May 18, 2018 7:07 PM
> > To: Zhang, Qi Z ; Wu, Yanglong
> > ; dev@dpdk.org
> > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per
> > port
> >
> > > -Original Message-
> > > From: Zhang, Qi Z
> > > Sent: Friday, May 18, 2018 3:46 PM
> > > To: Wu, Yanglong ; dev@dpdk.org
> > > Cc: Dai, Wei
> > > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> > > per port
> > >
> > > > -Original Message-
> > > > From: Wu, Yanglong
> > > > Sent: Friday, May 18, 2018 3:24 PM
> > > > To: dev@dpdk.org
> > > > Cc: Zhang, Qi Z ; Dai, Wei
> > > > ; Wu, Yanglong
> > > > Subject: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per
> > > > port
> > > >
> > > > rxq->offload should synchronize with dev_conf
> > > >
> > > > Fixes: 860a94d3c692 ("net/ixgbe: support VLAN strip per queue
> > > > offloading in
> > > > VF")
> > > > Signed-off-by: Yanglong Wu
> > >
> > > Acked-by: Qi Zhang
> >
> > The release date is coming soon.
> > Sorry, I have to NACK it.
> > VLAN strip is per-queue feature,
> > If it is disabled on port level, it still can be enabled on queue level.
> > So the else branches still should be removed.
>
> Remove the else branch will not disable all queues if some queue is enabled
> at queue configure level, I think this is not user expected.
> The purpose of i40e_vlan_offload_set here is to disable all queue's vlan
> strip,
> though vlan strip is per queue offload and some queue may be enabled at
> queue configure level, I don't know why we can't disable them in this
> function.
>
> Thanks
> Qi
As VLAN_STRIP has already been advertised to per-queue offloading on ixgbe
82599/X540/X550.
The else branches will break this per-queue feature.
The issues is from the testpmd command "vlan set strip on "
Which is meant to enable/disable VLAN_STRIP on whole port on the fly.
The call stack is as follows:
rx_vlan_strip_set(portid_t port_id, int on)
rte_eth_dev_set_vlan_offload(port_id, vlan_offload); //modify
dev->data->dev_conf.rxmode.offloads
dev->dev_ops->vlan_offload_set(dev, mask)
ixgbe_vlan_offload_set(dev, mask)
ixgbe_vlan_hw_strip_config(struct rte_eth_dev
*dev)
ixgbe_vlan_hw_strip_bitmap_set(struct
rte_eth_dev *dev, uint16_t queue, bool on)
As the VLAN_STRIP is per-queue capability, ixgbe_vlan_hw_strip_config() only
get it from rxq->offloads which hasn't been update in
rte_eth_dev_set_vlan_offload(port_id, vlan_offload);
And the ixgbe_vlan_offload_set() is also be called by ixgbe_dev_start() which
is normal called after dev_configure() and queue_setup().
These are 2 different path to config VLAN_STRIP.
So we can add a function ixgbe_vlan_offload_config() to let them go different
way as follows:
dev->dev_ops->vlan_offload_set(dev, mask) -> point to new function
ixgbe_vlan_offload_config()
ixgbe_vlan_offload_config(dev, mask) {
if vlan_strip is configured on whole port {
update dev->data->dev_conf.rxmode.offloads
update rxq->offloads on all queues
}
Ixgbe_vlan_offload_set()
}
Ixgbe_dev_start()
ixgbe_vlan_offload_set()
Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per port
As 18.05 release is coming soon.
I'd like to submit http://dpdk.org/dev/patchwork/patch/40226/
in reply to yanglong's v2 patch for quick review and validation.
Thanks for your understanding.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Dai, Wei
> Sent: Friday, May 18, 2018 11:06 PM
> To: Zhang, Qi Z ; Wu, Yanglong
> ; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> per port
>
> > -Original Message-
> > From: Zhang, Qi Z
> > Sent: Friday, May 18, 2018 8:37 PM
> > To: Dai, Wei ; Wu, Yanglong
> > ; dev@dpdk.org
> > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for per
> > port
> >
> > Hi Daiwei:
> >
> > > -Original Message-
> > > From: Dai, Wei
> > > Sent: Friday, May 18, 2018 7:07 PM
> > > To: Zhang, Qi Z ; Wu, Yanglong
> > > ; dev@dpdk.org
> > > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> > > per port
> > >
> > > > -Original Message-
> > > > From: Zhang, Qi Z
> > > > Sent: Friday, May 18, 2018 3:46 PM
> > > > To: Wu, Yanglong ; dev@dpdk.org
> > > > Cc: Dai, Wei
> > > > Subject: RE: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> > > > per port
> > > >
> > > > > -Original Message-
> > > > > From: Wu, Yanglong
> > > > > Sent: Friday, May 18, 2018 3:24 PM
> > > > > To: dev@dpdk.org
> > > > > Cc: Zhang, Qi Z ; Dai, Wei
> > > > > ; Wu, Yanglong
> > > > > Subject: [PATCH v2] net/ixgbe: fix VLAN strip setting fail for
> > > > > per port
> > > > >
> > > > > rxq->offload should synchronize with dev_conf
> > > > >
> > > > > Fixes: 860a94d3c692 ("net/ixgbe: support VLAN strip per queue
> > > > > offloading in
> > > > > VF")
> > > > > Signed-off-by: Yanglong Wu
> > > >
> > > > Acked-by: Qi Zhang
> > >
> > > The release date is coming soon.
> > > Sorry, I have to NACK it.
> > > VLAN strip is per-queue feature,
> > > If it is disabled on port level, it still can be enabled on queue level.
> > > So the else branches still should be removed.
> >
> > Remove the else branch will not disable all queues if some queue is
> > enabled at queue configure level, I think this is not user expected.
> > The purpose of i40e_vlan_offload_set here is to disable all queue's
> > vlan strip, though vlan strip is per queue offload and some queue may
> > be enabled at queue configure level, I don't know why we can't disable
> > them in this function.
> >
> > Thanks
> > Qi
>
> As VLAN_STRIP has already been advertised to per-queue offloading on
> ixgbe 82599/X540/X550.
> The else branches will break this per-queue feature.
>
> The issues is from the testpmd command "vlan set strip on "
> Which is meant to enable/disable VLAN_STRIP on whole port on the fly.
> The call stack is as follows:
> rx_vlan_strip_set(portid_t port_id, int on)
> rte_eth_dev_set_vlan_offload(port_id, vlan_offload); //modify
> dev->data->dev_conf.rxmode.offloads
> dev->dev_ops->vlan_offload_set(dev, mask)
> ixgbe_vlan_offload_set(dev, mask)
> ixgbe_vlan_hw_strip_config(struct rte_eth_dev
> *dev)
> ixgbe_vlan_hw_strip_bitmap_set(struct
> rte_eth_dev
> *dev, uint16_t queue, bool on)
>
> As the VLAN_STRIP is per-queue capability, ixgbe_vlan_hw_strip_config()
> only get it from rxq->offloads which hasn't been update in
> rte_eth_dev_set_vlan_offload(port_id, vlan_offload);
>
> And the ixgbe_vlan_offload_set() is also be called by ixgbe_dev_start() which
> is normal called after dev_configure() and queue_setup().
>
> These are 2 different path to config VLAN_STRIP.
> So we can add a function ixgbe_vlan_offload_config() to let them go
> different way as follows:
>
> dev->dev_ops->vlan_offload_set(dev, mask) -> point to new function
> dev->ixgbe_vlan_offload_config()
> ixgbe_vlan_offload_config(dev, mask) {
> if vlan_strip is configured on whole port {
> update dev->data->dev_conf.rxmode.offloads
> update rxq->offloads on all queues
> }
> Ixgbe_vlan_offload_set()
> }
>
> Ixgbe_dev_start()
> ixgbe_vlan_offload_set()
>
Re: [dpdk-dev] [PATCH v4] net/ixgbe: config VLAN strip on the fly
Hi, Zhang Qi
Thanks for your feedback.
I've just submitted v5 patch to follow your guidance.
> -Original Message-
> From: Zhang, Qi Z
> Sent: Saturday, May 19, 2018 8:19 AM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Ananyev, Konstantin ; Wu, Yanglong
> ; Yigit, Ferruh
> Cc: dev@dpdk.org
> Subject: RE: [PATCH v4] net/ixgbe: config VLAN strip on the fly
>
>
>
> > -Original Message-
> > From: Dai, Wei
> > Sent: Saturday, May 19, 2018 12:09 AM
> > To: Lu, Wenzhuo ; Ananyev, Konstantin
> > ; Zhang, Qi Z ;
> > Wu, Yanglong ; Yigit, Ferruh
> >
> > Cc: dev@dpdk.org; Dai, Wei
> > Subject: [PATCH v4] net/ixgbe: config VLAN strip on the fly
> >
> > The old ixgbe_vlan_offload_set() is called by
> > rte_eth_dev_set_vlan_offload() which is meant to config VLAN
> > strip/filter/extend on all queues.
> > This old function is also called by
> > rte_eth_dev_start()/ixgbe_dev_start()
>
> OK, I think this is what we missed in previous patch, good capture, thanks!
>
> > which need support per-queue VALN strip on only parts of queues.
> > So add new function ixgbe_vlan_offload_config() = old
> > ixgbe_vlan_offload_set().
> > New ixgbe_vlan_offload_set = codes to align VLAN strip flags on all
> > queues with port level setting + ixgbe_vlan_offload_configure().
> >
> > Signed-off-by: Wei Dai
> > Signed-off-by: Yanglong Wu
>
> Though the code can be improved to remove some redundant , but I think
> it's not a big deal right now.
> BTW, I think we still need the fixed line, so it will be added during apply.
>
> Fixes: 860a94d3c692 ("net/ixgbe: support VLAN strip per queue offloading in
> VF")
>
> Acked-by: Qi Zhang
Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link status on start
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Zhang, Qi Z
> Sent: Monday, April 2, 2018 10:34 PM
> To: Chas Williams <3ch...@gmail.com>
> Cc: Zhang, Helin ; dev@dpdk.org; Lu, Wenzhuo
> ; Ananyev, Konstantin
> ; Charles (Chas) Williams
> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link status on
> start
>
>
>
> > -Original Message-
> > From: Chas Williams [mailto:3ch...@gmail.com]
> > Sent: Monday, April 2, 2018 9:57 PM
> > To: Zhang, Qi Z
> > Cc: Zhang, Helin ; dev@dpdk.org; Lu, Wenzhuo
> > ; Ananyev, Konstantin
> > ; Charles (Chas) Williams
> >
> > Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link
> > status on start
> >
> > On Mon, Apr 2, 2018 at 9:45 AM, Zhang, Qi Z
> wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: Chas Williams [mailto:3ch...@gmail.com]
> > >> Sent: Monday, April 2, 2018 9:38 PM
> > >> To: Zhang, Qi Z
> > >> Cc: Zhang, Helin ; dev@dpdk.org; Lu,
> Wenzhuo
> > >> ; Ananyev, Konstantin
> > >> ; Charles (Chas) Williams
> > >>
> > >> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link
> > >> status on start
> > >>
> > >> On Mon, Apr 2, 2018 at 8:40 AM, Zhang, Qi Z
> > wrote:
> > >> > Hi Williams:
> > >> >
> > >> >> -Original Message-
> > >> >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Chas
> > >> >> Williams
> > >> >> Sent: Saturday, March 31, 2018 1:22 AM
> > >> >> To: Zhang, Helin
> > >> >> Cc: dev@dpdk.org; Lu, Wenzhuo ;
> Ananyev,
> > >> >> Konstantin ; Charles (Chas)
> > >> >> Williams
> > >> >> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link
> > >> >> status on start
> > >> >>
> > >> >> On Fri, Mar 30, 2018 at 12:30 PM, Zhang, Helin
> > >> >>
> > >> >> wrote:
> > >> >> >
> > >> >> >
> > >> >> >> -Original Message-
> > >> >> >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Chas
> > >> >> >> Williams
> > >> >> >> Sent: Wednesday, February 14, 2018 6:56 AM
> > >> >> >> To: dev@dpdk.org
> > >> >> >> Cc: Lu, Wenzhuo; Ananyev, Konstantin; Charles (Chas) Williams
> > >> >> >> Subject: [dpdk-dev] [PATCH] net/ixgbe: update data->eth_link
> > >> >> >> status on start
> > >> >> >>
> > >> >> >> From: "Charles (Chas) Williams"
> > >> >> >>
> > >> >> >> dev->data->eth_link isn't updated until the first interrupt.
> > >> >> >> dev->data->If a
> > >> >> >> link is carrier down, then this interrupt may never happen.
> > >> >> >> Before we finished starting the PMD, call
> > >> >> >> ixgbe_dev_link_update() to ensure we
> > >> >> have a valid status.
> > >> >> >>
> > >> >> >> Signed-off-by: Chas Williams
> > >> >> >> ---
> > >> >> >> drivers/net/ixgbe/ixgbe_ethdev.c | 4
> > >> >> >> 1 file changed, 4 insertions(+)
> > >> >> >>
> > >> >> >> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > >> >> >> b/drivers/net/ixgbe/ixgbe_ethdev.c
> > >> >> >> index 37eb668..27d29dc 100644
> > >> >> >> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > >> >> >> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > >> >> >> @@ -2666,6 +2666,8 @@ ixgbe_dev_start(struct rte_eth_dev
> *dev)
> > >> >> >> if (err)
> > >> >> >> goto error;
> > >> >> >>
> > >> >> >> + ixgbe_dev_link_update(dev, 0);
> > >> >> > It is called in rte_eth_dev_start() if lsc is not enabled, and
> > >> >> > it is not needed here to avoid any duplication.
> > >> >> > BTW, did you see any issue or just check the code? Thanks!
> > >> >>
> > >> >> Yes, I see an issue with bonding. If LSC is enabled, then
> > >> >> link_status isn't set until the first interrupt to update the
> > >> >> link status. If a link is down, this interrupt may never happen
> > >> >> result in
> > >> link_status being somewhat undefined.
> > >> >
> > >> > Is your issue only happened on VF?
> > >> > For PF, I saw ixgbe_check_link is called at ixgbe_dev_start, so
> > >> > link status is
> > >> assume be updated.
> > >> > If you think it is just missed in VF, can you implemented this in
> > >> > the similar way
> > >> as PF?
> > >>
> > >> No, I don't believe it's isolated to VF. ixgbe_check_link()
> > >> doesn't update (atomically write) the dev->data->dev_link. After
> > >> .dev_start() finishes, I need the link_status of the adapter to be set.
> > >
> > > I saw dev_link.link_status does be updated.
> > > err = ixgbe_check_link(hw, &speed, &link_up, 0);
> > > if (err)
> > > goto error;
> > > dev->data->dev_link.link_status = link_up;
> >
> > That doesn't fill in link_duplex, link_speed, or link_autoneg.
> > 802.3ad requires that all the ports of the same bonding group have the
> > same speed and duplex. I need to be able to check the speed and the
> > duplex at least (and autoneg as well).
>
> OK, I'm not sure if it is better to call this at rte_eth_dev_start So far we
> have
> below code.
> if (dev->data->dev_conf.intr_conf.lsc == 0) {
> RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->link_update,
> -ENOTSUP);
> (*dev->dev_ops->link_
Re: [dpdk-dev] [PATCH v2] ethdev: check Rx/Tx offloads
Thanks, Thomas and Ferruh I think I can implement v3 for this. > -Original Message- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Sunday, April 15, 2018 6:37 PM > To: Yigit, Ferruh ; Dai, Wei > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2] ethdev: check Rx/Tx offloads > > 13/04/2018 19:31, Ferruh Yigit: > > On 3/28/2018 9:57 AM, Wei Dai wrote: > > > This patch check if a requested offloading is supported in the > > > device capability. > > > A per port offloading feature should be enabled or disabled at same > > > time in both rte_eth_dev_configure( ) and rte_eth_rx_queue_setup( > > > )/rte_eth_tx_queue_setup( ). > > > This patch check if a per port offloading flag has same > > > configuration in rte_eth_dev_configure( ) and > > > rte_eth_rx_queue_setup( )/rte_eth_tx_queue_setup( ). > > > This patch can make such checking in a common way in rte_ethdev > > > layer to avoid same checking in underlying PMD. > > > > I think it is good idea to move common check to the abstraction layer > > as much as possible. > > > > But for this case we are targeting an API change in rc2, I believe > > better wait that API change for this update. > > I think Wei could implement some filtering of offload flags: > If an offload is already enabled at port level, we can filter out them when > enabling again at queue level. > By removing such repetition in ethdev, before calling the PMD op, the PMD > does not need to bother for offloads enabled twice. >
Re: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number setting
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Tuesday, January 9, 2018 4:06 AM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Wu, Jingjing ; Peng, Yuan
> Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> Subject: RE: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number
> setting
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Monday, January 8, 2018 1:03 PM
> > To: Lu, Wenzhuo ; Wu, Jingjing
> > ; Peng, Yuan
> > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > Subject: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number
> > setting
> >
> > If an invalid RX queue is configured from testpmd command like "port
> > config all rxq number", the global variable rxq is updated by this
> > invalid value. It may cause testpmd crash.
> > This patch restores its last correct value when an invalid rxq number
> > configured is detected.
> >
> > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 1 +
> > app/test-pmd/testpmd.c | 10 -- app/test-pmd/testpmd.h |
> 2
> > ++
> > 3 files changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > f71d963..3f3986c 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -1501,6 +1501,7 @@ cmd_config_rx_tx_parsed(void *parsed_result,
> > printf("Warning: Either rx or tx queues should be non
> > zero\n");
> > return;
> > }
> > + nb_rxq_bak = nb_rxq;
> > nb_rxq = res->value;
> > }
> > else if (!strcmp(res->name, "txq")) { diff --git
> > a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > 47e145c..5939c88 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -188,6 +188,8 @@ uint8_t dcb_test = 0; queueid_t nb_rxq = 1; /**<
> > Number of RX queues per port. */ queueid_t nb_txq = 1; /**< Number of
> > TX queues per port. */
> >
> > +queueid_t nb_rxq_bak = 1; /**< Backup of last correct number of RX
> > +queues */
> > +
> > /*
> > * Configurable number of RX/TX ring descriptors.
> > */
> > @@ -708,10 +710,14 @@ init_fwd_streams(void)
> > port = &ports[pid];
> > if (nb_rxq > port->dev_info.max_rx_queues) {
>
> Why not to add that check in the function handler for " port config ... rxq
> ..."
> command itself?
> In that case you wouldn't need nb_rxq_bak at all.
> Konstantin
Thanks for your feedback, Konstantin.
I see your point. If that check is added in the function handler of command
line,
same loop code will be repeated.
There are 2 ways to change nb_rxq:
1. with --rxq in the command line to start testpmd app to overwrite the default
value 1
2. with "port config all rxq number" in the testpmd run time command line
How can your method correct an invalid input with --rxq in the command to start
testpm app ?
By the way, my v1 patch has a bug in case of more than 1 port with different
maximum number of Rx queues.
For example, the max_rx_queues of port 0 is 8 and that of port 1 is 4.
The previous valid rxq=4, if "port config all rxq 5" is run,
The nb_rxq_bak is updated to 5, nb_rxq can't be restored to last correct value
4 for port 1.
I will fix bug in my v2 patch.
>
> > printf("Fail: nb_rxq(%d) is greater than "
> > - "max_rx_queues(%d)\n", nb_rxq,
> > - port->dev_info.max_rx_queues);
> > + "max_rx_queues(%d), restore to backup "
> > + "rxq number(%d)\n", nb_rxq,
> > + port->dev_info.max_rx_queues,
> > + nb_rxq_bak);
> > + nb_rxq = nb_rxq_bak;
> > return -1;
> > }
> > + nb_rxq_bak = nb_rxq;
> > if (nb_txq > port->dev_info.max_tx_queues) {
> > printf("Fail: nb_txq(%d) is greater than "
> > "max_tx_queues(%d)\n", nb_txq,
> > diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index
> > 4d7f27c..84246f7 100644
> > --- a/app/test-pmd/testpmd.h
> > +++ b/app/test-pmd/testpmd.h
> > @@ -391,6 +391,8 @@ extern uint64_t rss_hf; extern queueid_t nb_rxq;
> > extern queueid_t nb_txq;
> >
> > +extern queueid_t nb_rxq_bak;
> > +
> > extern uint16_t nb_rxd;
> > extern uint16_t nb_txd;
> >
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number setting
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Wednesday, January 10, 2018 9:55 AM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Wu, Jingjing ; Peng, Yuan
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq number
> setting
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, January 10, 2018 1:34 AM
> > To: Ananyev, Konstantin ; Lu, Wenzhuo
> > ; Wu, Jingjing ; Peng,
> > Yuan
> > Cc: dev@dpdk.org; sta...@dpdk.org
> > Subject: RE: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq
> > number setting
> >
> > > -Original Message-
> > > From: Ananyev, Konstantin
> > > Sent: Tuesday, January 9, 2018 4:06 AM
> > > To: Dai, Wei ; Lu, Wenzhuo
> > > ; Wu, Jingjing ; Peng,
> > > Yuan
> > > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > > Subject: RE: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq
> > > number setting
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > > > Sent: Monday, January 8, 2018 1:03 PM
> > > > To: Lu, Wenzhuo ; Wu, Jingjing
> > > > ; Peng, Yuan
> > > > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > > > Subject: [dpdk-dev] [PATCH 1/2] app/testpmd: fix invalid rxq
> > > > number setting
> > > >
> > > > If an invalid RX queue is configured from testpmd command like
> > > > "port config all rxq number", the global variable rxq is updated
> > > > by this invalid value. It may cause testpmd crash.
> > > > This patch restores its last correct value when an invalid rxq
> > > > number configured is detected.
> > > >
> > > > Fixes: ce8d561418d4 ("app/testpmd: add port configuration
> > > > settings")
> > > > Cc: sta...@dpdk.org
> > > >
> > > > Signed-off-by: Wei Dai
> > > > ---
> > > > app/test-pmd/cmdline.c | 1 +
> > > > app/test-pmd/testpmd.c | 10 -- app/test-pmd/testpmd.h
> |
> > > 2
> > > > ++
> > > > 3 files changed, 11 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > > > f71d963..3f3986c 100644
> > > > --- a/app/test-pmd/cmdline.c
> > > > +++ b/app/test-pmd/cmdline.c
> > > > @@ -1501,6 +1501,7 @@ cmd_config_rx_tx_parsed(void
> *parsed_result,
> > > > printf("Warning: Either rx or tx queues should
> > > > be non
> zero\n");
> > > > return;
> > > > }
> > > > + nb_rxq_bak = nb_rxq;
> > > > nb_rxq = res->value;
> > > > }
> > > > else if (!strcmp(res->name, "txq")) { diff --git
> > > > a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > > > 47e145c..5939c88 100644
> > > > --- a/app/test-pmd/testpmd.c
> > > > +++ b/app/test-pmd/testpmd.c
> > > > @@ -188,6 +188,8 @@ uint8_t dcb_test = 0; queueid_t nb_rxq = 1;
> > > > /**< Number of RX queues per port. */ queueid_t nb_txq = 1; /**<
> > > > Number of TX queues per port. */
> > > >
> > > > +queueid_t nb_rxq_bak = 1; /**< Backup of last correct number of
> > > > +RX queues */
> > > > +
> > > > /*
> > > > * Configurable number of RX/TX ring descriptors.
> > > > */
> > > > @@ -708,10 +710,14 @@ init_fwd_streams(void)
> > > > port = &ports[pid];
> > > > if (nb_rxq > port->dev_info.max_rx_queues) {
> > >
> > > Why not to add that check in the function handler for " port config ...
> rxq ..."
> > > command itself?
> > > In that case you wouldn't need nb_rxq_bak at all.
> > > Konstantin
> >
> > Thanks for your feedback, Konstantin.
> > I see your point. If that check is added in the function handler of
> > command line, same loop code will be repeated.
> >
> > There are 2 ways to change nb_rxq:
> > 1. with --rxq in the command line to start testpmd app to overwrite
> > the default value 1 2. with "port config all rxq number" in the
> > testpmd run time command li
Re: [dpdk-dev] [PATCH v2 2/2] app/testpmd: fix invalid txq number setting
> -Original Message-
> From: Yang, Qiming
> Sent: Wednesday, January 10, 2018 2:38 PM
> To: Dai, Wei ; Lu, Wenzhuo ;
> Wu, Jingjing ; Peng, Yuan ;
> Ananyev, Konstantin
> Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> Subject: RE: [dpdk-dev] [PATCH v2 2/2] app/testpmd: fix invalid txq number
> setting
>
> I think the name bak is a little bit confused, what do you think just use
> nd_txq_backup/nd_rxq_backup?
> And I think it's no need to break the patch into two patch, them fix the same
> thing and the code amount are not large.
I will follow Konstantin's guide to give v3 patch set.
By the way, I think 2 patches are much clearer and keep each very simple
for others to review and for maintainer's convenience.
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wei Dai
> > Sent: Wednesday, January 10, 2018 12:14 PM
> > To: Lu, Wenzhuo ; Wu, Jingjing
> > ; Peng, Yuan ; Ananyev,
> > Konstantin
> > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > Subject: [dpdk-dev] [PATCH v2 2/2] app/testpmd: fix invalid txq number
> > setting
> >
> > If an invalid TX queue is configured from testpmd command like "port
> > config all txq number", the global variable txq is updated by this
> > invalid value. It may cause testpmd crash.
> > This patch restores its last correct value when an invalid txq number
> > configured is detected.
> >
> > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> > ---
> > app/test-pmd/cmdline.c | 2 ++
> > app/test-pmd/testpmd.c | 12 +--- app/test-pmd/testpmd.h |
> 1
> > +
> > 3 files changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c index
> > a5a1d57..26dd81a 100644
> > --- a/app/test-pmd/cmdline.c
> > +++ b/app/test-pmd/cmdline.c
> > @@ -1527,6 +1527,8 @@ cmd_config_rx_tx_parsed(void *parsed_result,
> > printf("Warning: Either rx or tx queues should be non
> > zero\n");
> > return;
> > }
> > + /* bakcup last correct nb_txq */
> > + nb_txq_bak = nb_txq;
> > nb_txq = res->value;
> > }
> > else if (!strcmp(res->name, "rxd")) { diff --git
> > a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > efafc24..8b49d96 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -190,6 +190,7 @@ queueid_t nb_rxq = 1; /**< Number of RX queues
> per
> > port. */ queueid_t nb_txq = 1; /**< Number of TX queues per port. */
> >
> > queueid_t nb_rxq_bak = 1; /**< Backup of last correct number of RX
> > queues */
> > +queueid_t nb_txq_bak = 1; /**< Backup of last correct number of TX
> > +queues */
> >
> > /*
> > * Configurable number of RX/TX ring descriptors.
> > @@ -721,8 +722,12 @@ init_fwd_streams(void)
> > }
> > if (nb_txq > port->dev_info.max_tx_queues) {
> > printf("Fail: nb_txq(%d) is greater than "
> > - "max_tx_queues(%d)\n", nb_txq,
> > - port->dev_info.max_tx_queues);
> > + "max_tx_queues(%d), restored to backup "
> > + "txq number(%d)\n", nb_txq,
> > + port->dev_info.max_tx_queues,
> > + nb_txq_bak);
> > + /* restored to last correct nb_txq */
> > + nb_txq = nb_txq_bak;
> > return -1;
> > }
> > if (numa_support) {
> > @@ -744,8 +749,9 @@ init_fwd_streams(void)
> > }
> > }
> >
> > - /* backup the correct nb_rxq */
> > + /* backup the correct nb_rxq and nb_txq */
> > nb_rxq_bak = nb_rxq;
> > + nb_txq_bak = nb_txq;
> >
> > q = RTE_MAX(nb_rxq, nb_txq);
> > if (q == 0) {
> > diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index
> > 6f7932d..bca93c1 100644
> > --- a/app/test-pmd/testpmd.h
> > +++ b/app/test-pmd/testpmd.h
> > @@ -393,6 +393,7 @@ extern queueid_t nb_rxq; extern queueid_t
> nb_txq;
> >
> > extern queueid_t nb_rxq_bak;
> > +extern queueid_t nb_txq_bak;
> >
> > extern uint16_t nb_rxd;
> > extern uint16_t nb_txd;
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v3 0/2] app/testpmd: fix invalid rxq and txq nubmer setting
> -Original Message-
> From: Ananyev, Konstantin
> Sent: Wednesday, January 10, 2018 5:59 PM
> To: Dai, Wei ; Yang, Qiming ;
> Peng, Yuan ; Lu, Wenzhuo ;
> Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v3 0/2] app/testpmd: fix invalid rxq and txq nubmer
> setting
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Wednesday, January 10, 2018 8:41 AM
> > To: Ananyev, Konstantin ; Yang, Qiming
> > ; Peng, Yuan ; Lu,
> Wenzhuo
> > ; Wu, Jingjing
> > Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> > Subject: [PATCH v3 0/2] app/testpmd: fix invalid rxq and txq nubmer
> > setting
> >
> > If an invlaid number of RX or TX queues is configured from testpmd
> > command like "port config all rxq number" or "port config all txq number".
> > The global variable rxq or txq is updated by the invalid input.
> > This can cause testpmd crash. For example, if the maximum number of RX
> > or TX queues is 4, testpmd will crash after running commands "port
> > config all rxq 5", "port config all txq 5" and "start" in sequence.
> >
> > These 2 patches reserve the last correct rxq and txq, if an invalid
> > input is detected, it is restored to the backup value to avoid crash.
> >
> > Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> > Cc: sta...@dpdk.org
> >
> > Signed-off-by: Wei Dai
> >
> > ---
>
> The code looks good to me, just seems some misspellings in the comments
> (mimumal).
> Acked-by: Konstantin Ananyev
Thanks, Konstantin.
I'll correct these misspellings in my v4 patch set.
>
> > v3: follow the guide from Konstantin to use functions to check
> > input rxq and txq instead of usage of new added global variables.
> >
> > v2: fix a bug in v1
> >
> >
> > Wei Dai (2):
> > app/testpmd: fix invalid rxq number setting
> > app/testpmd: fix invalid txq number setting
> >
> > app/test-pmd/cmdline.c| 4 ++
> > app/test-pmd/parameters.c | 13 ---
> > app/test-pmd/testpmd.c| 94
> +++
> > app/test-pmd/testpmd.h| 5 +++
> > 4 files changed, 110 insertions(+), 6 deletions(-)
> >
> > --
> > 2.7.5
Re: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF
According to 82599 datasheet, VF working mode is controlled by its host PF. If VF is working in RSS or DCB mode, it can use more than 1 queues. That also means its host PF should enable RSS or DCB. The PF Rx mode can be ETH_MQ_RX_VMDQ_RSS or ETH_MQ_RX_VMDQ_DCB. So I think that DPDK app with PF cause this issue, not ixgbe PMD itself. By the way, you can reply your patch mail to provide more info about how You reproduce this issue to easy others' reviewing and testing your patch. Thanks > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu > Sent: Tuesday, January 9, 2018 2:32 PM > To: dev@dpdk.org; Yang, Zhiyong > Cc: Wu, Yanglong > Subject: [dpdk-dev] [PATCH v4] 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 > --- > v1~v3: > coding style issue fix > --- > v4: > Rework according to comments > --- > 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 baaeee5d9..6af4f8b2b 100644 > --- a/drivers/net/ixgbe/ixgbe_ethdev.c > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c > @@ -2240,8 +2240,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
Re: [dpdk-dev] [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, January 11, 2018 4:08 PM
> To: Dai, Wei ; Lu, Wenzhuo
> Cc: dev@dpdk.org; Wang, Liang-min ;
> sta...@dpdk.org
> Subject: RE: [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
>
>
>
> > -----Original Message-
> > From: Dai, Wei
> > Sent: Thursday, December 28, 2017 12:39 PM
> > To: Zhang, Qi Z ; Lu, Wenzhuo
> >
> > Cc: dev@dpdk.org; Wang, Liang-min ;
> > sta...@dpdk.org
> > Subject: RE: [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
> >
> > According to step 7 & 8 in Table 7-74 PF-to-VF Messaging Flow in 82599
> > datasheet, The calling of ixgbe_read_mbx( ) can be replaced by
> > following lines to avoid touching ->mbx.v2p_mailbox,
> > IXGBE_WRITE_REG(hw, IXGBE_VFMAILBOX, IXGBE_VFMAILBOX_ACK);
>
> Thanks for the suggestion.
>
> I think the patch try to keep things unchanged when a PF reset happen, but it
> is not going to cover the case that PF reset interrupt and a foreground VF to
> PF request happen simultaneously which is an knowing issue Your suggestion
> may help on that, but it is not a complete fix. I think it will be better to
> have
> a separate patch that focus on it.
Agree with you.
>
> Regards
> Qi
> >
> > > -Original Message-
> > > From: Zhang, Qi Z
> > > Sent: Thursday, December 28, 2017 4:22 AM
> > > To: Lu, Wenzhuo
> > > Cc: dev@dpdk.org; Dai, Wei ; Wang, Liang-min
> > > ; Zhang, Qi Z ;
> > > sta...@dpdk.org
> > > Subject: [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
> > >
> > > Mailbox interrupt handler only take care of PF reset notification,
> > > for other message ixgbe_read_mbx should not be called since it get
> > > chance to break the foreground VF to PF communication.
> > > This can be simply repeated by
> > > testpmd>rx_vlan rm all 0
> > >
> > > Fixes: 77234603fba0 ("net/ixgbe: support VF mailbox interrupt for
> > > link
> > > up/down")
> > > Cc: sta...@dpdk.org
> > >
> > > Signed-off-by: Qi Zhang
Acked-by: Wei Dai
> > > ---
> > > drivers/net/ixgbe/ixgbe_ethdev.c | 10 +++---
> > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > index ff19a56..02121f4 100644
> > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > @@ -8165,13 +8165,17 @@ static void ixgbevf_mbx_process(struct
> > > rte_eth_dev *dev)
> > > struct ixgbe_hw *hw =
> > > IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > > u32 in_msg = 0;
> > >
> > > - if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> > > - return;
> > > + /* peek the message first */
> > > + in_msg = IXGBE_READ_REG(hw, IXGBE_VFMBMEM);
> > >
> > > /* PF reset VF event */
> > > - if (in_msg == IXGBE_PF_CONTROL_MSG)
> > > + if (in_msg == IXGBE_PF_CONTROL_MSG) {
> > > + /* dummy mbx read to ack pf */
> > > + if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> > > + return;
> > > _rte_eth_dev_callback_process(dev,
> > > RTE_ETH_EVENT_INTR_RESET,
> > > NULL, NULL);
> > > + }
> > > }
> > >
> > > static int
> > > --
> > > 2.7.4
Re: [dpdk-dev] [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, December 28, 2017 4:22 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Dai, Wei ; Wang, Liang-min
> ; Zhang, Qi Z ;
> sta...@dpdk.org
> Subject: [PATCH 1/2] net/ixgbe: fix mailbox interrupt handler
>
> Mailbox interrupt handler only take care of PF reset notification, for other
> message ixgbe_read_mbx should not be called since it get chance to break
> the foreground VF to PF communication.
> This can be simply repeated by
> testpmd>rx_vlan rm all 0
>
> Fixes: 77234603fba0 ("net/ixgbe: support VF mailbox interrupt for link
> up/down")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
Acked-by: Wei Dai
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ff19a56..02121f4 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -8165,13 +8165,17 @@ static void ixgbevf_mbx_process(struct
> rte_eth_dev *dev)
> struct ixgbe_hw *hw =
> IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> u32 in_msg = 0;
>
> - if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> - return;
> + /* peek the message first */
> + in_msg = IXGBE_READ_REG(hw, IXGBE_VFMBMEM);
>
> /* PF reset VF event */
> - if (in_msg == IXGBE_PF_CONTROL_MSG)
> + if (in_msg == IXGBE_PF_CONTROL_MSG) {
> + /* dummy mbx read to ack pf */
> + if (ixgbe_read_mbx(hw, &in_msg, 1, 0))
> + return;
> _rte_eth_dev_callback_process(dev,
> RTE_ETH_EVENT_INTR_RESET,
> NULL, NULL);
> + }
> }
>
> static int
> --
> 2.7.4
Re: [dpdk-dev] [PATCH 2/2] net/e1000: fix mailbox interrupt handler
> -Original Message-
> From: Zhang, Qi Z
> Sent: Thursday, December 28, 2017 4:23 AM
> To: Lu, Wenzhuo
> Cc: dev@dpdk.org; Dai, Wei ; Wang, Liang-min
> ; Zhang, Qi Z ;
> sta...@dpdk.org
> Subject: [PATCH 2/2] net/e1000: fix mailbox interrupt handler
>
> Mailbox interrupt handler only take care of the PF reset notification, for
> other message mbx->ops.read should not be called since it get chance to
> break the foreground VF to PF communication.
>
> Fixes: 316f4f1adc2e ("net/igb: support VF mailbox interrupt for link
> up/down")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Qi Zhang
Acked-by: Wei Dai
> ---
> drivers/net/e1000/igb_ethdev.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/e1000/igb_ethdev.c
> b/drivers/net/e1000/igb_ethdev.c index fdc139f..0d8bc49 100644
> --- a/drivers/net/e1000/igb_ethdev.c
> +++ b/drivers/net/e1000/igb_ethdev.c
> @@ -2970,13 +2970,17 @@ void igbvf_mbx_process(struct rte_eth_dev
> *dev)
> struct e1000_mbx_info *mbx = &hw->mbx;
> u32 in_msg = 0;
>
> - if (mbx->ops.read(hw, &in_msg, 1, 0))
> - return;
> + /* peek the message first */
> + in_msg = E1000_READ_REG(hw, E1000_VMBMEM(0));
>
> /* PF reset VF event */
> - if (in_msg == E1000_PF_CONTROL_MSG)
> + if (in_msg == E1000_PF_CONTROL_MSG) {
> + /* dummy mbx read to ack pf */
> + if (mbx->ops.read(hw, &in_msg, 1, 0))
> + return;
> _rte_eth_dev_callback_process(dev,
> RTE_ETH_EVENT_INTR_RESET,
> NULL, NULL);
> + }
> }
>
> static int
> --
> 2.7.4
Re: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF
> -Original Message- > From: Wu, Yanglong > Sent: Friday, January 12, 2018 10:38 AM > To: Dai, Wei ; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > Hi > After confirm with Daiwei and according to the data sheet, > RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool is the Max number of queue can > be used in VF, that would be assigned as IXGBE_MAX_RX_QUEUE_NUM / > RTE_ETH_DEV_SRIOV(dev).active, so that assigning nb_q_per_pool as 1 > when PF is in ETH_MQ_RX_NONE, which will make VF can just use only 1 > queue, is not right. So this patch is right. > > Yanglong > > -Original Message- > From: Wu, Yanglong > Sent: Thursday, January 11, 2018 11:29 PM > To: Wu, Yanglong ; Dai, Wei > ; dev@dpdk.org > Subject: RE: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > Hi daiwei: > > After I double checked with this bug, the problem can be described as follow: > When we start PF using testpmd like this: testpmd -c 0x3 -n 4 > --socket-mem=1024,1024 --file-prefix=pf -w :05:00.0 -w :05:00.1 > -- -i. The number of queue signed to each port would be 1 and the > rxmode.mq_mode of ixgbe eth_dev would be set as ETH_MQ_RX_NONE. > And this config info is make sense, so until now there is no problem, right? > And according to the code: > 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; > The nb_q_per_pool of (RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool would > be set as 1, that means for VF the number of max queue can be used would > be only 1. > > And next we start VF using l3fwd: > l3fwd/build/l3fwd -c 0xc -n 4 -w :05:10.0 -w :05:10.1 -- -p 0x3 > --config '(0,0,18),(1,0,19)' --parse-ptype The number of rx_q equal to 1 and > there is no problem. But, in l3fwd, the number of tx_q would equal to the > number of core used in l3fwd, so here number of tx_q equal to 2 but as > described above, the max number of queue can be used in VF is just only 1. > So there is problem and l3fwd will check failed. > > > So there is two ways to fix this bug, the first is using this patch, don't > assign > RTE_ETH_DEV_SRIOV(dev).nb_q_per_pool as 1 when mq_mode = > ETH_MQ_RX_VMDQ_ONLY. > And the second is that the number of tx_q would not assigned as the number > of cores used in l3fwd. > > Which one do you think is make sense? > > > > > Yanglong > > > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Wu, Yanglong > Sent: Thursday, January 11, 2018 6:30 PM > To: Dai, Wei ; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > Yes, this problem is caused by PF passing a wrong number of queue to VF. So > basically, I removed model check of "case ETH_MQ_RX_NONE". It seem > right after I do that but I'am also not very sure the changing is really > right. So > thank to your comments, I will redebug this problem. > > -Original Message- > From: Dai, Wei > Sent: Thursday, January 11, 2018 5:48 PM > To: Wu, Yanglong ; dev@dpdk.org; Yang, Zhiyong > > Cc: Wu, Yanglong > Subject: RE: [dpdk-dev] [PATCH v4] net/ixgbe: fix l3fwd start failed on VF > > According to 82599 datasheet, VF working mode is controlled by its host PF. > If VF is working in RSS or DCB mode, it can use more than 1 queues. > That also means its host PF should enable RSS or DCB. > The PF Rx mode can be ETH_MQ_RX_VMDQ_RSS or > ETH_MQ_RX_VMDQ_DCB. > So I think that DPDK app with PF cause this issue, not ixgbe PMD itself. > > By the way, you can reply your patch mail to provide more info about how > You reproduce this issue to easy others' reviewing and testing your patch. > > Thanks > > > -Original Message- > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Yanglong Wu > > Sent: Tuesday, January 9, 2018 2:32 PM > > To: dev@dpdk.org; Yang, Zhiyong > > Cc: Wu, Yanglong > > Subject: [dpdk-dev] [PATCH v4] 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: m
Re: [dpdk-dev] [PATCH v4 0/2] app/testpmd: fix invalid rxq and txq nubmer settings
Hi, Yuan
I can build dpdk with my patches successfully in my Fedora 24 with gcc 6.3.1
20161221 (Red Hat 6.3.1-1)
Anyway, I will make v5 patch to address the problem you report and correct
typos reported by Konstantin.
Thanks
> -Original Message-
> From: Peng, Yuan
> Sent: Friday, January 12, 2018 1:40 PM
> To: Dai, Wei ; Ananyev, Konstantin
> ; Yang, Qiming ;
> Lu, Wenzhuo ; Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org
> Subject: RE: [PATCH v4 0/2] app/testpmd: fix invalid rxq and txq nubmer
> settings
>
> Hi Wei,
>
> There is a build error applied your patches to the latest DPDK version.
> /root/dpdk/app/test-pmd/testpmd.c: In function 'check_nb_rxq':
> /root/dpdk/app/test-pmd/testpmd.c:579:3: error: 'pid' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>printf("Fail: input rxq (%u) can't be greater "
>^
> /root/dpdk/app/test-pmd/testpmd.c: In function 'check_nb_txq':
> /root/dpdk/app/test-pmd/testpmd.c:625:3: error: 'pid' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
>printf("Fail: input txq (%u) can't be greater "
>^
> My gcc verison is gcc version 5.3.1 20151207 (Red Hat 5.3.1-2) (GCC)
>
> Could you help to check it?
>
> Thanks.
> Yuan.
>
> -Original Message-
> From: Dai, Wei
> Sent: Thursday, January 11, 2018 12:58 PM
> To: Ananyev, Konstantin ; Yang, Qiming
> ; Peng, Yuan ; Lu,
> Wenzhuo ; Wu, Jingjing
> Cc: dev@dpdk.org; sta...@dpdk.org; Dai, Wei
> Subject: [PATCH v4 0/2] app/testpmd: fix invalid rxq and txq nubmer settings
>
> If an invlaid number of RX or TX queues is configured from testpmd
> command like "port config all rxq number" or "port config all txq number".
> or from --rxq and --txq in the command to start testpmd. The global variable
> nb_rxq or nb_txq is updated by the invalid input.
> This can cause testpmd crash. For example, if the maximum number of RX or
> TX queues is 4, testpmd will crash after running commands "port config all
> rxq 5", "port config all txq 5" and "start" in sequence.
>
> With these 2 patches, if an invalid input is detected, it is refused and
> testpmd
> keeps last correct values of nb_rxq and nb_txq.
>
> Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Wei Dai
> Aced-by: Konstantin Ananyev
>
> ---
> v4: update git log message and rename 2 new added functions
>
> v3: follow the guide from Konstantin to use functions to check
> input rxq and txq instead of usage of new added global variables.
>
> v2: fix a bug in v1
>
>
>
> Wei Dai (2):
> app/testpmd: fix invalid rxq number setting
> app/testpmd: fix invalid txq number setting
>
> app/test-pmd/cmdline.c| 4 +++
> app/test-pmd/parameters.c | 13 +++
> app/test-pmd/testpmd.c| 92
> +++
> app/test-pmd/testpmd.h| 5 +++
> 4 files changed, 108 insertions(+), 6 deletions(-)
>
> --
> 2.7.5
Re: [dpdk-dev] [PATCH v2 1/4] net/ixgbevf: unregister irq handler when other interrupts not allowed.
Hi, Tonghao & Beilei
The issue reported by Tonghao is caused by shortage of igb_uio.
If you want to use Rx queue interrupt in your DPDK application,
I suggest use VFIO-PCI to bind NIC port instead of igb_uio.
Currently igb_uio only support single event fd. This fd is triggered by
both miscellaneous and RX queue interrupt in ixgbe VF.
But same event fd is added to epoll fd of eal-intr-thread
and also epoll fd of normal thread for Rx task, this cause the issue.
If VFIO-PCI is used, different event fd for misc and Rx queue are created.
By the way, your patch also lead to missing of PF to VF reset interrupt.
So, I am sorry that I can't agree it now.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of
> xiangxia.m@gmail.com
> Sent: Friday, January 12, 2018 12:40 AM
> To: Xing, Beilei ; dev@dpdk.org
> Cc: Tonghao Zhang
> Subject: [dpdk-dev] [PATCH v2 1/4] net/ixgbevf: unregister irq handler when
> other interrupts not allowed.
>
> From: Tonghao Zhang
>
> When bind the ixgbe VF (e.g 82599 card) to igb_uio and enable the
> rx-interrupt, there will be more than one epoll_wait on intr_handle.fd.
> One is in "eal-intr-thread" thread, and the others are in the thread which
> call
> the "rte_epoll_wait". The problem is that sometimes "eal-intr-thread" thread
> will process the rx interrupt, and then rte_epoll_wait can't get the event
> anymore, and the packets may be lost.
>
> The patch unregister the status interrupt handler in "eal-intr-thread"
> thread and the ixgbe pf is in the same case.
>
> Signed-off-by: Tonghao Zhang
> Acked-by: Beilei Xing
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index ff19a56..0e056a2 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -5078,6 +5078,15 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> }
> ixgbevf_configure_msix(dev);
>
> + if (!rte_intr_allow_others(intr_handle)) {
> + rte_intr_callback_unregister(intr_handle,
> + ixgbevf_dev_interrupt_handler,
> + dev);
> + if (dev->data->dev_conf.intr_conf.lsc != 0)
> + PMD_INIT_LOG(INFO, "lsc won't enable because of"
> + " no intr multiplex");
> + }
> +
> /* When a VF port is bound to VFIO-PCI, only miscellaneous interrupt
>* is mapped to VFIO vector 0 in eth_ixgbevf_dev_init( ).
>* If previous VFIO interrupt mapping setting in eth_ixgbevf_dev_init( )
> @@ -5120,6 +5129,12 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
>
> ixgbe_dev_clear_queues(dev);
>
> + if (!rte_intr_allow_others(intr_handle))
> + /* resume to the default handler */
> + rte_intr_callback_register(intr_handle,
> +ixgbevf_dev_interrupt_handler,
> +(void *)dev);
> +
> /* Clean datapath event and queue/vec mapping */
> rte_intr_efd_disable(intr_handle);
> if (intr_handle->intr_vec != NULL) {
> --
> 1.8.3.1
Re: [dpdk-dev] [PATCH v2 3/4] net/ixgbevf: save IXGBE_VTEIMS to intr->mask for performance.
> -Original Message-
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of
> xiangxia.m@gmail.com
> Sent: Friday, January 12, 2018 12:40 AM
> To: Xing, Beilei ; dev@dpdk.org
> Cc: Tonghao Zhang
> Subject: [dpdk-dev] [PATCH v2 3/4] net/ixgbevf: save IXGBE_VTEIMS to
> intr->mask for performance.
>
> From: Tonghao Zhang
>
> If dpdk APPs call the rte_eth_dev_rx_intr_enable or
> rte_eth_dev_rx_intr_disable frequently, and ixgbe vf will read the
> IXGBE_VTEIMS register everytime. The patch saves the IXGBE_VTEIMS to
> mask to avoid read frequently.
>
> Signed-off-by: Tonghao Zhang
> Acked-by: Beilei Xing
Acked-by: Wei Dai
> ---
> drivers/net/ixgbe/ixgbe_ethdev.c | 55
> +---
> 1 file changed, 35 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> b/drivers/net/ixgbe/ixgbe_ethdev.c
> index 49f486a..cab243d 100644
> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> @@ -270,8 +270,8 @@ static int ixgbevf_dev_link_update(struct
> rte_eth_dev *dev, static void ixgbevf_dev_stop(struct rte_eth_dev *dev);
> static void ixgbevf_dev_close(struct rte_eth_dev *dev); static int
> ixgbevf_dev_reset(struct rte_eth_dev *dev); -static void
> ixgbevf_intr_disable(struct ixgbe_hw *hw); -static void
> ixgbevf_intr_enable(struct ixgbe_hw *hw);
> +static void ixgbevf_intr_disable(struct rte_eth_dev *dev); static void
> +ixgbevf_intr_enable(struct rte_eth_dev *dev);
> static int ixgbevf_dev_stats_get(struct rte_eth_dev *dev,
> struct rte_eth_stats *stats);
> static void ixgbevf_dev_stats_reset(struct rte_eth_dev *dev); @@ -1665,7
> +1665,7 @@ static int ixgbe_l2_tn_filter_init(struct rte_eth_dev *eth_dev)
> ixgbevf_dev_stats_reset(eth_dev);
>
> /* Disable the interrupts for VF */
> - ixgbevf_intr_disable(hw);
> + ixgbevf_intr_disable(eth_dev);
>
> hw->mac.num_rar_entries = 128; /* The MAX of the underlying PF */
> diag = hw->mac.ops.reset_hw(hw);
> @@ -1734,7 +1734,7 @@ static int ixgbe_l2_tn_filter_init(struct
> rte_eth_dev *eth_dev)
> rte_intr_callback_register(intr_handle,
> ixgbevf_dev_interrupt_handler, eth_dev);
> rte_intr_enable(intr_handle);
> - ixgbevf_intr_enable(hw);
> + ixgbevf_intr_enable(eth_dev);
>
> PMD_INIT_LOG(DEBUG, "port %d vendorID=0x%x deviceID=0x%x
> mac.type=%s",
>eth_dev->data->port_id, pci_dev->id.vendor_id, @@
> -1767,7 +1767,7 @@ static int ixgbe_l2_tn_filter_init(struct rte_eth_dev
> *eth_dev)
> eth_dev->tx_pkt_burst = NULL;
>
> /* Disable the interrupts for VF */
> - ixgbevf_intr_disable(hw);
> + ixgbevf_intr_disable(eth_dev);
>
> rte_free(eth_dev->data->mac_addrs);
> eth_dev->data->mac_addrs = NULL;
> @@ -4953,19 +4953,32 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> * Virtual Function operations
> */
> static void
> -ixgbevf_intr_disable(struct ixgbe_hw *hw)
> +ixgbevf_intr_disable(struct rte_eth_dev *dev)
> {
> + struct ixgbe_interrupt *intr =
> + IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
> + struct ixgbe_hw *hw =
> + IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> PMD_INIT_FUNC_TRACE();
>
> /* Clear interrupt mask to stop from interrupts being generated */
> IXGBE_WRITE_REG(hw, IXGBE_VTEIMC, IXGBE_VF_IRQ_CLEAR_MASK);
>
> IXGBE_WRITE_FLUSH(hw);
> +
> + /* Clear mask value. */
> + intr->mask = 0;
> }
>
> static void
> -ixgbevf_intr_enable(struct ixgbe_hw *hw)
> +ixgbevf_intr_enable(struct rte_eth_dev *dev)
> {
> + struct ixgbe_interrupt *intr =
> + IXGBE_DEV_PRIVATE_TO_INTR(dev->data->dev_private);
> + struct ixgbe_hw *hw =
> + IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> +
> PMD_INIT_FUNC_TRACE();
>
> /* VF enable interrupt autoclean */
> @@ -4974,6 +4987,9 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> IXGBE_WRITE_REG(hw, IXGBE_VTEIMS,
> IXGBE_VF_IRQ_ENABLE_MASK);
>
> IXGBE_WRITE_FLUSH(hw);
> +
> + /* Save IXGBE_VTEIMS value to mask. */
> + intr->mask = IXGBE_VF_IRQ_ENABLE_MASK;
> }
>
> static int
> @@ -5099,7 +5115,7 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
> rte_intr_enable(intr_handle);
>
> /* Re-enable interrupt for VF */
> - ixgbevf_intr_enable(hw);
> + ixgbevf_intr_enable(dev);
>
> return 0;
> }
> @@ -5113,7 +5129,7 @@ static int
> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev,
>
> PMD_INIT_FUNC_TRACE();
>
> - ixgbevf_intr_disable(hw);
> + ixgbevf_intr_disable(dev);
>
> hw->adapter_stopped = 1;
> ixgbe_stop_adapter(hw);
> @@ -5611,17 +5627,17 @@ static void ixgbevf_set_vfta_all(struct
> rte_eth_dev *dev, bool on) {
> struct rte_pci_device *pci_dev =
