Hi

-----Original Message-----
From: Andrew Rybchenko <redacted>
Sent: Wednesday, October 6, 2021 11:38 AM
data

On 10/6/21 11:30 AM, Thomas Monjalon wrote:

quoted

05/10/2021 13:11, Andrew Rybchenko:

quoted

On 10/5/21 1:10 PM, Ori Kam wrote:

quoted

From: Andrew Rybchenko <redacted>

quoted

On 10/5/21 12:41 PM, Ori Kam wrote:

quoted

From: Andrew Rybchenko <redacted>

quoted

On 10/5/21 11:17 AM, Ori Kam wrote:

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

quoted

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

We have MARK, FLAG, and META.
MARK and FLAG are the same just one of them give predefined value.
we should merged those two for sure.
META allows the application to get more bits from the HW.
Like I said above I think we should merge everything.
but this is a talk for a different thread, and different time.

Ori