On 14 Jan 2018, at 19:51, Jon Loeliger <[email protected]<mailto:[email protected]>> wrote:
On Sun, Jan 14, 2018 at 12:10 PM, Damjan Marion (damarion) <[email protected]<mailto:[email protected]>> wrote: master 1: create memif id 33 master socket /tmp/memif1.sock Interface name: memif-0/33 Here! You know that because you had to look at "show int" or "show memif". What if earlier allocations of memif had happened to create a new socket? You don't know the "0" part of that name unless you look. Or rely on a very specific API call sequence ordering. master 2: create memif id 33 master socket /tmp/memif2.sock Interface name: memif-0/33 No, it is a new socket, and a new pool index, so this one is named "memif1/33". And *that* is precisely the problem I am having to prevent here. this is first socket on master2 so it is 0. Also, there are no dashes in these names despite your using them with me on every example you have sent me. not big deal... vpp# create memif id 33 master socket /tmp/memif1.sock vpp# show memif interface memif0/33 id 33 mode ethernet file /tmp/memif1.sock flags listener-fd 28 conn-fd 0 num-s2m-rings 0 num-m2s-rings 0 buffer-size 0 vpp# create memif id 33 master socket /tmp/memif2.sock vpp# vpp# show memif interface memif0/33 id 33 mode ethernet file /tmp/memif1.sock flags listener-fd 28 conn-fd 0 num-s2m-rings 0 num-m2s-rings 0 buffer-size 0 interface memif1/33 id 33 mode ethernet file /tmp/memif2.sock flags listener-fd 29 conn-fd 0 num-s2m-rings 0 num-m2s-rings 0 buffer-size 0 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 No. vpp# create memif id 33 slave socket /tmp/memif1.sock create memif: Interface with same id already exists not sure what are you talking about here... > 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. No, I don't think it does limit anything like that. The underlying implementation can remain the same, and the connection set ups can remain. It's just the name of the interface that gets created is in a single global namespace like "memif%d". I think you are pretty much confused here. interface_id is unique interface identifier for specific unix socket listener. So if slave connects to 2 master vpp instances, both masters can have same id. > 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. I'm not able to use the CLI, so I want to see the API form. Like I said, I think this means that we effectively name the memif by its (full socket path name, id) pair all the time. It's really the wrong approach. i disagree Fundamentally, the user should never need to have the "socket" aspect of the underlying implementation exposed to him. Call it anything else and you'll see what I mean. Say, "grouping", so that we place various masters and slaves into the same "grouping". sounds like you want to break fisrt law of memif here and i'm not fine with that. Interface_id is unique per listener, and it should stay like that. So scenario above will look like: master 1: create memif socket file /tmp/memif1.sock socket-id 11 server Note, I added "socket-" here ----------------^^^^ As i said before, i'm nor fine with single id in the interface name, but if my proposal works for you and if you are willing to contribute patch, I can review and merge.
_______________________________________________ vpp-dev mailing list [email protected] https://lists.fd.io/mailman/listinfo/vpp-dev
