On Sun, Jan 14, 2018 at 9:36 AM, Damjan Marion (damarion) <
damar...@cisco.com> wrote:
> Jon,
>
Hi Damjan,
Thanks for answering my email!
I think there are somethings I'm not quite understanding yet,
so I have a few more questions and suggestions.
> Each memif connection between master and slave is uniquely identified
> by AF_UNIX socket and ID pair. This is first law of memif :)
>
I understand that.
> On unix side AF_UNIX socket is identified by filename in the filesystem
> but that is too long so in VPP each AF_UNIX socket have assigned file_id
> and that index is used in
> memif interface name.
>
I understand that.
> So as you described, memif interface is formatted as follows:
>
> memif-<file_id>/<interface id>
>
And I understand that.
> You cannot have 2 VPP instances listening on the same AF_UNIX socket, so
> only one VPP instance can be listener. Because of that you cannot configure
> both master and slave to use same AF_UNIX socket.
> This is simply how system works.
>
I understand UNIX. I get it.
> On other side it is perfectly fine to have one slave connected to 2
> different
> masters where both connections have same interface ID. That's why
> interface name is constructed out of 2 numbers. Having only interface_id
> in interface name will simply not work in this case.
>
This I need help understanding still.
What are the CLI commands to set this up?
create memif id 13 master socket /tmp/master-13.sock
create memif id 23 master socket /tmp/master-23.sock
create memif id 100 slave
???
I don't know how the connections are set up.
I _think_ you don't understand my issue here. I am in no way
questioning the underlying implementation, nor am I questioning
having the index-mappings that you use.
My issue is in the names that get exposed to the user and when
they become knowable.
In order to make your mechanisms work, it relies on having to reveal
or expose the names mid-setup and then proceeding with the rest
of the setup commands.
> Possible area for improvement is adding explicit "create memif listener
> <filename> <id XXX>"
>
cli and API so
> you can better control assignment mapping of file_id to actual AF_UNIX
> socket.
>
OK, that is equivalent to my third suggestion, I think. Pre-allocating the
sockets
in a known order so that they have known index numbers. In advance.
If you don't allow for the creation of the (socket-name to socket-index)
mapping in advance
of creating the memif itself, then the name of the memif effectively
becomes something
unwieldly like "memif /path/to/socket/foo.sock id 23" everywhere.
> Today file_id is simply index to the pool of memif files.
>
I know. And that is the problem. You have exposed an unreliable
allocation
result to be the only authoritative and yet unknowable user identifier.
And here
by "user" I mean any other "API user". In no way can the user say "Make an
item for me and call it <X>."
Beside that, i don't see what else we can do to make your life easier....
>
I think the problem stems from the fact that you expose the socket index
to the user visible names, and there is no way of knowing what those
values will be.
I think the whole problem can be avoid by simply exposing a memif name
with just the one id that is used during creation of the memif. From an
implementation standpoint, I think it is pretty easy to add to the current
implementation.
- Add a hash in memif_main mapping user memif id to socket_index(*)
- The uniqueness test during creation needs to be modified to check
for the id within the global mapping,
- When the memif is made, add the id to socket_index to the new hash
- When the memif is removed, remove the id from the new hash
Then only expose to the user the global memif id, and not the socket_index
too.
The user supplied the id in the first place during creation, so we satisfy
the
need to be able to say "Make a <thing> for me and call it <X>." So now
the user knows that the corresponding SW IF will be named "memif-<id>"
without having to guess or rely on API call ordering.
We had this same "naming problem" with loopback interfaces last year too,
and we had to fix aspects of that as well. Similarly, the loopback
interfaces
were just created sequentially, but the user had no idea what interface name
was actually created as a result. In order to determine that, the user must
have run some form of "inspect the results" command before further
configuration
could take place on the corresponding interface.
Just like with loopback interfaces then, we really need to have predictable
naming creation mechanisms in every aspect of the API presented by VPP.
Thanks,
> Damjan
>
Thanks,
jdl
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
