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" :)
