On 11/5/19 7:37 PM, Ori Kam wrote: > > >> -----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.
It would make it too strictly dependent on pattern/actions/state. >> 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" If so, what application author should do if even maintainers cannot formalize it. It sounds like the approach does not work. >> 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. I'm afraid it is not always true. >> Andrew. > > Ori >
