DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Zhang, AlvinX" <alvinx.zhang@intel.com>
To: "Yigit, Ferruh" <ferruh.yigit@intel.com>,
	Tudor Cornea <tudor.cornea@gmail.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>
Cc: "Wang, Haiyue" <haiyue.wang@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: initialize max_rx_pkt_len if rlpml_set_vf fails
Date: Wed, 20 Oct 2021 03:08:30 +0000	[thread overview]
Message-ID: <DM6PR11MB38987BF9DE66D396BF86D20E9FBE9@DM6PR11MB3898.namprd11.prod.outlook.com> (raw)
In-Reply-To: <b2d59aa1-fea0-503a-c0b5-8ef7909b7814@intel.com>

> -----Original Message-----
> From: Yigit, Ferruh <ferruh.yigit@intel.com>
> Sent: Tuesday, October 19, 2021 8:58 PM
> To: Tudor Cornea <tudor.cornea@gmail.com>; Zhang, Qi Z
> <qi.z.zhang@intel.com>
> Cc: Zhang, AlvinX <alvinx.zhang@intel.com>; Wang, Haiyue
> <haiyue.wang@intel.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: initialize max_rx_pkt_len if
> rlpml_set_vf fails
> 
> On 10/15/2021 3:20 PM, Tudor Cornea wrote:
> > Some of our customers use ESXi 6.0 or 6.5 servers, which could have
> > older versions of the PF ixgbe driver.
> > It seems that with a more recent version of the PMD driver, we are not
> > able to initialize 82599EB ports correctly.
> > This scenario seems to have worked with DPDK 19.11.
> >
> > Would it be possible to print a warning, while still allowing the
> > driver to initialize the ports ?

There is a scenario that we initialize the port successful, with no any error, but we cannot get any packets.
So keep printing error or warning and still allowing the driver to initialize the port may be the best solution.

> >
> > I was also thinking about the return code of ixgbevf_dev_set_mtu.
> > Do you think it would be more appropriate to return ENOTSUP or ENOSYS
> > instead of EINVAL ?

If ixgbevf_dev_set_mtu fails, we have no way to know it because of invalid value or not supported?
ixgbevf_dev_set_mtu returns one the these values: 0 or IXGBE_ERR_MBX

> >
> > As a user, calling 'rte_eth_dev_mtu_set', I would expect an error like
> > EINVAL to suggest to me that the mtu value which I provided is
> > incorrect [1]. The 82599 NIC, however has some particularities related
> > to mtu, which could cause the operation to fail. I was thinking that
> > EINVAL might not be most descriptive error.
> >
> > [1] https://doc.dpdk.org/api/rte__ethdev_8h.html
> >
> > Thanks,
> > Tudor
> 
> Hi Tudor,
> 
> Can you please check if the patch is still after 'max_rx_pkt_len' related changes
> in next-net?
> 
> >
> > On Fri, 15 Oct 2021 at 17:06, Tudor Cornea <tudor.cornea@gmail.com>
> wrote:
> >
> >> It seems that if the call to ixgbevf_rlpml_set_vf fails, we will not
> >> initialize dev_conf.rxmode.max_rx_pkt_len correctly anymore.
> >>
> >> This happens with a 82599EB NIC and a VMware ESXI 6.0 setup, and is
> >> causing VF the ports to fail to initialize
> >>
> >> We see the following error:
> >> ixgbevf_dev_rx_init(): Set max packet length to 1518 failed.
> >>
> >> Investigating over DPDK 19.11, it seems that the call still fails,
> >> but it doesn't exit prematurely, and max_rx_pkt_len is initialized in
> >> the respective case.
> >>
> >> On the ESXi server, we seem to have the following driver
> >> net-ixgbe: 3.7.13.7.14iov-20vmw.600.0.0.2494585
> >>
> >> It seems that the behavior related to MTU setting has changed since
> >> the following commit:
> >>
> >> commit c77866a16904 ("net/ixgbe: detect failed VF MTU set")
> >>
> >> We would like to still be able to support older setups if possible,
> >> as we might have customers running ESXi 6.0 or 6.5, and these seem to
> >> have an older version of the PF driver as default.
> >>
> >> Signed-off-by: Tudor Cornea <tudor.cornea@gmail.com>
> >> ---
> >>   drivers/net/ixgbe/ixgbe_ethdev.c | 5 +++--
> >>   drivers/net/ixgbe/ixgbe_rxtx.c   | 1 -
> >>   2 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> >> b/drivers/net/ixgbe/ixgbe_ethdev.c
> >> index 4dbe049..4301dfd 100644
> >> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> >> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> >> @@ -6369,6 +6369,9 @@ ixgbevf_dev_set_mtu(struct rte_eth_dev *dev,
> >> uint16_t mtu)
> >>                  return -EINVAL;
> >>          }
> >>
> >> +       /* update max frame size */
> >> +       dev->data->dev_conf.rxmode.max_rx_pkt_len = max_frame;
> >> +
> >>          /*
> >>           * When supported by the underlying PF driver, use the
> >> IXGBE_VF_SET_MTU
> >>           * request of the version 2.0 of the mailbox API.
> >> @@ -6381,8 +6384,6 @@ ixgbevf_dev_set_mtu(struct rte_eth_dev *dev,
> >> uint16_t mtu)
> >>          if (ixgbevf_rlpml_set_vf(hw, max_frame))
> >>                  return -EINVAL;
> >>
> >> -       /* update max frame size */
> >> -       dev->data->dev_conf.rxmode.max_rx_pkt_len = max_frame;
> >>          return 0;
> >>   }
> >>
> >> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c
> >> b/drivers/net/ixgbe/ixgbe_rxtx.c index 0ac89cb..02d9809 100644
> >> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> >> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> >> @@ -5677,7 +5677,6 @@ ixgbevf_dev_rx_init(struct rte_eth_dev *dev)
> >>              (uint16_t)dev->data->dev_conf.rxmode.max_rx_pkt_len)) {
> >>                  PMD_INIT_LOG(ERR, "Set max packet length to %d
> failed.",
> >>
> dev->data->dev_conf.rxmode.max_rx_pkt_len);
> >> -               return -EINVAL;
> >>          }
> >>
> >>          /*
> >> --
> >> 2.7.4
> >>
> >>


  reply	other threads:[~2021-10-20  3:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15 14:06 Tudor Cornea
2021-10-15 14:20 ` Tudor Cornea
2021-10-19 12:58   ` Ferruh Yigit
2021-10-20  3:08     ` Zhang, AlvinX [this message]
2021-10-20  7:13       ` Tudor Cornea
2021-10-20  7:29         ` Wang, Haiyue
2021-10-20 18:13 ` [dpdk-dev] [PATCH v2] net/ixgbe: initialize port even if mtu config fails Tudor Cornea
2021-10-21  1:14   ` Wang, Haiyue
2021-10-21  2:54     ` Zhang, Qi Z
2021-10-21 15:33   ` Ferruh Yigit
2021-10-21 16:40     ` Tudor Cornea

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM6PR11MB38987BF9DE66D396BF86D20E9FBE9@DM6PR11MB3898.namprd11.prod.outlook.com \
    --to=alvinx.zhang@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=haiyue.wang@intel.com \
    --cc=qi.z.zhang@intel.com \
    --cc=tudor.cornea@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).