Re: [dpdk-dev] [PATCH v2 0/4] Introduce IF proxy library

[Andrzej Ostruszka <amo@semihalf.com>]

Thank you David for taking time to look at this.

On 3/25/20 9:08 AM, David Marchand wrote:
> Hello Andrzej,
> 
> On Tue, Mar 10, 2020 at 12:11 PM Andrzej Ostruszka
[...]
> I can see we end up exposing structures for registering callbacks.

Right.  I was thinking more in terms of user convenience so it seemed
like a good choice to gather them in one struct and call 'register'
once.  The fact that the same structure is used to keep them is an
implementation choice and this can be decoupled.

> Did you consider some ways to avoid exposure of those? (thinking of
> ABI maintenance for when this library will elect to non-experimental).

I will.  So far I used the union for the input since I like when things
are well typed :) and there is no need for casting.  However I will
spend some time on this and will get back to you soon (if you have
already something in your head please share).  Right now I'm thinking
about taking array of callbacks with each entry being ("event type",
callback) pair, however need to figure out how to have minimum amount of
type casting.

> I can see some canary at the end of an enum, can we do without it?

I followed discussion on the list about that and have thought about it
but deemed that to be not a problem.  This enum value is never returned
from the library and the event type enum is never taken as an input
(only used for event notification).  So this is really implementation
thing and you are right it would be better to hide it.  This might be
resolved by itself when I come up with something for the above ABI
stability issue.

> Is there a pb with merging ifpx support into the existing l3fwd
> application rather than introduce a new example?

I don't see a problem with merging per se.  That might be my
misunderstanding of what the examples are.  I thought that each library
can have its own example to show how it is supposed to be used.  So
decided to have simplified version of l3fwd  - and initially I thought
about updating l3fwd but it has some non-trivial optimizations and two
modes of operations (hash/lpm) so I wanted something simple to just show
how to use the library.  Don't know what is the reason for this
bi-modality of l3fwd:
- if this is just a need to show LPM/Hash in use then I can replace that
  with single mode of l3fwd-ifpx where LPM is used for routing and Hash
  is used to keep neighbouring info
- if this is to show that both LPM and Hash can be used for routing then
  it would complicate things as these two have different update
  properties.

I assume (but don't have a solid proof for that) that LPM can be updated
by a single writer while being used by multiple readers and use this
assumption to show how such structures can be updated (Morten please
cover your eyes ;-)) from a callback while other can be updated via
event queuing.

So if the community decides that it would be OK to morph l3fwd to:
- strip the bi-modality
- use LPM and Hash for different things (not both for routing)
then I'm OK with that and will happily do that.  Otherwise adding IFPX
to l3fwd will end up with two modes with different routing
implementation and different update strategies - a bit like two
different apps bundled into one and chosen by the command arg.

There is also a question of not having FreeBSD and Windows support yet -
so things might get complicated.

With regards
Andrzej Ostruszka