On Sun, Jul 5, 2020 at 3:56 PM Ori Kam <or...@mellanox.com> wrote: > > Hi Jerin, > PSB, > > Thanks, > Ori > > > -----Original Message----- > > From: Jerin Jacob <jerinjac...@gmail.com> > > Sent: Saturday, July 4, 2020 3:33 PM > > dpdk-dev <dev@dpdk.org> > > Subject: Re: [dpdk-dev] [PATCH] add flow shared action API > > > > On Sat, Jul 4, 2020 at 3:40 PM Andrey Vesnovaty > > <andrey.vesnov...@gmail.com> wrote: > > > > > > > > > Thanks, > > > > > > Andrey Vesnovaty > > > (+972)526775512 | Skype: andrey775512 > > > > > > [..Nip ..] > > > > I need to mention the locking issue once again. > > > If there is a need to maintain "shared session" in the generic rte_flow > > > layer > > all > > > calls to flow_create() with shared action & all delete need to take > > sharedsession > > > management locks at least for verification. Lock partitioning is also bit > > problematic > > > since one flow may have more than one shared action. > > > > Then, I think better approach would be to introduce > > rte_flow_action_update() public > > API which can either take "const struct rte_flow_action []" OR shared > > context ID, to cater to > > both cases or something on similar lines. This would allow HW's > > without have the shared context ID > > to use the action update. > > Can you please explain your idea?
I see two types of HW schemes supporting action updates without going through call `rte_flow_destroy()` and call `rte_flow_create()` - The shared HW action context feature - The HW has "pattern" and "action" mapped to different HW objects and action can be updated any time. Other than above-mentioned RSS use case, another use case would be to a) create rte_flow and set the action as DROP (Kind of reserving the HW object) b) Update the action only when the rest of the requirements ready. Any API schematic that supports both notions of HW is fine with me. > As I can see if we use the flow_action array it may result in bugs. > For example, the application created two flows with the same RSS (not using > the context) > Then he wants to change one flow to use different RSS, but the result will > that both flows > will be changed. Sorry. I don't quite follow this. > Also this will enforce the PMD to keep track on all flows which will have > memory penalty for > some PMDs.
