On 10/30/19 6:49 PM, Olivier Matz wrote:
Hi,
On Wed, Oct 30, 2019 at 10:35:16AM +0300, Andrew Rybchenko wrote:
@Olivier, please, take a look at the end of the mail.
(...)
On 10/29/19 8:19 PM, Slava Ovsiienko wrote:
+};
+
+/* Mbuf dynamic field offset for metadata. */ extern int
+rte_flow_dynf_metadata_offs;
+
+/* Mbuf dynamic field flag mask for metadata. */ extern uint64_t
+rte_flow_dynf_metadata_mask;
These two global variables look frightening to me.
It does not look good to me.
For me too. But we need the performance, these ones are
intended for usage in datapath, any overhead is painful.
@Olivier, could you share your thoughts, please.
Having a global variable looks unavoidable to me, if we want
performance.
An alternative can be to use static global variables in every file that
use this dynamic field, and call the register method from it. But I
don't think it would scale if a dynamic field is widely used.
Yes, I see.
Why does it look frigthening to you?
It is just a good/bad design feeling. No specific technical reasons
right now.
Let's try and take a look how it goes.
The constraint is that before using this variable, the register function
has to be called. I don't think there are race conditions, because the
field/flag registration is lock protected and always return the same
value.
