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? 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. Also this will enforce the PMD to keep track on all flows which will have memory penalty for some PMDs.
