On 10/6/21 11:30 AM, Thomas Monjalon wrote: > 05/10/2021 13:11, Andrew Rybchenko: >> On 10/5/21 1:10 PM, Ori Kam wrote: >>> From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> >>>> On 10/5/21 12:41 PM, Ori Kam wrote: >>>>> From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru> >>>>>> On 10/5/21 11:17 AM, Ori Kam wrote: >>>>>>> One more thing, I think this flag should be added now since you need >>>>>>> it, I think you should report that you don't support it. >>>>>>> since just like we talked there is no real difference between metadata >>>>>>> and >>>> MARK. >>>>>>> What do you think? >>>>>> >>>>>> It sounds like a trick :) Negative support is *not* a support in >>>>>> fact. DPDK policy requires support of a feature in a PMD and in-tree >>>>>> application. Of course, it is not a problem to add meta. It is really >>>>>> easy to do. I just don't want to add it in >>>>>> v5 to be deleted in v6 because of my above concerns. >>>>>> >>>>> This was not a trick. I understand what you are saying. >>>>> if we say that metadata is the same as mark, (I think we all agree on >>>>> it) and that application need to notify pmd about such operations, I >>>>> assume it will try to see how to request the metadata. >>>> >>>> Frankly speaking I feel sick when I think about META and MARK together. Do >>>> we really need both in DPDK? >>>> >>> I realy don't want you the be sick, >>> The resoun that we need both of them is that 32 in Nvidia it is only 24 >>> bits of mark is not >>> enough, so there is a need for more bits. >>> I think that in the end we will go to something much more generic that the >>> application >>> will just say how many bits it wants to get and this what he will get. >>> for example the application may say it needs 128 bits and it will register >>> this size to the mbuf >>> or give in the mbuf pointer two where those values should be set. >>> In any case as you can see we have already to many changes in rte_flow in >>> this release and the >>> next one, but I'm planning to push this feature in the future >>> what do you think of such a feature? >> >> I agree that there are really many changes in flow API which >> are on review in the release cycle. >> I hope the above idea will allow to merge MARK and META. > > I agree we should merge mark and meta in a common dynamic mbuf field. > What do we need in mark which is not in meta? > I think dynamic mbuf field of meta is the way to go but I prefer the name > "mark" :) >
+1 but I don't have answer to the question
