> From: Dumitrescu, Cristian [mailto:cristian.dumitre...@intel.com] > Sent: Monday, 25 September 2023 13.52 > > Hi Ori, > > Will implement your comments and send the V2 straight away. Answers inline. > > > From: Ori Kam <or...@nvidia.com> > > Sent: Thursday, September 21, 2023 5:39 PM > > > > Hi Cristian, > > > > > From: Cristian Dumitrescu <cristian.dumitre...@intel.com> > > > Sent: Friday, September 15, 2023 10:00 PM > > > > > > This patch introduces the new "program" action type to enable flow API > > > support for P4-programmable devices. > > > > > > In the case of P4-programmable devices, the device is initially blank. > > > The flow items and actions are defined by the user (outside of any > > > vendor control) through the P4 program, which is typically compiled > > > into firmware that is loaded on the device at init time. These flow > > > items and actions are then used during the run-time phase to add flows > > > on the device. > > > > > > Signed-off-by: Cristian Dumitrescu <cristian.dumitre...@intel.com> > > > Signed-off-by: Qi Zhang <qi.z.zh...@intel.com> > > > ---
[...] > > > +struct rte_flow_action_prog_argument { > > > + /** Argument name. */ > > > + const char *arg_name; > > > > Maybe uint32 id? > > The reason for having the argument name also specified here is purely related > to > allowing the control plane to specify the action arguments in a potentially > different > order than in the P4 program, or to skip some arguments, implying a default > value > to be used for these arguments. > > Since the arguments have a string identifier in the P4 program, we kept a > string > name here for this reason. Having a numerical ID would imply the position of > the > argument within the argument list in the P4 program, which is IMO less useful. Having an index would imply the position within the argument list. However, an ID is more like an enum, and does not imply any position. The application would probably need to treat the possible string values like enum values anyway. In other words: It's not really a string, it's an enum represented by a string. So we might as well represent it by an integer type (uint32_t). > > I agree we can remove this name, but then we lose the ability explained above. > Therefore, I am going to keep this for now, in case you agree with my > explanation, > But we can remove it if you're strongly against it. Intuitively, a numerical ID seems easier and faster to handle than a string. I don’t feel strongly about this. And I'm not really involved with RTE_FLOW or P4, so not really qualified. ;-)