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.
