DPDK patches and discussions
 help / color / mirror / Atom feed
From: Tudor Cornea <tudor.cornea@gmail.com>
To: "Zhang, AlvinX" <alvinx.zhang@intel.com>
Cc: "Yigit, Ferruh" <ferruh.yigit@intel.com>,
	"Zhang, Qi Z" <qi.z.zhang@intel.com>,
	 "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 10:13:20 +0300	[thread overview]
Message-ID: <CAOuQ8vXgSRmqMDU205AD44wY-7F6nwCXkXQ2xU6NLALB1fNBqQ@mail.gmail.com> (raw)
In-Reply-To: <DM6PR11MB38987BF9DE66D396BF86D20E9FBE9@DM6PR11MB3898.namprd11.prod.outlook.com>

Hi Ferruh,

I have tested with the dpdk-next-net branch.
It includes the commit 'ethdev: fix max Rx packet length'

Setup:
Hypervisor: VMware ESXi 6.0.0
PF ixgbe Driver: 3.7.13.7 (default PF driver installed with ESXi 6.0 and
6.5)
NIC: Intel 82599
Guest OS : Ubuntu 20.04

It seems that with the recent changes testpmd still can't initialize the
ports.

EAL: Detected CPU lcores: 8
EAL: Detected NUMA nodes: 1
EAL: Detected static linkage of DPDK
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket
EAL: Selected IOVA mode 'PA'
EAL: No available 1048576 kB hugepages reported
EAL: VFIO support initialized
EAL: Probe PCI driver: net_ixgbe_vf (8086:10ed) device: 0000:0b:00.0
(socket 0)
EAL: Probe PCI driver: net_ixgbe_vf (8086:10ed) device: 0000:13:00.0
(socket 0)
TELEMETRY: No legacy callbacks, legacy socket not created
Interactive-mode selected
previous number of forwarding ports 2 - changed to number of configured
ports 1
Error picking flow transfer proxy for port 0: Function not implemented -
ignore
Error picking flow transfer proxy for port 1: Function not implemented -
ignore
testpmd: create a new mbuf pool <mb_pool_0>: n=171456, size=2176, socket=0
testpmd: preferred mempool ops selected: ring_mp_mc

Warning! port-topology=paired and odd forward ports number, the last port
will pair with itself.

Configuring Port 0 (socket 0)
ixgbevf_dev_rx_init(): Set max packet length to 1518 failed.
ixgbevf_dev_start(): Unable to initialize RX hardware (-22)
Fail to start port 0: Invalid argument
Configuring Port 1 (socket 0)
ixgbevf_dev_rx_init(): Set max packet length to 1518 failed.
ixgbevf_dev_start(): Unable to initialize RX hardware (-22)
Fail to start port 1: Invalid argument
Please stop the ports first
Done
Error during enabling promiscuous mode for port 0: Operation not supported
- ignore
Error during enabling promiscuous mode for port 1: Operation not supported
- ignore
testpmd> start tx_first
Not all ports were started

I think failing to set set 'max_rx_pkt_len' after ixgbevf_rlpml_set_vf()
call failed in ixgbevf_dev_set_mtu(), might have been one half of the
problem.
The other one is in ixgbevf_dev_rx_init(). The init function seems to
return prematurely, and not initialize the ports.

With the below patch (on top of net-next branch), I seem to be able to
initialize the ports correctly, and send packets using testpmd.

diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index b263dfe1d5..fdd057c789 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -5676,7 +5676,6 @@ ixgbevf_dev_rx_init(struct rte_eth_dev *dev)
        if (ixgbevf_rlpml_set_vf(hw, frame_size) != 0) {
                PMD_INIT_LOG(ERR, "Set max packet length to %d failed.",
                             frame_size);
-               return -EINVAL;
        }

        /*

Alvin, would it be acceptable to not return -EINVAL in this case while
still printing an error, so that we can still debug mtu issues on 82599 ?

If I recall correctly, the NIC has issues when the MTU of VFs is bigger
than the MTU of the PFs. On my setup, however the MTUs have default values
(1500).
Should I rebase the patch on top of net-next ?

Thanks,
Tudor

On Wed, 20 Oct 2021 at 06:08, Zhang, AlvinX <alvinx.zhang@intel.com> wrote:

> > -----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  7:13 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
2021-10-20  7:13       ` Tudor Cornea [this message]
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=CAOuQ8vXgSRmqMDU205AD44wY-7F6nwCXkXQ2xU6NLALB1fNBqQ@mail.gmail.com \
    --to=tudor.cornea@gmail.com \
    --cc=alvinx.zhang@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=haiyue.wang@intel.com \
    --cc=qi.z.zhang@intel.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).