From: Jan Viktorin <viktorin@cesnet.cz>
To: Matan Azrad <matan@nvidia.com>
Cc: "Havlík Martin" <xhavli56@stud.fit.vutbr.cz>,
"Min Hu (Connor)" <humin29@huawei.com>,
"chas3@att.com" <chas3@att.com>, "dev@dpdk.org" <dev@dpdk.org>,
"Shahaf Shuler" <shahafs@nvidia.com>,
"Slava Ovsiienko" <viacheslavo@nvidia.com>
Subject: Re: [dpdk-dev] [PATCH 3/3] net/bonding: start ethdev prior to setting 8023ad flow
Date: Wed, 7 Jul 2021 17:54:20 +0200 [thread overview]
Message-ID: <20210707175420.4d81fdaf@coaster.localdomain> (raw)
In-Reply-To: <DM4PR12MB53890798F2BBC531F64D7CFADF1D9@DM4PR12MB5389.namprd12.prod.outlook.com>
On Sun, 4 Jul 2021 15:18:01 +0000
Matan Azrad <matan@nvidia.com> wrote:
> From: Havlík Martin
> > Dne 2021-06-23 09:04, Min Hu (Connor) napsal:
> > > 在 2021/6/22 17:25, Martin Havlik 写道:
> > >> When dedicated queues are enabled, mlx5 PMD fails to install RTE
> > >> Flows if the underlying ethdev is not started:
> > >> bond_ethdev_8023ad_flow_set(267) - bond_ethdev_8023ad_flow_set:
> > port
> > >> not started (slave_port=0 queue_id=1)
> > >>
> > > Why mlx5 PMD doing flow create relys on port started ?
> > > I noticed other PMDs did not has that reliance.
> > >
> > After looking into it, I really can't answer this mlx5 centered
> > question. Closest related info we found so far is the 5th point in
> > https://doc.dpdk.org/guides/prog_guide/rte_flow.html#caveats
> > but it only specifies it's the application's responsibility and
> > that flow rules are assumed invalid after port stop/close/restart
> > but doesn't say anything about <stop - flow rule create - start> vs
> > <stop - start - flow rule create> where the former is the point of
> > failure on mlx5. I'm addressing the maintainers for mlx5, who might
> > know a bit more on the topic.
>
Hello Matan,
> From rte_ethdev.h
>
> * Please note that some configuration is not stored between calls to
> * rte_eth_dev_stop()/rte_eth_dev_start(). The following
> configuration will
> * be retained:
> *
> * - MTU
> * - flow control settings
> * - receive mode configuration (promiscuous mode, all-multicast
> mode,
> * hardware checksum mode, RSS/VMDQ settings etc.)
> * - VLAN filtering configuration
> * - default MAC address
> * - MAC addresses supplied to MAC address array
> * - flow director filtering mode (but not filtering rules)
> * - NIC queue statistics mappings
just after this section, you can find the following statement:
* Any other configuration will not be stored and will need to be re-entered
* before a call to rte_eth_dev_start().
It is not very clear how is this exactly related to flows (and this
applies for all the quoted section, I think) but at least it can be used
as a counter argument.
>
>
> Mlx5 assumes flows are allowed to be configured only after
> rte_eth_dev_start(). Before start \ after stop - no flow is valid
> anymore.
I believe that this discussion is not about validity of flows. Let the flows
be invalid after calling to rte_eth_dev_stop(). This is OK, flows must be
recreated and the bonding driver works this way. But why not *before start*?
Does somebody know how other drivers behaves in this situation? (We know and
can check for Intel, there it does not seem to be an issue.)
By the way, the mlx5 behaviour opens a (probably short) time window
between starting of a port and configuation of filtering flows. You may
want to start the port with thousands of flows that apply just when the
port starts (not after, that's late). This may introduce glitches in
filtering and measuring of traffic (well, it is a question how serious
issue could it be...).
This matters for the bonding case as well, doesn't it?. It is not
desirable to accidently omit a packet that was received by primary
ingress logic instead of being redirected into the dedicated queue.
Are there any chances that for mlx5 it would be possible to insert flow
rules before calling rte_eth_dev_start? Anyway, the behaviour should be
specified and documented in DPDK more precisely to avoid such
uncertainty in the future.
Jan
>
> Matan
>
> > >> Signed-off-by: Martin Havlik <xhavli56@stud.fit.vutbr.cz>
> > >> Cc: Jan Viktorin <viktorin@cesnet.cz>
> > >> ---
> > >> drivers/net/bonding/rte_eth_bond_pmd.c | 26
> > >> ++++++++++++++++++--------
> > >> 1 file changed, 18 insertions(+), 8 deletions(-)
> > >>
> > >> diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
> > >> b/drivers/net/bonding/rte_eth_bond_pmd.c
> > >> index a6755661c..fea3bc537 100644
> > >> --- a/drivers/net/bonding/rte_eth_bond_pmd.c
> > >> +++ b/drivers/net/bonding/rte_eth_bond_pmd.c
> > >> @@ -1818,25 +1818,35 @@ slave_configure(struct rte_eth_dev
> > >> *bonded_eth_dev,
> > >> rte_flow_destroy(slave_eth_dev->data->port_id,
> > >>
> > >> internals-
> > >mode4.dedicated_queues.flow[slave_eth_dev->data->port_id],
> > >> &flow_error);
> > >> + }
> > >> + /* Start device */
> > >> + errval = rte_eth_dev_start(slave_eth_dev->data->port_id);
> > >> + if (errval != 0) {
> > >> + RTE_BOND_LOG(ERR, "rte_eth_dev_start: port=%u, err
> > >> (%d)",
> > >> + slave_eth_dev->data->port_id,
> > >> errval);
> > >> + return -1;
> > >> + }
> > >> +
> > >> + if (internals->mode == BONDING_MODE_8023AD &&
> > >> + internals->mode4.dedicated_queues.enabled
> > >> == 1)
> > >> + {
> > >> errval = bond_ethdev_8023ad_flow_set(bonded_eth_dev,
> > >> slave_eth_dev->data->port_id);
> > >> if (errval != 0) {
> > >> RTE_BOND_LOG(ERR,
> > >> "bond_ethdev_8023ad_flow_set:
> > >> port=%d, err (%d)", slave_eth_dev->data->port_id, errval);
> > >> +
> > >> + errval =
> > >> rte_eth_dev_stop(slave_eth_dev->data->port_id);
> > >> + if (errval < 0) {
> > >> + RTE_BOND_LOG(ERR,
> > >> + "rte_eth_dev_stop: port=%d,
> > >> err (%d)",
> > >> +
> > >> slave_eth_dev->data->port_id, errval);
> > >> + }
> > >> return errval;
> > >> }
> > >> }
> > >> - /* Start device */
> > >> - errval = rte_eth_dev_start(slave_eth_dev->data->port_id);
> > >> - if (errval != 0) {
> > >> - RTE_BOND_LOG(ERR, "rte_eth_dev_start: port=%u, err
> > >> (%d)",
> > >> - slave_eth_dev->data->port_id,
> > >> errval);
> > >> - return -1;
> > >> - }
> > >> -
> > >> /* If RSS is enabled for bonding, synchronize RETA */
> > >> if (bonded_eth_dev->data->dev_conf.rxmode.mq_mode &
> > >> ETH_MQ_RX_RSS) {
> > >> int i;
> > >>
next prev parent reply other threads:[~2021-07-07 15:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 9:25 [dpdk-dev] [PATCH 0/3] net/bonding: make dedicated queues work with mlx5 Martin Havlik
2021-06-22 9:25 ` [dpdk-dev] [PATCH 1/3] net/bonding: fix proper return value check and correct log message Martin Havlik
2021-07-08 12:33 ` Min Hu (Connor)
2021-07-13 9:26 ` Andrew Rybchenko
2021-06-22 9:25 ` [dpdk-dev] [PATCH 2/3] net/bonding: fix not checked return value Martin Havlik
2021-07-08 12:43 ` Min Hu (Connor)
2021-07-08 13:20 ` Havlík Martin
2021-07-09 0:09 ` Min Hu (Connor)
2021-07-13 9:26 ` Andrew Rybchenko
2021-06-22 9:25 ` [dpdk-dev] [PATCH 3/3] net/bonding: start ethdev prior to setting 8023ad flow Martin Havlik
2021-06-23 7:04 ` Min Hu (Connor)
2021-06-24 11:57 ` Havlík Martin
2021-07-04 15:18 ` Matan Azrad
2021-07-07 15:54 ` Jan Viktorin [this message]
2021-07-11 8:49 ` Ori Kam
2021-07-11 21:45 ` Jan Viktorin
2021-07-12 13:07 ` Ori Kam
2021-07-13 8:18 ` Havlík Martin
2021-07-13 9:26 ` Andrew Rybchenko
2021-07-13 11:06 ` Jan Viktorin
2021-07-13 17:17 ` Ori Kam
2021-07-14 15:00 ` Jan Viktorin
2021-07-15 13:58 ` Thomas Monjalon
2021-08-24 13:18 ` Ferruh Yigit
2021-08-26 10:15 ` Jan Viktorin
2021-07-04 15:03 ` [dpdk-dev] [PATCH 0/3] net/bonding: make dedicated queues work with mlx5 Andrew Rybchenko
2021-09-25 6:15 [dpdk-dev] [PATCH 3/3] net/bonding: start ethdev prior to setting 8023ad flow Havlík Martin
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=20210707175420.4d81fdaf@coaster.localdomain \
--to=viktorin@cesnet.cz \
--cc=chas3@att.com \
--cc=dev@dpdk.org \
--cc=humin29@huawei.com \
--cc=matan@nvidia.com \
--cc=shahafs@nvidia.com \
--cc=viacheslavo@nvidia.com \
--cc=xhavli56@stud.fit.vutbr.cz \
/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).