From: Ivan Malov <ivan.malov@oktetlabs.ru>
To: Rongwei Liu <rongweil@nvidia.com>
Cc: Matan Azrad <matan@nvidia.com>,
Slava Ovsiienko <viacheslavo@nvidia.com>,
Ori Kam <orika@nvidia.com>,
"NBU-Contact-Thomas Monjalon (EXTERNAL)" <thomas@monjalon.net>,
Aman Singh <aman.deep.singh@intel.com>,
Yuying Zhang <yuying.zhang@intel.com>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
"dev@dpdk.org" <dev@dpdk.org>,
Raslan Darawsheh <rasland@nvidia.com>
Subject: RE: [PATCH v1] ethdev: add direction info when creating the transfer table
Date: Thu, 15 Sep 2022 13:59:21 +0300 (MSK) [thread overview]
Message-ID: <297a487e-b5d-4928-e96-c80b2603dd8@oktetlabs.ru> (raw)
In-Reply-To: <BN9PR12MB5273E15D18360526FDD6A14AAB499@BN9PR12MB5273.namprd12.prod.outlook.com>
Hi Rongwei,
In this reply, I do not include the previous mail because the amount
of inline commentary has gone haywire over the past couple of days.
Let's re-iterate.
But before I get to that, I'd like to offer a fresh perspective:
Perhaps, if we all agree that term "vport" means an endpoint which
can stand for any "port" except for physical one, then it should
be possible to use term ANY_VPORTS rather than ANY_GUEST_PORTS.
But that's tricky, of course. I don't have a way with naming,
so more opinions are welcome and very-very desirable here.
So:
1) Do you agree that, in your proposal, the new "wire_orig" / "vf_orig"
primitives are in fact yet another match criteria?
..
To me, it looks so. If they are match criteria, then they belong
in match pattern, that is, they should be expressed as new items.
For "transfer" rules, the *existing* attributes are: "group"
and "priority". As you may note, these are clearly not match
criteria. They control the look-up order. So, to this day,
there're no match criteria in DPDK expressed as attributes.
If these "wire_orig" / "vf_orig" are going to be introduced
as attributes, that should be backed with strong motivation.
2) From your viewpoint, why items "ANY_PHYS_PORTS" and "ANY_VPORTS"
won't do? Or, which problems do you think they may inflict?
..
Previously, you explained why REPRESENTED_PORT would not
fit your needs. And I understand your point: to async API,
two pattern templates which both have item REPRESENTED_PORT
in them cannot be clearly distinguished and are in fact the
same set of criteria (provided that all other items are also
the same and have the same masks). Templates are, well,
templates (or shapes) of the rules to come later and
do not include exact "spec" for the "ethdev_id".
Got it.
But that's not going to be the case with items ANY_PHYS_PORTS and
ANY_VPORTS, is it? In one async table template, the user submits
item ANY_PHYS_PORTS (instead of table attribute "wire_orig").
In another template, the user submits item ANY_VPORTS to
state that they want to match only traffic transmitted
software endpoints (DPDK ethdevs, guest VFs, etc.)
connected to the switch.
In this example, the PMD will clearly see that the two templates
differ. So it will be able to allocate separate resources, each
one "cutting one half of traffic" (as per your concept).
3) In your most recent response, you suggested that one might have
had the attributes occupied for some other purposes. To me,
they're not. Neither me nor my closest colleagues have
any plans on them. When I advocate using item approach
over the attribute approach, I do this to ensure
a) clarity of the API contract and b) robustness.
4) Also, in your response, you suggested that I might have
confused item mask and spec. That is not the case.
If we agree, that switch domain ID is unneeded in
the new items, then these items will have no
fields in them (like item PF had not had any
before it was deprecated).
No fields in new items => no field masks.
So what's the problem then?
5) With regard to our talk about identifying the relationship
between ethdevs and switch domains, you said that the user
could know the difference from the very beginning:
/sysfs/ .... /PF_BDF/sriov_num
That is true for the user who starts the application, but
this knowledge is hard to obtain from the application
perspective = it's hard to automate.
This is why ethdevs are able to advertise their domain IDs.
And, as I explained, looking at domain ID to understand
port relationship is valid, whilst looking at proxy IDs
to achieve the same goal is not. Proxy port IDs only
serve the purpose of finding an entry point for
managing flows. That has slightly different
meaning, but this subtle difference is important.
6) As for the confusion over the difference between fixing
bugs and making the code robust by extra checks:
Yes, I agree that the programmer who writes the
application must be intelligent enough to use
flow primitives the proper way. Yes, the user
who starts the application also should thread
carefully. But that does not prevent some
mistakes in other parts of code from
corrupting various chunks of memory,
including, for example, flow attrs.
You say that such mistakes have to be "just fixed"
as any other bugs. Right. But how much time will
the programmer spend to identify the bugs?
If the PMDs do all the checks (as with attributes),
the hypothetical bug will manifest itself much
earlier. That will simplify debugging by a lot...
So, my point is that it's still better to ensure
that new flow primitives have all necessary
checks in place. For attributes, it is
required to add them separately.
For items, as I explained, it might not be necessary
in the majority of cases simply because of the
switch (item->type) { case } structure.
So, these are some of my points to explain why the
attribute approach is untenable. To me, attributes
are something global, which demands checks in all
flow-capable PMDs. Items seem better because they
are don't cares to all PMDs which are unaware of
the async concept. So, even if someone does not
implement the async concept or does not like
the new item names, they can turn a blind
eye to this - with attributes, thay can't.
Thank you.
next prev parent reply other threads:[~2022-09-15 10:59 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-07 2:40 Rongwei Liu
2022-09-11 8:22 ` Ori Kam
2022-09-12 16:57 ` Ivan Malov
2022-09-13 13:46 ` Rongwei Liu
2022-09-13 14:33 ` Ivan Malov
2022-09-14 5:16 ` Rongwei Liu
2022-09-14 7:32 ` Ivan Malov
2022-09-14 10:17 ` Rongwei Liu
2022-09-14 15:18 ` Ivan Malov
2022-09-14 21:02 ` Thomas Monjalon
2022-09-15 0:58 ` Rongwei Liu
2022-09-15 7:47 ` Ivan Malov
2022-09-15 8:18 ` Thomas Monjalon
2022-09-15 9:42 ` Ivan Malov
2022-09-15 8:48 ` Rongwei Liu
2022-09-15 10:59 ` Ivan Malov [this message]
2022-09-15 11:16 ` Thomas Monjalon
2022-09-20 9:41 ` Ori Kam
2022-09-20 12:45 ` Ivan Malov
2022-09-20 13:59 ` Ori Kam
2022-09-20 15:28 ` Ivan Malov
2022-09-21 7:34 ` Ori Kam
2022-09-21 8:39 ` Andrew Rybchenko
2022-09-21 9:04 ` Ivan Malov
2022-09-21 9:40 ` Thomas Monjalon
2022-09-21 10:04 ` Andrew Rybchenko
2022-09-21 12:41 ` Ori Kam
2022-09-21 12:51 ` Morten Brørup
2022-09-22 7:39 ` Andrew Rybchenko
2022-09-22 10:06 ` Ori Kam
2022-09-22 10:31 ` Andrew Rybchenko
2022-09-22 13:00 ` Ori Kam
2022-09-23 7:25 ` Andrew Rybchenko
2022-09-23 16:11 ` Ori Kam
2022-09-22 12:43 ` Ivan Malov
2022-09-22 14:46 ` Ori Kam
2022-09-28 9:24 ` [PATCH v3] ethdev: add hint when creating async " Rongwei Liu
2022-10-04 8:31 ` Andrew Rybchenko
2022-11-04 10:42 ` [PATCH v4] ethdev: add special flags " Rongwei Liu
2022-11-04 10:44 ` Rongwei Liu
2022-11-08 11:39 ` Andrew Rybchenko
2022-11-08 11:47 ` Andrew Rybchenko
2022-11-08 13:29 ` Thomas Monjalon
2022-11-08 14:38 ` Andrew Rybchenko
2022-11-08 15:25 ` Thomas Monjalon
2022-11-09 8:53 ` Andrew Rybchenko
2022-11-09 9:03 ` Thomas Monjalon
2022-11-09 9:36 ` Andrew Rybchenko
2022-11-09 10:50 ` Thomas Monjalon
2022-11-06 10:02 ` [PATCH v3] ethdev: add hint " Andrew Rybchenko
2022-11-07 1:58 ` Rongwei Liu
2022-11-08 9:19 ` Thomas Monjalon
2022-11-08 9:35 ` Andrew Rybchenko
2022-11-08 11:18 ` Thomas Monjalon
2022-11-08 11:48 ` Andrew Rybchenko
2022-11-14 8:47 ` [PATCH v6] ethdev: add special flags " Rongwei Liu
2022-11-14 11:59 ` [PATCH v7] " Rongwei Liu
2023-01-17 15:13 ` Ferruh Yigit
2023-01-17 17:01 ` Ferruh Yigit
2023-01-18 2:50 ` Rongwei Liu
2023-01-18 7:30 ` Andrew Rybchenko
2023-01-18 7:28 ` Andrew Rybchenko
2023-01-18 16:18 ` Thomas Monjalon
2023-02-01 10:17 ` Andrew Rybchenko
2023-02-01 10:58 ` Thomas Monjalon
2023-02-01 11:10 ` Andrew Rybchenko
2023-02-01 11:18 ` Thomas Monjalon
2023-02-01 11:38 ` Andrew Rybchenko
2023-02-01 13:48 ` Thomas Monjalon
2023-02-02 9:21 ` Andrew Rybchenko
2023-02-02 11:29 ` Thomas Monjalon
2023-02-02 12:24 ` Andrew Rybchenko
2023-02-01 11:22 ` Ori Kam
2023-02-01 11:29 ` Andrew Rybchenko
2023-02-01 11:12 ` Ori Kam
2023-02-01 11:20 ` Thomas Monjalon
2023-01-30 0:00 ` Ivan Malov
2023-01-30 2:34 ` Rongwei Liu
2023-01-30 7:40 ` Ivan Malov
2023-01-30 14:49 ` Rongwei Liu
2023-01-30 23:00 ` Ivan Malov
2023-01-31 3:06 ` Rongwei Liu
2023-01-31 5:30 ` Ivan Malov
2023-01-31 6:14 ` Rongwei Liu
2023-02-01 10:12 ` Thomas Monjalon
2023-02-01 11:50 ` Ivan Malov
2023-02-01 13:37 ` Thomas Monjalon
2023-02-01 14:04 ` Ivan Malov
2023-02-01 14:23 ` Thomas Monjalon
2023-02-01 14:29 ` Ori Kam
2023-02-02 11:19 ` [PATCH v8] ethdev: add optimization hints in flow template table Rongwei Liu
2023-02-02 11:33 ` Thomas Monjalon
2023-02-08 23:19 ` Ferruh Yigit
2022-11-09 8:11 ` [PATCH v5] ethdev: add special flags when creating async transfer table Rongwei Liu
2022-11-09 8:13 ` Rongwei Liu
2022-11-09 8:31 ` Thomas Monjalon
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=297a487e-b5d-4928-e96-c80b2603dd8@oktetlabs.ru \
--to=ivan.malov@oktetlabs.ru \
--cc=aman.deep.singh@intel.com \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=matan@nvidia.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=rongweil@nvidia.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.com \
--cc=yuying.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).