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

["Morten Brørup" <mb@smartsharesystems.com>]

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Andrzej Ostruszka
> Sent: Thursday, January 16, 2020 10:10 AM
> 
> 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.

Yes, it is beyond the scope of the library; but I prefer the library to be designed for how typical applications are going to use it.

I suggest that you supplement the library with an example DPDK application that is a simple IPv4 router, forwarding packets and responding to ARP requests - according to its configuration applied in the O/S via your proxy library. You could even add support for relevant ICMP packets (e.g. respond to ICMP Echo Request and send TTL Exceeded when appropriate). It will help you determine what is required by the library, and how the library best interfaces to a "typical" DPDK application.

> 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.
> 

I think a poll based design pattern is more appropriate. Getting a Netlink message from the O/S and converting it to a callback in the library, and then converting it back to a message in the DPDK application seems like crossing the river to get water.

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

It was a bitmap of wanted callbacks. I only skimmed the source code, so I'm probably wrong about this. Forget I mentioned 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