Re: [dpdk-dev] [RFC PATCH 0/3] introduce IF proxy library

[Andrzej Ostruszka <amo@semihalf.com>]

On 1/15/20 7:15 PM, Morten Brørup wrote:
[...]
> OK, you convinced me that a general API for interfacing to the O/S
> control plane might be useful.

Glad to hear that.

[...]
> You should consider that most DPDK APIs are not thread safe,
> meaning that their internal structures cannot be manipulated/reconfigured
> by a control plane thread while data plane threads are accessing them.
> E.g. a route cannot be added in the DPDK route library while it is also
> being used by for lookups by a DPDK data plane thread. The same goes
> for the hash table library.

You are thinking already about modification of the application data.
That is actually beyond the scope of the library.  The intention of the
library is to provide with notification of a change.  It is meant to be
the task of the callback (provided by the user) to act on the change.
It can store the change to be picked up at the next packet burst
iteration, or use some RCU synchronization or even stop the world and
push the change (if the writer of application deems that appropriate).

> This means that callbacks are probably not the right design pattern.

What are other possibilities?  The library could keep "copy" of the
interesting configuration and periodically update it and mark the
changes to let application notice.  But that would be inefficient - I
would have to query all data to check for the diff.  So I think the
callback is the right design - we get only changes.  However please note
above explanation, that it is up to application writer to provide
callback that would fit design of the application and in cooperation
with it will move the network config change into internal data structures.

> Furthermore, I have now skimmed the other parts of your patch set.
> If I got it right, it looks like there's a limit of 64 callbacks;
> this will probably not suffice in the long run.

This is interesting.  What has given you that impression?  I'm really
curious since I've written it :).  There is a limit on a number of
proxies (but this is the same as limit on DPDK ports - so not really a
limitation of this lib).  BTW since this is a slow path, and I don't
need a fast access I keep proxies in a list, so that only those active
have allocated memory.

Each type of callback is just a member of rte_ifpx_callbacks struct -
and yes, as you previously noted, this struct will grow with additional
functionality added, but there is no real limit on it.  At the moment
callbacks are meant to be global - there is a list of callback sets
(ifpx_callbacks) that is common for all proxies.

I expect that the most common use will be just one set of callbacks for
application.  But instead of having just one global var I keep a list of
sets so many can be registered.  There are other options possible:
- each type of callback can be a list
- callbacks could be "per proxy" - meaning that each proxy port could
  have its own callbacks

The first one could be beneficial if user wants many callbacks
registered for some particular type of notification and is not
interested in others.
The second one can be useful if different proxies should be treated
differently - in that case one could avoid conditionals in callback
switching behaviour depending on the proxy used.

But again this kind of uses are not what I expect as a common use case
so I went with current design.

> And on the administrative side, I assume one of you guys will volunteer
> as the maintainer of this library?

Yes.

With regards
Andrzej Ostruszka