-----Original Message-----
From: Andrew Rybchenko <arybche...@solarflare.com>
Sent: Thursday, September 17, 2020 9:50 AM
On 9/16/20 8:21 PM, Gregory Etelson wrote:
From: Gregory Etelson
Sent: Tuesday, September 15, 2020 13:27
To: Andrew Rybchenko <arybche...@solarflare.com>; Ajit Khaparde
<ajit.khapa...@broadcom.com>
Cc: dpdk-dev <dev@dpdk.org>; Matan Azrad <ma...@nvidia.com>; Raslan
Darawsheh <rasl...@nvidia.com>; Ori Kam <or...@nvidia.com>; Gregory
Etelson <getel...@mellanox.com>; Ori Kam <or...@mellanox.com>; NBU-
Contact-Thomas Monjalon <tho...@monjalon.net>; Ferruh Yigit
<ferruh.yi...@intel.com>
Subject: RE: [dpdk-dev] [PATCH v2 1/4] ethdev: allow negative values in flow
rule types
Subject: Re: [dpdk-dev] [PATCH v2 1/4] ethdev: allow negative values in flow
rule types
On 9/15/20 7:36 AM, Ajit Khaparde wrote:
On Tue, Sep 8, 2020 at 1:16 PM Gregory Etelson
<mailto:getel...@nvidia.com> wrote:
From: Gregory Etelson <mailto:getel...@mellanox.com>
RTE flow items & actions use positive values in item & action type.
Negative values are reserved for PMD private types. PMD
items & actions usually are not exposed to application and are not
used to create RTE flows.
The patch allows applications with access to PMD flow
items & actions ability to integrate RTE and PMD items & actions
and use them to create flow rule.
While we are reviewing this, some quick comment/questions..
Doesn't this go against the above "PMD
items & actions usually are not exposed to application and are not
used to create RTE flows."?
Why would an application try to use PMD specific private types?
Isn't this contrary to having a standard API?
+1
I would like to clarify the purpose and use of private elements patch.
That patch is prerequisite for [PATCH v2 2/4] ethdev: tunnel offload model
patch.
The tunnel offload API provides unified hardware independent model to
offload tunneled packets,
match on packet headers in hardware and to restore outer headers of
partially offloaded packets.
The model implementation depends on hardware capabilities. For example,
if hardware supports inner nat,
it can do nat first and postpone decap to the end, while other hardware that
cannot do inner nat must decap first
and run nat actions afterwards. Such hardware has to save outer header in
some hardware context,
register or memory, for application to restore a packet later, if needed. Also,
in this case the exact solution
depends on PMD because of limited number of hardware contexts.
Although application working with DKDK can implement all these
requirements with existing flow rules API,
it will have to address each hardware specifications separately.
To solve this limitation we selected design where application quires PMD for
actions, or items,
that are optimal for a hardware that PMD represents. Result can be a
mixture of RTE and PMD private elements -
it's up to PMD implementation. Application passes these elements back to
PMD as a flow rule recipe
that's already optimal for underlying hardware.
If PMD has private elements in such rule items or actions, these private
elements must not be rejected by RTE layer.
I hope it helps to understand what this model is trying to achieve.
Did that clarify your concerns ?
There is a very simple question which I can't answer after
reading it.
Why these PMD specific actions and items do not bind
application to a specific vendor. If it binds, it should
be clearly stated in the description. If no, I'd like to
understand why since opaque actions/items are not really
well defined and hardly portable across vendors.
