Re: [dpdk-dev] [PATCH v2 1/4] lib: introduce IF Proxy library

[Thomas Monjalon <thomas@monjalon.net>]

09/07/2020 10:43, Andrzej Ostruszka [C]:
> First of all let me thank you all one again for the time you took 
> looking at this and summarize your feedback as I understand it.
> 
> 1. Don't use interrupt thread because in heavy load scenarios this might 
> cause problems.

Yes
For this usage, and for other configuration controls like log/trace,
we should have a new communication channel.
The telemetry and IPC are other examples of communication channels.
Ideally we should keep only one channel.

> 2. Provide higher level functionality - so that application can just use 
> it instead of maintaining the info on their own.

As said below, higher layers can come later.

> 3. Provide way to have control over the changes - if I remember 
> correctly someone wanted apps to be able to reject the changes (meaning 
> rolling back the changes to the kernel)

Yes, the DPDK app must remain in control of any change.

> 4. Don't parse netlink on your own (use e.g. libmnl)
> 5. Don't use callbacks

Not sure about which communication API to use. It must be discussed.


> These are the specific things that I managed to understand.  Have I 
> missed anything?  If so please add this to the list!
> 
> To that I say:
> Ad1. Agree, will change that.
> Ad2. OK, but this can be added later.
> Ad3. Currently the lib was meant to be one way but as in previous point 
> this can change in the future.
> Ad4. As mentioned in previous mail I judged it not worthy of adding 
> dependency but I'm OK with using it.  This might be more relevant when 
> we address point 3 and can be introduced then, but I can do it now.

No problem with adding dependencies, especially with meson.

> Ad5. There are now notification queues and I'm fine with adapting to any 
> standard of notification/communication that DPDK will agree on.
> 
> In addition may I ask your opinion on the changes that are required 
> before the library can be accepted?

Very few contributors take time to look at it.
Clearly we want this feature. We really want it,
but we are not able to dedicate enough time for its review (blaming myself).
That's why I Cc the techboard to try a new process:

For such feature requiring a community design,
and not having enough feedback to progress in a timely manner,
I propose drafting the design in a Technical Board meeting
(a regular or specific one).