Hi Damjan,
Let's try again. I've spoken with a colleague here and I think
I may have misunderstood a few aspects of your proposal.
Reviewing it with him, I think we can make it work!
Let me review, and see if I understand (better) what you are
saying and proposing.
You said:
On Sun, Jan 14, 2018 at 12:10 PM, Damjan Marion (damarion) <
damar...@cisco.com> wrote:
>
> If "create memif socket file <file> id <id> [master|slave|"
> works for you i would suggest that we go that way.
>
> So scenario above will look like:
>
> master 1:
> create memif socket file /tmp/memif1.sock id 11 server
> create memif id 33 master socket-id 11
>
> Interface name: memif-11/33
>
> master 2:
> create memif socket file /tmp/memif2.sock id 22 server
> create memif id 33 master socket-id 22
>
> Interface name: memif-22/33
(OK, so my first point of misunderstanding here was that
you had two different instances of VPP, one for each master,
in this example. But that doesn't matter WRT the proposal.)
Second, I didn't realize that these were two separate API calls now.
Specifically, I now think you are saying that this command:
create memif socket file /tmp/memif1.sock id 11 server
Is a new memif API call that places the socket file name in
a table with the user-assigned id 11 associated with it.
Later, a "create memif" API call can reference "socket id 11"
as its socket, along with its memif id, (here 33), so that it
would yield the SW IF name "memif11/33".
If so, this is perfect and satisfies the naming problem that
I was describing.
> slave:
> create memif socket file /tmp/memif1.sock id 11 client
> create memif socket file /tmp/memif2.sock id 22 client
> create memif id 33 slave socket-id 11
> create memif id 33 slave socket-id 22
>
> Interface names: memif-11/33, memif-22/33
>
Right.
So. Bottom line: I think this proposal is a viable solution!
Would you like me to write a first patch effort?
Thanks,
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
