> > 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.
master 1: create memif id 33 master socket /tmp/memif1.sock Interface name: memif-0/33 master 2: create memif id 33 master socket /tmp/memif2.sock Interface name: memif-0/33 slave: create memif id 33 slave socket /tmp/memif1.sock create memif id 33 slave socket /tmp/memif2.sock Interface names: memif-0/33, memif-1/33 > > 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. I dont like this proposal, it adds another ID to the game or limits us for using same id on 2 different socket files. > > 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. 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 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 _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
