On 10/13/2021 9:32 AM, Dmitry Kozlyuk wrote:
This thread continues discussions on previous versions
to keep everything in the thread with final patches:
[1]:
http://inbox.dpdk.org/dev/d5673b58-5aa6-ca35-5b60-d938e56cf...@oktetlabs.ru/
[2]:
http://inbox.dpdk.org/dev/dm8pr12mb5400997ccec9169ac5ae0c89d6...@dm8pr12mb5400.namprd12.prod.outlook.com/
Please see below.
-----Original Message-----
From: Dmitry Kozlyuk <dkozl...@nvidia.com>
Sent: 5 октября 2021 г. 3:52
To: dev@dpdk.org
Cc: Dmitry Kozlyuk <dkozl...@nvidia.com>; Ori Kam <or...@nvidia.com>; NBU-
Contact-Thomas Monjalon <tho...@monjalon.net>; Ferruh Yigit
<ferruh.yi...@intel.com>; Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
Subject: [PATCH 2/5] ethdev: add capability to keep shared objects on
restart
From: Dmitry Kozlyuk <dkozl...@nvidia.com>
rte_flow_action_handle_create() did not mention what happens with an
indirect action when a device is stopped, possibly reconfigured, and
started again. It is natural for some indirect actions to be persistent,
like counters and meters; keeping others just saves application time and
complexity. However, not all PMDs can support it.
It is proposed to add a device capability to indicate if indirect actions
are kept across the above sequence or implicitly destroyed.
In the future, indirect actions may not be the only type of objects shared
between flow rules. The capability bit intends to cover all possible types
of such objects, hence its name.
It may happen that in the future a PMD acquires support for a type of
shared objects that it cannot keep across a restart. It is undesirable to
stop advertising the capability so that applications that don't use
objects of the problematic type can still take advantage of it.
This is why PMDs are allowed to keep only a subset of shared objects
provided that the vendor mandatorily documents it.
If the device is being reconfigured in a way that is incompatible with an
existing shared objects, PMD is required to report an error.
This is mandatory, because flow API does not supply users with
capabilities, so this is the only way for a user to learn that
configuration is invalid. For example, if queue count changes and RSS
indirect action specifies queues that are going away, the user must update
the action before removing the queues or remove the action and all flow
rules that were using it.
Signed-off-by: Dmitry Kozlyuk <dkozl...@nvidia.com>
---
[...]
Current pain point is that capability bits may be insufficient
and a programmatic way is desired to check which types of objects
can be kept across restart, instead of documenting the limitations.
I support one of previous Ori's suggestions and want to clarify it [1]:
Ori: "Another way is to assume that if the action was created before port start it
will be kept after port stop."
Andrew: "It does not sound like a solution. May be I simply don't know
target usecase."
What Ori suggests (offline discussion summary): Suppose an application wants to check whether a shared object
(indirect action) or a flow rule of a particular kind. It calls rte_flow_action_handle_create() or
rte_flow_create() before rte_eth_dev_start(). If it succeeds, 1) it means objects of this type can be kept
across restart, 2) it's a normal object created that will work after the port is started. This is logical,
because if the PMD can keep some kind of objects when the port is stopped, it is likely to be able to create
them when the port is not started. It is subject to discussion if "object kind" means only
"type" or "type + transfer bit" combination; for mlx5 PMD it doesn't matter. One minor
drawback is that applications can only do the test when the port is stopped, but it seems likely that the
test really needs to be done at startup anyway.
If this is acceptable:
1. Capability bits are not needed anymore.
2. ethdev patches can be accepted in RC1, present behavior is undefined anyway.
3. PMD patches will need update that can be done by RC2.
Hi Dmitry,
Are you planning to update drivers yourself on -rc2?
Or do you mean PMD maintainers should update themselves, if so do they
know about it?
If the ethdev layer is updated in a way to impact the drivers, it should
be either:
- all drivers updated with a change
or
- give PMDs time to implement it on their own time, meanwhile they can report
their support status by a flag
We had multiple sample of second case in the past but it is harder for
this case.
For this case what about having three states:
- FLOW_RULE_KEEP
- FLOW_RULE_DESTROY
- FLOW_RULE_UNKNOWN
And set 'FLOW_RULE_UNKNOWN' for all drivers, to simulate current status,
until driver is updated.
