From: Thomas Monjalon <thomas@monjalon.net>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: Matan Azrad <matan@mellanox.com>, "dev@dpdk.org" <dev@dpdk.org>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH 10/11] net/failsafe: fix sub-device ownership race
Date: Wed, 09 May 2018 15:43:31 +0200 [thread overview]
Message-ID: <10613870.Sdbp1i1ck2@xps> (raw)
In-Reply-To: <20180509133013.yxy66njakty2g7y2@bidouze.vm.6wind.com>
09/05/2018 15:30, Gaëtan Rivet:
> On Wed, May 09, 2018 at 01:01:58PM +0000, Matan Azrad wrote:
> > Hi Gaetan
> >
> > Regarding backporting.
> > This version should be bacported for 18.02.1.
> > There we have the new event.
> >
>
> Then the fixline should probably reflect this instead.
> Targetting the initial failsafe release won't work.
>
> This patch also relies on probing_finish() being introduced, so I guess
> the plan is to backport the whole series in 18.02.1?
Yes, I will provide a backported series for 18.02.
> If so, I think the whole series should target the same commit id within
> this release, maybe the introduction of ownership or RTE_ETH_EVENT_NEW.
>
> In any case, I think I recall being told to leave this to stable
> maintainers to deal with. However, I do not see the benefit of having
> a fixline if the information is meant to be discarded for someone to do
> the work again.
The information in the Fixes line shows where the bug was introduced.
It is used to do our backports (to know if a fix is relevant)
but it can be used for other purposes like identifying known issues
in a given version.
So, in short, these bugs can be fixed easily in 18.02, but probably not
worth to backport in older releases (no 17.11 backport).
> > Regarding uint32
> > The maximum port id number can be 0xffff.
> > In this case the loop will be infinite if we use uint16 to iterate over all the ports.
>
> If RTE_MAX_ETHPORTS is set to 0xffff, an array rte_eth_devices[0xffff]
> would be defined statically, and I think other issues would arise
> before our being stuck in an infinite loop?
>
> In any case, if this had to be fixed, then there should be a
> BUILD_BUG_ON RTE_MAX_ETHPORTS being 0xffff, in the relevant part of
> librte_ethdev, instead of relying on librte_ethdev users skirting
> shortfalls of the library. Anyone iterating on port IDs should expect the
> port_id type to be sufficient to hold this information.
Interesting thought.
I vote for keeping Matan's option as it is correct,
and will accept a patch in 18.08 for your option (BUILD_BUG_ON).
Maybe we should send a deprecation notice before limiting the max
number of ports to 0xfffe? Or is it ridiculous for such unlikely constraint?
next prev parent reply other threads:[~2018-05-09 13:43 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180509094337.26112-1-thomas@monjalon.net>
2018-05-09 9:43 ` [dpdk-stable] [PATCH 01/11] ethdev: fix debug log of owner id Thomas Monjalon
2018-05-09 17:53 ` Ferruh Yigit
2018-05-09 9:43 ` [dpdk-stable] [PATCH 02/11] net/failsafe: fix sub-device visibility Thomas Monjalon
2018-05-09 12:13 ` [dpdk-stable] [dpdk-dev] " Gaëtan Rivet
2018-05-09 9:43 ` [dpdk-stable] [PATCH 04/11] drivers/net: use higher level of probing helper for PCI Thomas Monjalon
2018-05-09 17:54 ` [dpdk-stable] [dpdk-dev] " Ferruh Yigit
2018-05-09 9:43 ` [dpdk-stable] [PATCH 05/11] ethdev: add probing finish function Thomas Monjalon
2018-05-10 20:18 ` [dpdk-stable] [dpdk-dev] " Stephen Hemminger
2018-05-09 9:43 ` [dpdk-stable] [PATCH 06/11] ethdev: allow ownership operations on unused port Thomas Monjalon
2018-05-09 18:00 ` [dpdk-stable] [dpdk-dev] " Ferruh Yigit
2018-05-09 19:05 ` Thomas Monjalon
2018-05-10 20:26 ` Stephen Hemminger
2018-05-09 9:43 ` [dpdk-stable] [PATCH 07/11] ethdev: add lock to port allocation check Thomas Monjalon
2018-05-09 12:21 ` [dpdk-stable] [dpdk-dev] " Gaëtan Rivet
2018-05-10 20:35 ` Stephen Hemminger
2018-05-10 20:33 ` Stephen Hemminger
2018-05-10 22:10 ` Thomas Monjalon
2018-05-10 22:29 ` Stephen Hemminger
2018-05-09 9:43 ` [dpdk-stable] [PATCH 08/11] ethdev: fix port visibility before initialization Thomas Monjalon
2018-05-09 18:03 ` Ferruh Yigit
2018-05-09 19:08 ` Thomas Monjalon
2018-05-10 20:40 ` [dpdk-stable] [dpdk-dev] " Stephen Hemminger
2018-05-10 22:18 ` Thomas Monjalon
2018-05-09 9:43 ` [dpdk-stable] [PATCH 09/11] ethdev: fix port probing notification Thomas Monjalon
2018-05-09 18:07 ` Ferruh Yigit
2018-05-09 19:13 ` Thomas Monjalon
2018-05-09 9:43 ` [dpdk-stable] [PATCH 10/11] net/failsafe: fix sub-device ownership race Thomas Monjalon
2018-05-09 12:41 ` [dpdk-stable] [dpdk-dev] " Gaëtan Rivet
2018-05-09 13:01 ` Matan Azrad
2018-05-09 13:30 ` Gaëtan Rivet
2018-05-09 13:43 ` Thomas Monjalon [this message]
2018-05-09 14:03 ` Gaëtan Rivet
2018-05-09 13:26 ` Thomas Monjalon
2018-05-09 9:43 ` [dpdk-stable] [PATCH 11/11] ethdev: fix port removal notification timing Thomas Monjalon
2018-05-09 18:07 ` Ferruh Yigit
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=10613870.Sdbp1i1ck2@xps \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
--cc=matan@mellanox.com \
--cc=stable@dpdk.org \
/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).