> 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.
Tunnel Offload API does not bind application to a vendor. One of the main goals of that model is to provide application with vendor/hardware independent solution. PMD transfer to application an array of items. Application passes that array back to PMD as opaque data, in rte_flow_create(), without reviewing the array content. Therefore, if there are internal PMD actions in the array, they have no effect on application. Consider the following application code example: /* get PMD actions that implement tunnel offload */ rte_tunnel_decap_set(&tunnel, &pmd_actions, pmd_actions_num, error); /* compile an array of actions to create flow rule */ memcpy(actions, pmd_actions, pmd_actions_num * sizeof(actions[0])); memcpy(actions + pmd_actions_num, app_actions, app_actions_num * sizeof(actions[0])); /* create flow rule*/ rte_flow_create(port_id, attr, pattern, actions, error); vendor A provides pmd_actions_A = {va1, va2 …. vaN} vendor B provides pmd_actions_B = {vb1} Regardless of pmd_actions content, application code will not change. However, each PMD will receive exact, hardware related, actions for tunnel offload.