> -----Original Message----- > From: Andrew Rybchenko <arybche...@solarflare.com> > Sent: Tuesday, November 5, 2019 1:31 PM > To: Ori Kam <or...@mellanox.com>; Thomas Monjalon > <tho...@monjalon.net> > Cc: dev@dpdk.org; pbhagavat...@marvell.com; ferruh.yi...@intel.com; > jer...@marvell.com; John McNamara <john.mcnam...@intel.com>; Marko > Kovacevic <marko.kovace...@intel.com>; Adrien Mazarguil > <adrien.mazarg...@6wind.com>; david.march...@redhat.com; > ktray...@redhat.com > Subject: Re: [dpdk-dev] [PATCH 1/2] ethdev: add flow action type update as an > offload >
[Snip] > > > > Yes but like I said in Mellanox PMD for example we supported the mark only > on non-transfer flows until this release. > > so when the user set mark on transfer flow it was invalid. (in transfer > > flow if > we have a miss we send the packet back to the Rx > > port so the application can understand on which table the miss happened) > > In this version we added the support for mark also in transfer (E-Switch) > flows. > > So my question before this release what should the PMD report? What should > the PMD report after this release? > > > > Your idea was our first thought when adding the Tx meta, in that case the > meta was always set in application > > so we thought that this offload will enable us better function selection, > > but as > you know we removed this capability > > since it is not correct any more. > > > > > > > >> The above also highlights problems of the meta vs mark design. They are > very > >> similar and there is no any good definition of the difference and rules > >> which > >> one should be used/supported in which conditions. > >> > > > > Mark and Meta are exactly the same, the meta is just another value that the > application can use. > > This is why both should act the same. > > > > And maybe this is the wining argument, the rte_flow validation approach was > used and accepted for the meta. > > So lets try it also with the mark. (please also remember that we didn't have > this mark until now to somehow the > > PMD worked 😊) > > > > Like I said before, I understand your approach, and each one of them has its > own advantages and draw backs. > > Lets start using the rte_flow approach and see how it goes, I promise you > > that > if I see that it doesn't scale or cause more > > issues I will be first one to submit changes. > > I tend to say OK, let's try. However, it must be documented > in MARK action that if an application wants to use it, a rule > with the action must be validated before device start. I agree to add this to the rte_flow mark action documation. > PMD may use the attempt as an indication from the application > that it would like to use flow mark even if the validation > fails. No if the PMD uses this validation as hint it should return success and use the correct PMD. Ori, please, suggest formalized pattern and actions > specification to use if application wants to utilize > validation result as a criteria to enable/disable flow > marks usage. I can’t do that, it depends on the application, the most basic is just "pattern eth actions mark / queue" . In some cases where you need it for E-Switch if should be something like "transfer items port / eth / actions mark" > What should be done if patterns to use and set > of actions together with MARK are not known in advance. I think that the application knows which kind of traffic it expects and which actions it needs. > Andrew. Ori
